RE: mustUnderstand on the client side

Below is my contribution to the mustUnderstand discussion. Let me add the
caveat that I've just skimmed the discussion on the mailing list, and have
not read everything in detail. Actually, I think maybe what I have to say is
somewhat orthogonal to the current discussion. My basic question is: "What
use is mustUnderstand anyway?"

F

The SOAP spec states:

<quote>
If a header element is tagged with a SOAP mustUnderstand attribute with a
value of "1", the recipient of that header entry either MUST obey the
semantics (as conveyed by the fully qualified name of the element) and
process correctly to those semantics, or MUST fail processing the message
(see section 4.4).

The SOAP mustUnderstand attribute allows for robust evolution. Elements
tagged with the SOAP mustUnderstand attribute with a value of "1" MUST be
presumed to somehow modify the semantics of their parent or peer elements.
Tagging elements in this manner assures that this change in semantics will
not be silently (and, presumably, erroneously) ignored by those who may not
fully understand it.
</quote>

Now, if I am a recipient of a message with a header entry with
mustUnderstand="1", there's simply no way in hell you can FORCE me to
"process correctly to those semantics." I am quite free to ignore the
attribute. The worst thing that can happen is that I will be in
non-compliance with the spec. Now, if I'm truly unscrupulous, I'm not going
to care about that. I'm simply going to say: "Heck yeah, I processed it
correctly." Even if I am scrupulous, I may think I processed "correctly to
those semantics," when, in fact, I did not. Thus, the claim in the SOAP spec
that "[t]agging elements in this manner assures that this change in
semantics will be not be ... ignored" seems IMHO false. Simply adding the
mustUnderstand attr provides no such assurance.

The only way to guarantee that the recipient "processes correctly to those
semantics" is to require the recipient to return some kind of token to the
sender that proves the recipient correctly understood and processed the
header entry. Presumably, this token would be in the form of a header item.
Also, if the messaging were not reliable and the response message carrying
this token got lost on the way back, the client would incorrectly assume
that the recipient had not "processed correctly to those semantics," when
the server actually had. Thus, if guaranteeing that the recipient "processes
correctly to those semantics" requires the recipient to return proof that he
did and to do so reliably, then such a guarantee can only be made if the
exchange pattern is request-reply and messaging is reliable.

So, it would seem that the correct way to achieve the "assurance" aimed at
by the authors of the SOAP spec would be to require the server to reliably
return a token that provides such an assurance. Given such a mechanism, the
mustUnderstand attribute would seem superfluous.

The authors of the SOAP spec are aiming at an "assurance." Such an assurance
can only be obtained through a combination of trust and reliability
mechanisms.

Received on Wednesday, 2 May 2001 16:44:06 UTC