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

Re: Content Sniffing impact on HTTPbis - #155

From: Adam Barth <w3c@adambarth.com>
Date: Tue, 16 Jun 2009 10:03:31 -0700
Message-ID: <7789133a0906161003s6686af50sf7fd3fb92f55f56d@mail.gmail.com>
To: "Roy T. Fielding" <fielding@gbiv.com>
Cc: Jamie Lokier <jamie@shareable.org>, Ian Hickson <ian@hixie.ch>, HTTP Working Group <ietf-http-wg@w3.org>, Mark Nottingham <mnot@mnot.net>
Thank you all for this discussion.  It appears that the path of least
resistance is for me to change the terminology in the next draft,
which I will do.


On Tue, Jun 16, 2009 at 9:47 AM, Roy T. Fielding<fielding@gbiv.com> wrote:
> On Jun 16, 2009, at 7:45 AM, Jamie Lokier wrote:
>> 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.
> No, (http://example.com/post-news/) is not *the* resource.
> It may be a resource, but it is not the resource to which
> the URI above identifies, and therefore your assumption about
> the meaning of "resource" in Web architecture is wrong.
>> 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?
> Because it isn't a conceptual mistake.  Your mistake is assuming
> that "resource" has something to do with the implementation behind
> the server interface.  Ian's mistake is assuming that what people
> refer to is the bag of bits they get back, as opposed to the function
> being exploited by the request method on the server-provided resource
> at the time of the request (e.g., if the link is to today's weather
> report then the resource is today's weather report, not some former
> weather report's bag of bits).
> In any case, the word "resource" is far more commonly used the way
> I use it than the way that Ian described.  As indicated, it comes
> direct from the English language.  Ian's opinion is simply wrong
> and you can't "simplify" a specification by defining the basic
> architectural elements incorrectly.
> ....Roy
Received on Tuesday, 16 June 2009 17:04:24 UTC

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