Possibly these have been previously reported or identified.
MS Spec issues and questions:
Lines 256-257: Why are the terms "reliably" and "reliable messaging" in
quotes? This hints that these terms have some unspecified special meaning.
Line 257: Reference to section 11.1 is incorrect.
MS Spec Minor corrections:
Line 233: Period missing at the end of the sentence
Lines 237-239: Inconsistent punctuation at the end of bullet list items
Lines 243-251: Inconsistent punctuation at the end of bullet list items
Lines 254-261: Inconsistent punctuation at the end of bullet list items
{I'll stop listing these... but they are more...)
Line 296: The period should go after the closing parenthesis.
Line 312: Remove space before "[secRISK]" for consistency. (Or, add a space
to the other bullet points.)
-----Original Message-----
From: David Fischer [mailto:david@drummondgroup.com]
Sent: Monday, October 15, 2001 5:22 PM
To: ebxml-msg@lists.oasis-open.org
Cc: ebxml-cppa@lists.oasis-open.org
Subject: [ebxml-cppa] MS v1.05
OK, How's this?
<<see comments inline>>
David Fischer
Drummond Group.
-----Original Message-----
From: Arvola Chan [mailto:arvola@tibco.com]
Sent: Sunday, October 14, 2001 5:54 PM
To: ebxml-msg@lists.oasis-open.org
Cc: ebxml-cppa@lists.oasis-open.org
Subject: [ebxml-msg] Comments on ebMS_v1.04c
David:
Please see the attached Word document (View Comments) for the contexts for
these comments.
Regards,
-Arvola
----------------------------------------------------------------------------
----
Page: 2
Fulfills
<<fixed>>
Page: 2
Pete Wenzel (RosettaNet/SeeBeyond) is missing from this list. Actually,
quite a few names found on http://www.oasis-open.org/committees/ebxml-msg/
are missing from this list.
<<fixed>>
Page: 2
E2Open
<<fixed>>
Page: 7
This section needs to be updated to reflect more closely the current round
of modularization changes. Also, the use of punctuation after each bulleted
item seems inconsistent.
<<fixed>>
Page: 7
Invalid reference
<<fixed>>
Page: 7
Invalid reference
<<fixed>>
Page: 7
Invalid reference
<<fixed>>
Page: 7
There is a section 11 with the title Multi-Hop Module. Appendix C is
currently titled Supported Security Services.
<<fixed>>
Page: 17
Chris Ferris has suggested that the namespace value should match the
schemaLocation value. The examples need to be updated accordingly if we
agree to adopt that convention.
<<not sure what to do. Please be more specific>>
Page: 23
Shouldn't the TimeToLive element be present if Reliable Messaging is in use?
<<Yes? Do you mean should it be present if RM is NOT in use? Answer is
still
yes.>>
Page: 23
How can the equivalent of BestEffort be specified? In that case, the
semantics is not at-least-once.
<<fixed>>
Page: 25
I find the reorganization of the Security section rather awkward. Shouldn't
the section on Security and Management precede the sections on Signature
element and on Signature Generation. It does not make sense talk about
Signature Generation even before Persistent Digital Signature is introduced
as a countermeasure technology.
<<fixed>>
Page: 27
This is insufficient. If intermediaries can change the AckRequested and Via
elements, then these elements have to be excluded from the signature.
<<Yes, need to fix -- TBD>>
Page: 28
This section needs to be updated to reflect changes in the 1.1 CPP/A spec.
Currently, the CollaborationRole element contains a CertificateRef element
that is also used for security definition.
<<TBD>>
Page: 30
Should www.ebxml.org be replaced with www.oasis-open.org?
<<Fixed Throughout>>
Page: 31
This should probably be replaced with an appropriate XPointer.
<<TBD>>
Page: 33
What happens when the incoming message specifies syncReply=true? Shouldn't
errors be returned synchronously in this case?
Page: 33
I suggest moving this section to the end of Part II Optional Features.
Alternatively, the introductory paragraph in this section should be updated
to indicate that optional elements from Part II can also be present.
<<No, need Parts to be independant. Each optional section as an Interaction
sub-section>>
Page: 35
Incorrect statement.
<<fixed>>
Page: 35
Should this be replaced with oasis-open.org?
<<fixed>>
Page: 36
I don't see why this is necessary. A DeliveryReceipt is generated by the To
Party MSH and should be returned at the latter's earliest convenience. It
should always be possible to piggyback the DeliveryReceipt element with the
first application level message that is in response to the message in
question and therefore be able to share the same RefToMessageId in
MessageData. If the DeliveryReceipt is sent on its own, again the
RefToMessageId in MessageData should suffice.
<<Added to make modules independent. Not sure we can Guarantee that
returned
message will be a response with the same RefToMessageId.>>
Page: 36
This contradicts lines 1397 and 1398.
<<fixed>>
Page: 36
Duplicate elimination may be a more meaningful phrase in this context.
<<There may be more use for Duplicate Elimination than just RM. The
Receiver
may do Duplicate Elimination under all circumstances. This parameter is to
make
sure it is on.>>
Page: 37
Messages that are sent in response to messages arriving on a reliable but
synchronous delivery channel also need to be kept in persistent storage!
<<Agreed. Persistant Store is not only for RM. Persistant Store should
work
for sync and for async. Is there a change?>>
Page: 37
Is the presence of a Via element mandatory when there are two instances of
the AckRequested element?
<<Good question. I don't know. Ask David Burdett.>>
Page: 37
This suggests that the From Party MSH can request the To Party MSH to return
an end-to-end acknowledgment, thereby rendering the DeliveryReceipt element
redundant. I would recommend getting rid of the DeliveryReceipt element.
<<Yes, we all agree -- except that DR is already being implemented. We left
DR
in for backward compatability but made it optional.>>
Page: 38
Should this be replaced with oasis-open.org?
<<fixed>>
Page: 38
An.
<<fixed>>
Page: 38
Included in the same message with.
<<fixed>>
Page: 38
What is this attribute?
<<fixed>>
Page: 38
Shouldn't this be the From Party?
<<fixed>>
Page: 38
Should this be "used by one Message Service Handler to indicate to another
Message Service Handler that it ..." instead?
<<fixed>>
Page: 39
Again, I question whether this is necessary. See my earlier comments
regarding the use of a RefToMessageId attribute within the DeliveryReceipt
element.
<<see previous comment>>
Page: 39
Is the presence of a Via element mandatory when there are two instances of
the Acknowledgment element?
<<good question. Don't know yet.>>
Page: 39
Incorrectly cut and pasted.
<<??? Looks OK???>>
Page: 39
Corresponding to the ...
<<fixed>>
Page: 39
Isn't it true that an Acknowledgment element an an AckRequested element
cannot be present in the same ebXML message if the latter is not generated
by the application layer?
<<Not sure.>>
Page: 40
Please note that Retries, RetryInterval, PersistDuration are only in the
CPA, not in the message header.
<<Yes. This has come up many times. How shall we fix?>>
Page: 40
Spelling.
<<fixed>>
Page: 40
Spelling.
<<fixed>>
Page: 40
Spelling.
<<fixed>>
Page: 40
Spelling.
<<fixed>>
Page: 40
Is there such an element? There is a duplicateElimination attribute in the
QualityOfServiceInfo element.
<<fixed>>
Page: 40
See comment above.
<<fixed>>
Page: 40
Has received?
<<fixed>>
Page: 40
There are two kinds of retries: retry due to non receipt of Acknowledgement
from the nextMSH, and retry due to non receipt of Acknowledgment from the
ToPartyMSH. The CPA only deals with the latter type of retry.
<<need to work on this -- TBD>>
Page: 40
See above comment on Retries.
<<Same as above>>
Page: 41
This statement is imprecise. TimeToLive is of type dateTime whereas the
product of Retries and RetryInterval is of type duration.
<<looks OK. Do you have a suggestion?>>
Page: 41
This should be of type duration.
<<fixed>>
Page: 41
The timestamp for a reliably sent message (found in the message header),
plus its PersistDuration (found in the CPA), must be greater than its
TimeToLive (found in the message header).
<<fixed>>
Page: 41
All of the figures in this section illustrate the single-hop case. It should
be made clear whether the discussions apply both to the single-hop and
multi-hop cases.
<<need to put some explaination in RM section, not here.>>
Page: 42
This statement is very confusing. Why should it be either or? It seems that
if the sender is aware of the use of an intermediary, then it should specify
two AckRequested elements. The phrase "as determined by the AckRequested
parameter" is rather meaningless.
<<a single AckRequested element cannot be targetted at both the Next and the
End. Use two. I will move the part about Next to the Multi-hop RM
section.>>
Page: 42
Are we waiting for the Ack from the nextMSH or the ToPartyMSH?
<<For this section it is the ToPartyMSH. Also added 11.2.3.>>
Page: 42
Again, are we talking about an Ack from the nextMSH or an Ack from the
ToPartyMSH?
<<For this section it is the ToPartyMSH. Also added 11.2.3.>>
Page: 42
Isn't it the case that only the ToPartyMSH is supposed to perform duplicate
elimination?
<<see the paragraph following your comment>>
Page: 42
Intermediate MSH's should not have to do this.
<<see the paragraph following your comment>>
Page: 42
If the CPA indicates that an application response is included, then it must
be the case that the processing of the earlier message is not yet complete.
In this case, the MSH must wait for the response to the earlier message and
then return it synchronously.
<<What words need to be used? This seems to be to be an unknown situation
and I
am not comfortable with "don't do anything" since any number of problems
might
have arisen. What do we do if there is no CPA?>>
Page: 43
I still think that either all intermediaries, or none of them, should
exhibit store and forward (with retry) behavior.
<<Let's not be that prescriptive.>>
Page: 43
Earlier discussions in this draft indicate that an Acknowledgment message
must contain an Acknowledgment element. See line 1443.
<<fixed>>
Page: 43
I think we should allow for the possibility of having the Acknowledgment
message returned synchronously without being piggybacked on the business
response.
<<We discussed this on the call.>>
Page: 43
Should this be oasis-open.org?
<<fixed>>
Page: 43
This works only for the ToPartyMSH. Need to explain how an intermediary
should populate the From andTo elements when it needs to generate an
intermediate Acknowledgment because sync reply is not in use.
<<fixed in section 11.2.1>>
Page: 44
Need to account for the fact that there are two kinds of retries and two
sets of retry parameters.
<<we decided not to. Added note that any single node SHOULD only add one
AckRequested.>>
Page: 44
Strike out this phrase.
<<I think we decided not to worry about this?>>
Page: 44
I suggest renaming this as "first response message"
<<fixed>>
Page: 45
First response message.
<<fixed>>
Page: 45
The From Party MSH many have no knowledge of an intermediate MSH. Why should
it trust a Delivery Failure Notification from an untrusted intermediate MSH?
<<Yes, added a note>>
Page: 46
Should this be oasis-open.org?
<<fixed>>
Page: 49
Should this be oasis-open.org?
<<fixed>>
Page: 49
Should this be oasis-open.org?
<<fixed>>
Page: 49
Use.
<<fixed>>
Page: 49
This is quite different from the 1.0 spec which states that the
SequenceNumber element must not be present unless deliverySemantics is
OnceAndOnlyOnce and messageOrderSemantics is Guaranteed. Message ordering
cannot be guaranteed unless messages with sequence numbers are guaranteed
not to be lost!
<<We discussed this and decided that only duplicateElimination was
necessary. I
do agree that RM would be preferrable. Do you still think this is
required?>>
Page: 50
I don't think messageOrderSemantics is currently specified in the CPA. We
may have to provide feedback to the CPP/A TC.
<<OK>>
Page: 51
Does this rule apply only to the ToPartyMSH or does it apply to the nextMSH
as well?
<<added rule in 11.4>
Page: 51
Should the AckRequested element that is addressed to the nextMSH be placed
under the Via element?
<<Putting AckRequested under Via would require two elements. We have
created
one dual-use element using SOAP actor.>>
Page: 52
Should this be www.oasis-open.org?
<<fixed>>
Page: 52
Don't need to capitalize?
<<fixed>>
Page: 52
Forwarding the message to ...
<<fixed>>
Page: 52
The sending MSH may not be aware of the use intermediate MSH's and therefore
not include a Via element. When the first MSH forwards the message to the
second MSH, it will have to construct a Via element that contains a
TraceHeaderList with Two TraceHeaders!
<<Maybe, I still question the need for TraceHeaderList. The only time I see
that it is needed is for AckRequested with actor=NextMSH. Even here we only
need the last To/From pair.>>
Page: 55
The sending MSH may not be aware if any intermediary is used in the message
path. Therefore, the decision to exclude the Via element from the signature
must not rely on knowledge of the presence or absence of intermediaries.
<<Yes, we are creating a new Transform which excludes all elements with
Actor=Next or Actor=NextMSH.>>
Page: 56
The locations of these schemas have to be updated.
<<Yes>>