HTTPbis and the definition of "resource"

Here's a summary of the definition-of-"resource" issue:
(this is in partial fulfillment of AWWSW ACTION-19
http://www.w3.org/2007/awwsw/tracker/actions/19 "Raise httpbis text
issues on awwsw mailing list"; not included here is the question of
the text for 303):

I wrote to http-wg in January complaining that the HTTPbis definition
of "resource" didn't match the normative definition in RFC 3986:
http://lists.w3.org/Archives/Public/ietf-http-wg/2009JanMar/0142.html

Basically 3986 allows a resource to be anything, while HTTPbis (like
RFC 2616) insists that a resource be a "network data object or
service":

http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-07#page-61
(unchanged from 2616)
   "resource
      A network data object or service that can be identified by a URI,
      as defined in Section 2.1.  Resources may be available in multiple
      representations (e.g. multiple languages, data formats, size, and
      resolutions) or vary in other ways."

After a brief exchange I received this from Julian Reschke:
"To get this done it would help if you could propose a precise
description of the problem, plus, optimally, a proposed change."

I suppose this is still pending; I got distracted with the whole
identifies/refers to issue, and the http: URI scheme registration, and
never got back to this particular issue. I think it was discussed
recently on the HTTPbis and TAG lists, HTTPbis said "stop bothering
HTTPbis with this, we're fixing it", and Larry Masinter said "stop
bother www-tag with this, set up another list so that I can ignore it
more easily".

How to fix HTTPbis? There are many options.
 - change its definition of "resource" to agree with 3986
 - replace "resource" with a different term locally in the HTTP spec
 - come clean that a local definition of "resource" is in effect at
odds with 3986
 - leave things as they are, and to hell with those who would be
confused by the discrepancy
 - change 3986 so that "resource" is limited to "network data object or service"

To get a handle on this I simply did a search for "resource" in
HTTPbis part 2; there are a few dozen uses.

1. "requested resource"
   "resource mapping"
   "resource metadata"

2, 5. "the resource identified by the request-target"
   This used to be "requested resource"... I think the new phrase is
an improvement

7.6 "If the request-target refers to an already existing resource,"
    "If the request-target does not point to an existing resource,"

   In the RDF context this is a very unfortunate use of "refers to".
Maybe we can get them to change this to "identifies".

   "and that URI
   is capable of being defined as a new resource by the requesting user
   agent"   -- a valiant attempt to avoid introducing "authority" / "ownership"

8.3.4 303 - let's discuss this separately.

8.4.10 "The request could not be completed due to a conflict with the current
   state of the resource."
   "... changes to a resource"

9.4 "the choice decision is intended
      to be made on resource characteristics"
    this should probably be "entity characteristics"

2.1.1. http URI scheme
   The "http" scheme is used to locate network resources via the HTTP
   protocol.

The word "network" is redundant here if the 2616 definition of
"resource" prevails.

Note that in RDF, assuming httpRange-14 prevails, the "http" scheme is
also used for other purposes - namely, to refer to resources of any
kind. The registration for the http: scheme does not say that http: is
*only* used to locate network resources, but one could easily read it
as saying this.

Indeed, there are some cases in HTTPbis where the "http" scheme is
used to identify resources that can't be located. (Or the new text
covering 303.) So the choice will be between clarity, which will
require many changes here, and stability of scripture, which I think
is what Larry is pushing for.

I think the http: scheme registration text can be discussed separately
from the definition-of-"resource" text, so if we discuss it let's do
so in a separate thread.

````

My conclusion is that HTTPbis could replace its current definition of
"resource" with anything that's consistent with RFC 3986, and not
suffer any ill consequences. That is, all of the HTTP methods simply
do things with resources, and if they can't (or won't, or choose not
to) do what they're asked to do to whatever resource they choose to
"identify" using the request-target, they can just report an error
(405 works pretty well) or use 303 (assuming the new usage survives).
There is no assumption anywhere that all "resources" are "network data
objects or services", although those ought to be trotted forward as
the ones that the protocol cares about.

This is what I propose to propose to Julian; to be helpful I guess I
could come up with some actual text to put in the terminology appendix
(part 2 appendix C), but I think it would be much better if the
editors did this for themselves.

,,,,,

Some bugs I came across in my review:

big doo-doo in PUT...
   "A single resource MAY be identified by many different URIs.  For
   example, an article might have a URI for identifying "the current
   version" which is separate from the URI identifying each particular
   version."
[compare 7.3? or 8.2.1?]
I think we can get them to fix this.

7.6 "the URI in a PUT request identifies the
   entity enclosed with the request"  -- no, it identifies the new
resource that needs to be created. We can probably get this fixed.

8.1.2 "delivering resources that use such features."  One delivers
entities, not resources.

Mystery:
8.3.3, 8.3.8
   "The requested resource resides temporarily under a different URI."
What does "reside under" mean? Same as "is identified by"?
- I doubt we'll see any motion on this. If it were up to me I would
say that responses to requests on the original resource can be
obtained by making requests on the redirected-to URI -- without saying
*anything* about either residence or identification. But then when I
took this up here before, Stuart had a very different theory of what's
going on with redirects. There's nothing in 2616 that would let one
decide between the two theories, and if *we* can't agree, I doubt
HTTPbis will be able to.

Received on Monday, 31 August 2009 14:58:22 UTC