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

Re: Content Sniffing impact on HTTPbis - #155

From: Jamie Lokier <jamie@shareable.org>
Date: Sun, 14 Jun 2009 12:24:31 +0100
To: Mark Nottingham <mnot@mnot.net>
Cc: Ian Hickson <ian@hixie.ch>, Julian Reschke <julian.reschke@gmx.de>, Mark Baker <distobj@acm.org>, Adam Barth <w3c@adambarth.com>, HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <20090614112431.GB9514@shareable.org>
Mark Nottingham wrote:
> Of course resources are abstract, Ian.
> 
> You may have no need to refer to anything but the response (or entity,  
> or representation; all might be appropriate), but others do need to  
> refer to the thing that the URI identifies, and the thing that  
> generates the response.
> 
> This argument seems to be covering the same ground quite quickly. As I  
> said, if you want to press the point, go ahead and use the term this  
> way in a submission; going around in circles on this list doesn't do  
> any good.

I sort of agree with everyone on this.

A 'representation' often isn't a representation; it's sometimes the
result of a calculation.  You could think of 1.41421356 as a
'representation' of the resource at (hypothetical)
http://example.com/calculator?sqrt(2), but the common language sense
of 'representation' doesn't fit that.  It's just a result.

But it's not a resource being returned either.

The calculator at (again hypotheical) http://example.com/calculator is
a resource in the common language sense, without the query part.  Yet
it might never be permitted to fetch that URL.

You can't use the fact there's a query part to distinguish, because of
http://example.com/calculator/sqrt_2, where the calculator accepts
it's parameters as the remainder of the URL.

So the terminology doesn't model the real web particularly well either
way.  So let's just use definitions and admit they don't fit common
language usage particularly well.

Personally I was quite happy with 'entity', which I always thought of
as what is found in a request or response, and that all the stuff
about resources and representations was outside the scope of HTTP,
because it's implicitly describing server internals which HTTP should
not do, even abstractly.

So far as I can tell in a hand-waving *practical* sense, 'resource' is
another name for URI/URL (because "the thing at the URI/URL" is pure
abstraction and often doesn't exist other than as an idea), the
URI/URL distinction isn't proving helpful any more (better to use URNs
or a non-HTTP method if you want to say you don't want dereferencing),
and 'representation' means practically the same as 'entity' or 'body'.

I appreciate there's a theoretical model behind resource and
representations, but it doesn't fit what really happens particularly
well in a lot of HTTP usages.

-- Jamie
Received on Sunday, 14 June 2009 11:25:11 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:03 GMT