Proposed resolution for Rel57

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

Title: Proposed resolution for Rel57

Rel 57: Ordering and Missing Message Behavior
---------------------------------------

Proposal:

[short answer]:
the RMP will wait until the sequence expires (indicated either by GroupExpiryTime,
or by MaxGroupIdleTime). All out-of-order messages will be then discarded.
However, even so storage resources may be insufficient to persist further out-of-order
messages. In that case, a resource fault (Fault code: "MessageStoreOverflow" will be
generated and made available to the Sender.

[long answer]:
Given the definition of Guaranteed Ordered Delivery, a message must not be delivered
to the receiver application if not all previous messages were.
Therefore in case a Receiver RMP decides to not wait any longer for a missing
message, the already received out-of-order messages MUST be discarded and not
delivered to the application.

Discarding an out-of-order group occurs in the following cases (d1, d2, d3):

Case d1: the group had GroupExpiryTime specified in its messages.
On the Receiver side, the out-of-order messages MUST be discarded as soon as this date
expires, and the group MUST be terminated. Indeed, any missing message received after
this date, will not be accepted by the RMP (as GroupExpiryTime is always greater than
ExpiryTime of any message in the group), and the group will never be complete.
On the Sender side,

Case d2: the group did not have GroupExpiryTime specified, but had GroupMaxIdleTime.
On the Receiver side, the out-of-order messages MUST be discarded if this maximum idle time
from the last received message expires, and the group MUST be terminated.

Case d3: neither GroupExpiryTime nor GroupMaxIdleTime were specified for messages
of this group. In this case, any out of order message will be discarded, and
the group immediately terminated.
NOTE: In order to avoid this situation, a Sender SHOULD either use time-based termination
criteria (like in d1, d2), or if not, SHOULD always wait for a message to be acknowledged,
before sending the next message in the sequence.

In all cases (d1, d2, d3), the Receiver RMP MUST generate an RM Fault "OutOfOrderSequenceExpired".
In case the Sender must take the initiative to poll for such a fault, it SHOULD do so when:
(1) some Acks are missing, (2) the group has expired according to GroupMaxIdleTime
or GroupExpiryTime, if these are specified.
Once the Fault has been obtained, the Sender MUST NOT send further messages for this group,
and MUST communicate instead a delivery failure to its application.

NOTE: the cases above (d1, d2, d3) decide of the discarding of out-of-order messages
of a group, and therefore of the termination of a failed ordered group.
This does not mean yet the removal of the group state, as message IDs may still be needed
for duplicate checks.