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

RE: ISSUE: Where do faults go?

From: Glen Daniels <gdaniels@sonicsoftware.com>
Date: Mon, 13 Mar 2006 16:05:51 -0500
Message-ID: <80A43FC052CE3949A327527DCD5D6B270198690A@MAIL01.bedford.progress.com>
To: "David Orchard" <dorchard@bea.com>, "Christopher B Ferris" <chrisfer@us.ibm.com>, "David Hull" <dmh@tibco.com>
Cc: <public-ws-addressing@w3.org>


> I agree with what I think are Chris/Dave's position, that 
> WS-A info MUST not be used for formulating MAPs when an mU 
> fault is generated.
> Said differently, the WS-A header blocks are not treated 
> differently than other header blocks.

+1, absolutely, though I think we've gotten a little off-track here.
This behavior was never in question (IIRC), and the SOAP spec covers us

My issue was with what happens when WSA processing is happening (after
MU processing) and we can't get a consistent FaultTo (or MessageID) MAP
out of the headers because of dups.  I was wondering if the spec is
indeed clear and precise enough to make it obvious how an implementor
should deal in that situation.  According to DaveH, one can "infer" that
[fault endpoint] will be empty if there are multiple <FaultTo> headers,
and therefore we're taken care of (default to [reply endpoint] or
anonymous).  While I don't necessarily disagree, I'd rather see this
more explicitly stated.

Also, there is an interaction with [message id] here - if the [fault
endpoint] property is correctly filled in, but the [message id] property
can't be, what should we do?  A case can be made that since there would
be no way of correlating the fault response to the original request, we
should ignore non-anonymous [fault endpoint]s in that case.
Alternately, we could toss back <RelatesTo>s for ALL the <MessageID>
headers we received (but we'd need to say that) in hopes that the remote
endpoint would be able to deal.... I don't think that sending a fault to
a non-anonymous endpoint with no <RelatesTo>s is a good idea, though.


Received on Monday, 13 March 2006 21:07:29 UTC

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