RE: [ws-rx] New issue

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

Makes sense, this one might be to big to swallow on tomorrow's call but
maybe we should try. :-)

-----Original Message-----
From: Matthew Lovett [mailto:MLOVETT@uk.ibm.com] 
Sent: Friday, June 09, 2006 1:47 AM
To: ws-rx@lists.oasis-open.org
Subject: [ws-rx] New issue

Hi all,

Here is another new issue based off WD 13.

Thanks

Matt


Title - Offer/Accept elements are incomplete

Description:
The use of Offer/Accept to create an inbound sequence should carry
equivalent information as a CreateSequence/CreateSequenceResponse (in
the other direction). A simple test for this is to look at the child
elements of CreateSequenceResponse and compare them to Offer, and then
apply the same test to Accept & CreateSequence. Currently there are
differences:


CreateSequenceResponse compared to Offer: (e.g. the information the RMD
transmits to the RMS) Both have: Identifier, Expires
- These are ok, though the meaning of Expires is different, as on Offer
it is the RMD's decision, so this is a statement rather than the start
of a negotiation.

Offer has additional: Endpoint
- This is ok, and is a necessary addition (see i090)

CreateSequenceResponse has additional: AcknowledgementInterval,
IncompleteSequenceBehaviour
- The RMS should not dictate these settings, and we cannot assume that
they are the same as for the outbound sequence, so we should add these
elements to the Offer.


CreateSequence compared to Accept: (e.g. the information that the RMS
transmits to the RMD) Both have: AcksTo

Accept has additional: none

CreateSequence has additional: Expires
- This is ok, as the RMD has the final say on Expiry. There is no need
to have a matching element in the Accept.


Justification
The Offer/Accept mechanism should have the same information exchange as
a 
CreateSequence/CreateSequenceResponse. If it does not then Offered 
sequences are in some way less capable/flexible/well-defined as 'normal'

sequences, which seems inconsistent.

Target core, schema

Type: design

Proposal:

Add the following to the CreateSequence exemplar (surrounding lines
shown 
for context), there are 2 inserted lines:

  <wsrm:Offer ...>
    <wsrm:Identifier ...> xs:anyURI </wsrm:Identifier>
    <wsrm:Endpoint> wsa:EndpointReferenceType </wsrm:Endpoint>
    <wsrm:Expires ...> xs:duration </wsrm:Expires> ?
!! Insert from here
    <wsrm:AcknowledgementInterval Milliseconds="xs:unsignedLong" ... />
?
    <wsrm:IncompleteSequenceBehavior>
wsrm:IncompleteSequenceBehaviorType 
</wsrm:IncompleteSequenceBehavior> ?
!! End of insert
    ...
  </wsrm:Offer> ?

Add the following after line 250

/wsrm:CreateSequence/wsrm:Offer/wsrm:AcknowledgementInterval
This element, if present, specifies the duration after which the RM 
Destination will transmit an acknowledgement. If omitted, there is no 
implied value.

/wsrm:CreateSequenceResponse/wsrm:Offer/wsrm:AcknowledgementInterval/@Mi
lliseconds
The acknowledgement interval, specified in milliseconds.

/wsrm:CreateSequenceResponse/wsrm:Offer/wsrm:AcknowledgementInterval/@{a
ny}
This is an extensibility mechanism to allow additional attributes, based

on schemas, to be added to the element.

/wsrm:CreateSequenceResponse/wsrm:Offer/wsrm:IncompleteSequenceBehavior
This element, if present, specifies the behavior that the RM Destination

will exhibit upon the closure of an incomplete sequence.

A value of ?DiscardEntireSequence? indicates that the entire sequence
will 
be discarded by the RM
Destination if the sequence is closed when there are one or more gaps in

the SequenceAcknowledgement/Final.

A value of ?DiscardFollowingFirstGap? indicates that messages in the 
sequence beyond the first gap will be discarded by the RM Destination
when 
there are one or more gaps in the

SequenceAcknowledgement/Final.
The default value of ?NoDiscard? indicates that no acknowledged messages

in the sequence will be discarded by the RM Destination.


Finally, the schema needs to be updated to introduce the 2 new child 
elements to the Offer.