Re: another approach to status codes, etc. in HTTP binding

On Wed, Jul 18, 2001 at 06:51:30PM -0400, Mark Baker wrote:
> Mark Nottingham wrote:
> > 
> > On Wed, Jul 18, 2001 at 04:50:42PM -0400, Mark Baker wrote:
> > > >> As SOAP/HTTP reuses HTTP's application semantics (see the charter
> > > >> 8-)
> > > >
> > > > reference?
> > >
> > > 2.4, "Out of Scope; Application Semantics"
> > 
> > That's taking it completely out of context. Section 2.4 is a call to
> > avoid the specification of *SOAP* application semantics. How does
> > that translate to a requirement to reuse HTTP's application
> > semantics?
> 
> I didn't say that *SOAP* had to reuse HTTP's application semantics, I
> said "SOAP/HTTP" - meaning the binding - should.  Sorry if that wasn't
> clear.
> 
> Anyhow, how can 2.4 *not* mean to reuse the application semantics of the
> application protocol to which it is bound?  If it doesn't define its
> own, then where do they come from?

I read 2.4 as saying: "the WG shall not define semantics tailored to
a specific application of SOAP". IMHO it's quite a stretch to get
that to "SOAP transport bindings should specify the use of
application-layer transfer protocol semantics so that they concur
with SOAP message semantics".

Where the underlying application semantics come from is a seperate
question.



> > > I believe the meaning of a SOAP server fault fits within the
> > > definition of 500 (and implicitly, the definition of 5xx).
> > 
> > "Server" is being used in two different contexts (their respective
> > documents). An HTTP server is very different from a SOAP server, and
> > may be implemented by a completely different process.
> 
> I look at it this way; sending a SOAP message over HTTP means
> transferring it with HTTP POST  semantics.  So if the transfer of that
> message fails, i.e. if the message cannot be processed (or otherwise
> "accepted as a subordinate", per 2616 sec 9.5) by the resource
> identified by the POST URL, there's an HTTP error to be reported because
> the POST did not succeed.  That the reason for it not being accepted was
> a problem with a processor that isn't the web server, matters not; the
> POST failed, and this has to be communicated.

It seems that the criteria for success and failure in HTTP's context
is the central issue here.


-- 
Mark Nottingham
http://www.mnot.net/

Received on Wednesday, 18 July 2001 20:00:47 UTC