RE: ISSUE: Where do faults go?

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,
--Glen

Received on Monday, 13 March 2006 17:20:39 UTC