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

Hi Henry,

Thanks for taking the time to make a suggestion. Based on the discussions in Vancouver, I don¢t see consensus to make a change like this.

Regards,


On 6 Nov 2013, at 7:06 pm, Henry S. Thompson <ht@inf.ed.ac.uk> wrote:

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

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

Received on Monday, 11 November 2013 09:32:03 UTC