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

ISSUE: Where do faults go?

From: Glen Daniels <gdaniels@sonicsoftware.com>
Date: Mon, 13 Mar 2006 10:51:09 -0500
Message-ID: <80A43FC052CE3949A327527DCD5D6B270198683E@MAIL01.bedford.progress.com>
To: <public-ws-addressing@w3.org>

Hi folks:

Sorry for the last-minute issue, but this just came up as a result of

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


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

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


[1] http://www.w3.org/2002/ws/addr/testsuite/testcases/#test1242
Received on Monday, 13 March 2006 15:52:41 UTC

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