Re: [ws-rx] NEW ISSUE: Inefficient close/terminate of offered sequences

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

Marc,

I think you've previously asked us not to extend threads starting from 
NEW ISSUE.  What should the subject now be?

Paul,

A few questions...

On 16/05/06 14:44, paul@wso2.com wrote:
> Description:
> Currently the spec allows one side to optimise creation of two sequences
> using the Offer. However, to close and/or terminate a pair of sequences
> requires a pair of request-response operations.
> To properly initiate and terminate a two-way reliable messaging exchange
> therefore has an overhead of 3 extra message exchanges (Create+Offer,
> TermSeq outbound, TermSeq inbound). A simple improvement is to allow the
> client to optionally close and/or terminate the offered sequence at the
> same time as the outbound sequence. Note this is not attempting to tie the
> two sequences together. It is an option to leave the offered sequence
> open. The attached sequence diagram shows the overhead when a single
> req-resp is used.
>   
What prevents an RMS or RMD putting 2 close or terminate sequence 
requests in the same message?  Each exchange is carefully identified and 
may be handled separately without conflict.
> Target: core
>
> Type: design
>
> Proposal:
>
> Based on WD12
>
> At line 446 add:
> <wsrm:Offer><wsrm:Identifier>xs:anyURI</wsrm:Identifier>...</wsrm:Offer>?
>
> At line 484 add:
> /wsrm:TerminateSequence/wsrm:Offer
> This element, if present, enables the RM Source to signal that it is
> terminating an Offered Sequence. This MUST only be used to terminate a
> sequence that was established through <wsrm:Offer>. It is RECOMMENDED that
> a final SequenceAcknowledgement header for the Offered Sequence is
> included with this message.
>   
The MUST doesn't require that Offer be used to close a sequence opened 
as part of the same create sequence exchange.  Was that intentional?

The RECOMMENDED seems a higher bar than set in the regular termination 
exchange.  Why is a sequence acknowledgement needed in this case but not 
the regular one?

i093 crops up again in your proposed changes, though more below than in 
this first section.  Don't personify elements or attributes.  Instead, 
state what the RMS and / or RMD MUST / MAY / SHOULD do.
> /wsrm:TerminateSequence/wsrm:Offer/wsrm:Identifier
> This REQUIRED element MUST contain an absolute URI conformant with RFC3986
> [URI] that uniquely identifies the offered Sequence that is to be
> terminated.
>
> /wsrm:TerminateSequence/wsrm:Offer/{any}
> This is an extensibility mechanism to allow different (extensible) types
> of information, based on a schema,
> to be passed.
>
> /wsrm:TerminateSequence/wsrm:Offer/@{any}
> This is an extensibility mechanism to allow additional attributes, based
> on schemas, to be added to the
> element.
>
>
> At end line 492 insert:
>
> A TerminateSequenceResponse message sent in response to a message
> containing wsrm:TerminateSequence/wsrm:Offer shall be taken to indicate
> that the RM Destination has received the signal that the Offered Sequence
> is terminated.
>   
How does an RMD fault the offer but not the "main" sequence identified 
in the terminate sequence request?  Visa versa?
> After line 405 insert:
>   
Why are we moving through the document in this order?

thanx,
    doug
> /wsrm:CloseSequence/wsrm:Offer
> This element, if present, enables the RM Source to signal that it is
> closing an Offered Sequence. This MUST only be used to close a sequence
> that was established through <wsrm:Offer>. A final SequenceAcknowledgement
> header for the Offered Sequence MUST be included with this message.
>
> /wsrm:CloseSequence/wsrm:Offer/wsrm:Identifier
> This REQUIRED element MUST contain an absolute URI conformant with RFC3986
> [URI] that uniquely identifies the offered Sequence that is to be
> terminated.
>
> /wsrm:CloseSequence/wsrm:Offer/{any}
> This is an extensibility mechanism to allow different (extensible) types
> of information, based on a schema,
> to be passed.
>
> /wsrm:CloseSequence/wsrm:Offer/@{any}
> This is an extensibility mechanism to allow additional attributes, based
> on schemas, to be added to the
> element.
>
> After line 435 insert:
>
> A CloseSequenceResponse message sent in response to a message containing
> wsrm:CloseSequence/wsrm:Offer shall be taken to indicate that the RM
> Destination has received the signal that the Offered Sequence is closed.
>   
>
> ------------------------------------------------------------------------
>