W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2009

Re: requested resource / entity / representation / variant again..

From: Mark Nottingham <mnot@mnot.net>
Date: Thu, 23 Jul 2009 10:15:41 +1000
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <CC0C8625-95B7-42FC-AEFD-69F3EBBB1224@mnot.net>
To: Adrien de Croy <adrien@qbik.com>, Henrik Nordstrom <henrik@henriknordstrom.net>
I had a quick look through the drafts, and found only one place where  
"requested resource" means anything other than "the resource  
identified by the target-URI (regardless of conneg)":

p3 3.2.1:
> Content-Encoding may be used to indicate any additional content  
> codings applied to the data, usually for the purpose of data  
> compression, that are a property of the requested resource. There is  
> no default encoding.

Here, conneg does (obviously) need to be taken into account (and I've  
created <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/183> to  
track this).

Did I miss any?

In other places where "requested resource" is used I think it is  
appropriate and switching to "requested representation" (or whatever)  
would be a mistake; e.g., the last-modified time *is* a property of  
the resource as a whole, not a specific representation. We do have a  
related open issue here, tangentially: <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/107 

The only one where I had to stop and think was in p2 3.2.1 (semantics  
of 200 for a GET, as H points out); however, that's probably dependent  
upon the resolution of <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/69 
 > (which accounts for many of the surviving uses of "variant", BTW).

I've put a note in #69 to have a look at p2 3.2.1 to revisit this  
section as part of that issue's resolution. If you can find other  
places like that, please add them (or send to me).

I agree that conneg would benefit if it were mentioned that it's  
scoped to a requested resource.

All of that said, I'd very much like to see us take a systematic  
approach to determining the scope (server/resource/representation/ 
response/etc.) of metadata in the spec, because IME it's often been  
misinterpreted, and sometimes led to interop problems.

WRT "variant" -- that issue has not yet been closed, I think the  
editors are planning to work on it soon. See: <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/109 


On 22/07/2009, at 8:45 AM, Adrien de Croy wrote:

> how about...
> call it a response.  That way we don't make any assumptions about  
> anything nor set any limitations.  You make a request, and you get a  
> response.  The response may have changed or not since last time.   
> The response may vary on Accept-* headers.  The response may be  
> cached.  The response may have been generated at a time specified in  
> a Last-Modifed header.  The response may be the content of a file  
> whose location matched the path part of the requested URI.  Or it  
> may not.  The server can choose any response it wishes without any  
> restriction.
> This is basically the reality anyway.
> To distinguish between the entire response message and the part of  
> the message that is deemed to be "transferred", we could add some  
> other noun to refer to the content (+ attributes) or refer to the  
> response message as just that - the response message.
> Just an idea.
> Adrien
> Henrik Nordstrom wrote:
>> The "resource" discussion again highlighted the fuzziness on what
>> "requested resource" really means.
>> When reading the specs again I can only agree that it's still quite
>> fuzzy, but for other reasons. The way "requested resource" vs
>> "representation" is currently used confuses matters a bit.
>> Intuitively "requested resource" should refer to the resource  
>> identified
>> by the Request-URI. But in fact it's not..
>> To me it seems that quite many of the places which today say  
>> "requested
>> resource" maybe should say "requested representation" (if one can say
>> anything like that) to align them better with the language used for
>> server driven content negotiation, or perhaps we should use the term
>> "variant" consistently pretty much anywhere we say "requested  
>> resource"
>> or "selected representation". But neither is good if there exists
>> resources with no representations associated...
>> If not that then the concept of "requested resource" and language  
>> used
>> for describing server driven content negotiation both needs to be
>> adjusted/clarified to connect them together.
>> Some examples:
>> p3 4. Content Negotiation
>>        "content negotiation" -- the process of selecting the best
>>        representation for a given response when there are multiple
>>        representations available.
>> p3 4.1 Server-driven Negotiation
>>        ... select a representation ...
>> etc, quite consistent use representation to identify what was  
>> selected
>> and acted upon. Oddly this chapter talks very little about resources
>> however..
>> However, in other areas "requested resource" or even  
>> "variant" (wasn't
>> variant supposed to be killed some time ago?) is used for referring  
>> to
>> pretty much the same thing. For example
>> p4 6.5 If-Unmodified-Since
>>        If the requested resource has not been modified since ...
>> p4 6.6 Last-Modified
>>        ... the variant was last modified.
>> p2 8.2.1 200 OK
>>        GET & HEAD ... the requested resource ...
>> While in some other areas "requested resource" seems to refer to the
>> "resource" identified by the URI, regardless of any content  
>> negotiation
>> taking place.
>> And yes, Server driven content negotiation IS confusing to  
>> terminology
>> as it causes the notion of a resource to be quite twisted and in  
>> reality
>> is often implemented as several independent resources sharing the  
>> same
>> URI...
>> Sorry, head a litte dizzy now trying to sort some sense out of these
>> terms when content negotiation is used.. can't really say I see a  
>> light
>> yet.
>> Regards
>> Henrik
> -- 
> Adrien de Croy - WinGate Proxy Server - http://www.wingate.com

Mark Nottingham     http://www.mnot.net/
Received on Thursday, 23 July 2009 00:16:26 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:50 UTC