comments on Messaging Service Specification v0-1, Aug. 10, 2000

[mwsachs@us.ibm.com]

1. Introduction, 1st paragraph

line 100-101: Please delte "ebXML message headers" since the headers are
part of the structure specified in this document.

line 103:  "Agnostic" means "skeptical about the existence of God".  The
religious meaning is the only definition in Webster's Third International
Dictionary.  I know that "agnostic" is starting to be used as "neutral" or
something similar.  Please see that the glossary contains a definition of
"agnostic" appropriate to its use here.

   I am agnostic about the possibility of maintaining  complete
   agnositicisma about the transport once the reliable messaging
   specification is incorporated into (or referenced by) the Message
   Service Specification because choices of operating parameters for
   reliable messaging will depend on the low level transport (this relates
   to ACKs and message latency introduced by reliable messaging).  I have
   submitted detailed comments on this against the reliable messaging
   document.

2.2  Transport Envelope

In general, I do not fully understand these paragraphs and therefore cannot
suggest specific improvements for the following comments. Improvments and
clarifications are needed.

Line 184-5:  I don't understand what the "standard transport level
envelopes are".  If this refers to the standard headers defined by HTTP,
FTP, SMTP, etc., have all transport envelopes places to put the identity of
a specific ebXML handler?

Line 187:  Please explain "such structures" and when the transport envelope
is required.  If the transport envelope is really the HTTP, SMTP, FTP etc.
header, then it is always required.  This sentence seems to imply that the
transport envelope is in fact something else.  What is it?

Line 188-189:  "A transport envelope is not needed for FTP".  FTP must have
some kind of headers so again, there is an implication that the transport
envelope is something else.

(Light comes on):  Is "Transport Envelope" supposed to be "Message
envelope"?  But if so, why is it not needed for FTP?

2.3.1.2  boundary Attribute

Line 210-211:  This specification should specify a boundary string that
cannot occur in the content area of a body part.  If there is not such a
unique string, then this specification should have some discussion
(informative?) of how to select an appropriate string for a given message.

2.5.1  Content ID

Line 300: I believe that the words "identifies the instance of an ebXML"
should be deleted.

2.6  Message Digest Computation

I cannot find anything in this document indicating where the message digest
goes.

line 344:  I believe that some words are missing at the end of this line.

3.  Message Header

Line 373:  The word "MAY" on this line (two instances of it) is not being
used in the RFC2119 sense.  Please remove the capitalization.

3.1  Root Element

Line 383:  Please replace "transport-specific" by
"message-service-specific".  Please scrub the document of any remaining
instance of "transport" which really refer to the messaging service.

3.3.1  From and To

Line 458-460:  More discussion of the context attribute is needed.  At a
minimum, the following sentence should be added following the sentence
ending on line 459:

   The context attribute identifies the set of identifiers from which the
   value of PartyId is derived.  It may either identify a standard set of
   identifiers such as DUNS numbers or may be a keyword which identifies
   non-standard identifiers agreed to by the partners who are exchanging
   ebXML messages.

As a possible implementation convenience, the specification may list a set
of identifier standards, but users should retain the option to define their
identifiers privately between two partners to a business relationship.

3.3.2  TPAInfo

(I have made some of these points previously, I am repeating some material
here to have everything in one place.)

Line 374, TPAId:  Each partner should be able to select its own value of
TPAId in order to use it as a local rapid locator.  Please provide "To" and
"From" subelements for TPAId.

   NOTE:  In general, either ConversationID or TPAId should be able to be a
   rapid locator.  For a specific implementation, it is probably not
   necessary to use both as rapid locators since, for example, TPAId can be
   part of the state of the conversation (locate the conversation state,
   then locate the TPAID).  In the interest of implementation flexibility,
   we should permit either or both to be rapid locators.

Line 374, TPAId:  Please add text explaining the meaning of the context
attribute in TPAId.

Line 376, ConversationId:  Please add text explaining the meaning of the
context attribute on ConversationID.

