Re: ISSUE: Where do faults go?

The latest editors' draft says:

    The faults defined in this section are generated if the condition
    stated in the preamble in each subsection is met. They are sent to
    the [fault endpoint], if present and valid. Otherwise they are sent
    to the [reply endpoint] if present. If neither is present faults may
    be sent to the [source endpoint].

(shouldn't the [reply endpoint] have to be "present and valid" and not
just "present", and similar for "if neither is present"?)
Also, I'm not sure when, and in response to what issue, the text above
found its way in.  It's not in the CR draft.

I think this text would mostly answer the question of "where do faults
go" in this particular case (but if wsa:ReplyTo is present but invalid
and wsa:From is missing or invalid, do we revert to anonymous?).  Given
that there was confusion, though, I would like to see a quick summary of
how this fits in with "when is addressing engaged?" (e.g., does an
invalid wsa:Action still engage addressing), and "Tony's timeline" (what
faults are definitely /not/ sent with addressing engaged, what faults
definitely /are/, and which if any do we allow to be handled either way).

As to whether either of the fault endpoints could be considered valid: 
The cardinality of FaultTo is [0 .. 1], so if there are more, /all/ are
invalid.

Glen Daniels wrote:

>Hi folks:
>
>Sorry for the last-minute issue, but this just came up as a result of
>testing....
>
>In the test suite, we have a test [1] for generating a fault when a
>request message contains 2 <wsa:FaultTo> headers.  Imagine a message
>like:
>
><soap:Header>
> <wsa:FaultTo>
> 
><wsa:Address>http://www.w3.org/2005/08/addressing/anonymous</wsa:Address
>  
>
> </wsa:FaultTo>
> <wsa:FaultTo>
>  <wsa:Address>http://some-other-address</wsa:Address>
> </wsa:FaultTo>
> ...
></soap:Header>
>
>The question is - where should the InvalidAddressingHeader fault go?  I
>see three possible choices:
>
>1) to the first <FaultTo>
>2) to the second <FaultTo>
>3) to the default (anonymous? see below)
>
>The test assumes that the fault will be delivered via the HTTP
>backchannel, i.e. to anonymous.  But I can't find anything in the spec
>that would constrain an implementation to do so - in other words, it
>might be just as valid to try to send it to http://some-other-address.
>Therefore either the test is wrong to make the assumption, or the spec
>should be clarified.
>
>I do think that in the case where we cannot correctly convert SOAP
>headers into an appropriate MAP, the value for that MAP should not be
>set (and in this case would therefore default to anonymous) - perhaps
>this is the intent, but we should really be explicit about this if
>that's what we mean.
>
>Another question also arises - in the case where we have a problem
>generating the [FaultTo] MAP from the headers, should the generated
>fault be delivered to the [ReplyTo] address if there is one, or always
>to anonymous?  I'd guess the former, but again we should make sure we're
>clear and explicit about it.
>
>I'd propose we fix this by adding something like the following at the
>end of the last paragraph in section 3.2: "In that case, any duplicated
>headers MUST NOT be used to populate the appropriate MAPs - the MAPs
>should be interpreted as if no such headers were present."  I *think*
>this should do it, and since we're already clear about the lack of an
>explicit FaultTo causing faults to go to ReplyTo, I think we're covered
>there.
>
>I'd also like to add, for clarity, section headings for the last two
>paragraphs of section 3.2:
>
>3.2.1 Sending Messages
>
>3.2.2 Receiving Messages
>
>Thanks,
>--Glen
>
>[1] http://www.w3.org/2002/ws/addr/testsuite/testcases/#test1242
>
>
>  
>