OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-caf message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [ws-caf] Revised MustUnderstand Proposal


I don't see the problem in the proposal. The Qname is asserted as the 
basis for understanding the protocol, the type goes away. Recognizing 
the header (which in the proposal is innately bound to the protocol) 
when required is a function of the MU semantics. That protocol we 
happily don't need to spell out because it is well understood and 
specified elsewhere.

Whether there is some problem in processing the header is another matter 
altogether and not in scope for this issue.

Greg

Furniss, Peter wrote:

>Greg,
>
>It doesn't satisfy my concerns because I'm not sure what the impact
>would be on the spec. (Your original message of 12 April just discusses
>the situation, but doesn't actually make proposals as to what should be
>in the spec and required of implementations)
>
>Failure of processing due to other problems is different. Let us confine
>ourselves to the case of receiver ignorance of the semantics of some
>part of a header that is marked as critical.
>
>Thinking this through as I write:
>
>thought sequence A:
> i) an implementation that is aware of ws-context will attempt to
>process a context header, regardless of soap:mustUnderstand
> ii) if it finds it doesn't know the particular context type, it sends
>back a fault
> iii) soap's mustUnderstandFault is only allowed if soap:mustUnderstand
>was true (is that correct ?)
> iv) thus the fault in the absence of soap:mustUnderstand had to be
>ws-context defined
> v) it's absurd to have two different faults for the same failure to
>understand
> vi) therefore ws-context needs to define a "type not understood" fault.
>
>thought sequence B:
> i) the purpose of the soap:mustUnderstand is to allow the sender to
>declare that some header is critical to the processing of the message
> ii) if the context type isn't understood (though context itself is),
>then the receiver needs only to know if the processing of the header is
>critical to the processing of the message
> iii) if soap:mustUnderstand is not true, then it is known the header is
>useful, not critical, so it can be ignored however far in it got
> iv) the context header should be taken as a whole, and failure to
>understand part of it should be taken as failure to understand all of
>it. The semantics of the top-level element of the header are
>incompletely defined and are only fully defined by the inner elements.
>
>In terms of what makes sense, I prefer sequence B above, though that
>does end up interpreting the spirit of the SOAP spec rather than
>following the letter (not something I'd normally like to do with a
>standards). That requires only that we specify some behaviour.
>
>If B is considered unacceptable, then I guess we must follow A. Which
>means we must at least define a fault value.  I'd suggest we avoid
>another attribute of our own by saying that the soap:mustUnderstand is
>taken to have implications for the need for understanding the inner
>elements of the header. But the extra fault is only needed to avoid what
>seems to be over-precise statements in the SOAP spec. (Does anyone know
>if the issue of non-recognition of inner elements was discussed in the
>SOAP group ?)
>
>Peter
>
>  
>
>>-----Original Message-----
>>From: Greg Pavlik [mailto:greg.pavlik@oracle.com]
>>Sent: 20 April 2005 14:25
>>To: Kevin Conner
>>Cc: ws-caf
>>Subject: Re: [ws-caf] Revised MustUnderstand Proposal
>>
>>
>>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
>>>
>>>      
>>>
>>    
>>
>
>  
>



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]