wsa:FaultTo unusable for SOAP mustUnderstand faults

[ I realize that the LC period for Core+SOAP is over, but I believe
  that the issue below is substantive and needs to be addressed. ]

wsa:FaultTo has been designed for sending faults to a particular
recipient.

However, it seems that this mechanism doesn't work for SOAP
mustUnderstand faults.

Here is an example:

  <S:Envelope>
   <S:Header>
     <wsa:To>
      http://destination.example/
     </wsa:To>
     <wsa:Action>
      http://action.example/
     </wsa:Action>
     <wsa:FaultTo>
      <address>
       mailto:faults@example.com
      </address>
     </wsa:FaultTo>
     <x:YouDontKnowThisHeader mustUnderstand="true"/>
   <S:Header>
   <S:Body>
     <b:foo/>
   </S:Body>
  </S:Envelope>

I am making the hypothesis that the SOAP receiver will not understand
x:YouDontKnowThisHeader, and will therefore fault with a
mustUnderstand fault.

The SOAP 1.2 processing rules state:

[[

  2.4 Understanding SOAP Header Blocks

[…]

   A SOAP header block MAY carry a mustUnderstand attribute information item (see 5.2.3
   SOAP mustUnderstand Attribute). When the value of such an attribute information item
   is "true", the SOAP header block is said to be mandatory.

   Mandatory SOAP header blocks are presumed to somehow modify the semantics of other
   SOAP header blocks or SOAP body elements. Therefore, for every mandatory SOAP header
   block targeted to a node, that node MUST either process the header block or not
   process the SOAP message at all, and instead generate a fault (see 2.6 Processing SOAP
   Messages and 5.4 SOAP Fault). Tagging SOAP header blocks as mandatory thus assures
   that such modifications will not be silently (and, presumably, erroneously) ignored by
   a SOAP node to which the header block is targeted.

]]

and further:

[[

  2.6 Processing SOAP Messages

   This section sets out the rules by which SOAP messages are processed. Nothing in this
   specification prevents the use of optimistic concurrency, roll back, or other
   techniques that might provide increased flexibility in processing order. Unless
   otherwise stated, processing of all generated SOAP messages, SOAP faults and
   application-level side effects MUST be semantically equivalent to performing the
   following steps separately, and in the order given.

    1. Determine the set of roles in which the node is to act. The contents of the SOAP
       envelope, including any SOAP header blocks and the SOAP body, MAY be inspected in
       making such determination.

    2. Identify all header blocks targeted at the node that are mandatory.

    3. If one or more of the SOAP header blocks identified in the preceding step are not
       understood by the node then generate a single SOAP fault with the Value of Code
       set to "env:MustUnderstand" (see 5.4.8 SOAP mustUnderstand Faults). If such a
       fault is generated, any further processing MUST NOT be done. Faults relating to
       the contents of the SOAP body MUST NOT be generated in this step.

[…]

]]

Based on this, as the SOAP receiver realizes in step 3 above that it
does not understand x:YouDontKnowThisHeader which is a mandatory
header block, the message will not be processed at all, which includes
all WS-Addressing SOAP Header Blocks, and therefore wsa:FaultTo will
*not* be used to send the fault to mailto:faults@example.com.

I believe that marking wsa:FaultTo as mandatory and trying to modify
the SOAP processing rules in our spec as part of understanding it to
make sure a WS-Addressing knowledgeable processor will act on
wsa:FaultTo whatever happens is likely not to work, as the processing
won't go past step 3 if there's an ununderstandable header around.

One work-around *might* be to present the wsa:FaultTo (as well as
other WS-Addressing headers, namely wsa:ReplyTo, wsa:MessageId,
wsa:Action) as metadata which is populated in a way which falls out of
the processing of SOAP header blocks.

In a way, our spec is half-way there by not using the word processing:

[[

   When receiving a message, the abstract properties are populated from their
   corresponding element information items in the message.

]]

However, I believe that it is close to abusing the SOAP specification
as it's hard to argue that reading the metadata which can be found in
SOAP header block and changing the processor's behavior based on it
does not mean processing the SOAP header blocks.

At this point, I'm afraid that I don't have a concrete proposal for
how to use wsa:FaultTo with mustUnderstand faults while following the
SOAP processing model to the letter.

In any case, we need to:
- talk about processing of headers in our SOAP binding document to
  clarify how our spec fits into the SOAP processing model; in
  particular, clarify what happens in case of a mustUnderstand fault:
  is a wsa:FaultTo;
- add the above example message to the test suite with the appropriate
  reference to our spec.

Cheers,

Hugo

-- 
Hugo Haas - W3C
mailto:hugo@w3.org - http://www.w3.org/People/Hugo/