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