Subject: Definition of 'resource' not consistent with RFC 3986

From: Jonathan Rees <[email-masked]>
Date: Fri, 30 Jan 2009 10:54:27 -0500

I looked here:

http://svn.tools.ietf.org/svn/wg/httpbis/draft-ietf-httpbis/latest/p1-messaging.html#intro.terminology

and found that the definition of 'resource' is unchanged since RFC  
2616, and does not even agree with RFC 2396.  Let's please do one of  
the following:

(a) replace the definition with one that references RFC 3986, and  
assure ourselves that all the rest of the RFC is still correct after  
having made this change (which should be easy if one thinks this does  
not affect the protocol), or

(b) introduce a new term to replace 'resource' with the definition  
unchanged, so that there is no chance of collision or confusion with  
the normative sense of 'resource', and then use that term instead of  
'resource' throughout the new RFC.

My guess is that no one will want to choose (b), but I offer it as an  
option because it's obviously semantics-preserving.

The issue is that RFC 2396 and 3986 clearly allow 'resources' to be  
'abstract,' while figuring out where 2616 stands on this, or whether  
it matters to the protocol, is nearly impossible.

It may be necessary to go over what in the original are sections 3.3.2  
and 9.3 in order to fix this properly.

Apologies if this has been raised before and decided, but I'm new to  
this place.

Best
Jonathan Rees
Creative Commons / Science Commons

---

From: Julian Reschke <[email-masked]>
Date: Fri, 30 Jan 2009 17:21:03 +0100

> http://svn.tools.ietf.org/svn/wg/httpbis/draft-ietf-httpbis/latest/p1-messaging.html#intro.terminology 

You meant to say: 
<http://svn.tools.ietf.org/svn/wg/httpbis/draft-ietf-httpbis/latest/p1-messaging.html#terminology>, 
  right?

> ...
> and found that the definition of 'resource' is unchanged since RFC 2616, 
> and does not even agree with RFC 2396.  Let's please do one of the 
> following:
> 
> (a) replace the definition with one that references RFC 3986, and assure 
> ourselves that all the rest of the RFC is still correct after having 
> made this change (which should be easy if one thinks this does not 
> affect the protocol), or
> 
> unchanged, so that there is no chance of collision or confusion with the 
> normative sense of 'resource', and then use that term instead of 
> 'abstract,' while figuring out where 2616 stands on this, or whether it 
> matters to the protocol, is nearly impossible.
> 

3.2.2 (http URL) and 9.3 (GET)?

> ...

I don't think this has been raised before. That being said, this area 
(Part 1) is work-in-progress, so now certainly is the right moment to 
raise it.

BR, Julian

---

From: Jonathan Rees <[email-masked]>
Date: Fri, 30 Jan 2009 16:13:20 -0500

> 3.2.2 (http URL) and 9.3 (GET)?

Yes.
3.2.2: The "http" scheme is used to locate network resources via the  
HTTP protocol.
-- In RFC 2616, resource = network resource, so this is not  
problematic. But if these are different, one might ask whether  
anything should be said here about other kinds of resources -- can an  
application use the http: scheme to do anything with 'abstract  
resources'?  Actually once the question is raised the language of the  
whole section becomes 
rather weird -- the scheme "is used" - does that mean used with the  
HTTP protocol? (Yes; anything other than HTTP is out of scope.) Does  
that distinguish http: from any other scheme? (No; any URI can be used  
with HTTP to locate network
resources.) Since the http: scheme can be used in other ways than with  
HTTP, and HTTP is not tied to http:, the scheme's distinguishing  
feature really is that it has no distinguishing features.

9.3: Two cases are covered in the text, URIs identifying network data  
objects, and URIs identifying network services.
(Clarification needed perhaps: the URI doesn't identify the  
information, it identifies something whose 'state' is retrieved; at  
least in the REST formulation, and I don't know to what extent the RFC  
should codify that.) Nothing is said about the case where the URI  
identifies neither of these, but the way it's worded it's difficult to  
tell whether this case is unconstrained.

Because there has been so much confusion around this issue, I think  
there should be sufficient language to enable a reader to understand  
one of the following: it's allowed, it's forbidden, or it's out of  
scope and is to be settled in some other way.

Jonathan