Arvola:
just a
few comments on your comments:
>Page:
10
>Has.
I guess the intent
was "MUST have" here.
>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
