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

RE: When is a Fault a Fault?

From: Williams, Stuart <skw@hplb.hpl.hp.com>
Date: Tue, 5 Mar 2002 14:06:28 -0000
Message-ID: <5E13A1874524D411A876006008CD059F1929D7@0-mail-1.hpl.hp.com>
To: "'Mark Baker'" <distobj@acm.org>
Cc: xml-dist-app@w3.org
Hi Mark,

[I know this looks a bit long, please bear with it up to the end of the
second of the two following paragraphs before filing in the usual place -
Thanks]

So... I think we are yet again running up against the tensions between the
'tunneling' and 'chameleon' views of SOAP. I'm not sure that I believe that
these two views can be accomodated within a single binding... but I have a
thought with respect to the 'chameleon' view applied in the context of HTTP
- which I'll try out here and see if I get buried under a tonne of rubble
;-)

I think that it would be possible to regard a SOAP message simply as a
content-type (application/soap+xml) along with a model for processing that
content-type (the SOAP part 1 section 2 processing model). Move SOAP
messages around in HTTP and you are doing HTTP.... no-binding required...
you're doing HTTP and normal HTTP semantics apply - and the SOAP messages
are in some sense (although I don't know what) resource representations.
This gives you access to all the HTTP methods and (I think) requires no
definition of a binding. Of course in the process SOAP ceases to be a
protocol (in this view), it becomes a content-type and a processing model.

In the other view, the 'tunneling' view, folks very much see SOAP as a
protocol for exchanging messages and they want to be somewhat agnostic to
what underlying protocol SOAP is bound to, much in the way that folks can be
(mostly) agnostic about what the data-link technology IP is bound to. In
this view folks conceive of themselves as exchanging messages (SOAP
messages) between endpoints (which process messages) identified by URIs. In
this 'view' the messages are not considered to be representations of
resource state (representations of the state of an endpoint) - they are
messages exchanged between entities bound to those endpoints. This view
requires a binding, because it is *not* doing HTTP, its is doing Message
Exchange over HTTP (tunneling).

These two views are at odds because the 'chameleon' view seeks to expose
HTTP as fully as possible and in the limit SOAP/HTTP is HTTP (full-richness)
whereas the 'tunneling' view seeks to abstract away from or 'hide' HTTP and
avoid exposing details of the underlying protocol to the thing (application
entity) using SOAP.

So we have two communities (at least) pulling toward these different
extremes. 

I think that one reasonable viewpoint is that one can 'do' HTTP and
simply(?) use SOAP for the content-type of the of an HTTP request/response
entity body. This *is* HTTP, no binding required.

However, in the Messaging/Tunneling view you do need a binding to establish
how messages are exchanged between messaging endpoints. Of course you then
need to establish the (binding independent) semantics of your messaging
system (what messaging operations does it support and what are their
semantics) - and an account that describes how the semantics of message
transfer are accomplished as a pattern of resource state manipulations. eg.
these resources represent intermediary-points and end-points in a messaging
system, and that the effects of  HTTP are to transfer messages that are
either immediately processed yielding an immediate result (200), or that are
accepted as subordinates (201) (an entry in a queue at the endpoint).

I have a concern that we may be trying to align messaging semantics and HTTP
semantics so tightly that ultimately we fail to define a messaging system
and all we end up with is SOAP as a content-type for HTTP.

More comments in line below.

Regards

Stuart

> -----Original Message-----
> From: Mark Baker [mailto:distobj@acm.org]
> Sent: 04 March 2002 19:42
> To: skw@hplb.hpl.hp.com
> Cc: xml-dist-app@w3.org
> Subject: Re: When is a Fault a Fault?
> 
> 
> > > Ah, didn't see that.  If we go with this though, it should also hold
> > > that a Fault is a Fault if it's over 4xx or 5xx.
> > 
> > Not sure how may of the conditions that give rise to:
> > 
> >    10.4.1    400 Bad Request .........................................65
> >    10.4.2    401 Unauthorized ........................................66
> >    10.4.3    402 Payment Required ....................................66
> >    10.4.4    403 Forbidden ...........................................66
> >    10.4.5    404 Not Found ...........................................66
> >    10.4.6    405 Method Not Allowed ..................................66
> >    10.4.7    406 Not Acceptable ......................................67
> >    10.4.8    407 Proxy Authentication Required .......................67
> >    10.4.9    408 Request Timeout .....................................67
> >    10.4.10   409 Conflict ............................................67
> >    10.4.11   410 Gone ................................................68
> >    10.4.12   411 Length Required .....................................68
> >    10.4.13   412 Precondition Failed .................................68
> >    10.4.14   413 Request Entity Too Large ............................69
> >    10.4.15   414 Request-URI Too Long ................................69
> >    10.4.16   415 Unsupported Media Type ..............................69
> >    10.4.17   416 Requested Range Not Satisfiable .....................69
> >    10.4.18   417 Expectation Failed ..................................70
> > 
> > result in a request message being delivered to the SOAP node at the HTTP
> > origin server or which are (could be/should be) handled directly by
HTTP,
> > and effectively return an 'empty' response (hence no fault bearing SOAP
> > envelope).
> 
> For sure, and I'd rather not have to enumerate these.  That's why I
> think it's easiest to use broad strokes and say that *if* a response
> includes a body *and* uses any 4xx or 5xx response code, then it is a
> fault ...

So wrt 4xx status codes, 2616 states:

<quote>
   Except when responding to a HEAD request,
   the server SHOULD include an entity containing an explanation of the
   error situation, and whether it is a temporary or permanent
   condition. These status codes are applicable to any request method.
   User agents SHOULD display any included entity to the user.
</quote>

I think that there is a mismatch of expectations here if the entity body is
a SOAP fault ;-)

