2xx/202 and "a priori"

[moving this to xml-dist-app.  It's in regard to my earlier email;
http://lists.w3.org/Archives/Public/xml-dist-app/2002Apr/0205
and also the issue of the HTTP 202 response code that the TBTF is
considering.]

On Mon, May 06, 2002 at 05:56:45PM -0700, Henrik Frystyk Nielsen wrote:
> No, any HTTP 2xx status code other than 202 means that the request was
> successfully received and processed.

I don't believe so.

RFC 2616 says;

  "10.2 Successful 2xx

     This class of status code indicates that the client's request was
     successfully received, understood, and accepted."

Even ignoring what 10.2 says, the "2" has to mean the same thing
for all 2xx response codes.  Any extension response code can not be
interpreted to mean "succeeded", since the code may mean something
like 202.  This interpretation is consistent with RFC 2616, from
everything I've read, specifically 10.2.

> 202 means received but processing
> not completed. If this was not the case then I would never have been
> able to buy anything using HTML forms as they have exactly the same
> property.  Actually, I wouldn't even have been able to do a GET because I
> wouldn't know whether a 200 response was a representation of the
> resource or just something else saying that processing is under way.
> 
> The solution you point out is of course exactly the same as the "Ext"
> mechanism in RFC 2774  but the reason that was introduced was because
> many CGI scripts disregard the method name entirely. This is not really
> the case here as you are not going to throw HTTP/SOAP messages at
> arbitrary URIs.

Is this an assumption that we can make?  I was not assuming this,
but I would agree that if we could assume this, that this issue
goes away.

But our charter says;

"In particular, it must support distributed extensibility where the
communicating parties do not have a priori knowledge of each other."

I believe that what you suggest (maintaining the status quo) requires
that there be a priori knowledge about which URIs identify SOAP
services.

> I don't think we need anything else other than another property in the
> SOAP RR MEP describing the type of success.

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@planetfred.com
http://www.markbaker.ca   http://www.planetfred.com

Received on Monday, 6 May 2002 22:35:52 UTC