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

RE: [RFC] HTTP Information Request

From: Larry Masinter <LMM@acm.org>
Date: Thu, 21 Jun 2007 10:27:33 -0700
To: "'Stefanos Harhalakis'" <v13@priest.com>, <ietf-http-wg@w3.org>
Message-ID: <004601c7b429$74a68f40$5df3adc0$@org>

This proposal seems to fall into the same trap that most proposed
HTTP extensions fall into: there's no motivation to deploy this
in clients because most servers don't support it, and no motivation
to deploy this in servers, because most clients don't support it.

Unless you have a better story for how this will get deployed,
its mainly an academic exercise.

Things might have been different when HTTP 1.0 or 1.1 were
being developed, but that's not the case now.

That's the general problem. The specific problem with this
is that it's a kind of reverse content negotiation, and many
of the features you're thinking of (e.g., screen/window size,
accessibility requirements) fit into the framework of media
negotiation, and the others might, with a bit of stretching
(e.g., "timezone" as a media feature meaning "content
appropriate for someone in the named timezone", or, more
likely, locale.)  In most cases, we talked about the combination
of client characteristics, capabilities and preferences,
which seems to cover almost all of your tokens.

There's been a great deal of work in this area, most of
it not deployed (for reasons above), e.g.,

http://www.imc.org/ietf-medfree/ in IETF and
http://www.w3.org/TR/CCPP-ra/ 
http://www.zurich.ibm.com/ucp/

In general, media negotiation in HTTP hasn't been successful,
see note & following discussion:

http://www.alvestrand.no/pipermail/ietf-types/2006-April/001707.html 

Larry
-- 
http://larry.masinter.net
Received on Thursday, 21 June 2007 17:27:42 GMT

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