Line 376, 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.
   The messaging 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 subelements.
   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.

     Rather than define "initiator" and "other" subelements, "From" and
     "To" could be used as follows:  For the first message of a
     conversation, the sender of the message puts its conversation ID in
     the From element.  When the other party sends a response message, it
     puts its conversation ID in the "From" element and the other party's
     conversation ID in the "To" element.  From then on, both conversations
     IDs are supplied in every message but each one alternates between
     "From" and "To", depending on the direction of the message.

   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.

   There has been a lot of discussion about what the conversation is for.
   Here is a rudimentary use case:

     A conversation is a group of messages between the two partners (A and
     B) which represents a unit of business such as issuing and processing
     a purchase order.  One execution of a RosettaNet PIP is a good example
     of a conversation.

     The conversation is established with a signal on the (as yet
     undefined) interface between BP and the Messaging Service when a
     partner sends the first message of a conversation.

     The conversation is terminated at Partner A with a signal on the
     interface between BP and the Messaging Service when Partner A sends
     the last message of the conversation.  Generally, this message will be
     a response to the last message received from Partner B. When Partner B
     receives and processes that message, it then signals its messaging
     service to terminate the conversation, via the BP-Messaging Service
     API.

     I am considering that the messaging service is involved because an
     implementation such as the IBM Research prototype run-time uses the
     conversation ID for routing and also maintains the conversation logs
     needed for recovery and audit.  Whether or not this is architecturally
     part of the messaging service, these functions should be provided by
     middleware to the business process level and therefore the
     conversation Id is needed in the message header.

Line 378,  ServiceInteface: Please state that the value of the
ServiceInterface tag is stated in the TPA.

Line 381,  Action:  Please state that the action name is defined in the
TPA.

   NOTE:  In the IBM Research prototype run-time, a TPA object is created
   at each party from the contents of the TPA and local registration
   information.  Among other things, the TPA object maps the action names
   in the messages to the local method calls.

3.3.3  MessageData

Line 497, MessageId: MessageId does not have to be globally unique.  At
most, it has to be unique between a pair of partners who have a business
relationship.  It should be unacceptable to have to go to a global
repository to obtain a message Id for each message to be sent.  I believe
that the message Id has to be unique only within the messaging service of
the "From" party.  The value of MessagId should be allowed to be
implementation-defined as a rapid locator for finding the message when a
response arrives.  The message which resulted in the response is idnetified
in RefToMessageId.  The receiving party can and probably should save the
message ID in its conversation state information for later reference.

Line 497, MessageId: Please add a discussion of the attribute called for in
the DTD and add the attribute to the example.

Line 501, RefToMessageId:  RefToMessageId has to state which party created
the referred-to message.  This provides the necessary uniqueness within the
pair of parties, assuming my proposed definition of MessageId above.
Please create a tag structure which provides the use of PartyId to identify
the issuer of the referred-to message, such as

   <RefToMessage>
      <RefToMessageId>....</RefToMessageId>
      <PartyID context=...>...</PartyId>
      </RefToMessage>

Line 501, RefToMessageId:  Please add a discussion of the attribute called
for in the DTD and add the attribute to the example. UUID is a default
value of the attribute, not the message ID.

Line 508 and 510:  Please use different message ids in these example for
MessageId and RefToMessageID.

3.3.4  ReliableMessagingInfo

Line 516:  Please delete the word "subordinate".  An attribute is part of
the tag.

Line 517:  Please remove the capitalization from "MAY".  It is not being
used here in the RFC2119 sense.

Please give an example of this tag.

4. Security Considerations

Line 523:  Please provide a normative reference to Realm Security.

Line 524:  Please provide a normative reference to SSL.

5.  References

Line 528:  Please change the title to "Normative Referneces".  Any
informative references should go in a separate section.

Line 537:  Please add the title of RFC 2111.

Please add a reference to XML 1.0.

Please add a reference to the MIME RFC.

Please add references to any other standards referred to in the text.

6.  Acknowledgments

Is this list complete to date?

Regards,
Marty



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

   Martin W. Sachs
   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
   *************************************************************************************