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

>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.

I agree with this. But if so, the relationship between PersistDuration and TimeToLive need be clarified (if still applicable): they seem to address time windows that are quite independent (do not overlap at all). In that case, there is no clear reason anymore to require PersistDuration+timestamp to be greater than TimeToLive (in 7.4.6)

<ac>The reason for requiring timestamp + PersistDuration to be greater than TimeToLive in section 7.4.6 is to ensure that duplicate messages are properly detected. Once the received message has stayed in the persistent store beyond the PersistDuration, it is liable to be garbage collected. Therefore, it would be problematic if TimeToLive is set to an arbitrary time value that does not bear a relationship with timestamp and PersistDuration</ac>

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

in case sequence numbers are used, very fast (and space efficient) duplicate elimination can be done using sliding windows, that does not rely on storage of messages and their IDs. Just a possibility.

<ac>I agree it is possible to remember sequence numbers instead of message IDs and/or message contents to facilitate duplicate elimination. Still, it is necessary to keep track of the the received sequence numbers in some form of a persistent store. Otherwise, duplicates may not be detected after a crash recovery.</ac>

>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.

Although I believe what you suggest is the general use case, I do not see a major technical issue here, because messages that hav NotGuaranteed, will simply NOT report any sequence number. So even if some messages in a conversation are left out of the order enforcement (an app could decide that order be relaxed for some lesser messages, e.g. some receipts), then all order-guaranteed messages would still have contiguous numbers. Maybe that is a CPA decision.

<ac>In section 10.1.2, it is stated that (a) the SequenceNumber is incremented for every message sent within a conversation; (b) if duplicateElimination is set to true then messageOrderSemantics may be set to Guaranteed or NotGuaranteed; (c) a SequenceNumber may be present even if messageOrderSemantics is NotGuaranteed provided that duplicateElimination is true. Now consider the scenario where messages with SequenceNumbers 1, 3, and 5 require message order guarantee while messages with SequenceNumbers 2 and 4 require no message order guarantee. One correct delivery order is 1, 2, 4, 3, 5. However, the MSH will have to persistently remember more information to enable such out of order delivery. Instead of just remembering the highest SequenceNumber message with message order guarantee requirement that has been delivered, it will be necessary to remember also the SequenceNumbers of messages that do not have message order guarantee requirement and have been delivered ahead of the ones which have message order guarantee requirement. Point (a) above is the problematic requirement. Even if a message does not require message order guarantee, it still must be assigned a unique SequenceNumber within the conversation.</ac>

Jacques Durand

Fujitsu Software

ebxml-msg message