RE: [ws-caf] Revised MustUnderstand Proposal

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

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
> >
> 
>