Re: Changing the default value of mustUnderstand to "true"

The mU proposal reminds me of a true story from years ago at a place where 
I worked.  They had an employee  "suggestion program", and suggestions 
relating to safety were particularly welcome.  An employee suggested that 
one particular door was hinged on the wrong side, and would be safer 
openning the other way.  He was right.  The hinges were moved, the 
employee got a $25 check for the suggestion, and for months everyone got 
hurt banging their heads as the door opened in a way they did not expect. 
(Amazingly, the same employee got another later for suggesting that it be 
put back the original way.)

Even if the mU default is sub-optimal in principal, it's been this way 
since before I've been involved with SOAP.  Everyone who uses SOAP expects 
the current convention.  Yes, a namespace change makes the new convention 
safe on paper, but in practice, I think people will "bang their heads on 
the door."  Furthermore, now that we're in last call, I think the bar has 
to be very, very high on functional changes.  If we change now, either our 
users don't get to review the change, or we have to go back to last call.

So, while I don't disagree in principle, I'd leave it.  Thanks.

Noah Mendelsohn                              Voice: 1-617-693-4036
IBM Corporation                                Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142

"Jean-Jacques Moreau" <>
Sent by:
07/03/02 04:08 AM

        To:     Hugo Haas <>
        cc:     "" <>, (bcc: Noah 
        Subject:        Re: Changing the default value of mustUnderstand to "true"

Personally, I disagree. I think the general expectation is that all header 
blocks will be processed,
where mU or not. However, some may be ignored, for a variety of reasons. 
mU signals blocks that, if not
processed, would significantly alter the processing of the entire message.

IMO, this is very similar to XML processing. An XML processor may (in 
certain circumstances) decide to
ignore certain elements, such as the ones it does not understand. So I see 
the default for XML as
mU="false", although formally XML does not have any such element (unless 
you count DTDs or Schemas;


> Date: Mon, 1 Jul 2002 15:52:50 -0400
> From: Hugo Haas <>
> To:
> Subject: Changing the default value of mustUnderstand to "true"
> Hi.
> The default value of the mustUnderstand Attribute is "false"[1]:
> |   The type of the mustUnderstand attribute information item is boolean
> |   in the namespace "".
> |
> |   Omitting this attribute information item is defined as being
> |   semantically equivalent to including it with a value of "false" or
> |   "0".
> Having a header block without mustUnderstand set to "true" allows the
> SOAP node supposed to process this block to ignore it as shown in
> 2.7.1 Forwarding Intermediaries[2]:
> |   Forwarding intermediaries MUST process the message according to the
> |   SOAP processing model defined in 2.6 Processing SOAP Messages. They
> |   MUST also remove from the message all SOAP header blocks targeted at
> |   themselves, prior to forwarding, regardless of whether these header
> |   blocks were processed or ignored.
> and in 2.6 Processing SOAP Messages[3]:
> |    4. Process all header blocks targeted at the node and, in the case 
> |       an ultimate SOAP receiver, the SOAP body. A SOAP node MUST 
> |       all SOAP header blocks targeted at it. A SOAP node MAY choose to
> |       ignore the application level processing specified by 
> |       SOAP header blocks targeted at it.
> The probability that somebody included a header and really wants
> something to happen as a result of its processing is high. The
> probability that the person doesn't care if the header is ignored is
> low.
> For example, every header block used as examples in the primer[4]
> (that I saw) uses env:mustUnderstand="true".
> It therefore seems natural to make "true" the default value for
> mustUnderstand.
> Regards,
> Hugo
>   1.
>   2.
>   3.
>   4.
> --
> Hugo Haas - W3C
> - - tel:+1-617-452-2092

Received on Wednesday, 3 July 2002 09:26:25 UTC