idnits 2.17.1 draft-ietf-http-feature-scenarios-01.txt: 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-19) 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 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 545 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 3 characters in excess of 72. 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.) -- The document date (July 28, 1997) is 9762 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '3' is defined on line 504, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2048 (ref. '1') (Obsoleted by RFC 4288, RFC 4289) ** Obsolete normative reference: RFC 2068 (ref. '2') (Obsoleted by RFC 2616) == Outdated reference: A later version (-05) exists of draft-ietf-http-negotiation-03 ** Downref: Normative reference to an Experimental draft: draft-ietf-http-negotiation (ref. '3') Summary: 11 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 HTTP Working Group Koen Holtman, TUE 2 Internet-Draft Andrew Mutz, Hewlett-Packard 3 Expires: January 28, 1998 July 28, 1997 5 Feature Tag Scenarios 7 draft-ietf-http-feature-scenarios-01.txt 9 STATUS OF THIS MEMO 11 This document is an Internet-Draft. Internet-Drafts are 12 working documents of the Internet Engineering Task Force 13 (IETF), its areas, and its working groups. Note that other 14 groups may also distribute working documents as 15 Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of 18 six months and may be updated, replaced, or obsoleted by 19 other documents at any time. It is inappropriate to use 20 Internet-Drafts as reference material or to cite them other 21 than as "work in progress". 23 To learn the current status of any Internet-Draft, please 24 check the "1id-abstracts.txt" listing contained in the 25 Internet-Drafts Shadow Directories on ftp.is.co.za 26 (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific 27 Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US 28 West Coast). 30 Distribution of this document is unlimited. Please send 31 comments to the HTTP working group at 32 . Discussions of the working 33 group are archived at 34 . General 35 discussions about HTTP and the applications which use HTTP 36 should take place on the mailing list. 38 A HTML version of this document can be found at 39 . 41 ABSTRACT 43 Recent Internet applications, such as the World Wide Web, tie 44 together a great diversity in data formats, client and server 45 platforms, and communities. This has created a need for various 46 kinds of negotiation mechanisms, which tailor the data which is 47 exchanged, or the exchange process itself, to the capabilities and 48 preferences of the parties involved. 50 Extensible negotiation mechanisms need a vocabulary to identify 51 various things which can be negotiated on. To promote 52 interoperability, a registration process is needed to ensure that 53 that this vocabulary, which can be shared between negotiation 54 mechanisms, is developed in an orderly, well-specified, and public 55 manner. 57 This document discusses requirements and scenarios the registration 58 of this vocabulary, which is the vocabulary of feature tags. 59 Feature tag registration is foreseen as an ongoing, open process 60 which will keep pace with the introduction of new features by 61 software vendors, and other parties such as standards bodies. 63 TABLE OF CONTENTS 65 1 Introduction 67 2 Basic concepts and definitions 68 2.1 Areas of negotiation and feature tags 69 2.2 Complexity of negotiation 70 2.3 The result in an area of negotiation 72 3 Extensible negotiation mechanisms 73 3.1 The need for extensible negotiation mechanisms: the case of the Web 74 3.2 Extensible negotiation mechanisms for the Web 75 3.3 Extensible negotiation mechanisms for other Internet protocols 77 4 Feature tag registration 78 4.1 IANA registration procedures 79 4.2 Examples of parties who would want to register feature tags 80 4.3 Feature tag registration scenario 81 4.4 Volume considerations 82 4.5 Danger of excessive registration 84 5 Security considerations 86 6 Acknowledgments 88 7 References 90 8 Authors' addresses 92 1 Introduction 94 Recent Internet applications, such as the World Wide Web, tie 95 together a great diversity in data formats, client and server 96 platforms, and communities. This has created a need for various 97 kinds of negotiation mechanisms, which tailor the data which is 98 exchanged, or the exchange process itself, to the capabilities and 99 preferences of the parties involved. 101 Extensible negotiation mechanisms need a vocabulary to identify 102 various things which can be negotiated on. To promote 103 interoperability, a registration process is needed to ensure that 104 that this vocabulary, which can be shared between negotiation 105 mechanisms, is developed in an orderly, well-specified, and public 106 manner. 108 This document discusses requirements and scenarios the registration 109 of this vocabulary, which is the vocabulary of feature tags. 110 Feature tag registration is foreseen as an ongoing, open process 111 which will keep pace with the introduction of new features by 112 software vendors, and other parties such as standards bodies. 114 2 Basic concepts and definitions 116 2.1 Areas of negotiation and feature tags 118 Something which can be negotiated on is called an `area of 119 negotiation' in this document. Examples of areas of negotiation 120 are: 122 * the MIME media type of the data which is transmitted 123 * the language of the text document which is transmitted 124 * the color depth of the screen on which something is to be 125 displayed 126 * whether the recipient supports the `floating 5 dimensional 127 tables' feature 128 * the fonts which are available to the recipient 129 * whether a Web user prefers speed over graphical detail 130 * whether the recipient is capable of displaying graphical 131 content 132 * whether the user prefers a blue background with purple dots over 133 a green background with pictures of small furry animals, except 134 on Fridays. 136 A feature tag identifies a single area of negotiation. 138 It is expected that the majority of feature tags will identify new 139 areas of negotiation, in which the object of negotiation is to 140 decide on the presence or use of some new feature in a software 141 product. This explains the name `feature tag'. 143 It is recognized that there is continuous growth in the number of 144 areas in which some form of negotiation is desirable. To keep up 145 with this growth, extensible negotiation mechanisms are needed, 146 which refer to the feature tag vocabulary to identify new areas of 147 negotiation, rather than relying on hard-coded knowledge about a 148 few areas. 150 To avoid the duplication of work, and to promote the interoperable 151 naming of areas of negotiation across protocols and applications, 152 the feature tag namespace should not be bound to a particular 153 protocol or negotiation mechanism. Also, there should be no prior 154 restriction on the areas of negotiation which may be identified by 155 a feature tag, other than that it must be conceivable to negotiate 156 in these areas in the context of some Internet application. 158 2.2 Complexity of negotiation 160 Negotiation processes can often be complex. Two frequent sources 161 of complexity are: 163 1. An area of negotiation may be inherently complex. For 164 example, negotiating on the use of a particular media type is 165 inherently more complex than negotiating on the presence of a 166 single feature, because there are more possible outcomes. 168 2. There may be complex of interdependencies between the choices 169 in different areas of negotiation. For example, if the 170 following versions of a document are available on a Web server: 172 * text/html, English 173 * text/plain, French 174 * audio/x-wav, German 176 then the content negotiation mechanism cannot treat the areas 177 of `MIME media type negotiation' and `language negotiation' as 178 separate. 180 It is recognized that extensible negotiation mechanisms will often 181 differ in the type and amount of complexity they can handle. Thus, 182 though negotiation mechanisms share the feature tag namespace, it 183 will not be the case that every tag is usable in every negotiation 184 mechanism, or that every negotiation mechanism will be able to 185 handle all possible interdependencies. 187 2.3 The result in an area of negotiation 189 During negotiation, negotiation mechanisms will often need to 190 transmit (canonical representations of) the possible results in 191 various areas of negotiation over the wire. Also, at the end of a 192 negotiation process, the mechanism may need to return (a 193 canonical representation of) the result to the application which 194 invoked it. 196 In many areas of negotiation, there will be a natural, canonical 197 representation of the result. For example, in the area 199 * whether the recipient supports the `floating 5 dimensional 200 tables' feature 202 the canonical representation of the result is a boolean value (yes, 203 the feature is supported, or no, the feature is not supported). In 204 the area 206 * the MIME media type of the data which is transmitted 208 the canonical representation of the result will be a MIME media 209 type identifier like text/html or application/postscript. In some 210 areas of negotiation, the result could be a compound value (e.g. a 211 coordinate in a 3D space). 213 To promote interoperability, the registration entry of a feature 214 tag can include a definition of the canonical representations of 215 the possible results in the corresponding area of negotiation. 217 3 Extensible negotiation mechanisms 219 We call a negotiation mechanism extensible if the set of areas 220 on which the mechanism can negotiate is extensible, instead of 221 hard-coded inside the mechanism. 223 3.1 The need for extensible negotiation mechanisms: the case of the Web 225 HTTP [2] has traditionally recognized four areas of negotiation: 227 1. MIME media type 228 2. Charset 229 3. Language 230 4. Encoding 232 HTTP provides support for these areas of negotiation by defining 233 identifiers (Accept headers) for these areas, and defining 234 canonical representations of the possible results in these areas. 236 Experience with the Web has shown there is a great need to 237 negotiate on things which do not fit the four areas above. This 238 need has shown itself in a number of ways: 240 - Web servers routinely use (abuse) other headers than the Accept 241 headers for negotiation purposes. In particular, the HTTP 242 User-Agent header has been widely used by web sites to detect 243 the presence of certain features in browsers, and by browsers 244 to trigger certain features in web sites, even though such use 245 is error-prone, and conflicts with the original purpose of the 246 User-Agent header. 248 - Web servers routinely use `dynamic URLs' and cookies to encode 249 negotiation related information like user preferences. This 250 can be cache-unfriendly, in particular in the case of `dynamic 251 URLs'. 253 - During the standardization of HTTP, several proposals for 254 additional Accept headers, matching additional areas of 255 negotiation, were made. These proposals have been rejected in 256 favor of developing an extensible negotiation mechanism. 258 - There has been pressure to extend the MIME media type parameter 259 mechanism to allow for the naming of, and negotiation on, new 260 features in media types already registered, something which is 261 explicitly disallowed in the MIME type registration rules. It 262 was recognized that this pressure would be better addressed by 263 creating a new namespace independent from the MIME media type 264 space. 266 3.2 Extensible negotiation mechanisms for the Web 268 In the IETF HTTP working group, it has been recognized that the 269 number of areas for Web content negotiation is growing so rapidly 270 that the IETF would never be able to keep up with this growth by by 271 continually revising a negotiation mechanism with a hard-coded set 272 of areas. Instead, a number of extensible content negotiation 273 mechanisms have been proposed. All of these mechanisms share the 274 need for an external vocabulary to identify areas, a vocabulary 275 which can be updated quickly enough to keep pace with the 276 introduction of new features by Web software vendors. 278 The proposed extensible content negotiation mechanisms are 279 transparent content negotiation [2], and negotiation mechanisms 280 based on various forms of "active content". In "active content" 281 negotiation, the web server returns an executable program which is 282 run by the browser. This program then accesses a database of 283 negotiation related settings inside the browser, and chooses and 284 renders the most appropriate content. Note that there are several 285 existing and proposed forms of active content. 287 To tie everything together, a browser architecture with a common 288 internal database for negotiation related information has been 289 proposed. The database would be filled to reflect the capabilities 290 of all browser components, both native components and plugins, and 291 the preference settings made by the user. Feature tags would serve 292 as the keys under which the database entries for different areas of 293 negotiation are stored. Individual negotiation mechanisms could 294 access the central database through some API. The architecture is 295 shown in the following picture. 297 +-----------------------------------------------------------------+ 298 | BROWSER | 299 | | 300 | +------------------+ +----------+ +----------+ +-----------+ | 301 | | Native browser | | Plugin 1 | | Plugin 2 | |User | | 302 | | rendering engine | +----------+ +----------+ |preferences| | 303 | +------------------+ | | +-----------+ | 304 | | | | | | 305 | V V V V | 306 | +------------------------------------------------------+ | 307 | | Common internal database for negotiation information | | 308 | +------------------------------------------------------+ | 309 | | | | | | 310 | API API API API | 311 | | | | | | 312 | V V V V | 313 | +---------+ +---------+ +-------------+ | 314 | | Java | | JScript | | transparent | | 315 | | based | | based | ..etc | content | | 316 | | active | | active | | negotiation | | 317 | | content | | content | | engine | | 318 | +---------+ +---------+ +-------------+ | 319 | | 320 +-----------------------------------------------------------------+ 322 3.3 Extensible negotiation mechanisms for other Internet protocols 324 Extensible negotiation mechanisms for Internet printing and 325 Internet fax are currently under investigation in the IETF. 327 It has been proposed to make multipart/alternative negotiation in 328 Internet mail more extensible, in particular if the mail client is 329 part of a Web browser, by adapting some of the protocol elements 330 developed for transparent content negotiation [2] to Internet mail. 332 4 Feature tag registration 334 4.1 IANA registration procedures 336 Examples of IANA registration procedures can be found in [1]. 338 There has been some confusion over what the IANA will register. 339 Jon Postel told us that: 341 The IANA is pretty good at keeping lists. It is not so good at 342 evaluating the merits (or lack thereof) of the requests to add 343 things to lists. [...] So, yes the IANA would keep the list of 344 "feature tags" provided that that there is either a very simple 345 way to decide if requests pass muster, or a designated someone 346 else will be available to make that decision. 348 So two types of registration namespaces can be created: 350 a) a space with feature tag review process performed by the IETF 352 b) a space with very basic registration rules which do not take 353 the merit of the feature tag into account. To quote [1], 354 this type of registration "does not imply endorsement, 355 approval, or recommendation by the IANA or IETF or even 356 certification that the specification is adequate." 358 If extensible negotiation mechanisms are to keep up with the speed 359 of development in the Web, a type b) registration process for 360 feature tags seems necessary, if only because the IETF does not 361 have the manpower required for a review process which can keep up 362 with the speed of Web development. 364 It is proposed that feature tag registration closely mimics the new 365 MIME media type registration rules in [1], providing both type a) 366 and b) namespaces. This proposal is based on the observation that 367 the rules in [1] seem to be working nicely. 369 4.2 Examples of parties who would want to register feature tags 371 Feature registration allows for the quick introduction of new areas 372 of negotiation in extensible negotiation mechanisms. In a Web 373 context, examples of parties which might want to introduce new 374 areas of negotiation are: 376 1. Browser and browser component vendors, when inventing and 377 implementing new features or components. 379 2. The IETF or some other standards body, when creating a new 380 standard for a content format, or when identifying a new type 381 of user preference (for example a preference for 382 representations without animated gifs). 384 3. Content authors, when identifying a new type of user 385 preference and creating new content to match. 387 A fast registration process is mainly needed for registration by 388 group 1 and 3. For 2, a slower process would suffice. 390 4.3 Feature tag registration scenario 392 Below is a scenario, in a Web context, for the registration of a 393 feature tag which succeeds in being generally used. 395 Time Action 396 (months) 398 t+0 Browser vendor A invents the new feature XY. 400 t+1 Vendor A starts implementing XY, and completes a 401 feature tag registration form for the `g.xy' tag. 403 t+2 Vendor A submits the form and the IANA registers the `g.xy' 404 feature tag. 406 t+2.1 Vendor A releases a new browser version, which 407 a) implements the feature XY 408 b) has an entry under `g.xy' in its negotiation database, 409 which tells extensible negotiation mechanisms that this 410 feature is present 412 t+2.5 `Early adopter' content authors start making content 413 representations which use XY. 415 t+3 Vendor B starts implementing XY in their own browser. 417 t+3 The `g.xy' tag appears in lists of useful tags maintained by 418 third parties. 420 t+3.5 Vendor B releases a new browser version, which 421 a) implements the feature XY 422 b) has an entry under `g.xy' in its negotiation database, 423 which tells extensible negotiation mechanisms that this 424 feature is present 426 t+3.5 Many content authors start making content representations 427 which use XY. 429 t+4 Vendor C starts implementing XY, and invents the extension 430 XY_COLOR. 432 t+4.5 Vendor C registers the `g.xy_color' feature tag. 434 t+4.5 Vendor C releases a new browser version, which 435 a) implements the features XY and XY_COLOR 436 b) has appropriate entries under `g.xy' and `g.xy_color' 437 in its database 439 t+10 90% of all deployed browsers support XY. Content authors 440 start using XY it without bothering to provide an alternate 441 representation. 443 4.4 Volume considerations 445 Feature tag registration which will have to keep pace with the 446 introduction of new features by vendors. 448 In particular in the Web domain, vendors are moving fast, and this 449 will inevitably lead to a feature tag namespace which contains a 450 lot of tags. Also, a lot of tags will be `dead' tags, tags related 451 to features which failed to take off and gain widespread use. 452 Compare this to the situation in the USENET newsgroup namespace. 454 Like a list of all MIME media types, a list of all registered 455 feature tags will generally be too long to be useful to any content 456 author. Third parties could filter the feature tag namespace and 457 compile short lists of useful tags. In the Web domain, Web 458 indexing robots could, while traversing the web, gather statistics 459 about actual use of feature tags; these statistics could help in 460 compiling lists. 462 4.5 Danger of excessive registration 464 One danger for the feature tag namespace is the emergence of 465 excessive registration as seen in the internet domain name system 466 (DNS) namespace. 468 We speculate that the various forces which contributed to the DNS 469 registration problems are absent for feature tags: feature tags 470 will not be very visible to end users, and registration of a 471 feature tag does not mean you get exclusive use. 473 We therefore do not expect excessive registration to occur. We 474 note it has not occured (so far) in the MIME media type namespace. 475 Of course it is possible to update the registration procedure if 476 excessive registration _does_ occur. A necessary precaution is to 477 reserve a part of the feature tag namespace for future use. 479 5 Security considerations 481 When used, negotiation mechanisms usually reveal some information 482 about one party to other parties. This may raise privacy concerns, 483 and may allow a malicious party to make more educated guesses about 484 the presence of security holes in the other party. 486 6 Acknowledgments 488 The idea of creating a vocabulary of areas of negotiation, which is 489 maintained in a central open registry, is due to discussions on 490 extensible negotiation mechanisms in the IETF HTTP working group. 491 The authors wish to thank Larry Masinter and Graham Klyne for 492 contributing to discussions about feature tag registration. 494 7 References 496 [1] N. Freed, J. Klensin, J. Postel, Multipurpose Internet Mail 497 Extensions (MIME) Part Four: Registration Procedures. RFC 498 2048, BCP 13, Network Working Group, November 1996 500 [2] R. Fielding, J. Gettys, J. C. Mogul, H. Frystyk, and 501 T. Berners-Lee. Hypertext Transfer Protocol -- HTTP/1.1. RFC 502 2068, HTTP Working Group, January, 1997. 504 [3] K. Holtman, A. Mutz. Transparent Content Negotiation in HTTP. 505 Internet-Draft draft-ietf-http-negotiation-03.txt, HTTP Working 506 Group. July 1997. 508 8 Authors' addresses 510 Koen Holtman 511 Technische Universiteit Eindhoven 512 Postbus 513 513 Kamer HG 6.57 514 5600 MB Eindhoven (The Netherlands) 515 Email: koen@win.tue.nl 517 Andrew H. Mutz 518 Hewlett-Packard Company 519 1501 Page Mill Road 3U-3 520 Palo Alto CA 94304, USA 521 Fax +1 415 857 4691 522 Email: mutz@hpl.hp.com 524 Expires: January 28, 1998