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

[Christopher B Ferris <chrisfer@us.ibm.com>]

+1

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

Doug Davis/Raleigh/IBM@IBMUS wrote on 03/23/2006 08:22:45
AM:

> 
> Bob - this gets into the entire DA issue which is out of scope.  All
> the RMD can/should say is whether or not it got the messages - and
> that list of messages should never decrease.  If there are gaps
in 
> the sequence then the RMS will know which messages will be delivered
> (or not) based on the DA in use.  How it knows the DA is out
of scope  :-) 
> thanks, 
> -Doug 
> 
> 

> 
> "Bob Freund-Hitachi" <bob.freund@hitachisoftware.com>

> 03/23/2006 06:35 AM 
> 
> To
> 
> Doug Davis/Raleigh/IBM@IBMUS, "[WS-RX]" <ws-rx@lists.oasis-open.org>

> 
> cc
> 
> Subject
> 
> RE: [ws-rx] New Issue; SequenceAcknowledgement:Final assumption of
> deliverability
> 
> 
> 
> 
> Doug 
> If “taking responsibility” for a message implies that at least an
> attempt to deliver the message will be made, then I guess that the
> previous ack of a message with a sequence number larger than a gap
> is untruthful if in-order delivery is enforced. 
> The proposal allows the rmd to correct the previous misstatement,
> which it had no way of knowing was untruthful at the time it was 
> made.  The RMS had the expectation at the previous acknowledgement
> that further messages may be coming which was shattered when the 
> sequence was closed without that expectation being met. 
> The RMS has no way of knowing that ordered delivery was in effect,
> so it cannot second guess the RMD. 
> Alternatively, we could say that all messages that have been 
> acknowledged will be delivered, on at least a best-efforts basis,
> independent of in-order delivery and the existence of gaps in the
sequence. 
> Or, we could define durable persistence and a way for sequences to
> be resumed after closure (I think just too complicated) 
> Thanks 
> -bob 
>   
>   
> 

> 
> From: Doug Davis [mailto:dug@us.ibm.com] 
> Sent: Wednesday, March 22, 2006 10:54 PM
> To: Bob Freund-Hitachi
> Cc: [WS-RX]
> Subject: Re: [ws-rx] New Issue; SequenceAcknowledgement:Final 
> assumption of deliverability 
>   
> 
> Bob, 
>  I'm confused - doesn't the sending of an Ack for a certain message
> number already imply that the RMD is taking responsibility for it?
 
> If only SeqAck+Final means that, then does that mean that a SeqAck
> (non-final) means something less?  like a lie? 
> -Doug 

> 
> "Bob Freund-Hitachi" <bob.freund@hitachisoftware.com>

> 03/22/2006 02:07 PM 
> 
> To
> 
> "[WS-RX]" <ws-rx@lists.oasis-open.org> 
> 
> cc
> 
>   
> 
> Subject
> 
> [ws-rx] New Issue; SequenceAcknowledgement:Final assumption of deliverability
> 
> 
>   
> 
>   
> 
>  
> 
> 
> 
> 
> 
> 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 
>