> > The only place that "faultHint" is currently spoken about is with
respect to
> > the receipt of an HTTP POST response message by the requesting SOAP
node.
> > The last sentence is about mirroring something similar so that the SOAP
> > processor can inform the binding that it regards the outbound message as
> > being a fault message and that the binding should mark it appropriately
(ie
> > status code 500).
> 
> Ok.  The phrase "SOAP processor can inform the binding" was confusing
> me, but there's enough context to interpret it there.  I don't
> personally see "the binding" as being a different piece of software.

Ok... but we are talking about the separate specification of SOAP processors
and SOAP bindings much in the way that we speak separately of IP and IP over
X.25 or IP over 802.3 or IP over serial-lines... we end up needing the
abstraction for descriptive purposes even if the implementation ends up as
one homogenised chuck of software with very different internal structure.

> > > Which mechanism are you suggesting be authoritative?
> > 
> > >From the POV of processing the SOAP message I'd like to regard the SOAP
> > message as authoritative. From the POV of HTTP infrastructure, proxies,
> > caches, routers..., certainly those that can't usefully peek inside the
SOAP
> > message then really all they have to go on is the status code.
> > 
> > This is probably one of those places where we should properly us a MUST
in
> > the HTTP binding spec, to say that the generator of a SOAP message MUST
> > ensure the appropriate status code is used (and go on to say what the
> > appropriate status code is). The defendable interop concern is the
sustained
> > correct operation of existing infrastructure... and if you don't do as
the
> > MUST say's then you are non-compliant with the binding spec.
> 
> I agree that there are different POVs, and that MUST is the right
> conformance level here, but that still doesn't say what the
> authoritative determinant of a fault is.

Well, it would say that one party is non-compliant... ie is broken. They are
in error. If you proceed at all, proceed with caution. Maybe throw your
hands up in horror and refuse to play because you have received something
invalid... as broken as badly formed XML.

One could produce a ruling one way or the other for these non-conformant
cases, but which way to make the rule is open to debate. 

> > > I would be uncomfortable with using anything other than the
success/fail mechanism
> > > of the underlying protocol, where present.  And where it's not
present,
> > > I don't think it matters much how it's determined, as long as it's
> > > standardized in the binding.
> > > 
> > > Another option is including some information within the envelope to
> > > indicate the intent, but that feels uncomfortable to me.  Not sure
> > > why exactly, but I'll think more about it.
> > 
> > Basically, I think your concern is due to there being two (or more)
> > mechanisms to signify the same information and in those cases where
there is
> > inconsistency, do you resolve in favour of what the message says of
itself
> > or status information from the underlying protocol. I think we should
> > probably have MUSTs that require consistency, such that the generation
of
> > something inconsistent is regarded as non-conforming. 
> 
> That's definitely *a* concern, and is why I asked which was the
> authoritative souce.  But it's not the concern I was talking about.
> I think my response to Jacek included some thoughts about that.
> 
> MB
> -- 
> Mark Baker, Chief Science Officer, Planetfred, Inc.
> Ottawa, Ontario, CANADA.      mbaker@planetfred.com
> http://www.markbaker.ca   http://www.planetfred.com
> 

Stuart
Received on Tuesday, 5 March 2002 09:07:09 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:09 GMT