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

Another protocol/application example is Internet Fax, where SMTP is used to
transport a document for printing.  The SMTP receipt response mechanism
(MDN) is held until the document is printed successfully by the receiving
device.  The original sender would be notified that the print request was
successful(or unsuccessful), by the resulting MDN.  It would have been
worthless to only acknowledge that the email message was received - the
objective was to get the document printed successfully.  The alternative
would be to send another unrelated email message back to the original sender
acknowledging the successful print job, in lieu or in addition to the MDN.  

An analogous example could be created for transporting SOAP via SMTP.



More information for reference:

From RFC 2532  (Extended Facsimile Using Internet Mail):
2.1.2 Processing Confirmation


      *  MDNs MUST NOT be used for delivery confirmation, but are only
         useful for disposition ("processing") notification.




-----Original Message-----
From: Mark Baker [mailto:distobj@acm.org]
Sent: Wednesday, July 18, 2001 3:52 PM
To: Mark Nottingham
Cc: Mark Nottingham; xml-dist-app@w3.org
Subject: Re: another approach to status codes, etc. in HTTP binding


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 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.

Henrik, help me out here! 8-)

MB

Received on Wednesday, 18 July 2001 19:48:44 UTC