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] Issue 25 - form of seqAck when RMD has received no message

> Are you saying we should treat nack 1 differently than any other nack

No, I am saying exactly the opposite in fact - Nack has _exactly_ the same meaning in this context as it does in _all others_. I characterize that meaning as "I haven't received message #X and I need you to re-transmit it". 
That is whole my point about re-using the existing functionality.
The only special treatment here is that #1 is the first message in the sequence, which a-priori is already defined by the RM spec.

If you have already received messages #2 and #3 then we are not in this edge case status - which is about when we have received no messages.
FWIW, I think Ack 2..3 or Nack 1 are both equally valid responses in that situation, and have the same intended result - "please send me Msg #1".
However, that does not affect the special case scenario of "no messages received yet".

From: Lei Jin [mailto:ljin@bea.com] 
Sent: Thursday, September 22, 2005 10:55 AM
To: Jorgen Thelin; ws-rx@lists.oasis-open.org
Subject: RE: [ws-rx] Issue 25 - form of seqAck when RMD has received no message

Are you saying we should treat nack 1 differently than any other nack?  In every other nack with message number n, it means I haven't received message n.  I think this has exactly the same problem of checking for message number of 0, in the sense that implementation has to check for a special condition, but also we can't express the condition where I received message 2, 3, but not 1.
-----Original Message-----
From: Jorgen Thelin [mailto:jthelin@microsoft.com] 
Sent: Thursday, September 22, 2005 6:10 AM
To: ws-rx@lists.oasis-open.org
Subject: [ws-rx] Issue 25 - form of seqAck when RMD has received no message
I'd like to propose an alternate resolution for issue 25.

In the meeting yesterday, we discussed issue 25 and the group expressed its opinion that they preferred a definite statement to be made in this boundary case of no messages received yet.

The remaining proposal being considered last night was to send "Ack 0..0" for the case where no messages have been received.

<wsrm:SequenceAcknowledgement xmlns:wsrm="http://docs.oasis-open.org/whatever";>
        <wsrm:AcknowledgementRange Upper="0" Lower="0">

My intellectual concerns with this approach are that we are making an incorrect statement - we are acknowledging receipt of a message [#0] that (a) we haven't actually received, (b) doesn't actually exist, and (c) will never be sent

My practical concerns with this approach are that I fear this change may cause a large ripple effect on implementations. 
I suspect implementations will need to change to explicitly recognize and exclude / ignore the dummy message #0 anywhere they use a sequence range (although I haven't actually checked into the details yet). 
Also changing the schema to say #0 is in the message number range makes it harder to do effective validation of message content on the wire (should you wish to do that) - specifically is Ack 0..10 valid or just Ack 0..0?

I believe we already have existing features of the RM spec that can be used to solve this problem and make a definite but correct statement to handle this boundary condition - We can assert "I'm still waiting for you to send me the first message" - eg. "Nack 1"

<wsrm:SequenceAcknowledgement xmlns:wsrm="http://docs.oasis-open.org/whatever";>

The advantages of this approach are:

1. It makes a definite statement rather than relying on the absence of a statement to convey meaning 
2. The statement made is accurate - "I haven't received message #1" 
3. We don't need to change the message number range to accommodate this boundary condition - the schema can show the real 1..unbounded condition to allow better validation of on-the-wire messages 
4. We don't need to introduce and document the concept of the fictitious "Message #0" and explain where and when it is valid to use that message number 
5. I _suspect_ the impact on existing implementation will be less by not introducing lots of special-case handling code 
6. We are re-using existing functionality in the spec rather than introducing new functionality to handle special cases - which should ultimately lead to fewer code paths and a smaller surface area. 
7. This approach is basically backward compatible with exiting spec versions (both syntactically and semantically) - it represents a clarification for this boundary case rather than introducing completely new functionality. 

So I propose the following resolution for Issue 25
Recommend that an RMD be required to respond with a SequenceAcknowledgement element containing a Nack child element with content "1" to signify that the first message has not yet been received for a given Sequence. e.g. 
<wsrm:SequenceAcknowledgement xmlns:wsrm="http://docs.oasis-open.org/whatever";>

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