Re: Review of new HTTPbis text for 303 See Other

On Sat, Jul 11, 2009 at 6:27 AM, Richard Cyganiak<richard@cyganiak.de> wrote:
> Not as far as HTTP is concerned. HTTP is just a transfer protocol. The HTTP
> world is really simple:
>
> 1. There are URIs. URIs are thought to identify things called resources. As
> far as HTTP is concerned, it does not matter much what the resource actually
> is -- a document, a file on a server, a person, whatever.
>
> 2. Resources (whatever they are) are thought to have things called
> representations. As far as HTTP is concerned, it is totally up to the server
> owner to decide what's a representation of what. After the server owner has
> made their decision, a resource either has a representation or not.
>
> 3. If a resource has a representation, then a GET to its URI should be
> answered by 200. If not, then 303, 404 or 410 would be fine choices.
>
> I repeat: For the operation of the HTTP protocol, IT DOES NOT MATTER what
> exactly a resource is and what the exact relationship between resources and
> representations is. All these matters of denotation, information resources
> and so on are introduced by higher layers of the architecture.

This is a nice simple story, but as far as I can tell it just isn't
correct. There are many places in HTTP which address issues of
semantics or otherwise go beyond transport.

e.g Content negotiation:

Most HTTP responses include an entity which contains information for
   interpretation by a human user. Naturally, it is desirable to supply
   the user with the "best available" entity corresponding to the
   request. Unfortunately for servers and caches, not all users have the
   same preferences for what is "best," and not all user agents are
   equally capable of rendering all entity types. For that reason, HTTP
   has provisions for several mechanisms for "content negotiation" --
   the process of selecting the best representation for a given response
   when there are multiple representations available.

      Note: This is not called "format negotiation" because the
      alternate representations may be of the same media type, but use
      different capabilities of that type, be in different languages,
      etc.

or:

 10.2.4   203 Non-Authoritative Information ........................59

or:

 10.4.3    402 Payment Required ....................................66

or:

14.11   Content-Encoding .........................................118
14.12   Content-Language .........................................118

or any of the caching stuff.

---

TCP is a transport protocol. HTTP is concerned with more than just
transport of opaque bit strings. In my view, your presentation of
HTTP's view of resources and representations as a kind of mathematical
abstraction doesn't do justice to the intellectual work that preceded
and led to the development of HTTP (H = Hypertext, for example).

It is certainly true that there are additional layerings that are
added by, e.g. AWWW and RDF, but to suggest that HTTP did not  bring
to the table anything more than shipping certain kinds of packets
called representations which are in grouped in buckets called
resources doesn't seem accurate.

It may very well be the case that whatever HTTP brings to the table in
these areas is underspecified, ambiguous, inconsistent,  and
unhelpful, and that a retrenchment to a view of HTTP along the lines
you suggest might be a useful advance towards a more coherent overall
infrastructure for a Semantic Web. Let's have that discussion, then,
rather than one over who's account of history is right. (my suspicion
is that the older folks will win that one ;-)

-Alan

Received on Tuesday, 14 July 2009 06:04:04 UTC