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

Re: Issue 192; HTTP binding looks ok

From: Mark Baker <distobj@acm.org>
Date: Tue, 19 Mar 2002 21:45:10 -0500 (EST)
Message-Id: <200203200245.VAA29896@markbaker.ca>
To: skw@hplb.hpl.hp.com (Williams, Stuart)
Cc: jacek@systinet.com, xml-dist-app@w3.org, henrikn@microsoft.com

> Hi Mark,
> Just wanted to record that you and I (at least) had not reached a common
> view about this when this was discussed earlier [1][2] (long messages but
> viewpoint at the end).

I understand.  I'm just saying that as things are in the current
editor's copy of the specification, I'm happy with the HTTP binding as
the state transition table provides no path to the Fail state if a fault
is received on a 2xx response.

> > I wonder how many SOAP 1.1 implementations get it right?
> I don't know that we have actually agreed what "right" is. In particular,

Sorry, that was a bit off-the-cuff.  I only meant my definition of
"right" (the one reflected in the spec 8-).

> the use-case that you promote is the 'quoting' of a fault say in response to
> a request to return a copy of the most recent fault generated.
> My own viewpoint is that, given the resolution of issue #12, the transfer of
> a fault in an HTTP POST response with a status code of 2xx is inconsistent
> lies outside the scope of what we attribute meaning to... its an error in an
> implementation.


> Personnally, if the fault quoting use-case *is* of interest to us, I would
> rather was embedded a little more deeply in the response message. A bit like
> giving our answers to the teacher... "The most recent fault that I generated
> was <....>".

Many (all?) application protocols already provide a means to distinguish
between a body that is a fault and a body that is "content".  If we also
place this information within the envelope when bound to these
protocols, then we create the opportunity for inconsistent
interpretation (this is assuming you'd agree that this feature of the
protocol should also be used).

But I would support an in-envelope mechanism for use with protocols that
don't have a pre-existing means of distinguishing between fault and

Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@planetfred.com
http://www.markbaker.ca   http://www.planetfred.com
Received on Tuesday, 19 March 2002 21:53:35 UTC

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