Subject: for GET, does the request-target identify information?

From: Jonathan Rees <[email-masked]>
Date: Tue, 24 Nov 2009 10:11:54 -0500

There is some confusion as to whether the request-target identifies
information or identifies a resource (or both). The description of GET
("The GET method means retrieve whatever information (in the form of
an entity) is identified by the request-target") says the former,
while other parts of the draft suggest the latter.

The difference, as you know, is that you can get different information
from (or "corresponding to") a single resource at different times. The
resource is like a mutable file or a communication channel, not like
an entity or "information" (except in very special situations).

I recommend you change the description of GET.  May I propose "the
{entity/variant/representation} corresponding to the resource", which
is the language used in semantics/8.2.1 ("an entity corresponding to
the requested resource is sent in the response").  7.3 then becomes

   the GET method means retrieve whatever information (in the form of an
   entity) corresponds [or currently corresponds] to the resource
identified by the request-target.

or

   the GET method means retrieve an entity corresponding to the
resource identified by the request-target.

neither of which is particularly beautiful - but I know from the
wonderful job you did on 2.6.1 that you can come up with much better
wording than I can. The word "currently" or some other qualifier might
help (or not, I don't know).

semantics/7.3 also says:

   If the request-target
   refers to a data-producing process, it is the produced data which
   shall be returned as the entity in the response and not the source
   text of the process, unless that text happens to be the output of the
   process.

I'm not sure why this is "refers to" instead of "identifies" - I
recommend switching to "identifies" for consistency, since there is no
reason to introduce an additional term "refers" that does not
obviously mean the same thing.

The section could stand an overhaul of the sort you did for the http
URI scheme. Perhaps you can come up with some clever rhetorical device
that lets you sidestep all questions about the nature of the resource
(information vs. changeable thing vs. data-producing process, etc.),
which are both unimportant and distracting.

Best
Jonathan