Re: [ws-rx] i0019 - a formal proposal - take 4

[Doug Bunting <Doug.Bunting@Sun.COM>]

DougD,

On 01/09/05 10:34, Doug Davis wrote:

>
> DougB,
> I like the 1st change if others are ok with it.  My only concern is 
> that it doesn't
> explicitly say that SequenceClosed could/should be used instead of
> TerminateSequence - which wouldn't allow the RMS to get the final ACK.
>
> What about:
>
>     In the case where the RM Destination wishes to discontinue use of a
>    sequence it may 'close' the sequence itself.  Please see wsrm:Final
>    above and the Sequence Closed fault below. Note the SequenceClosed
>     Fault SHOULD be used in place of the SequenceTerminated Fault, 
> whenever
>     possible, to allow the RM Source to still receive Acknowledgements.
> ??

wfm

> re:2nd change - I agree that its untestable but there's there's part 
> of me that
> worries that w/o saying that the RMD can't deliver those messages on
> to the app in some DA, some implementations would deliver them.  It 
> should
> be obvious but I thought being clear about it couldn't hurt.  Like 
> with the
> first change, if others are ok your suggestion then I'm ok.

Not our problem to address but I agree with polling the group.

> I'd like to discuss these two on the call today to see what other's think.

+1

thanx,
    doug

> re:3rd change - yes - that's a typo.
>
> thanks!
> -DougD
>
>
>
> *Doug Bunting <Doug.Bunting@Sun.COM>*
> Sent by: Doug.Bunting@Sun.COM
>
> 09/01/2005 11:45 AM
>
> 	
> To
> 	Doug Davis/Raleigh/IBM@IBMUS
> cc
> 	ws-rx@lists.oasis-open.org
> Subject
> 	Re: [ws-rx] i0019 - a formal proposal - take 4
>
>
>
> 	
>
>
>
>
>
> Doug,
>
> A few smaller, potentially editorial questions:
>
> On 01/09/05 06:41, Doug Davis wrote:
> ...
>
> >  In the case where the RM Destination wishes to discontinue use of a
> >  sequence it may choose to 'close' the sequence itself.  In cases where
> >  the RM Destination wishes to generate a Fault but still allow RM
> >protocol
> >  messages (for example, AckRequested) but not allow any new application
> >  messages to be processed it may use the SequenceClosed Fault in 
> place of
> >the
> >  SequenceTerminated fault.  Since the SequenceTerminated fault may
> >  result in the state information about the sequence to be reclaimed,
> >  use of the SequenceClosed fault will allow the RM Source to still
> >  retrieve a final and accurate accounting of the state of the sequence.
> >  
> >
> I find the above fairly difficult to parse.  The choices I see for the
> RMD are to send a <SequenceAcknowledgement/> containing <Final/> or to
> issue a Sequence Closed fault.  The first choice is not covered above.  
> The second choice is covered but might be more clear without repeating
> text from elsewhere.  How about:
>
>    In the case where the RM Destination wishes to discontinue use of a
>    sequence it may 'close' the sequence itself.  Please see wsrm:Final
>    above and the Sequence Closed fault below.
>
> >  When a Sequence is closed and there are messages at the RM 
> Destination  
> >
> >  that are waiting for lower-numbered messages to arrive (such as the  
> >  case when InOrder and ExactlyOnce delivery assurance is being 
> enforced)  
> >
> >  before they can be delivered to the RM Destination's application, 
> the RM
> >
> >  Destination MUST NOT deliver those messages.
> >  
> >
> The above seems untestable and invisible on the wire.  It also applies
> MUSTs to the RMD to AD interface which go much further than the rest of
> the WS-RM specification, potentially to the detriment of the DA ("almost
> perfect in-order with warnings" anyone?).  A RMD implementation which
> delivers all messages to the AD but clearly identifies the existence of
> gaps should be allowed.  I recommend deleting this paragraph.
>
> >  The following exemplar defines the <wsrm:Closed> syntax:  
> >
> >  /wsrm:CloseSequenceResponse
> >
> I hope you mean <wsrm:CloseSequenceResponse> on the line above.
>
> thanx,
>    doug
>
>