Proposed resolution for Rel57

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.