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

[Doug Davis <dug@us.ibm.com>]

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.
??

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.

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

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