Rel-102 (Persistence requirements)

[Jacques Durand <JDurand@us.fujitsu.com>]

Title: Rel-102 (Persistence requirements)

Rel-102 (Persistence requirements):

Overall proposal:

just remove the section 2.7, because it is redundant with what RM features
require. I.e. when implementing most of these features, persistence will automatically
appear as necessary. It is an implementation aspect.
In addition, some persistence requirements may actually NOT be necessary
to satisfy some RM requirements, i.e. are encroaching on implementation choices.

Details:

<JD>
- the Sender side has to be able to resend the same message (retry).
We don't need to state more than that.
How is that achieved, is an implementation decision. Some form of persistence is
likely to be needed, but after all there may be alternatives that we should not
preclude (e.g. the RMP fetching messages to be resent, from an external store...)
- Receiver side: same proposal: persistence is implied by the RM features.
In addition, here again the current proposal in the Feb 4 issue list, will unnecessarily
restrict implementation choices.
</JD>

The current proposal:
"When supporting Guaranteed Message Ordering, the receiver is REQUIRED to persist
out of order messages until one of the following conditions are met:
* Receipt of all previous messages and successful invocation of the deliver operation.
* The span of time indicated by the ExpiryTime element has expired.

<JD> The first bullet is a repeat from the definition of Ordering, along with a way to
implement it (persist messages). The second bullet is also a consequence of our definition
of Expiry time, obvious to an implementor.
Finally, the REQUIRED above is too strong: memory constraints can also
limit the persistence of such sequences.
Finally, there are other ways to implement ordering, by relying on the persistence of the
Sender instead of the Receiver: As Jun mentioned, there is a way to implement Ordering
without persisting any pending out-of-order sequence, e.g. just by relying on the
resending window to get messages in the right order. This may not allow long
out-of-order sequences, but this is an implementor's discretion to decide how much
can be stored based on physical constraints.</JD>

When supporting Duplicate Elimination, the receiver is REQUIRED to persist the
Message Identifier until one of the following conditions are met:
* The span of time indicated by the ExpiryTime element has expired
* anything else?.

<JD> again, this is implied by the definition of Duplicate Elimination,
and the definition of Expirytime. We might as well make this a more explicit and abstract
requirement of Duplicate elimination: "when D.E. is required, the receiver RMP MUST
check duplicates over all previous non-expired messages."
Plus, this persistence requirement is
somehow confusing, as for groups we don't need to actually persist every ID
but just remember intervals of seq nums.</JD>