Re: Summarizing the last 192 discussion

1+3 a Fault is a Fault

noah_mendelsohn@us.ibm.com wrote:

> Henrik Frystyk Nielsen writes:
> 
> 
>>>I think we have to be careful not to encourage 
>>>"smart" implementations and be very crisp on 
>>>that we see it as a buggy implementation.
>>>
> 
> I think we have the following proposed imperatives:
> 
> 1. If a SOAP Body contains a fault, the message is a fault, independent of 
> the binding. (Noah, and others)
> 
> 2. The HTTP status code SHOULD never lie about faults.  (Mark Baker) and 
> maybe take your choice of...
> 2a. Regardless of the envelope, the HTTP code should take precedence.  A 
> SOAP fault received with a 200 cannot be a fault...though I'm not quite 
> sure what it is then! (Mark Baker)
> 2b. Only if there is not a prohibitive performance problem, the receiver 
> should check, note the mismatch, and somehow fault.  Since that takes too 
> long sometimes (Chris), we make the check optional, and give the binding 
> the choice to either decline to receive the message, or to process it per 
> #1.  (Noah)
> 2c. Ignore the performance problem.  The binding must always check for 
> consistency (any advodates?)
> 
> 3. Don't encourage smart implementations. (Henrik)
> 
> We can't have all of these at the same time.  I think the self-consistent 
> combinations are:
> 
>         1+2+2b
> 
>         1+2+2c+3
> 
>         2+2a+3
> 
>         1+3 (always accept the body and process the fault, even if HTTP 
> 200)
> 
> Did I miss any?  Now, which one of these four combinations do we want? 
> Each is a tradeoff in one dimension or another, I think.
> 
> ------------------------------------------------------------------
> Noah Mendelsohn                              Voice: 1-617-693-4036
> IBM Corporation                                Fax: 1-617-693-8676
> One Rogers Street
> Cambridge, MA 02142
> ------------------------------------------------------------------
> 
> 
> 
> 
>

Received on Monday, 1 April 2002 08:06:02 UTC