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: 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:Identifier>http://example.org/mysequence/1234</wsrm:Identifier>

        <wsrm:AcknowledgementRange Upper="0" Lower="0">

</wsrm:SequenceAcknowledgement>

 

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

        <wsrm:Identifier>http://example.org/mysequence/1234</wsrm:Identifier>

        <wsrm:Nack>1</wsrm:Nack>

</wsrm:SequenceAcknowledgement>

 

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

        <wsrm:Identifier>http://example.org/mysequence/1234</wsrm:Identifier>

        <wsrm:Nack>1</wsrm:Nack>

</wsrm:SequenceAcknowledgement>

 



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