Message Structure Specification ver 0-1, 8/8/00

[mwsachs@us.ibm.com]

*************************************************************************************

IBM T. J. Watson Research Center
P. O. B. 704
Yorktown Hts, NY 10598
914-784-7287;  IBM tie line 863-7287
Notes address:  Martin W Sachs/Watson/IBM
Internet address:  mwsachs @ us.ibm.com
*************************************************************************************
---------------------- Forwarded by Martin W Sachs/Watson/IBM on 08/13/2000
11:56 PM ---------------------------

Martin W Sachs
08/12/2000 12:50 AM

To:   dick@8760.com
cc:   Ebxml <ebxml-transport@lists.ebxml.org>
From: Martin W Sachs/Watson/IBM@IBMUS
Subject:  Message Structure Specification ver 0-1, 8/8/00  (Document link:
      Martin W. Sachs)

I have a few comments on TPAInfo.  I will submit other comments later.

   Please add an explanation of the context attribute (what it is used for)
   in tpaId and conversationId.

   The conversation ID should be able to be a rapid locator in the message
   service at each party.  Assuming that a URI has a particular structure,
   it is not obvious that this would always be suitable as a rapid locator.
   If I am correct, the message service at each party should be free to
   supply the identifier in whatever form is appropriate for its
   implementation.  (see the next comment regarding global uniqueness).

   In order to be a rapid identifier for each message service while being
   globally unique, the conversation ID should contain two elements.  One
   is the conversationId supplied by the initiator of the conversation.
   The other is the conversationID supplied by the other party. When a
   message arrives, the receiving message service uses "it's own"
   conversationID element to locate the conversation state information. The
   following protocol can be used for the conversation ID (I believe that
   this description is normative):
     When a party sends the initial request of a conversation, it inserts
     the conversation ID that it created into the initiator conversation ID
     element and leave the other one with a defined null value, probably a
     blank character.
     When the other party sends the first (or only) response to the first
     request (including an exception response if needed), it inserts the
     initiator conversation ID into its element and adds its own
     conversation ID in the other conversation ID element. From then on,
     each message within the conversation carries both conversation IDs.
     Thus, each messaging service has its own rapid locator for
     conversation state.  Because each messaging service has its own
     conversation ID element, there are no restrictions on how the values
     of the two elements relate.  The two messaging services are not
     required to recognize the same value;  the values of the two elements
     may be either the same or different.  Each may use any data type that
     is permitted in a #PCDATA value.

   One concern:  A binary value is often desirable for a rapid locator
   since the state information may be in main memory.  I don't have an XML
   book with me so I am not sure if a binary value is acceptable as the
   value of a tag.  If there is some definition which permits a binary
   value, that is preferable for the conversation ID and perhaps for the
   message ID as well.

Regards,
Marty



*************************************************************************************

IBM T. J. Watson Research Center
P. O. B. 704
Yorktown Hts, NY 10598
914-784-7287;  IBM tie line 863-7287
Notes address:  Martin W Sachs/Watson/IBM
Internet address:  mwsachs @ us.ibm.com
*************************************************************************************



Dick Brooks <dick@8760.com> on 08/10/2000 03:27:28 AM

Please respond to dick@8760.com

To:   Ebxml <ebxml-transport@lists.ebxml.org>
cc:
Subject:  New and improved (merged) TR&P specifications for your reading
      pleasure





Dick Brooks
Group 8760
110 12th Street North
Birmingham, AL 35203
dick@8760.com
205-250-8053
Fax: 205-250-8057
http://www.8760.com/

InsideAgent - Empowering e-commerce solutions