New proposed issues 11/17 - 11/30

["Marc Goodner" <mgoodner@microsoft.com>]

Let me and the list know if any were missed.

Regards,
Marc g

Proposed-01
Title: Semantics of offered Sequences

Proposed-02
Title: How does a RM Destination reject an offered Sequence?

-------------------------------
Proposed-01
Title: Semantics of offered Sequences
Origin: Matt Lovett
http://lists.oasis-open.org/archives/ws-rx/200511/msg00205.html 

Description: 
The current specification explains how a RM Source may offer a Sequence
to the RM Destination, but does not explain what this really means. It
can be read as a protocol optimization, with no deeper semantics. It
could alternatively be assumed that the 2 sequences are linked in some
way - perhaps application replies are expected to travel back on this
sequence (and no other); perhaps the offered Sequence is supposed to
close/terminate when the other Sequence closes/terminates. Someone might
even assume that offers will only be made for request-reply
applications, wheras the absence of an offer implies fire-and-forget
messaging. (I am not advocating this interpretation!) 

We should clarify the specification, so that the reader is fully aware
of the semantic import of offering (or accepting the offer of) a
Sequence. 

Justification: The capabilities in the spec should have clear semantics

Target: core

Type: design

Proposal:
I think that we should clearly state that there is no deep semantic to
offering a Sequence, it is merely a protocol optimization. I think that
the right way to explain that is to add a note into the text that
introduces offer, saying that the use of offer is semantically identical
to not using offer, and then initiating another Sequence between the two
endpoints. Describing this is a little tricky, as we don't want to talk
about creating a Sequence from RM Destination to RM Source.... and we
don't have a term in the spec for the middleware layer that implements
RM in either direction. Here is a concrete proposal: 

Add the following as a continuation of line 256 (using line numbers from
wsrm-1.1-spec-wd-06.pdf): 
Note, offering a Sequence within the <wsrm:CreateSequence> element is
simply a protocol optimization. There is no semantic difference between
offering a Sequence, and choosing not to offer one and subsequently
creating a Sequence to carry messages from the Ultimate Receiver to the
Initial Sender. 

Related issues: None

-------------------------------
Proposed-02
Title: How does a RM Destination reject an offered Sequence?
Origin: Matt Lovett
http://lists.oasis-open.org/archives/ws-rx/200511/msg00206.html

Description:
Section 3.1 lines 254 - 256 in wsrm-1.1-spec-wd-06.pdf says: 
<wsrm:CreateSequence> MAY carry an offer to 
create an inbound sequence which is either accepted or rejected in the 
<wsrm:CreateSequenceResponse>. 

However, there is no way to reject the offered sequence without faulting
the entire CreateSequence message, as lines 348 - 352 also say: 
/wsrm:CreateSequenceResponse/wsrm:Accept 
This element, if present, enables an RM Destination to accept the offer
of a corresponding Sequence for 
the reliable exchange of messages transmitted from RM Destination to RM
Source. This element MUST 
be present if the corresponding <wsrm:CreateSequence> message contained
an <wsrm:Offer> 
element. 

I believe this is inconsistent. We should either define how a RM
Destination can accept an inbound Sequence while rejecting the offer, or
adjust the text in lines 254 - 256 to say that it is not possible. 

Justification: The specification should be consistent.

Target: core

Type: design

Proposal:
As noted above, I can see 2 alternatives. I believe the way to go is to
say that it is not possible to reject an offered Sequence without
rejecting the entire CreateSequence message. 

Reword lines 254 - 256 to read: 
<wsrm:CreateSequence> MAY carry an offer to 
create an inbound sequence which is then accepted in the 
<wsrm:CreateSequenceResponse>. If the RM Destination is unable to accept
the offered Sequence then it MUST respond with a CreateSequenceRefused
fault. 

Related issues: none