MHonArc v2.5.2 -->

















ebxml-msg message






[Date Prev]
 | [Thread Prev]
 | [Thread Next]
 | [Date Next]

--

[Date Index]
 | [Thread Index]
 | [Elist Home]








Subject: [ebxml-msg] Comments on the 1.09 draft




From: Arvola Chan <arvola@tibco.com>
To: ebxml-msg@lists.oasis-open.org
Date: Mon, 26 Nov 2001 17:07:49 -0800










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
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
Inconsistent 
notation.
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
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 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/.
ebMS_v1.09_arvola.zip












[Date Prev]
 | [Thread Prev]
 | [Thread Next]
 | [Date Next]

--

[Date Index]
 | [Thread Index]
 | [Elist Home]


  









Powered by eList eXpress LLC