proposal for issue #___ (Ack on dupl)

Title: proposal for issue #___  (Ack on dupl)

Proposal: 

If we do on "Ack of duplicate" then we should tighten the spec to remove

the following ambiguities and unnecessary restrictions:

The spec needs to be more precise on the conditions of persistence of message IDs

when supporting duplicate elimination. 

It should be made clear that only persistence of IDs of *delivered* messages is REQUIRED. 

That is important to help a fast yet easy implementation 

of Acknowledgment of *delivered* duplicates.

(the following changes below are also justified for other editorial reasons)

The order of the Message processing flow should then be: 

(this is a general sequence of steps, may have more steps in between, 

e.g. additional expiry checks, or some steps may be cancelled. 

The point is, "persist ID" may occur before (4) but does not have to )

1- M received

2- duplicate check

3- expiry check

4- (M delivery AND persist ID, i.e. both should succeed or fail)

5- Ack sent

----- Section 2.4 "Group Persistence":

Rename the section more generally "Message ID Persistence", and update as follows: 

Replace:

"The duplicate elimination feature requires persisting the Message Identifier (GroupId and optionally the Sequence Number), 

after the message has been processed and delivered (made available) to the application. ...

The general rule about Message Identifier persistence, is that an RMP MUST persist the ID of a message 

at least until the message expires regardless whether the message has been delivered or not to the application."

With:

"In case duplicate elimination is required, an RMP MUST persist the ID (GroupId and optionally the Sequence Number) 

of a delivered message at least until the message expires."

(rationale: it is a more precise wording that makes it clear that persistency of ID is NOT required as long as the

message is not delivered. Personally, I think that statements on persistence are unnecessary 

as they are implied by the feature itself - here duplicate elimination - but if we keep this one, propose that one.)

------ Section 2.8  Duplicate Elimination

Replace:

"A number of conditions may result in transmission of duplicate message(s), e.g.,

temporary downtime of the sender or receiver, a routing problem between the

sender and receiver, etc.  In order to provide at-most-once semantics, 

the ultimate receiver MUST eliminate duplicate messages.  Messages with the same 

Message Identifier MUST be treated as duplicates.  "

With more precise:

"A number of conditions may result in reception of duplicate message(s), e.g.,

temporary downtime of the sender or receiver, a routing problem between the

sender and receiver, etc.  In order to provide at-most-once semantics, 

the receiver RMP MUST NOT deliver a message that is a duplicate of a previously delivered message."

(Again, a subtle difference, very significant for implementing duplicate check:

 the initial wording is ambiguous and may be interpreted as " duplicate elimination of any received messages is required",

while only the elimination of those duplicates of previous *delivered* messages is needed: it should NOT

be required to do more than that. Remove "elimination" which is imprecise.) 

----- Section 3.2.1: AckRequested Element

Replace:

"... If a receiver receives a message with AckRequested element, the receiver MUST send an 

Acknowledgment message even when the message is a duplicate. "

With:

"... When receiving a message with AckRequested element, the receiver MUST send an 

Acknowledgment message if and only if either (1) the message has been delivered, or (2) the message is a duplicate

of a previously delivered message that has not expired."