New Issue: "must understand" attribute for extensions to RM components

All 
of the Sequence Lifecycle Messages (<wsrm:CreateSequence>, <wsrm:CreateSequenceResponse>, <wsrm:CloseSequence>, <wsrm:CloseSequenceResponse>, <wsrm:TerminateSequence>, and <wsrm:TerminateSequenceResponse>) and RM 
Protocol Header Blocks (<wsrm:Sequence>, 
<wsrm:AckRequested>, and <wsrm:SequenceAcknowledgement>) define extension 
points for adding additional elements to the message, however, there is 
currently no mechanism for the sending party (e.g. the RMS in the case of a 
<wsrm:CreateSequence> message or the RMD 
in the case of a <wsrm:TerminateSequence> 
message) to indicate to the receiving party that it must understand the 
semantics implied by the extension element(s).  The usefulness of these 
extension points is therefore imited by the fact that, in general, the sending 
party cannot be certain whether the receiving party understood the extension or 
is simply ignoring it.

 

 

Proposal:

 

(add to Glossary 
section) 

1.1 
Glossary

The following glossary defines a 
set of terms used to describe some of the different messages related to 
WS-RM:

Sequence Lifecycle 
Message: A message that contains one of: <wsrm:CreateSequence>, <wsrm:CreateSequenceResponse>, <wsrm:CloseSequence>, <wsrm:CloseSequenceResponse>, <wsrm:TerminateSequence>, <wsrm:TerminateSequenceResponse> as the child element of the <soap:Body> element.

RM 
Protocol Header Block: One of <wsrm:Sequence>, <wsrm:SequenceAcknowledgement>, or <wsrm:AckRequested> elements.

RM Component: 
One of the elements that either make up the body of a Sequence Lifecycle Message 
or that appears as an RM Protocol Header Block.

Sequence Traffic Messsage: 
A message that contains a <wsrm:Sequence> header block.

Acknowledgement Message: A 
message that contains a <wsrm:SequenceAcknowledgement> header block.

(add to Section 3)

3.7 Extension 
Elements

The definition of each of the RM 
Components includes an extension point that allows the addition of elements to 
that RM Component. It is likely that specifications for a wide 
variety of extensions to these RM Components (termed “RM extensions” for the 
purposes of this discussion) will be developed over time and that some RM nodes 
might include the software necessary to implement one or more such extensions. 
An RM extension is said to be understood by an RM node if the software at that 
RM node has been written to fully conform to and implement the semantics 
specified for the XML expanded name of the outer-most 
element information 
item of the extended element.

An RM extension 
element MAY carry a mustUnderstand attribute information 
item. When the value of such an 
attribute information 
item is "true", the 
RM extension is said to be mandatory.

Mandatory RM extension elements are presumed to modify 
the semantics of other RM Components. Therefore, for every mandatory RM 
extension recieved by an RM node, the receiving node MUST either process the 
element or not process the element at all, and instead generate a 
wsrm:MustUnderstandFault. Tagging RM extensions as mandatory thus assures that 
such modifications will not be silently (and, presumably, erroneously) ignored 
by the RM nodes that recieve the messages containing extended RM 
Components.

(add to Section 4)

4.9 
MustUnderstandFault

This fault is generated when an RM node (RMS or 
RMD) is presented with a Sequence Lifecycle Message or RM Protocol Header Block 
that contains an extension that is tagged with a wsrm:mustUnderstand attribute with a value of "true" and that node does 
not understand that extension element.

Properties:

[Code] Client or Server (as 
appropriate)

[Subcode] 
wsrm:MustUnderstandFault

[Reason] Do not understand the extension marked 
as "must understand"

[Detail]    
xs:any