- From: Yves Lafon <ylafon@w3.org>
- Date: Wed, 8 Jul 2009 05:50:36 -0400 (EDT)
- To: Jonathan Rees <jar@creativecommons.org>
- cc: Julian Reschke <julian.reschke@gmx.de>, HTTP Working Group <ietf-http-wg@w3.org>, www-tag@w3.org
On Tue, 7 Jul 2009, Jonathan Rees wrote: > 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. How about qualifying the 303 response (which is something I really don't like as a response to a GET, a new code would have been better) using a Link: header to specify that the targeted resource is intended to be metadata? > > 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. rfc2616 makes no assumption that it is metadata (hence my proposal above to use Link: in this specific case). >>> ... >>> >>> 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 >> > > -- Baroula que barouleras, au tiƩu toujou t'entourneras. ~~Yves
Received on Wednesday, 8 July 2009 09:50:48 UTC