W3C home > Mailing lists > Public > xml-dist-app@w3.org > March 2002

RE: Summarizing the last 192 discussion

From: <noah_mendelsohn@us.ibm.com>
Date: Fri, 29 Mar 2002 21:37:05 -0500
To: "Henrik Frystyk Nielsen" <henrikn@microsoft.com>
Cc: "Christopher Ferris" <chris.ferris@sun.com>, distobj@acm.org, xml-dist-app@w3.org
Message-ID: <OF5C859BCB.CF3CBFC9-ON85256B8C.000FA3C5@lotus.com>
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+3 (always accept the body and process the fault, even if HTTP 

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 Friday, 29 March 2002 21:54:16 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:11:48 UTC