Re: ISSUE: Where do faults go?

Glen,

I would put this in the same class as "where do SOAP mU faults get 
delivered". I believe that that
should be a function of the binding, not of WS-A because it is pretty 
clear to me that in the face 
of a SOAP mU (or VersionMismatch) fault, that WS-A processing cannot be 
presumed to have 
been performed (per the SOAP1.2 spec anyway).

Thus, I think that an endpoint that includes a non-anonymous [fault to] 
endpoint SHOULD expect
that it MAY receive SOAP faults in a manner defined as the default for the 
relevant SOAP
binding. In the case of the SOAP Req/Resp MEP and SOAP HTTP binding, that 
would be
the anonymous endpoint.

IMO, if a SOAP message contains WS-A headers that are inconsistent with 
the spec in any way
that the generated fault SHOULD be sent to the endpoint identified by the 
relevant SOAP 
MEP/binding.

Cheers,

Christopher Ferris
STSM, Software Group Standards Strategy
email: chrisfer@us.ibm.com
blog: http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440
phone: +1 508 377 9295

public-ws-addressing-request@w3.org wrote on 03/13/2006 10:51:09 AM:

> 
> 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
>