New issue

[Matthew Lovett <MLOVETT@uk.ibm.com>]

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/@Milliseconds
The acknowledgement interval, specified in milliseconds.

/wsrm:CreateSequenceResponse/wsrm:Offer/wsrm:AcknowledgementInterval/@{any}
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.