Re: Issue 192 & R803

Mark Baker writes:

>> If I understood your suggestion correctly, you're saying that a
>> receiving SOAP processor should treat a fault received 
>> over 200, even after acknowledging that it's broken, as a fault.

On the contrary, I said the binding can either notice that the message is 
buggy OR if it hasn't looked inside the message at all (probably for the 
performance reasons that Chris and Ray have mentioned), or did as a 
successfully received message.  Chapter 2 of the soap framework makes 
clear that a fault in such a successfully received message will be treated 
as a fault.

>> The more I think about it, the more this is an R803[1] issue. 

R803 says:

        "XMLP must not preclude the use of transport 
         bindings that define transport intermediary 
         roles such as store-and-forward, proxy and gateway."

How would one argue that even a (purported) serious design flaw in one 
particular binding is an indication that SOAP as a whole precludes the use 
of other bindings that make use of transport intermediaries?  If nothing 
else, it seems trivially apparent that you or anyone could define another 
HTTP binding that would indeed give primacy to the HTTP status code, and 
might in general be more faithful to your views on chameleon.  The 
possibility of that binding shows that we don't have an R803 problem, I 
think.

If you want to argue (and I certainly don't here!)  that something like 
soap RPC causes R803 problems, I would believe that.  I really don't see 
how the existence of a flawed HTTP binding can be an R803 problem, 
particularly since you have a concrete proposal for how the binding could 
be fixed without changing the rest of SOAP. 

So, I think it's quite legitimate for you to argue that my proposal would 
be the wrong one on the merits.  I don't see how it could be an R803 
violation.  Thank you.

------------------------------------------------------------------
Noah Mendelsohn                              Voice: 1-617-693-4036
IBM Corporation                                Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------







Mark Baker <distobj@acm.org>
03/28/02 03:16 PM

 
        To:     noah_mendelsohn@us.ibm.com
        cc:     rayw@netscape.com (Ray Whitmer), chris.ferris@sun.com, xml-dist-app@w3.org
        Subject:        Issue 192 & R803

> Ray Whitmer writes:
> 
> >> Great, I can live with that.
> 
> Terrific, thanks.  Now let's see whether anyone else can :-).

Sorry, but I can't. 8-(

The more I think about it, the more this is an R803[1] issue.  It is
critical, for the chameleon use, that a HTTP intermediary participating
in a chain of SOAP/HTTP intermediaries, have a consistent view of what
the SOAP/HTTP processors understand to be success or failure.  Because
in the chameleon view, this is all happening, SOAP and HTTP, at the
same layer in the stack.

If I understood your suggestion correctly, you're saying that a
receiving SOAP processor should treat a fault received over 200, even
after acknowledging that it's broken, as a fault.  Doing this would
leave the HTTP intermediary out of sync with the SOAP/HTTP
processors, as it has no knowledge of this SOAP-specific heuristic.
This would violate R803.

 [1] http://www.w3.org/TR/xmlp-reqs/#z803

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

Received on Thursday, 28 March 2002 17:23:48 UTC