Rel-102 (Persistence requirements)

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>