RE: When is a Fault a Fault?

 Stuart,
 thanks for this analysis. You seem to suggest that the sole 
existence of the transport binding framework is based on the
tunneling view. I think I always felt that way but weren't aware 
of it.        
 Speaking about using SOAP messages as representation of a
resource state, it feels very awkward, in the extreme comparable 
to using C++ to represent a web page.
 Best regards,

                   Jacek Kopecky

                   Senior Architect, Systinet (formerly Idoox)
                   http://www.systinet.com/



On Tue, 5 Mar 2002, Williams, Stuart wrote:

 > 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 10:30:33 UTC