OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-rx message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [ws-rx] PR26 - Retransmission



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
>
>


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]