Content Negotiation again

HTTPBIS WG issue 81

http://trac.tools.ietf.org/wg/httpbis/trac/ticket/81


W3C TAG action:
http://www.w3.org/2001/tag/group/track/actions/231

My ACTION-231 from W3C TAG was to propose to HTTP-WG to add a sentence
about "same information", since there have been some questions about
what constituted the "same information", e.g.:


>> is the PNG *representation* derived

>> via conneg from the generic resource

>> <http://sw-app.org/sandbox/house>

>> equivalent to the RDF in Turtle?

And after some wordsmithing, my current proposal is:
=====

Note that in all cases, the supplier of representations has the
responsibility for determining which representations might be
considered to be the "same information".

Looking at section 4 of Payload
 http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p3-payload-08.html#rfc.section.4
there was some question about how to integrate my proposed
rewording into the rest of section 4.

So to be more explicit:

I suggest leaving 4.1 and 4.2 alone , except to change
"HTTP/1.1 defines" to "This specification defines", and dropping
section 4.3 entirely, in lieu of the explicit reference to
RFC 2295. (I think originally section 4.3 was written before
2295 was completed, and a reference seems more appropriate
than a summary.)


========================

HTTP responses include a representation which contains information for
interpretation, whether by a human user or for further processing.
Often, the server has different ways of representing the
same information; for example, in different formats, languages,
or using different character encodings.

HTTP clients and their users might have different or variable
capabilities, characteristics or preferences which would 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
allowing selection of 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,  there are
other patterns: some applications 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. "Transparent Content Negotiation" [RFC 2295]
has also been proposed.


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 appropriate.

Note that caches can be instructed on how to manage 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.

Note that in all cases, the supplier of representations has the
responsibility for determining which representations might be
considered to be the "same information".