Re: When is a Fault a Fault?

Hi Stuart,

> Hi Mark,
> 
> I think that there is a small hook for this in the current HTTP binding and
> it was probably intended to be a larger hook that it currently seems to be.
> A property named "transport:faultHint" is used (once) at the requesting node
> with a boolean value is used to signify the receipt of an HTTP response with
> a 500 status code.

Ah, didn't see that.  If we go with this though, it should also hold
that a Fault is a Fault if it's over 4xx or 5xx.

> We need to include a description this property in the table at the end of
> section 6 [1]. We can also make use of it at the responding node as a means
> by which the responding SOAP processor can instruct the binding that it
> regards the SOAP response as containing a fault.

I'm unclear what you mean by that last sentence, but I reckon that it's
not important to this discussion (right?).

> An interesting question is then how we mark out a simlar use/mention
> distinction in the email binding.

Good point.  I haven't looked at it yet.  I'll try to do that soon.

> There are a number of cases that your question brings up:
> 
>   a) marking of faults carried in HTTP requests 
>      (eg. a one-way message reporting a fault in some TBD MEP)
> 
>   b) receipt of an HTTP (POST?) response, status code 500, containing 
>      a SOAP envelope that does *not* contain a SOAP fault.
> 
>   c) receipt of an HTTP response, status code <> 500, containing 
>      a SOAP envelope that *does* contain a SOAP Fault.

Right.

> The original intent of "transport:faultHint" was not so much as to enable
> the 'use'/'mention' distinction that you cite on your question. I'm not sure
> that I really want to go there. I think for the 'mention' use-case that you
> raise I would prefer to see a way to quote faults inside a SOAP message.
> That way, the primary way to know whether a fault is a fault is merely its
> unquoted presence in a SOAP message. Yes... do the right thing with the
> status codes underneath aswell... but make the distinction clear in the SOAP
> message.

Which mechanism are you suggesting be authoritative?  I would be
uncomfortable with using anything other than the success/fail mechanism
of the underlying protocol, where present.  And where it's not present,
I don't think it matters much how it's determined, as long as it's
standardized in the binding.

Another option is including some information within the envelope to
indicate the intent, but that feels uncomfortable to me.  Not sure
why exactly, but I'll think more about it.

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@planetfred.com
http://www.markbaker.ca   http://www.planetfred.com

Received on Monday, 4 March 2002 10:37:33 UTC