- 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>
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 UTC