Subject: RE: [httpbis] #81: Content Negotiation for media types

From: Larry Masinter <[email-masked]>
Date: Wed, 16 Sep 2009 18:27:07 -0700

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. 

HTTP clients may have different or variable capabilities, characteristics
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.

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.

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 17 Sep 2009 13:40:00 +1000

Reopened, and +1

--
Mark Nottingham     http://www.mnot.net/

---

From: Julian Reschke <[email-masked]>
Date: Thu, 17 Sep 2009 10:56:58 +0200

Larry Masinter wrote:
> ...

The text sounds good so far, but I'm not really sure how it would be put 
into Part 3.

In particular: would it replace Section 4 completely? In which case we 
may be losing useful information. On the other hand, if it only replaces 
the first four paragraphs, there will be an overlap with the subsequent 
text...

BR, Julian

---

From: "Martin J. Dürst" <[email-masked]>
Date: Thu, 17 Sep 2009 14:08:38 +0900

Overall, looks very good, so +1. Some minor nits inline.

> After review by Mark, here is a proposed rewrite:

"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')

> driven negotiation may not be.

"may not be" -> "may not be appropriate." (or similar)

Regards,   Martin.

-- 
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp   mailto:[email-masked]

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 21 Sep 2009 14:13:09 +1000

I think the intent was to replace the first four sections, and to give  
the editors license to adjust the subsequent text in 4.1-4.3.

Julian, does that work for you?

Any objections to this?

On 17/09/2009, at 6:56 PM, Julian Reschke wrote:

> The text sounds good so far, but I'm not really sure how it would be  
> put into Part 3.
>
> In particular: would it replace Section 4 completely? In which case  
> we may be losing useful information. On the other hand, if it only  
> replaces the first four paragraphs, there will be an overlap with  
> the subsequent text...
>
> BR, Julian
>
>
>