Title: 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.
Lei
-----Original Message-----
From: Jorgen Thelin
[mailto:]
Sent: Thursday, September 22, 2005
6:10 AM
To:
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: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:
It makes a definite
statement rather than relying on the absence of a statement to convey
meaning
The statement made
is accurate – “I haven’t received message #1”
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
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
I _suspect_ the impact on existing
implementation will be less by not introducing lots of special-case handling
code
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.
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>
