- From: Martin J. Dürst <duerst@it.aoyama.ac.jp>
- Date: Thu, 17 Sep 2009 14:08:38 +0900
- To: Larry Masinter <masinter@adobe.com>
- CC: Mark Nottingham <mnot@mnot.net>, "henrik@henriknordstrom.net Nordstrom" <henrik@henriknordstrom.net>, HTTP Working Group <ietf-http-wg@w3.org>
Overall, looks very good, so +1. Some minor nits inline. On 2009/09/17 10:27, Larry Masinter wrote: > Although http://trac.tools.ietf.org/wg/httpbis/trac/ticket/81 > is marked 'closed', Mark sent a strawman rewrite: > http://lists.w3.org/Archives/Public/ietf-http-wg/2009JulSep/0521.html > > After review by Mark, here is a proposed rewrite: > > > =========================================================== > HTTP responses include a representation which contains information for > interpretation, whether by a human user or for further processing. > Often, there are different ways to represent the same information; > for example, in different formats, languages, or using different > charsets. "in different formats or languages, or using different charsets." or "in different formats, languages, or character encodings." > HTTP clients may have different or variable capabilities, characteristics "HTTP clients" -> "HTTP clients and their users" (important in particular for 'language') > or preferences which might influence which representation among > those available from the server would be best for the server to > deliver. For this reason, HTTP provides mechanisms for > "content negotiation" -- a process of selecting a > representation of a given resource when more than one is available. > > This specification defines two patterns of content negotiation; > "server-driven", where the server selects the representation based > upon the client's stated preferences, and "agent-driven" negotiation, > where the server provides a list of representations for the client to > choose from, based upon their metadata. In addition, systems > also use an "active content" pattern, where the server returns > active content which runs on the client and, based on client > available parameters, selects additional resources to invoke. > > These patterns are all widely used, and have trade-offs in applicability > and practicality. In particular, when the number of preferences or > capabilities to be expressed by a client are large (such as when many > different formats are supported by a user-agent), server-driven > negotiation becomes unwieldy, and may not be appropriate. Conversely, > when the number of representations to choose from is very large, agent- > driven negotiation may not be. "may not be" -> "may not be appropriate." (or similar) Regards, Martin. > Note that caches can be instructed on how to serve server-negotiated > responses using the Vary header [ref], although this mechanism is not > richly descriptive. > > The headers "accept:", "accept-language:" and "accept-charset:" > are defined explicitly for content negotiation. In addition, > many systems employ "User-Agent" based negotiation, where different > content is delivered depending on the version of software employed. > In practice, User-Agent based negotiation is fragile, because new > clients are not recognized by the deployed servers or active content. > > > > > -- #-# Martin J. Dürst, Professor, Aoyama Gakuin University #-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp
Received on Friday, 18 September 2009 07:15:01 UTC