Re: [apps-discuss] Request that the WG reconsider section 3.4: Content Negotiation

Mark Nottingham writes:

> On 5 Nov 2013, at 4:18 am, Henry S. Thompson <ht@inf.ed.ac.uk> wrote:
>
>>> Reactive conneg isn't just about 300s and 406s. Another example would
>>> be a representation returned with a 200 response that contains links
>>> to alternate versions of the content. That's what the
>> 
>> How is this in scope for discussion _in the HTTP spec._?  People (not
>> user agents, note) use 200 responses for a huge range of interesting,
>> powerful, innovative things.  We don't look in the HTTP spec. to find
>> a discussion of them.
>
> You seem to be thinking of HTTP as a separate layer from the
> application; as section 3.4 of p2 says, it¢s defining a pattern of
> use, and that is certainly in scope for this specification, given
> that it was also in scope for RF2616.

I guess it's statements such as "HTTP provides mechanisms for content
negotiation" (1st para of 3.4) and "patterns . . . visible within the
protocol" (2nd para) which suggest that we're talking about the HTTP
layer, not a more general functionality.

> We talked about this issue at the WG meeting yesterday. Based upon
> that discussion, we decided to close this issue. Looking at
> <https://svn.tools.ietf.org/svn/wg/httpbis/draft-ietf-httpbis/latest/p2-semantics.html#content.negotiation>,
> I can¢t see any immediate clarifications that would help; if you can
> suggest some, please do bring them to our attention.

Thanks for your time.  Here's a quick redraft of 3.4 (the first para
is nearly unchanged) -- this is the direction I think would be a
helpful change.

--------
3.4 MSc Content Negotiation

When responses convey payload information, whether indicating a
success or an error, the origin server often has different ways of
representing that information; for example, in different formats,
languages, or encodings.  Likewise, different users or user agents
might have differing capabilities, characteristics, or preferences
that could influence which representation, among those available,
would be best to deliver.  For this reason, HTTP provides mechanisms
supporting content negotiation, that is, means for clients and servers
to select, or involve users and user agents in selecting, among
alternative representations.

Note that, in all cases, HTTP is not aware of resource semantics.  The
consistency with which an origin server responds to requests, over
time and over the varying dimensions of content negotiation, and thus
the "sameness" of a resource's observed representations over time, is
determined entirely by whatever entity or algorithm selects or
generates those responses.  HTTP pays no attention to the man behind
the curtain.

In particular, this specification defines headers and response codes
for use in exchanges where multiple representations are, or may be,
involved.  Accept headers in requests (Section 5.3) allow clients to
signal preferred alternatives.  Such explicit preferences may derive
from user agent capabilities (for example with respect to image format
support), user preferences (for example with respect to natural
language) or local context (for example with respect to media type).
Servers may also infer implicit preferences from other properties of
requests such as the network address or User-Agent header.
Response codes (Sections 6.4.1 and 6.5.6) and response headers
(Sections 7.1.4 and 7.1.2) allow servers (and proxies) to signal the
success or failure in any attempt to satisfy client preferences
(implicit or explicit) as well as the availability of alternatives.

Although the most common use of these mechanisms is for clients to
include Accept headers in requests, and servers (or proxies) to select
among available alternatives based on those headers, a wide range of
other patterns of use exist, including ones where the initiative is
all on the server side, where for example a 300 response may accompany
a payload offering what amounts to spelling correction, as an
alternative to a 404.  Many of these patterns depend on particular
media types and/or user agents.
------------------
and leave it at that.  Some corresponding changes to the referenced
sections would likely be necessary to pick up a few of the details
from the now-deleted 3.4.1 and 3.4.2.

ht

"Whereof one cannot speak, thereof one must be silent"
-- 
       Henry S. Thompson, School of Informatics, University of Edinburgh
      10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
                Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk
                       URL: http://www.ltg.ed.ac.uk/~ht/
 [mail from me _always_ has a .sig like this -- mail without it is forged spam]

Received on Wednesday, 6 November 2013 11:07:27 UTC