RE: [ws-caf] Revised MustUnderstand Proposal

[Kevin Conner <Kevin.Conner@arjuna.com>]

I knew I should have logged in yesterday :-)

On Wed, 20 Apr 2005, Furniss, Peter wrote:
> 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 ?)

I believe that A is the correct choice but do not agree with the
overloading of the soap:mustUnderstand attribute.  The reason for this is
that there are SOAP frameworks that handle the processing of the attribute
without deferring to the header processing code.

The SOAP implementations I have used generally fall into two distinct
categories, either a stack of interceptors that can process the message as
it passes or a set of handlers that are registered with the framework.

The interceptor frameworks allow the interceptors to perform any
processing (thus allowing B), requiring them to be aware of the
soap:mustUnderstand attribute and to indicate that compulsory headers have
been processed by modifying a message context.  This context is then
checked before processing the SOAP body.

The handler frameworks require the handler to be registered using the
namespace/local name of the header element.  They differ in how this is
configured (XML files, programmatically or a method on the handler) but 
they tend to enforce the soap:mustUnderstand attribute independently of
the handlers, the existence of the handler qualifying as understanding.

My understanding, as I previously stated, is that the soap:mustUnderstand 
attribute only requires the endpoint to be able to process the header 
element and not that this should be successful.  I believe these are
different aspects and should be treated as such.

The question I have regarding B is how to differentiate between an
endpoint that supports the element but not the extension and one that
doesn't support the element?  I believe that SOAP 1.1 requires the
definition of additional header elements to differentiate whereas 1.2
allows sub codes within the must understand fault.

	Kev