- From: Jonathan Rees <jar@creativecommons.org>
- Date: Tue, 7 Jul 2009 16:44:33 -0400
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>, www-tag@w3.org
Comments inline below. On Wed, Jul 1, 2009 at 12:56 AM, Julian Reschke<julian.reschke@gmx.de> wrote: > Jonathan Rees wrote: >> >> Quoting from >> http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-06#page-24 >> : >> >> A 303 response to a GET request indicates that the requested resource >> does not have a representation of its own that can be transferred by >> the server over HTTP. ... Note that answers to >> the questions of what can be represented, what representations are >> adequate, and what might be a useful description are outside the >> scope of HTTP and thus entirely determined by the resource owner(s). >> >> 1. I think the first sentence makes too strong a commitment. Some >> sites are using 303 for resources that *do* have perfectly good >> representations that can be transferred by the server over HTTP; they >> just don't want to do so because they consider the 303 redirect to a >> description of the resource to be more valuable than providing > > Could you please provide an example for a resource like that? My > understanding of the 303/information resource issue always was that if the > resource can be represented with a bag of bits then it *is* an information > resource. The TAG resolution, FWIW, says that if the response is a 303, the resource can be any kind of resource - information or non-information. My application is creating a large number of stable URIs (PURLs, in effect) for what could be considered information resources, AND adding metadata in the process, with the metadata reachable via 303. (The data would be found in some other way, not via 200.) This is because the metadata is deemed more important than the data. Now I have three ways out. One is for me to tell myself that "the requested resource does not have a representation of its own that can be transferred by the server over HTTP", which of course is untestable and so I doubt anyone would call me on it. Another is to ignore your 303 advice, as it will only have SHOULD status and not MUST status. Yes another is to use LRDD to provide access to the metadata, but LRDD is not likely to be ready before HTTPbis, and it's not obvious (yet) that it will serve my purposes. I can reverse the question and ask *you*: Tell me what kind of resource "does not have a representation of its own that can be transferred by the server over HTTP"? And what is an example of a representation that cannot be transferred over HTTP? You have entered one of the nastiest and most pointless debates around, that of the boundary between information resources and other resources, and I don't recommend going there - it's an ontological quagmire that has no place in HTTPbis. Better to just say that GET/303 may be used any time the server does not choose, for whatever reason, to respond with a representation, but rather with the location of a description of the resource. This is easy to specify and describe and is compatible with the TAG's previous advice. >> ... >> >> I recommend changing this to something weaselly like >> >> A 303 response to a GET request *may indicate* that the requested >> resource >> does not have a representation of its own that can be transferred by ... >> ... > > Assuming we did want to change it, it would still to be phrased in a way > that explains what 303 means, not what it "may" mean... See above. I don't think much meaning has to be given beyond that you get the location of a description. You can leave the 200/303 choice up to the server, just as a choice between a 300 and a 200 is up to the server. The server just decided. >> 2. The last sentence is also incorrect - to say that these decisions >> are up to the resource's owner is also too strong a commitment. For >> example, if I create a URI meant to "identify" my neighbor's car, it >> is not necessarily up to my neighbor to determine what a useful >> description of it is. > > From HTTP's point of view, the owner of the URI is the owner of the > resource. It just doesn't care about the case where you use an HTTP URI to > identify somebody's car. But you are the one who raises the question. If you mean resource owner in some narrow technical sense, instead of resource owner in, say, a legal sense (e.g. copyright), you need to be clear. It wasn't clear to me, and I don't think it's only because I'm steeped in a world view that makes a clear separation between URI and resource (e.g. the possibility that many URIs with different URI owners might all identify the same resource). Best Jonathan >> ... > > BR, Julian >
Received on Tuesday, 7 July 2009 20:45:20 UTC