W3C home > Mailing lists > Public > www-talk@w3.org > November to December 1995

Re: Content negotiation

From: Shel Kaphan <sjk@amazon.com>
Date: Wed, 8 Nov 1995 10:25:24 -0800
Message-Id: <199511081825.KAA00627@bert.amazon.com>
To: www-talk@w3.org

I realize this is pretty unlikely to happen in my lifetime, but...

It seems to me that the nicest way for browsers to communicate their
capabilities to servers would have the following properties:

	- it would be in a machine-readable format the server could parse

	- it would *not* be sent to the server unless the server
	  wanted it.

	- it would consist of a list of
	  a "standardized" (= generally agreed upon)
	  set of attributes and possible values thereof.  So there
	  would need to be some kind of registration authority.

	- it would be extensible, so that descriptions of 
	  new capabilities could be added


Trying to squeeze all this into HTTP as we know it would be, at best,
an unnatural act, though I can think of one approach (at least): if a
server does not have the "property list" for a given browser type and
version, it could return some version of a Redirect response to a
client, which would have the meaning "ask me again, but tell me what
you can do".  If the client asked again without the property list (but
with the redirected-to URL), the server would have to assume that the
client didn't know how to return a property list.  To retrofit this
into HTTP, this should probably just use the existing Redirect
response, with an added header something like "Send-capabilities" (or
whatever).

The reason I would like this to be machine readable is that it means
server programmers wouldn't have to manage a database of browser
properties by hand.  (well, of course this wouldn't be perfect, but it
might ease the load).

--Shel Kaphan
  sjk@amazon.com
Received on Wednesday, 8 November 1995 13:29:00 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 27 October 2010 18:14:18 GMT