[ebxml-msg] Comments on the 1.09 draft

Attached is a marked up copy of the 1.09 draft with comments from me and Michael Wang.

I have also copied the Comments section of the Word document to the body of this message. The contexts of these comments can be found in the attached zipped Word document (using the View Comments menu option). The ones in red are minor technical issues that may require some discussions.

-Arvola

Page: 2
Will be.

Page: 2
April.

Page: 4
Strike out “This section”. None of the other bullets use a complete sentence.

Page: 4
Should end with a period?

Page: 4
Add SyncReply.

Page: 4
Strike ths out. Sounds very repetitious.

Page: 5
Insert “XML schema definition” before [XMLSchema] reference. In general, I would recommend against using a bracketed reference as the object of a sentence.

Page: 5
Capitalize.

Page: 5
Replace with “security service profiles”.

Page: 5
Replace with “Profile/Agreement”

Page: 6
Replace with “—“

Page: 6
Strike out this word.

Page: 6
Be consistent about having or not having a space before the open square bracket within this document. I actually prefer having a space before the square bracket.

Page: 7
Replace with “the received ebXML message is syntactically correct”.

Page: 7
Shouldn’t this be singular?

Page: 8
Use parentheses instead of square brackets.

Page: 8
Implementations.

Page: 8
Into the following.

Page: 8
This bullet is not consistent with the figure. The latter indicates “Encryption and/or Digital Signatures”.

Page: 8
Inconsistent notation.

Page: 9
Inconsistent notation.

Page: 9
Replace with “The first”.

Page: 10
Replace with “zero or more additional MIME parts”.

Page: 10
Inconsistent notation.

Page: 10
Has.

Page: 10
I suggest the following clarification: “Implementation MUST support non-multipart messages, which may occur when there are no ebXML payloads. That is, an ebXML message with no payload may be sent either as a plain SOAP message or as a [SOAPATTACH] multipart message with only one body part.” Otherwise, the sentence may be mis-interpreted as “non-multipart messages must be used whenever there are no payloads”. That would contradict the example in section 9.1.

Page: 11
Replace with “simple plain-text objects”.

Page: 12
Incorrect hard-coded reference. Should point to section 1.3.2.

Page: 13
Incorrect hard-coded reference. Should point to section 2.2.1.

Page: 14
Perhaps this should be replaced with “…/msg-header-1_1.xsd” now.

Page: 14
Ditto.

Page: 14
The right hand side of the assignment has to be enclosed in double quotes.

Page: 14
Ditto.

Page: 15
It should be pointed out that ErrorList and Signature are SOAP Header extensions. As such, they should appear before SOAP Body extensions.

Page: 15
Or a warning.

Page: 15
Replace with “…/msg-header-1_1.xsd”.

Page: 16
The keyword MUST is not appropriate. In “extreme cases”, the version may be set to something other than “1.1”.

Page: 16
Replace with “The value urn:oasis:names:tc:ebxml-msg:actor:nextMSH when used in the context of the SOAP actor attribute”. We voted on replacing “service” with “actor”.

Page: 16
Replace with “The value urn:oasis:names:tc:ebxml-msg:actor:toPartyMSH when used in the context of the SOAP actor attribute”. We voted on replacing “service” with “actor”.

Page: 17
Contains.

Page: 17
Element contains.

Page: 17
Element.

Page: 17
Replace with a symbolic link.

Page: 18
I think this paragraph is confusing. It kind of suggests that when no real CPA is used, the reliable messaging parameters may come from the message header itself.

Page: 18
I think our current position is that message header parameters must not conflict/override their CPA counterparts.

Page: 18
The detection of inconsistency should be a mandatory requirement.

Page: 20
I think this should be the time by which a message is received by the To Party MSH. The receiving application may actually process the message at a time greater than TimeToLive.

Page: 20
This contradicts the immediately following explanation.

Page: 21
Add space before dash.

Page: 21
Ditto.

Page: 24
Replace “it” with “the ds:Transform element”.

Page: 24
Canonicalize.

Page: 25
Container(s).

Page: 25
Relate.

Page: 25
I don’t see why this should be strongly recommended.

Page: 27
Are.

Page: 27
A SOAP Fault message.

Page: 27
Or warning.

Page: 27
And/or warning(s).

Page: 30
What about the following discussions found earlier in section 4: “It is possible for the ebXML MSH software to cause a SOAP fault to be generated and returned to the sender of a SOAP Message. In this event, the returned message MUST conform to the [SOAP] specification processing guidelines for SOAP Faults.”?

Page: 31
Replace this with “neither”.

Page: 32
Replace with “same HTTP connection”.

Page: 32
The fixed value.

Page: 32
In the CPA.

Page: 33
Or At-Least-Once.

Page: 33
I suggest striking out this paragraph. What alternative to a persistent store can be used for duplicate detection?

Page: 33
The bullets are not properly formatted.

Page: 33
Ditto.

Page: 34
Ditto.

