idnits 2.17.1 draft-ietf-http-negotiate-scenario-02.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 313 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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) ** Obsolete normative reference: RFC 2068 (ref. '2') (Obsoleted by RFC 2616) ** Obsolete normative reference: RFC 1305 (ref. '3') (Obsoleted by RFC 5905) -- No information found for draft-ietf-http-alternates - is the name correct? -- Possible downref: Normative reference to a draft: ref. '4' Summary: 14 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Edward Hardie 2 Expires: May, 1998 NASA NIC 3 5 Scenarios for the Delivery of Negotiated Content 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 A number of Internet application protocols have a need to provide 30 content negotiation for the resources with which they interact. While 31 MIME media types [1] provide a standard method for handling one 32 major axis of variation, resources also vary in ways which cannot be 33 expressed using currently available MIME headers. This paper asserts 34 that a cross-protocol negotiation framework is needed, both to 35 leverage work already done for specific protocols and to allow for 36 content negotiation when resources will pass through several 37 protocols on their way from provider to recipient. To justify the 38 need, this paper puts forward several content negotiation scenarios 39 and discusses how they affect the requirements for such a framework. 41 3. Introduction 43 When a content provider makes a particular resource available in a 44 number of different representations, content negotiation may be used 45 to determine which of the available variants should be provided to a 46 particular recipient. This negotiation entails the exchange of 47 information between the resource provider and the recipient about 48 their respective capabilities and preferences. Among the key pieces 49 of information needed in this exchange are: 51 1) How the available representations of the resource vary. 53 2) The preferences of the provider among the available representations. 55 3) The capabilities and preferences of the recipient. 57 3.1 Representing variation 59 The MIME Content-type header can be used to differentiate 60 representations which differ by media type, and it is already used by 61 many protocols for that purpose. Many representations differ, 62 however, by features which are not reflected in media types; two 63 representations using the image/gif type may, for example, differ in 64 color depth. There are several possible methods for referring to 65 these features: 67 a) using a feature tag registry to record specific feature tags which can 68 be used to describe variants. 70 b) using URIs to point to descriptions of specific features. 72 c) using standardized reference documents as pointers to descriptions of 73 the features. 75 In each case, the association of a particular feature with a 76 registered tag, URI, or standardized reference must take place prior 77 to any content negotiation using that feature. The selection of which 78 method to use to represent variation will depend primarily on how the 79 need for extensibility contrasts with the need for a stable reference. 80 A single feature tag registry provides a highly stable core set of 81 features, but is likely to be relatively slow in deployment of new 82 features. A URI-based system is likely to be highly adaptable to new 83 features, but susceptible to duplication and loss of information. The 84 use of pointers to standardized reference documents allows more than one 85 organization to participate in the vetting of new features, but this 86 method may engender confusion about which organization should review a 87 feature. 89 3.2 Provider preferences 91 Provider preferences are commonly expressed as opinions on the quality 92 of various representations of the resource. The determination of 93 quality may be made by reference to a particular standard; the 94 determination of the lossiness of a JPEG image may, for example, be 95 made with reference to the JPEG standards. Quality may also be 96 assigned on a subjective basis, however; an author might, for example, 97 decide that the loss of figures in an ASCII representation of resource 98 implied a loss in quality, but she would have to invent a figure to 99 describe that loss. 101 The numerical expression of quality indicators can be ascending or 102 descending. In HTTP 1.1 [2], lower qvalues represent increasing 103 degradation of quality; in NTP [3], in contrast, quality indicators 104 like peer.dispersion use increasing values to represent increasing 105 degradation. A standard method for indicating provider preferences 106 for content-negotiating protocols is clearly needed for any system 107 based on numerical expressions of quality to work. Any system based 108 on non-numerical expressions of quality will similarly need 109 standardization of the terms by which quality is expressed. 111 3.3 Recipient capabilities and preferences 113 The expression of recipient capabilities and preferences presents all 114 of the problems of feature description and provider preferences, as 115 well as some unique issues. If a standardized method of expressing 116 features is available (cf 3.1, above), recipient capabilities may be 117 expressed with reference to Content-type and one or more features. 118 Similarly, recipient preferences can be expressed using a numerical 119 system like those described above in 3.2, with many of the same 120 problems of how to apply subjective criteria being present. 122 When to send indications of recipient preferences and capabilities and 123 how to indicate dependencies among them present problems unique to the 124 recipient side of the equation. A content provider knows when 125 multiple variants are present and on what basis the representations 126 vary. The recipient, in contrast, does not know a particular resource 127 has variants unless the content provider chooses to present that 128 information. Depending on the type of exchange, a recipient may be 129 able to choose when or if to present its capabilities and preferences. 130 If it can and chooses to do so prior to every exchange, it will be 131 wasting network and processor resources whenever the resource has no 132 variants. If it never presents its capabilities it may get a less 133 than optimal variant. If it waits for an indication that variants 134 exist, a lag in the exchange is introduced which may be quite 135 significant for store-and-forward protocols. 137 Expressing the dependencies among various capabilities also presents 138 problems. A printer may, for example, be able to print either in 139 color or at a high density; if the relationship between the two 140 features is not fixed, however, expressing it appropriately may be 141 very difficult. 143 4.0 Scenarios 145 Content negotiation may be provider-based, recipient-based, or based 146 on active content. 148 4.1 Provider-based negotiation 150 Provider-based content negotiation occurs when the provider of a 151 resource selects among the available variants without (or prior to) 152 notifying the potential recipient that alternatives exist. In HTTP, 153 for example, content providers may configure their servers to deliver 154 certain variants based on the user-agent of the requester or the 155 Accept headers available in the request. 157 This method is obviously limited to protocols in which recipients 158 initiate requests for resources and provide information about their 159 capabilities in those requests. Beyond that limitation are several 160 problems of scalability. As features multiply, the overhead of 161 providing information on capabilities for each potential feature 162 grows, and since that overhead is incurred for every exchange it can 163 rapidly lead to network resource problems. The use of feature 164 "bundles" would ameliorate this somewhat, but it would increase the 165 problems associated with maintenance for both provider and recipients. 167 Provider-based selection may also present privacy problems, as the 168 full set of preferences and capabilities must be released to the 169 provider for the negotiation to operate at its best. This creates an 170 effective user profile, which could be combined with other information 171 to reveal more about potential recipients than they intend or expect. 173 Lastly, it is common for a single provider to serve multiple 174 recipients. As the number of potential recipients grows, the 175 processing power required to handle variant selection also grows, 176 and this can strain providers. 178 4.2 Recipient-based negotiation 180 Recipient-based selection occurs whenever the provider notifies 181 the recipient that alternatives exist and allows the recipient to 182 select among them. The Multipart-alternative MIME type is currently 183 the chief method by which providers notify potential recipients that 184 alternatives exist. This message type allows the provider to send 185 either all of the available variants or, with external message bodies, 186 pointers to each of them. The alternatives are ranked by the provider 187 according to the provider's preferences, and the recipient selects the 188 first of the alternatives that it can handle. 190 An Alternates header [4] has been proposed to both extend and 191 simplify the Multipart alternative method for delivering information 192 on available variants. Using an Alternates header, a provider can 193 notify a potential recipient of available variants without the 194 overhead of MIME multipart. The Alternates header also proposes a 195 method by which the provider can indicate on what basis the variants 196 differ, so that recipients can select based on the variation rather 197 than the rank assigned by the provider. 199 This form of negotiation limits the process of selection among 200 variants to the axes along which they vary. This eliminates the need 201 for recipients to enumerate their capabilities and preferences, which 202 increases the recipients' privacy and reduces the possibility of 203 bandwidth wastage or provider processor strain. This shift to 204 recipient-based selection increases, however, the processing demanded 205 of the recipient. Depending on how the alternatives are presented, it 206 also either wastes bandwidth in the delivery of all available variants 207 or requires an additional step in the secondary retrieval of the one 208 selected. If no resources are available or if the available methods 209 for selecting among them are inadequate, this method may also require 210 direct user intervention. 212 4.3 Active content negotiation 214 Active content negotiation takes place when the resource provided 215 contains content for execution in the recipient's environment; this 216 active content then determines the capabilities and preferences of the 217 recipient and retrieves or produces the best available variant. 219 This method has several advantages: it reduces the possible need for 220 active user intervention; it has the potential to use more complex 221 algorithms for selection than are available with Multipart-alternative 222 or Alternates-based systems; and the active content can be cached for 223 later use. 225 There are, however, several limitations to the usefulness of active 226 content negotiation. The most severe problem is that there is no 227 cross-platform or cross-protocol standard for active content. Without 228 such a standard, providers must engage in other forms of content 229 negotiation before providing the correct form of active content. The 230 use of active content also raises the bar for recipients again, and 231 some recipients will be unable to use it, either because of limited 232 processing power or because of security considerations (cf 6, below). 234 5. Requirements and Desiderata 236 The limitations of each of the current methods of content negotiation 237 signal the need for a comprehensive framework for negotiation. For 238 that framework, this author believes that there are three principal 239 requirements and three additional desiderata: 241 1) A cross-protocol negotiation framework must include a standardized 242 method for reflecting content features. 244 2) A cross-protocol negotiation framework must include a standardized 245 method for associating variants with features. 247 3) A cross-protocol negotiation framework must provide a method for 248 indicating provider and recipient preferences for specific features 250 4) A cross-protocol negotiation framework should have the minimum 251 possible impact on network resource consumption, especially in terms 252 of bandwidth and number of round-trips required. 254 5) A cross-protocol negotiation framework should protect the privacy 255 of users' profiles and providers' inventories of variants. 257 6) A cross-protocol negotiation framework should allow intelligent 258 gateways, proxies, or caches to participate in the negotiation. 260 6. Security Consideration 262 Active content negotiation presumes that recipients will execute code 263 provided and will allow that code to examine user preferences and 264 capabilities in order to select among variants. Any such system would 265 have to be tightly bounded to prevent the active content from 266 executing arbitrary code on the client. 268 Detailed listings of user preferences and capabilities present 269 possible privacy problems, whether that listing occurs in 270 provider-based negotiation or via active content. Some content 271 providers may also find that exhaustive listings of available 272 representations may compromise their privacy. 274 7. Acknowledgments 276 Larry Masinter, Koen Holtman, Graham Klyne, Scott Lawrence, Dan Wing, 277 Andy Mutz, and Neil Joffe provided valuable comments on previous 278 versions of this draft. Discussions within the HTTP working group and 279 the IETF-FAX mailing list also provided insights into the scope of 280 negotiation needed in different contexts. 282 8. References 284 [1] Freed, N., and N. Borenstein, "Multipurpose Internet Mail 285 Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 286 2045 288 [2] Fielding, R., et al, "Hypertext Transfer Protocol -- HTTP/1.1", 289 RFC 2068 291 [3] Mills, D. "Network Time Protocol (Version 3) Specification, 292 Implementation", RFC 1305 294 [4] Holtman, K., et al, "The Alternates Header Field", Internet-Draft 295 draft-ietf-http-alternates-01.txt, HTTP working group, November 1997. 297 9. Author's Address 299 Edward Hardie 300 NASA Network Information Center 301 MS 204-14 302 Moffett Field, CA 94035-1000 303 +1 650 604 0134 304 hardie@nic.nasa.gov