- From: Henry S. Thompson <ht@inf.ed.ac.uk>
- Date: Wed, 06 Nov 2013 11:06:43 +0000
- To: Mark Nottingham <mnot@mnot.net>
- 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>
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