idnits 2.17.1 draft-ietf-http-negotiate-scenario-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 273 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** There are 2 instances of lines with control characters in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 209: '...gotiation method MUST meet the followi...' RFC 2119 keyword, line 212: '...1) It MUST provide at least as good a ...' RFC 2119 keyword, line 213: '... and User-Agent methods, and it SHOULD...' RFC 2119 keyword, line 217: '...2) It MUST NOT significantly increase ...' RFC 2119 keyword, line 220: '...3) It MUST NOT allow inappropriate con...' (1 more instance...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 1945 (ref. '1') == Outdated reference: A later version (-05) exists of draft-ietf-http-negotiation-02 ** Downref: Normative reference to an Experimental draft: draft-ietf-http-negotiation (ref. '2') Summary: 15 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Edward Hardie 2 Expires: December, 1997 NASA NIC 3 5 Scenarios for the Delivery of Negotiated Content using HTTP 7 1. Status of this Memo 9 This document is an Internet-Draft. Internet-Drafts are working 10 documents of the Internet Engineering Task Force (IETF), its areas, and 11 its working groups. Note that other groups may also distribute working 12 documents as Internet-Drafts. 14 Internet-Drafts are draft documents valid for a maximum of six months 15 and may be updated, replaced, or obsoleted by other documents at any 16 time. It is inappropriate to use Internet-Drafts as reference material 17 or to cite them other than as ``work in progress.'' 19 To learn the current status of any Internet-Draft, please check the 20 "1id-abstracts.txt" listing contained in the Internet- Drafts Shadow 21 Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), 22 ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 24 Distribution of this memo is unlimited. Please send comments to the 25 author. 27 2. Abstract 29 This document describes various problems which have arisen in attempts 30 to deliver negotiated content using HTTP and examines several 31 scenarios by which improvements in delivery might be accomplished. 32 This document does not discuss how HTTP might be used to negotiate the 33 use of other protocols to deliver content. 35 3. Problems with content negotiation in HTTP 37 Content providers on the World Wide Web would like to present their 38 material in the form most appropriate to each individual user. In 39 order to do this effectively, the content provider and content user 40 must be able negotiate among variants when more than one 41 representation of a resource is available. 43 The Hypertext Transport Protocol has since version 1.0 [1] used 44 certain request headers to indicate a list of the responses preferred 45 by the user agent making the request. The Accept request header is 46 used to indicate media types, Accept-Charset a list of preferred 47 character sets, Accept-Encoding supported content encodings, and 48 Accept-Language the set of natural languages preferred. In theory, a 49 server receiving these headers can use them to determine which of the 50 available variants of a particular item is most appropriate to the 51 requesting user agent. 53 Problems have emerged with this approach. First, the explosion of 54 content types in use on the World Wide Web has meant that Accept 55 headers would have to be extraordinarily long in order to adequately 56 state the user's Accept preferences. Increasing the length of the 57 Accept headers in order to negotiate consumes bandwidth for every 58 request, whether the resource has variants or not. Increasing their 59 complexity in order to account for all of the possible axes of 60 variation can also consume excessive amounts of server processing 61 power. Second, even if using a full list of Accept preferences did 62 not present resource problems, it could create privacy problems. A 63 full list of Accept preferences creates a user profile; in some 64 situations it could be combined with other information to track a 65 user's interaction with a server or set of servers even if the user 66 has taken steps to eliminate that possiblity. 68 Many content providers have attempted to circumvent the problems 69 associated with negotiation based on Accept headers. The most popular 70 method has been to examine the User-Agent header and to create content 71 tailored to the typical capabilities of that user agent. Because many 72 web user agents are both configurable and extensible, this method has 73 serious drawbacks. A user agent capable of using graphics but 74 configured to display only text may be presented with completely 75 unusable content. Conversely, a user agent which has been extended to 76 handle new media types may never be presented with them. The 77 usefulness of this method has been further degraded by some client 78 authors, who have chosen to use the User-Agent strings associated 79 with other clients in order to indicate compatibility; commonly, this 80 has been done even when the two clients are not, in fact, fully 81 compatible. 83 Content negotiation based on User-agent strings also creates 84 difficulties for caching proxies, as they have no way to determine 85 when the form of content delivered to two different user-agents would 86 be the same. The delivery of inappropriate content can be prevented 87 with the appropriate use of expiration times and cache control 88 directives, but only at the cost of serious losses in cache 89 efficiency. 91 4. Requirements for effective content negotiation 93 Content negotiation methods should improve the likelihood that the 94 best available resource variant is served to each user. If no 95 available resource variant is appropriate for a particular user, they 96 should furnish a method for the content provider to indicate that 97 lack. 99 Content negotiation methods should also accomplish their task without 100 substantially increasing the bandwidth required to deliver the 101 negotiated variant over that required to deliver similar invariant 102 content. Some increase must be expected, but the smallest possible 103 increase is preferred, and any overhead should be limited to those 104 resources for which variants are available. As a rule of thumb, any 105 method that increases bandwidth requirements by more than 50% is 106 unacceptable. For example, a method that delivered all available 107 variants to a client and expected the client to discard those that 108 were not used might be very successful in providing the best available 109 resource and in limiting overhead to those resources for which 110 variants existed; it would, nonetheless, be unacceptable for 111 deployment on the global Internet because of the wastage associated 112 with each delivery. 114 In addition, content negotiation methods should interact well with 115 caching proxies. They must prevent the delivery of inappropriate 116 content to proxy users. If possible, they should allow caches to 117 store sufficient information to participate in the negotiation 118 process. 120 5. Scenarios 122 5.1 Improvements to the current system 124 Content negotiation based on Accept headers or User-Agent strings is 125 undertaken by the server based on information present in all requests 126 from clients. The current problems with this method could be 127 ameliorated in a number of ways. Registration of feature bundles 128 could, for example, allow a client to indicate its capabilities 129 without the increase in packet size that individual enumeration of 130 capabilities requires. The use of registered feature bundles does, 131 however, require a fair amount of maintenance for both server and 132 clients, especially given their dynamic extendability. 134 Content providers could also improve the cachability of the variants 135 served by issuing redirects to unique URLs specific to each variant; 136 proxy users with equivalent feature bundles or user agents would then 137 be able to retrieve the cached variant once they received a redirect. 138 Some content providers already use this method to good effect. 140 5.2 Client-based negotiation 142 Improvements in the current method tend, however, to increase demands 143 on the processing power of the server, which raises serious problems 144 of scalability. Shifting all or part of the processing involved in 145 the negotiation to the client may improve scalability and shifts the 146 locus of negotiation to the party most aware of both the current and 147 potential possibilities for presentation to the user. 149 Client-based content negotiation can take two basic forms: elective 150 negotiation and "active content" negotiation. 152 5.2.1. Elective negotiation 154 Elective negotiation relies on the idea that the first response to a 155 request for a resource which has variants should be a statement naming 156 the choices and/or the axes along which they vary. The simplest form 157 of elective negotiation occurs when a content provider creates a 158 meta-resource with links to several variants and explanations of the 159 features needed to present each variant. This basic form presumes a 160 least common denominator for presentation of the links and an active 161 user selecting among the presentations. "Transport Content 162 Negotiation in HTTP" [2] provides for a more complex version of 163 elective negotiation. It describes a standard method for delineating 164 the axes along which a resource varies and a set of methods by which 165 caches can participate in the negotiation process. 167 Elective negotiation limits the process of selecting among variants to 168 the axes along which they vary. This eliminates the need for clients' 169 enumerating their capabilities and user preferences. It also provides 170 both a bandwidth savings and an increase in privacy. Many times, 171 however, this process requires a user to actively select among the 172 resources provided, which reduces perceived efficiency and increases 173 perceived latency. 175 5.2.2 "Active content" negotiation 177 "Active content" negotiation takes place when the request for a 178 resource which has variants returns content for execution in the 179 client context rather than for presentation to the user. This active 180 content determines the capabilities of the user agent and the 181 preferences of the user and then retrieves the best available variant 182 or provides an error status if no variants are appropriate. This 183 method has several advantages: the negotiation takes place without the 184 need for user intervention; the processing for selection of variants 185 is moved completely off the server; and the active content itself 186 should be cachable. 188 There are, however, several limitations to active content negotiation. 189 The most severe problem is that there is not yet a cross-platform 190 standard for active content. Without such a standard, servers may 191 have to engage in Accept header or User-Agent negotiation prior to 192 using active content in order to identify the correct form of active 193 content to send in response to a particular request. Some user agents 194 will also be unable to use active content, either because they have 195 limited processing power or because of security considerations (see 196 Section 7). For these user agents, a completely different method must 197 be provided. As with server-side negotiation, each variant will 198 require a unique URL to ensure cache correctness. 200 6. Summary 202 Content negotiation using HTTP currently presents problems in 203 accuracy, scalability, and privacy. Amelioration of the problems in 204 the current design is possible, but other content negotiation methods 205 may provide significant improvements. The type of content negotiation 206 most appropriate to a specific context will depend on the type of 207 variable content being served and the capabilities of the parties to 208 the negotiation. Before deployment on the global Internet, however, 209 any client-based content negotiation method MUST meet the following 210 tests: 212 1) It MUST provide at least as good a content negotiation facility as 213 the current Accept header and User-Agent methods, and it SHOULD 214 increase the likelihood that the best available variant is served to 215 each client. 217 2) It MUST NOT significantly increase the bandwidth required to 218 deliver the content. 220 3) It MUST NOT allow inappropriate content to be delivered to the 221 users of caching proxies. It SHOULD reduce overall bandwidth 222 requirements by providing cachable content and allowing proxies to 223 participate in the negotiation process. 225 Experimentation with various content negotiation methods may be 226 necessary to determine their usefulness for different types of 227 resources and contexts. Interoperability will be best maintained, 228 however, if a single method of each type is made standard as soon as 229 experience permits. 231 7. Security Considerations 233 "Active content" negotiation presumes that clients will execute code 234 provided by servers and that those clients will allow that code to 235 examine user preferences and user agent capabilities in order to 236 select among variants. Any such system would have to be tightly 237 bounded to prevent the active content from executing arbitrary code on 238 the client. The examination of user preferences and user agent 239 capabilities also presents a possible privacy problem, especially as 240 the selection of a particular variant provides an opportunity for the 241 active content to communicate its discoveries. 243 8. References 245 [1] Tim Berners-Lee, Roy Fielding, Henrik Frystk. Hypertext 246 Transfer Protocol -- HTTp/1.0. RFC RFC1945. May 1996. 248 [2] Koen Holtman and Andrew Mutz. Transport Content Negotiation in 249 HTTP. Internet-Draft draft-ietf-http-negotiation-02.txt, HTTP Working 250 Group, May 26, 1997. 252 9. Author's Address 254 Edward Hardie 255 NASA Network Information Center 256 MS 204-14 257 Moffett Field, CA 94035-1000 USA 258 +1 415 604 0134 259 hardie@nasa.gov