Comments on v.98 specification

[Prasad Yendluri <pyendluri@webmethods.com>]

Folks,

First, I would like to echo Chris's comments of appreciation of the hard work that has gone into producing this version of the specification. It shows! Here are a few comments from me.

Thanks, Prasad

1. The normative natures of the specification and the schema needs to be stated explicitly and clearly. Based on other email exchanges today, it was clarified that the "Schema" in the appendix-A provides the normative definition of the ebXML SOAP-Extension elements; and the specification part specifies where in the SOAP Envelope the top level elements belong. This could be accomplished by adding text to clarify this in the introductory part of Appendix-A.
2. Additionally, there are other aspects of the specification that the schema can not still capture.  For example, the semantic interdependency of elements (and attributes). That is, an optional element/attribute in the schema could be a required one when another element or semantic requirement calls for it. E.g. RefToMessageId is REQUIRED for Error messages (see: 503-504)
3. We need a statement on which one, the Schema or the specification part supersedes in case of an inconsistency between the two.
4. The SOAP specification calls for SOAP-Fault with different faultcode values for a variety of errors. Should  we be returning a SOAP-Fault for such errors? For example when MustUnderstand is '1' on an ebXML header and the receiver can not handle it. Perhaps more importantly errors that fall into the "Client" faultcode category. If an ebXML header element is  formed  incorrectly or did not contain a valid value from the receiver perspective etc.?
5. Do we still want to keep the references to the non-existent ebXML Service Interface? E.g. See lines 3-5; 91-92.
6. Lines 262-264: The words "MIME parameters" is being used loosely here. We do mean "MIME Headers" here.
7. Lines 269-272: Does this mean, even when the MIME processors fails, one should look in the message for who the sender is and send an error response? The use of MUST may not be appropriate here. It may not be feasible to adhere to this.
8. Lines 354-359:  To be compliant with the SOAP specification, I believe this needs to result in SOAP-Fault with a faultcode of "MustUnderstand". Now do we want to call for the Error element as described in addition to the above?
9. Lines 412-415: Who reports this Error? MSH? If not, how does the receiving party report this, especially when the "From" PartyId is not formed well?
10. Section 8.5.2 (lines 425-437): The error response behavior when the receiving party can not resolve the CPAId in the message, needs to be defined.
11. Section 8.5.3: There is no uniqueness specification on ConversationId. I think it is desirable to call for a unique values within the From/To PartyId pairs.
12. Section 8.5.5: Error behavior for missing or inconsistent Action element or Action element with value not understood by the receiving party needs to be defined.
13. Section 8.5.6.3 (lines 499-509): This makes the RefToMessageId element not a REQUIRED one for all but Error, Acknowledgment and Status messages. Is this intentional or MUST all messages that have an earlier related messages (e.g. all messages except the first one in a conversation), have this element with a valid value? Additionally could the RefToMessageId span conversations?
14. Section 8.5.7.1: This description should state that all messages in a conversation shall have the same messageOrderSemantics. That is some of the messages can not set to "Guaranteed" and others "NotGuaranteed".
15. Section 8.5.7.1 (2): Are the sequence numbers managed / updated by both parties in the conversation? Please clarify.
16. Line 574: The "MUST" is applicable only when the messageOrderSemantics is equal to "Guaranteed".
17. Line 586: Is "zero" a valid value for an implementation defined limit for saved out-of-sequence messages?
18. Lines 589-596: The From and To party keep flipping back and forth, especially in a conversation that has large number of messages exchanged. This description needs to be tightened up to clarify what is the "From Party" here.
19. Lines 601-607: Can both From and To parties reset the sequence number? Here, by From party I mean the party that initiated the conversation.
20. Section 8.6.3 TraceHeader:  It is not clear who is populating the TraceHeader entries. Is it the MSH at each node that the message passes through? Is the MSH supposed to check for looping etc.?
21. Section 8.8.2 (lines 883-884): So, we send a SOAP-Fault back on an ebXML Error element that is not understood? What is the purpose? What is the receiver of the SOAP-Fault supposed to do with it?
22. Section 10.2.2: This should not be here anymore unless the name is changed to BatchReply or something. SyncReply in now only in the Via element (section 8.7).