idnits 2.17.1 draft-ietf-http-negotiate-scenario-01.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-25) 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 306 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 227: '...gotiation method MUST meet the followi...' RFC 2119 keyword, line 230: '...1) It MUST provide at least as good a ...' RFC 2119 keyword, line 231: '... and User-Agent methods, and it SHOULD...' RFC 2119 keyword, line 235: '...2) It MUST NOT significantly increase ...' RFC 2119 keyword, line 238: '...3) It MUST NOT significantly increase ...' (3 more instances...) 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: January 18, 1998 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. 33 This document does not discuss how HTTP might be used to negotiate the 34 use of other protocols to deliver content. 36 3. Problems with content negotiation in HTTP 38 Content providers on the World Wide Web would like to present their 39 material in the form most appropriate to each individual user. In 40 order to do this effectively, the content provider and content user 41 must be able negotiate among variants when more than one 42 representation of a resource is available. This negotiation entails 43 the exchange of information between the provider and user about their 44 respective capabilities and preferences. 46 The Hypertext Transport Protocol has since version 1.0 [1] used 47 certain request headers to indicate a list of the responses preferred 48 by the user agent making the request. The Accept request header is 49 used to indicate media types, Accept-Charset a list of preferred 50 character sets, Accept-Encoding supported content encodings, and 51 Accept-Language the set of natural languages preferred. In theory, a 52 server receiving these headers can use them to determine which of the 53 available variants of a particular item is most appropriate to the 54 requesting user agent. 56 Problems have emerged with this approach. First, the explosion of 57 content types in use on the World Wide Web has meant that Accept 58 headers would have to be extraordinarily long in order to adequately 59 state the user's Accept preferences. Increasing the length of the 60 Accept headers in order to negotiate consumes bandwidth for every 61 request, whether the resource has variants or not. Increasing their 62 complexity in order to account for all of the possible axes of 63 variation can also consume excessive amounts of server processing 64 power. Second, even if using a full list of Accept preferences did 65 not present resource problems, it could create privacy problems. A 66 full list of Accept preferences creates a user profile; in some 67 situations it could be combined with other information to track a 68 user's interaction with a server or set of servers even if the user 69 has taken steps to eliminate that possiblity. 71 Many content providers have attempted to circumvent the problems 72 associated with negotiation based on Accept headers. The most popular 73 method has been to examine the User-Agent header and to create content 74 tailored to the typical capabilities of that user agent. Because many 75 web user agents are both configurable and extensible, this method has 76 serious drawbacks. A user agent capable of using graphics but 77 configured to display only text may be presented with completely 78 unusable content. Conversely, a user agent which has been extended to 79 handle new media types may never be presented with them. The 80 usefulness of this method has been further degraded by some client 81 authors, who have chosen to use the User-Agent strings associated 82 with other clients in order to indicate compatibility; commonly, this 83 has been done even when the two clients are not, in fact, fully 84 compatible. 86 Content negotiation based on Accept headers or User-agent strings also 87 creates difficulties for caching proxies, as they have no way to 88 determine when the form of content delivered to two different 89 user-agents would be the same. The delivery of inappropriate content 90 can be prevented with the appropriate use of expiration times and 91 cache control directives, but only at the cost of serious losses in 92 cache efficiency. 94 4. Requirements for effective content negotiation 96 Content negotiation methods should improve the likelihood that the 97 best available resource variant is served to each user. If no 98 available resource variant is appropriate for a particular user, they 99 should furnish a facility for the content provider to indicate that 100 lack. 102 Content negotiation methods should also accomplish their task without 103 substantially increasing the bandwidth or number of network round 104 trips required to deliver the negotiated variant over that required to 105 deliver similar invariant content. Some increase must be expected, 106 but the smallest possible increase is preferred, and any overhead 107 should be limited to those resources for which variants are available. 109 As a rule of thumb, any method that increases bandwidth requirements 110 by more than 50% is unacceptable. For example, a method that 111 delivered all available variants to a client and expected the client 112 to discard those that were not used might be very successful in 113 providing the best available resource and in limiting overhead to 114 those resources for which variants existed; it would, nonetheless, be 115 unacceptable for deployment on the global Internet because of the 116 wastage associated with each delivery. 118 Similarly, any method which adds more than two network round trips to 119 the content delivery is unacceptable. While some negotiation 120 exchanges might be appropriately conceived as a series of increasingly 121 detailed "questions" and "answers" about the respective capabilities 122 and preferences of the parties involved, the increase in latency such 123 extended exchanges would entail make them inappropriate for deployment 124 on the global Internet. 126 In addition, content negotiation methods should interact well with 127 caching proxies. They must prevent the delivery of inappropriate 128 content to proxy users. If possible, they should allow caches to 129 store sufficient information to participate in the negotiation 130 process. 132 Lastly, content negotiation methods used in this context will be 133 preferred if they are extensible to other MIME transport protocols 134 that have the need to negotiate over the same space. Not all aspects 135 of negotiation needed for HTTP fit within the MIME context, however, 136 and content negotiation should not be limited to just those aspects 137 which do. 139 5. Scenarios 141 5.1 Improvements to the current system 143 Content negotiation based on Accept headers or User-Agent strings is 144 undertaken by the server based on information present in all requests 145 from clients. The current problems with this method could be 146 ameliorated in a number of ways. Registration of feature bundles 147 could, for example, allow a client to indicate its capabilities 148 without the increase in packet size that individual enumeration of 149 capabilities requires. The use of registered feature bundles does, 150 however, require a fair amount of maintenance for both server and 151 clients, especially given their dynamic extendability. 153 Content providers could also improve the cachability of the variants 154 served by issuing redirects to unique URLs specific to each variant; 155 proxy users with equivalent feature bundles or user agents would then 156 be able to retrieve the cached variant once they received a redirect. 157 Some content providers already use this method to good effect. 159 5.2 Client-based negotiation 161 Improvements in the current method tend, however, to increase demands 162 on the processing power of the server, which raises serious problems 163 of scalability. Shifting all or part of the processing involved in 164 the negotiation to the client may improve scalability and shifts the 165 locus of negotiation to the party most aware of both the current and 166 potential possibilities for presentation to the user. 168 Client-based content negotiation can take two basic forms: elective 169 negotiation and "active content" negotiation. 171 5.2.1. Elective negotiation 173 Elective negotiation relies on the idea that the first response to a 174 request for a resource which has variants should be a statement naming 175 the choices and/or the axes along which they vary. The simplest form 176 of elective negotiation occurs when a content provider creates a 177 meta-resource with links to several variants and explanations of the 178 features needed to present each variant. This basic form presumes a 179 least common denominator for presentation of the links and an active 180 user selecting among the presentations. More complex versions of 181 elective negotiation might use HTTP protocol elements to present the 182 axes of variation for a particular resource ("Transparent Content 183 Negotiation in HTTP" [2] presents one proposal along these lines). 185 Elective negotiation limits the process of selecting among variants to 186 the axes along which they vary. This eliminates the need for clients' 187 enumerating their capabilities and user preferences. It also provides 188 both a bandwidth savings and an increase in privacy. This process may, 189 however, require a user's intervention to select among the resources 190 provided, which reduces perceived efficiency and increases perceived 191 latency. 193 5.2.2 "Active content" negotiation 195 "Active content" negotiation takes place when the request for a 196 resource which has variants returns content for execution in the 197 client context rather than for presentation to the user. This active 198 content determines the capabilities of the user agent and the 199 preferences of the user and then retrieves the best available variant 200 or provides an error status if no variants are appropriate. This 201 method has several advantages: the negotiation takes place without the 202 need for user intervention; the processing for selection of variants 203 is moved completely off the server; and the active content itself 204 should be cachable. 206 There are, however, several limitations to active content negotiation. 207 The most severe problem is that there is not yet a cross-platform 208 standard for active content. Without such a standard, servers may 209 have to engage in Accept header or User-Agent negotiation prior to 210 using active content in order to identify the correct form of active 211 content to send in response to a particular request. Some user agents 212 will also be unable to use active content, either because they have 213 limited processing power or because of security considerations (see 214 Section 7). For these user agents, a completely different method must 215 be provided. As with server-side negotiation, each variant will 216 require a unique URL to ensure cache correctness. 218 6. Summary 220 Content negotiation using HTTP currently presents problems in 221 accuracy, scalability, and privacy. Amelioration of the problems in 222 the current design is possible, but other content negotiation methods 223 may provide significant improvements. The type of content negotiation 224 most appropriate to a specific context will depend on the type of 225 variable content being served and the capabilities of the parties to 226 the negotiation. Before deployment on the global Internet, however, 227 any client-based content negotiation method MUST meet the following 228 tests: 230 1) It MUST provide at least as good a content negotiation facility as 231 the current Accept header and User-Agent methods, and it SHOULD 232 increase the likelihood that the best available variant is served to 233 each client. 235 2) It MUST NOT significantly increase the bandwidth required to 236 deliver the content. 238 3) It MUST NOT significantly increase the number of network round 239 trips required to deliver the content. 241 4) It MUST NOT allow inappropriate content to be delivered to the 242 users of caching proxies. It SHOULD reduce overall bandwidth 243 requirements by providing cachable content and allowing proxies to 244 participate in the negotiation process. 246 5) It SHOULD recognize HTTP's relationship to MIME and provide methods 247 which are extensible to other MIME transports when the space over 248 which negotiation takes place is the same. 250 Experimentation with various content negotiation methods may be 251 necessary to determine their usefulness for different types of 252 resources and contexts. Interoperability will be best maintained, 253 however, if a single method of each type is made standard as soon as 254 experience permits. 256 7. Security Considerations 258 "Active content" negotiation presumes that clients will execute code 259 provided by servers and that those clients will allow that code to 260 examine user preferences and user agent capabilities in order to 261 select among variants. Any such system would have to be tightly 262 bounded to prevent the active content from executing arbitrary code on 263 the client. The examination of user preferences and user agent 264 capabilities also presents a possible privacy problem, especially as 265 the selection of a particular variant provides an opportunity for the 266 active content to communicate its discoveries. 268 8. Acknowledgements 270 Koen Holtman, Graham Klyne, Scott Lawrence, and Larry Masinter 271 provided valuable feedback on the initial draft of this document. 272 Discussions within the HTTP working group and the IETF-FAX mailing 273 list also provided insights into the scope of negotiation needed in 274 the HTTP context. 276 9. References 278 [1] Tim Berners-Lee, Roy Fielding, Henrik Frystk. Hypertext 279 Transfer Protocol -- HTTP/1.0. RFC RFC1945. May 1996. 281 [2] Koen Holtman and Andrew Mutz. Transport Content Negotiation in 282 HTTP. Internet-Draft draft-ietf-http-negotiation-02.txt, HTTP Working 283 Group, May 26, 1997. 285 9. Author's Address 287 Edward Hardie 288 NASA Network Information Center 289 MS 204-14 290 Moffett Field, CA 94035-1000 USA 291 +1 415 604 0134 292 hardie@nasa.gov