Re: When is a Fault a Fault?

I don't buy this at all. Any "hint" in the underlying protocol
is just that, a "hint". Some protocols may not have an available
"hint" that can be reused (such as HTTP status response codes)
which suggests to me that the proper way to address this is
within the envelope itself. Any "hint" provided by the underlying
protocol is merely an optimization.

I would suggest that we say that a SOAP Fault is a SOAP
envelope containing a SOAP:Fault element as the first child
element information item of the SOAP:Body element information
item, period. That makes it abundantly clear and unambiguous
to a SOAP processor that this is indeed a SOAP Fault message.

If you wanted to support an edge case such as you describe
whereby a Fault element is carried in the Body of a SOAP
envelope (e.g. the gimme the last Fault you issued request)
but is not considered as a SOAP Fault message then
the appropriate means for doing so would be to either a)
wrapper the Fault element in another element that conveys some
harmless intent (like a SOAP RPC req/resp) or b) add a SOAP
extension header with mU="1" that says in effect "IGNORE the
Fault element in the Body of this message, it is informational
and NOT operational".

I would strongly object to requiring that a binding specification
be responsible for providing a mechanism for communicating what
amounts to little more than a "hint" to the SOAP processor. If they
want to go there, they are free to do so, but we shouldn't be
imposing any requirement that clearly cannot be readily fulfilled
by many communication protocols, email being but one of these.

Cheers,

Chris

Mark Baker wrote:

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

Received on Monday, 4 March 2002 11:34:58 UTC