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)

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

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

Jacques Durand

Fujitsu Software

ebxml-msg message