RE: [ws-rx] PR26 - Retransmission

[Matthew Lovett <MLOVETT@uk.ibm.com>]

Thanks Sanjay, I guess that removes the bit of wordsmithing that the 
editors would have needed to do.

+1 to your text.

Matt


"Patil, Sanjay" <sanjay.patil@sap.com> wrote on 13/12/2006 17:55:37:

> 
> I think there was some consensus on the mailing list in the past to
> simplify the text for referencing unacknowledged messages [1]. By
> applying that simplification and changing "MUST" to "SHOULD", the
> proposal below would read as:
> 
>    While the Sequence is not closed or terminated, the RM Source
> SHOULD retransmit unacknowledged messages.
> 
> Let us try to hash out any further changes/refinements to the proposal
> on the mailing list before the conf-call. We have many other major open
> issues to be discussed on the conf-call!
> 
> - Sanjay
> 
> [1] http://lists.oasis-open.org/archives/ws-rx/200611/msg00043.html
> 
> >-----Original Message-----
> >From: Matthew Lovett [mailto:MLOVETT@uk.ibm.com] 
> >Sent: Wednesday, Dec 13, 2006 6:43 AM
> >To: ws-rx@lists.oasis-open.org
> >Subject: [ws-rx] PR26 - Retransmission
> >
> >Hi all,
> >
> >The current proposal for PR26 reads as follows:
> >
> >Add a new invariant:
> >While the Sequence is not closed or terminated, the RMS must 
> >retransmit 
> >any messages that are missing from the most recent acknowledgement 
> >message.
> >
> >I don't think that is quite right. Using a lowercase must 
> >doesn't seem to 
> >help much, and an uppercase MUST would be too strong. 
> >(Consider a device 
> >with limited storage, they might be happy to retransmit messages up to 
> >some limit, but need to recover storage after that point. 
> >There are plenty 
> >of other impl choices that don't like this MUST too.)
> >
> >How about the following alternative:
> >
> >Add a new invariant:
> >While the Sequence is not closed or terminated, the RM Source SHOULD 
> >retransmit any messages that are missing from the most recent 
> >acknowledgement message.
> >
> >The editors may wish to play with the trailing part of the 
> >sentence, to 
> >cope with the permutations of Acks/Nacks, and the definition of 'most 
> >recent', but I don't think that is the core of the issue. I think the 
> >SHOULD makes the common impl choice clear, without forcing 
> >implementers 
> >into a corner.
> >
> >Note that this proposal basically matches the point that we 
> >got to on the 
> >last call. I hope that most people are able to accept it.
> >
> >Thanks
> >
> >Matt
> >
> >