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: Tue, 16 Jun 2009 15:45:01 +0100
To: "Roy T. Fielding" <fielding@gbiv.com>
Cc: Ian Hickson <ian@hixie.ch>, HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <20090616144501.GB29040@shareable.org>
Roy T. Fielding wrote:
> On Jun 14, 2009, at 12:21 PM, Ian Hickson wrote:
> >On Sun, 14 Jun 2009, Julian Reschke wrote:
> >>
> >>HTTP URIs are URLs, and URLs simply are URIs that also double as
> >>locators (see RFC 3986). I don't see how this changes the  
> >>definition of
> >>being an identifier at all.
> >
> >I'm not arguing that they aren't identifiers, I'm arguing that when  
> >you
> >dereference them you get an actual concrete resource, and that saying
> >that you get a resource representation is pointless and confusing  
> >hair-
> >splitting which doesn't actually help people understand the specs when
> >they implement them, since the thoretical "resource" construct never
> >actually needs to be dealt with in practice.
> 
> I'd like to see how you would describe a resource that accepts POSTed
> information without ever returning a "bag of bits", how you are going
> to describe a resource whose only purpose is to redirect to the
> "site of the day", or how you would implement a gateway to my
> friend's air conditioning unit.  I could enumerate thousands of
> examples of how limited your view of the Web really is, but then
> I already have done that many times.  Read the archives.

Ok, but what about a resource that accepts POSTed information _and_
information in the URL?  For example a hypothetical POSTable
http://example.com/post-news/author-is/Jamie/subject-is/Good%20morning

Then the URL doesn't point to the conceptual resource any more.  Part
of the URL does (http://example.com/post-news/); the rest of the URL
does not identify a resource, but is input to it.

Conceptually it's a mistake to equate "the thing that a specific URL
refers to" with the useful concept of a "resource that we may interact
with", because the most useful mapping often doesn't work that way.

You can say that the thing identified by the above long URL is a
resource, but it's a bit of a stretch and doesn't fit what it really does.

So if it's a conceptual mistake, why is it useful in specifications?

-- Jamie
Received on Tuesday, 16 June 2009 14:45:36 GMT

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