- From: Booth, David (HP Software - Boston) <dbooth@hp.com>
- Date: Thu, 27 Sep 2007 23:21:45 -0400
- To: "Rhys Lewis" <rhys@volantis.com>, "Pat Hayes" <phayes@ihmc.us>
- Cc: "Technical Architecture Group WG" <www-tag@w3.org>
Rhys, I agree entirely with your analysis about 303 responses and HTTP endpoints. I am only concerned that the terminology that you are using is likely to be confusing if you posit a thingie that responds with a 303 code for a URI. In general, any locator can be treated as a name for the thing that it locates. Thus, in one sense a locator *denotes* the thing that it locates. Indeed, in the 200 case the URI *does* denote the thing that it locates. But in the 303 case we're telling the world that it doesn't, in spite of the fact that the URI is a locator for that thingie. That's confusing, and that confusion occurs if you posit that thingie that responds with 303 codes for the URI. On the other hand, I think there is a lot of merit in viewing the 200 and 303 cases similarly in some sense, because from the server administrator's perspective, there isn't a lot of difference between serving a file with a .html or .rdf extension (sent with a 200 response) and a file with a .asis extension[1] that is sent with a 303 response. So I suppose if you do go down this route of defining a class of "HTTP endpoints", which are the thingies that send 200 or 303 responses, then you could define "information resource" as being the subclass of HTTP endpoints that send 200 responses. 1. http://httpd.apache.org/docs/1.3/mod/mod_asis.html David Booth, Ph.D. HP Software +1 617 629 8881 office | dbooth@hp.com http://www.hp.com/go/software Opinions expressed herein are those of the author and do not represent the official views of HP unless explicitly stated otherwise.
Received on Friday, 28 September 2007 03:22:04 UTC