W3C home > Mailing lists > Public > public-awwsw@w3.org > August 2009

Re: HTTPbis and the definition of "resource"

From: Pat Hayes <phayes@ihmc.us>
Date: Mon, 31 Aug 2009 09:21:56 -0700
Cc: AWWSW TF <public-awwsw@w3.org>
Message-Id: <26C88DFC-74BC-40E1-A833-52D8C03650ED@ihmc.us>
To: Jonathan Rees <jar@creativecommons.org>

On Aug 31, 2009, at 7:57 AM, Jonathan Rees wrote:

> 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":

FWIW, there is a proposal to replace the more general usage of  
'resource' with a more neutral word such as 'thing'. This strikes me  
as a vastly better way to resolve this clash of terminology. If  
adopted, it would free up "resource" to have its HTTPbis meaning. This  
would be more in line with historical usage of this term in this  
context (eg in the early writings on hypertext by Doug Engelbart) and  
would also be more natural, since to use the word "resource" to mean  
absolutely anything is a bit like calling everything a cabbage. In  
sum, the RFC 3986 usage of "resource", while currently definitive, is  
in fact the more idiosyncratic and confusing of the two usages. Maybe  
HTTP should stick to its guns and we should all push for changes to  
RFC 3986 instead :-) The phrase "network resource", while technically  
redundant, could still be used for clarification when there was any  
possibility of confusion with the current RFC usage.


> 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.

IHMC                                     (850)434 8903 or (650)494 3973
40 South Alcaniz St.           (850)202 4416   office
Pensacola                            (850)202 4440   fax
FL 32502                              (850)291 0667   mobile
phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes
Received on Monday, 31 August 2009 16:22:45 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:21:07 UTC