Re: Of Bank Tellers...

[dick@8760.com]

David,

I have a few questions (inline) to help me understand how the bank teller
metaphor relates to TR&P concepts.


----- Original Message -----
From: David RR Webber <Gnosis_@compuserve.com>
To: ebXML Transport <ebXML-Transport@lists.oasis-open.org>
Sent: Saturday, June 17, 2000 12:01 PM
Subject: Of Bank Tellers...


> Question?
>
> The 'mail room' model I understand and the use of MIME in the
> context of supporting low-tech interfaces.
>
> However, this is not my interchange model (or not the one I'm
> wanting to use), so has any thought been given to the
> 'bank teller' model?  If so - what's the schedule, and current
> executive strategy?

The TR&P group is developing a set of specifications that will allow
implementers to choose the "communication and processing model" (simplex - a.k.a
one-way, RPC, async messaging) that best fits their needs.  The 'mail room'
model is only one of the design patterns possible with the TR&P specs.

>
> Even though I'm calling it 'bank teller' don;t get misled - I'm
> seeing this primarily as a point-of-service for secure
> information interchange - not a money transaction model.
>
> Here's what I define properties of the bank teller model and
> consequently how it differs from the 'mail room'.
>
> 1) Face-to-face service in real time.
>

Does this correlate to "B2B", "A2A" concepts or something else? I think of B2B
as the "transport level exchange" and A2A as the "application level exchange".

> 2) Provision of service items, not just exchange of 'packages'.
>

The TR&P specs permit the use of null payloads. This allows implementers to
request execution of a service (e.g. RPC) using ONLY data contained in the ebxml
header.

> 3) Channels - ie. depending on who I am, I get to do/see/go to
>      different things.
>

This relates  to security/authorization which is an area of work that is pending
within the ebXML TR&P group. I believe the TR&P folks will need to work with
architecture folks to determine the security model to use within ebXML.

> 4) Safe deposit model
>

Could you provide more detail, I don't know what you mean by "safe deposit
model"? Are you referring to "secure connections"?

> 5) Sets of actors - employees, customers, new customers,
>       trusted third parties (Brink et al).
>

This also falls into the area of security/authentication and the notion of
"roles" and "proxies". This item is also dependant on the security model.


> 6) Direct connection via internet -
>      i.e. http - server/server and client/server query response model.
>

The TR&P specs make no assumptions nor impose any requirements that would
prevent a user from using either dedicated or part-time Internet connections.

> Now I realize that electronic money transfers are already
> covered by OTP and SWIFT - supplemental question -
> instead of re-inventing that wheel, do we just endorse OTP for
> e-money???
>
> OK - just to help clarify this further here's the sort of  XML
> interchange model I'm after seeing for this bank teller model,
> where you have some Access authnetication and Verb (what do I
> want to do / service to provide?), then some Input criteria, and
> optionally some Output criteria.   Both Input and Output may have
> a schema associated with them, and or, a driver process script.
> (simple URL suffices here to point to appropriate item).

A significant number of your comments relate to the design of ebXML headers.
There is a meeting this July in Boston to discuss "headers" I think you should
consider attending.

Thanks,

Dick Brooks
http://www.8760.com/



=======================================================================
= This is ebxml-transport, the general mailing list for the ebXML     =
= Transport project team. The owner of this list is                   =
= owner-ebxml-transport@oasis-open.org                                =
=                                                                     =
= To unsubscribe, send mail to majordomo@lists.oasis-open.org with    =
= the following in the body of the message:                           =
=      unsubscribe ebxml-transport                                    =
= If you are subscribed using a different email address, put the      =
= address you subscribed with at the end of the line; e.g.            =
=      unsubscribe ebxml-transport myname@company.com                 =
=======================================================================