[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 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/@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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]