Page: 34
Should specify whether an error or a warning is to be returned when there are more than two AckRequested elements.

Note that both a StatusRequest element and an Acknowledgment element may be present in the same SOAP envelope, without there being any payload. In that case, are we forbidding the StatusRequest from being sent reliably? It would have been simpler had we decided that all standalone MSH level messages are to be sent BestEffort only.

Page: 35
For a standalone Acknowledgment message.

Page: 35
Improper formatting of bullet.

Page: 35
Should an error or a warning be returned if there are more than two Acknowledgment elements?

Page: 36
This is not a proper sentence.

Page: 36
Improper formatting of bullets.

Page: 36
Replace with “duplicateElimination”.

Page: 36
If AckRequested is not set, retry will not happen!

Page: 37
Replace with “duplicateElimination”

Page: 37
This does not sound correct.

Page: 37
This parameter comes from the CPA!

Page: 37
Should be (Retries + 1).

Page: 37
This parameter comes from the CPA!

Page: 38
This discussion is confusing. There is no SyncReplyMode paramter in the message header. Instead, there is a syncReply attribute in the QualityOfServiceInfo element.

Page: 38
Strike this out.

Page: 38
This is not correct. Only one AckRequested element can be inserted. It can be targeted to the nextMSH or to the toPartyMSH.

Page: 38
If it does not arrive before RetryInterval has elapsed.

If the Acknowledgment message is signed and there is one or more ds:Reference elements within the Acknowledgment element, then the digest information contained in these ds:Reference elements ought to be compared against the digest information in the original message. However, given the rule that an error is not supposed to be generated due to any error in the Acknowledgment element, it is not clear what is the appropriate course of action.

Page: 39
Has been safely stored. This kind of contradicts (1) above which indicates that storing the entire received message persistently is optional. I think (1) is wrong.

Page: 39
Capitalize. Replace ‘see’ with ‘See’.

Page: 39
I think the Acknowledgment message, if bundled with an application response message, must be persisted before being sent. This point needs to be clarified in section 7.5.3.

Page: 39
Replace with ‘message’.

Page: 40
Fix formatting.

Page: 40
This section title is not appropriate. No duplicate filtering is discussed here. Both application level messages and MSH level Acknowledgments may be lost. Only application level messages are resent. I suggest changing the title of this section to “Resending Lost Application Messages”.

Page: 40
It is important to distinguish application level messages from MSH level Acknowledgments. Standalone Acknowledgment messages are never acknowledged!

Page: 40
Suggest replacing this with “The rules that apply to the non receipt of an anticipated Acknowledgment due to the loss of either the application message or the Acknowledgment message”.

Page: 40
Replace with RetryInterval parameter.

Page: 40
Use lowercase for parameter.

Page: 41
Strike out this phrase since a subject is included in each of the three following bullets. These definitions should appear before section 7.5.5 because the concept of a first response message is used in section 7.5.5.

Page: 41
Fix formatting of these bullets.

Page: 42
Replace with PartyA MSH.

Page: 42
Replace with PartyB MSH.

Page: 42
Replace with PartyA MSH.

Page: 42
Replace with PartyB MSH.

Page: 42
I think an ebXML Error with the error code NotSupported should be returned.

Page: 43
Section 8.1 is missing.

Page: 44
This has the same title as section 8.2. The material should be folded into section 8.2.

Page: 45
This has the same title as section 8.3. The material should be folded into section 8.3.

Page: 45
I don’t see why a SOAP fault should be returned in this case. Instead, an error with error code NotSupported should be returned.

Page: 45
Fix bullet alignment.

Page: 47
The MessageOrder element may specify that messageOrderSemantics be set to NotGuaranteed. That would render the recommendation (that Reliable Messaging be used when a MessageOrder element is present) inappropriate. Perhaps we have to get rid of the messageOrderSemantics attribute and to interpret the presence of the MessageOrder element to mean guaranteed message ordering is required.

Page: 47
Is this reasonable? How many errors will be reported?

Page: 47
This is misleading. First of all, messageOrderSemantics is in the MessageOrder element, a separate module from the MessageHeader module. Second, unless this property is “perMessage”, it should just be in the CPA and not in the SOAP Header. Are we saying that messageOrder is a “perMessage” property?

Page: 48
I think all messages sent with the same ConversationId should have the same value for duplicateElimination and messageOrderSemantics. You don’t want to allow messages 1, 3, 5 to have order Guaranteed and messages 2, 4 to have order NotGuaranteed.

Page: 48
Fix the formatting for these bullets.

Page: 48
What should it do with buffered up messages in the same conversation?

Page: 48
Incorrect numbering of list items.

For some reason, page numbers not registered beyond this point (see Word document):
Replace with “XPath”.

Retransmission.

The content of this Appendix should be replaced with the contents of the XSD once we are satisfied with the latter.

Replace with [RFC2821].

This is superseded by RFC2821.

This is an invalid URL. The latest document I can find is http://www.w3.org/TR/2001/PR-xmldsig-core-20010820/.

ebxml-msg message