RE: [ws-caf] Revised MustUnderstand Proposal

["Furniss, Peter" <Peter.Furniss@choreology.com>]

The proposal doesn't seem to say anything about mustUnderstand ! Is the
text complete ? Taking the whole, it might have had a paragraph saying
what a receiver was to do if it understood the header in general, but
not in detail.

SOAP 1.2 says "A SOAP header block is said to be understood by a SOAP
node if the software at that SOAP 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 that header block". 

Does an soap header-specifying spec (like ws-caf) have then to define
its own "header not fully understood" fault, or can it interpret "fully
conform to and implement" as including the effects of values which are
not recognised, but known (by their placement or type) to be critical to
the full implementation of the senders intent.  It would seem mildly
perverse of SOAP to say we must define our own fault merely because they
have been selfish with theirs :-)

Peter

> -----Original Message-----
> From: Greg Pavlik [mailto:greg.pavlik@oracle.com] 
> Sent: 12 April 2005 20:47
> To: ws-caf
> Subject: [ws-caf] Revised MustUnderstand Proposal
> 
> 
> And inline this time for Doug....
> 
> There is currently a problem with respect to Must Understand 
> semantics 
> (MUS) in WS-CAF: the context type is a neutral type that can 
> be used to 
> represent an activity of a single protocol domain. For example, a 
> Context may include a URI indicating the activity is an atomic 
> transaction type. At the same time, the specifications want 
> to preserve 
> MUS associated with SOAP processing rules. These rules are associated 
> specifically with the outermost XML element type in the SOAP headers, 
> not data elements within the enclosing header element.
> 
> This proposal seeks to resolve this problem with the following 
> recommendations:
> 
> 1) To preserve compatibility with the SOAP processing model, 
> protocols 
> should subtype the base context type with a derived type 
> specific to the 
> protocol domain. For example, an atomic transaction protocol would 
> define an atomic transaction context type that would be 
> useable in the 
> context of the SOAP processing rules.
> 
> 2) The type element in the base context type becomes redundant to the 
> information encoded in the enclosing context element based on this 
> proposal. However, many protocols have "subprotocols": for 
> example, many 
> TP monitors support two phase commit and synchronization 
> capabilities. 
> To eliminate the redundancy and to support subprotocols, zero or more 
> subtype elements may be included in the context structure. 
> The values of 
> the subtype URIs and their semantics are defined by referencing 
> specifications.
> 
> Subprotocols are of interest in establishing relationships between 
> services. This is properly the domain of WS-Coordination 
> Framework. The 
> RegistrationContext should provide infrastructure/syntax to support 
> lists of subprotocol zero or more URIs in RegistrationContexts. It 
> should also allow services to pass lists of zero or more 
> subprotocols to 
> a service when registering for membership in an activity group; group 
> members so registered will receive subsequent signals specific to the 
> subprotocol set for which it has registered interest. A registration 
> message without subprotocols included is assumed to represent the 
> complete set of subprotocols.
> 
>