Regarding "Proposed resolution for issue 129"

["Murray, Bryan P." <bryan.murray@hp.com>]

I assume the intended 'mustUnderstand' here is the SOAP:mustUnderstand
and not the one defined in WS-Context as an attribute of the element
participating-services.

The wording of the ballot is slightly confusing so I want to clarify
that responding "Yes" means that WS-Context should not require a value
for the SOAP:mustUnderstand attribute.

Please advise.


<BryansOpinion>
The SOAP:mustUnderstand attribute is so that a client can indicate to a
service that if the service does not understand the specified header,
the request must fail.

Use of the SOAP:mustUnderstand attribute cannot mandate the service to
understand the header - either the service understands it or not. If it
does not understand it the rule is that it must fault.

A service has a similar mechanism to express that a header is required.
It can fault if a received message does not contain the header -
independent of whether the header contains the SOAP:mustUnderstand
attribute. In fact, it can even optionally advertise the need for the
required header in its WSDL.

I don't think that any spec should mandate that the SOAP:mustUnderstand
attribute be set to a certain value. This is the prerogative of the
client. Maybe the client is sending the header just in case the service
understands it in which case there is some higher level of capability
that can be provided by the service.

However, I think it is perfectly reasonable for a spec to require that a
service generate a fault if a required header is not present. But this
has nothing to do with the SOAP:mustUnderstand header. So in the case of
WS-Context, I think every message that must contain a context header
must describe a fault that can be generated if the context header is
missing.
</BryansOpinion>


Bryan