Hi Chris: > 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). As per usual I'll request that we be crystal-clear when talking about any overused word like "binding"... you mean "SOAP protocol binding", right? :) > 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. Agreed, the question is just how exactly we say that in our specs in such a way as to make the behavior clear for present and future cases. > 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 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? If we DO mean to say that "any WSA screwup always ignores <FaultTo>" we definitely have to make some changes. Regardless we need to be crisper on this. Thanks, --GlenReceived on Monday, 13 March 2006 17:20:39 GMT
This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:35:12 GMT