- From: Glen Daniels <gdaniels@sonicsoftware.com>
- Date: Mon, 13 Mar 2006 16:10:05 -0500
- To: "Christopher B Ferris" <chrisfer@us.ibm.com>
- Cc: <public-ws-addressing@w3.org>, <public-ws-addressing-request@w3.org>
Hi Chris: > > > 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. > > > > This I'm not sure I agree with. If I send you a single, valid, > > non-anonymous FaultTo header, and duplicate ReplyTo headers (or any > > other WSA screwup), wouldn't you want the fault on the > FaultTo EPR? I > > Possibly, but what if the fault is generated *before* the > [fault to] is parsed/processed? Are you suggesting that if a > fault is generated that processing of the WS-A headers is to > continue? That seems a little odd to me. If you have an > endpoint that is sending garbage in regards to [reply > endpoint], what expectation would you have that the remaining > MAPs are coherent? I'd just as soon consider the whole lot as > tainted and send the fault as if WS-A were not being used. Well, I'm pretty sure that we don't say anything remotely resembling this. If we wanted this behavior (ignore ALL WSA headers if there's a fault with ANY of them) we would need to make this "WSA processing model" explicit. I'm not saying it would be a bad idea, even - just that it would be a serious change. > > suppose actually you need a valid FaultTo and also a valid > MessageID > > for correlation in that case, though - but assuming those, wouldn't > > you send other faults to FaultTo? > > I'm not convinced. However, the case I was making, possibly > poorly, is that no matter what [fault to] says, that the > sender of a (request) message MUST be prepared to receive a > fault as if WS-A were not in use. That is certainly true, though orthogonal to the point above, I think. --Glen
Received on Monday, 13 March 2006 21:11:24 UTC