Re: [ws-rx] New Issue; SequenceAcknowledgement:Final assumption ofdeliverability

From
Christopher B Ferris <>
Date
2006-03-23T11:29:47+00:00
ID
Thread
Re: [ws-rx] New Issue; SequenceAcknowledgement:Final assumption ofdeliverability
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: 

blog: http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440

phone: +1 508 377 9295

"Bob Freund-Hitachi" <>
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

>