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

Re: Content Sniffing impact on HTTPbis - #155

From: Julian Reschke <julian.reschke@gmx.de>
Date: Sun, 14 Jun 2009 09:51:53 +0200
Message-ID: <4A34AC19.4040804@gmx.de>
To: Ian Hickson <ian@hixie.ch>
CC: Adrien de Croy <adrien@qbik.com>, Mark Nottingham <mnot@mnot.net>, Mark Baker <distobj@acm.org>, Adam Barth <w3c@adambarth.com>, HTTP Working Group <ietf-http-wg@w3.org>
Ian Hickson wrote:
> ...
>> *You* may not need that distinction. However, when writing a spec, you 
>> aren't doing it for yourself, but for an audience of readers.
> It is precisely this audience of readers who are most likely to benefit 
> from specs using concrete, understandable, and familiar terms like 
> "resource" rather than theoretical, abstract, and confusing terms like 
> "resource representation". There really is no reason to refer to an 
> abstract concept here. There is an identifier, there is a server, there is 
> an actual resource (by the dictionary definition, not the "newspeak" 
> definition used in the HTTP spec). Why introduce another term? What else 
> is there to refer to?
> ...

Under your "definition", the resource is selected based on *both* the 
URI and the context of the GET request (request headers, point in time). 
It's *possible* to explain things that way, but it is totally confusing 
because the *URI* is supposed to be the identifier, by definition. So it 
seems to me you're creating more confusion, not less.

> When you tell your command-line tool to fetch http://google.com/, it 
> returns an actual sequence of bytes form a server. It doesn't obtain a 

Yes. Plus metadata.

> representation of something, it just gets a thing. There's no nebulous 
> "resource" here, just a concrete set of bytes (which will vary based on 
> many things, such as cookies, IP, headers, etc).

Yes, it does get you a sequence of octets (entity body) plus metadata. 
"We" call it "representation of the resource", you call it "resource".

>> Changing terminology at this point is only going to cause confusion.
> It is the HTTP and URI specifications that are, IMHO, continuing to cause 
> confusion by insisting on unfamiliar terminology.

Unfamiliar to whom?

Certainly not the W3C, see <http://www.w3.org/TR/webarch/#dereference-uri>.

But again; this discussion is pointless in that the inconsistency of 
terminology will be raised in Last Call, and then will have to change 

BR, Julian
Received on Sunday, 14 June 2009 07:52:43 UTC

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