- From: Mark Nottingham <mnot@mnot.net>
- Date: Mon, 11 Nov 2013 17:31:30 +0800
- To: "Henry S. Thompson" <ht@inf.ed.ac.uk>
- Cc: "Julian F. Reschke" <julian.reschke@gmx.de>, "www-tag@w3.org WG" <www-tag@w3.org>, "apps-discuss@ietf.org Discuss" <apps-discuss@ietf.org>
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