W3C home > Mailing lists > Public > public-ws-addressing@w3.org > March 2006

Re: ISSUE: Where do faults go?

From: Christopher B Ferris <chrisfer@us.ibm.com>
Date: Mon, 13 Mar 2006 12:12:07 -0500
To: "Glen Daniels" <gdaniels@sonicsoftware.com>
Cc: public-ws-addressing@w3.org, public-ws-addressing-request@w3.org
Message-ID: <OF62D28F96.A664E23D-ON85257130.005D4362-85257130.005E7D3C@us.ibm.com>

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 


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
Received on Monday, 13 March 2006 17:12:20 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:04:13 UTC