Re: [ws-caf] Revised MustUnderstand Proposal

[Greg Pavlik <greg.pavlik@oracle.com>]

The issue was raised by feedback to the CD version of WS-Context: there 
was a misunderstanding of how SOAP MU semantics are applied: 
specifically, in recognition of the header element type. In WS-Context, 
there's no basis for discriminating on the basis of specific protocol 
types as the "uber protocol" is identified by the type uri, not the 
QName of the header element. This proposal suggests that the protocol 
should be reflected in the QName, that the protocol type URI be removed, 
and that subprotocols be supported in WS-CF (which I believe has already 
been approved).

Greg


Mark Little wrote:

>Greg, for clarity can you re-phrase the issue and the proposal as it would now 
>stand, given the input. I'm still confused as to what is issue and what is 
>proposal.
>
>Mark.
>
>  
>
>>===== Original Message From Greg Pavlik <greg.pavlik@oracle.com> =====
>>Peter,
>>
>>Does this satisfy your concern? Does anyone else have comments on this?
>>I'd like to close out some of these basic issues so we can lock down
>>context/coordination and move on to the transaction space in the next
>>few weeks.
>>
>>Greg
>>
>>Kevin Conner wrote:
>>
>>    
>>
>>>Furniss, Peter wrote:
>>>
>>>      
>>>
>>>>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".
>>>>        
>>>>
>>>My understanding of this statement is that a SOAP node must have some
>>>mechanism of processing the header identified by the outer element and
>>>whether this processing is successful or not is another issue.
>>>Identification and handling of extensions is, to my mind, part of the
>>>processing stage.
>>>
>>>If the header arrives without the mustUnderstand attribute, and the
>>>SOAP node decides that it should handle it in any case, then I would
>>>hope that errors in processing would be handled in the same way.
>>>
>>>      
>>>
>>>>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 :-)
>>>>        
>>>>
>>>I would certainly like to see a context specific fault representing an
>>>unknown addressing specification. :-)
>>>
>>>   Kev
>>>
>>>      
>>>
>
>
>
>  
>