Chris,
Your point on the distinction between what
may be delivered vs what will be delivered is understood, but I think that if
the RMD knows that a previously acked message that cannot be delivered due to
the existence of in-order delivery and a gap, might be a situation best
confessed.
Your second comment concerning the withdrawal
of a previously acked message in SeqAck/Final is exactly what I am prosing
making legal in the protocol. I think that it is not a protocol
violation, per-se, since the sequence is closing, and that the RMD will accept
no further messages for the sequence. That closure does not imply that
the RMS is expected to re-send messages that are missing in the acknowledged
sequence since the sequence is effectively dead. SeqAck/Final does not
change the future order or existence of either messages or control messages, it
is just informative.
In the absence of ordered delivery, SeqAck/Final
always reflects messages that might be delivered, but it does not with my
interpretation of the likely implementations of ordered delivery. My proposal
rests on this assertion.
On your last point, I agree that the text
might be tightened, for all SeqAcks other than SeqAck/Final which my proposal
provides the freedom to do exactly that in the spirit of truthful ending
status.
Thanks
-bob
From: Christopher B
Ferris [mailto:chrisfer@us.ibm.com]
Sent: Thursday, March 23, 2006
6:31 AM
To: Bob Freund-Hitachi
Cc: [WS-RX]
Subject: Re: [ws-rx] New Issue;
SequenceAcknowledgement:Final assumption of deliverability
Bob,
Taking
responsibility for delivery and delivering are two separate things.
Just
because a message *could* be delivered, doesn't mean that it ever *can* be
delivered.
Are
we saying that SeqAck/Final should not ack messages that it knows cannot be
delivered?
What if the message had been previously ack'ed? Then, introducing a
GAP
where previously there had been an acknowledged message would be in violation
of
the protocol (at least as I understand it).
I
would also point out that apparently, while there is guidance related to
Nack-ing a message
previously
Ack'ed, there is no guidance that prohibits sending a SeqAck that introduces
a
gap that had previously been Ack'ed. I think that this needs to be rectified.
I
will gladly introduce a separate issue if people think that it deserves to be
addressed
on
its own merits.
Cheers,
Christopher
Ferris
STSM, Software Group Standards Strategy
email: chrisfer@us.ibm.com
blog: http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440
phone: +1 508 377 9295
"Bob Freund-Hitachi"
<bob.freund@hitachisoftware.com>
wrote on 03/22/2006 02:07:29 PM:
> Description
> Modify definition of
SequenceAcknowledgement:Final to reflect
> accurate ending delivery capability status.
>
Justification
> The protocol defines the
SequenceAcknowledgement:Final element which
> contains the final summary of message
acknowledgements at the
> closure of a sequence. It is assumed that the
RMD has taken
> responsibility for all messages that have
been acknowledged.
> Depending upon the operation of the RMD and
its interface with the
> application, Messages that have been
previously acknowledged as
> received by the RMD, may never be
deliverable. One such case of
> note that comes to mind is the situation of a
message sequence that
> is being delivered in-order to an application
which is closed at the
> time when one or more gaps that may exist in
the sequence. If this
> situation occurs, the RMS will have incorrect
information concerning
> exactly which messages have been or will be
deliverable at the
> conclusion of a sequence.
> Note
that there is nothing in the spec that states what the RMS is
> to do with the information contained in
SequenceAcknowledgement:
> Final. This proposal does not add any
such statement, but it does
> permit the information to be potentially
interpretable.
> Target:
core
>
Proposal:
> Reference Core Spec CD03
> insert after line 613:
> SequenceAcknowledgemnt:Final shall identify
only those messages that
> have been delivered or which the RMD has
taken responsibility for
> delivery without regard to the previous
acknowledgement status of any message.
> State
Table impact: None
>