- From: Glen Daniels <gdaniels@sonicsoftware.com>
- Date: Mon, 13 Mar 2006 16:05:51 -0500
- To: "David Orchard" <dorchard@bea.com>, "Christopher B Ferris" <chrisfer@us.ibm.com>, "David Hull" <dmh@tibco.com>
- Cc: <public-ws-addressing@w3.org>
Yo: > 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 here. 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. Thoughts? --Glen
Received on Monday, 13 March 2006 21:07:29 UTC