idnits 2.17.1 draft-ietf-http-rvsa-v10-00.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-18) 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 690 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations 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 are 5 instances of lines with non-RFC2606-compliant FQDNs in the document. 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 (February 5, 1997) is 9934 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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 637, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 641, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2068 (ref. '1') (Obsoleted by RFC 2616) == Outdated reference: A later version (-06) exists of draft-ietf-http-v11-spec-01 ** Downref: Normative reference to an Informational RFC: RFC 1945 (ref. '3') -- No information found for draft-ietf-http-feature-reg - is the name correct? -- Possible downref: Normative reference to a draft: ref. '4' == Outdated reference: A later version (-05) exists of draft-ietf-http-negotiation-00 ** Downref: Normative reference to an Experimental draft: draft-ietf-http-negotiation (ref. '5') Summary: 11 errors (**), 0 flaws (~~), 7 warnings (==), 5 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: August 5, 1997 February 5, 1997 5 HTTP Remote Variant Selection Algorithm -- RVSA/1.0 7 draft-ietf-http-rvsa-v10-00.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 HTML and change bar versions of this document are available 39 at . 41 ABSTRACT 43 HTTP allows web site authors to put multiple versions of the 44 same information under a single URL. Transparent content 45 negotiation is a mechanism for automatically selecting the 46 best version when the URL is accessed. A remote variant 47 selection algorithm can be used to speed up the transparent 48 negotiation process. This document defines the remote variant 49 selection algorithm with the version number 1.0. 51 OVERVIEW OF THE TRANSPARENT CONTENT NEGOTIATION DOCUMENT SET 53 An up-to-date overview of documents related to transparent content 54 negotiation is maintained on the web page 55 . 57 The transparent content negotiation document set currently consists 58 of three series of internet drafts. 60 1. draft-ietf-http-negotiation-XX.txt 62 `Transparent Content Negotiation in HTTP' 64 Defines the core mechanism. Standards track. 66 2. draft-ietf-http-rvsa-v10-XX.txt (this document) 68 `HTTP Remote Variant Selection Algorithm -- RVSA/1.0' 70 Defines the remote variant selection algorithm version 1.0. 71 Standards track. 73 3. draft-ietf-http-feature-reg-XX.txt 75 `Feature Tag Registration Procedures' 77 Defines feature tag registration. Best Current Practice track. 79 An additional document about `the core feature set', which may 80 later become an informational RFC, may also appear. Currently, 81 there are two internet drafts which discuss parts of what could be 82 a core feature set: draft-mutz-http-attributes-XX.txt and 83 draft-goland-http-headers-XX.txt 85 Older versions of the text in documents 1 and 2 may be found in the 86 draft-holtman-http-negotiation-XX.txt series of internet drafts. 88 TABLE OF CONTENTS 90 1 Introduction 91 1.1 Revision history 93 2 Terminology and notation 95 3 The remote variant selection algorithm 96 3.1 Input 97 3.2 Output 98 3.3 Computing overall quality values 99 3.4 Definite and speculative quality values 100 3.5 Determining the result 102 4 Use of the algorithm 103 4.1 Using quality factors to rank preferences 104 4.2 Construction of short requests 105 4.2.1 Collapsing Accept header elements 106 4.2.2 Omitting Accept headers 107 4.2.3 Dynamically lengthening requests 108 4.3 Differences between the local and the remote algorithm 109 4.3.1 Avoiding major differences 110 4.3.2 Working around minor differences 112 5 Security and privacy considerations 114 6 Acknowledgments 116 7 References 118 8 Authors' addresses 120 1 Introduction 122 HTTP allows web site authors to put multiple versions (variants) of 123 the same information under a single URL. Transparent content 124 negotiation [5] is a mechanism for automatically selecting the best 125 variant when the URL is accessed. A remote variant selection 126 algorithm can be used by a server to choose a best variant on 127 behalf of a negotiating user agent. The use of a remote algorithm 128 can speed up the transparent negotiation process by eliminating a 129 request-response round trip. 131 This document defines the remote variant selection algorithm with 132 the version number 1.0. The algorithm computes whether the Accept 133 headers in the request contain sufficient information to allow a 134 choice, and if so, which variant must be chosen. 136 1.1 Revision history 138 Most text in section 3 of this draft was taken from section 11 of 139 the draft-holtman-http-negotiation-04.txt internet draft. Major 140 changes are: 142 - The scope of the `network negotiation algorithm' has been 143 limited to variant selection by servers on behalf of the user 144 agent only. The algorithm has been renamed to `remote variant 145 selection algorithm'. 147 In the text and HTML versions with change marks, change bars or 148 change marks only appear in section 3. In the text version, all 149 changes are marked, except changes in formatting and punctuation. 150 In the HTML version, all changed words and symbols are typeset in 151 bold text. Deletions and changes in punctuation are not marked. 153 Section 4 of this draft contains almost exclusively new material. 155 2 Terminology and notation 157 This specification uses the terminology and notation of the HTTP 158 transparent content negotiation specification [5]. 160 3 The remote variant selection algorithm 162 This section defines the remote variant selection algorithm with 163 the version number 1.0. To implement this definition, a server may 164 run any algorithm which gives equal results. 166 Note: According to [5], servers are always free to return a list 167 response instead of running a remote algorithm. Therefore, 168 whenever a server may run a remote algorithm, it may also run a 169 partial implementation of the algorithm, provided that the 170 partial implementation always returns List_Response when it 171 cannot compute the real result. 173 3.1 Input 175 The algorithm is always run for a particular request on a 176 particular transparently negotiable resource. It takes the 177 following information as input. 179 1. The variant list of the resource, as present in the Alternates 180 header of the resource. 182 2. (Partial) Information about capabilities and preferences of the 183 user agent for this particular request, as given in the Accept 184 headers of the request. 186 If a fallback variant description 188 {"fallback.html"} 190 is present in the Alternates header, the algorithm must interpret 191 it as the variant description 193 {"fallback.html" 0.00000000000000000001} 195 The extremely low source quality value ensures that the fallback 196 variant only gets chosen if all other options are exhausted. 198 3.2 Output 200 As its output, the remote variant selection algorithm and will 201 yield the appropriate action to be performed. There are two 202 possibilities: 204 Choice_response 206 The Accept headers contain sufficient information to make a 207 choice on behalf of the user agent possible, and the best 208 variant may be returned in a choice response. 210 List_response 212 The Accept headers do not contain sufficient information to 213 make a choice on behalf of the user agent possible. A list 214 response must be returned, allowing the user agent to make the 215 choice itself. 217 3.3 Computing overall quality values 219 As a first step in the remote variant selection algorithm, the 220 overall qualities of the individual variants in the list are 221 computed. 223 The overall quality Q of a variant is the value 225 Q = qs * qt * qc * ql * qf 227 where the factors qs, qt, qc, ql, and qf are determined as follows. 229 qs Is the source quality factor in the variant description. 231 qt The media type quality factor is 1 if there is no type 232 attribute in the variant description, or if there is no 233 Accept header in the request. Otherwise, it is the quality 234 assigned by the Accept header to the media type in the type 235 attribute. 237 Note: If a type is matched by none of the elements of an 238 Accept header, the Accept header assigns the quality factor 239 0 to that type. 241 qc The charset quality factor is 1 if there is no charset 242 attribute in the variant description, or if there is no 243 Accept-Charset header in the request. Otherwise, the charset 244 quality factor is the quality assigned by the Accept-Charset 245 header to the charset in the charset attribute, see section 246 8.2 of [5]. 248 ql The language quality factor is 1 if there is no language 249 attribute in the variant description, or if there is no 250 Accept-Language header in the request. Otherwise, the 251 language quality factor is the highest quality factor 252 assigned by the Accept-Language header to any one of the 253 languages listed in the language attribute. 255 qf The features quality factor is 1 if there is no features 256 attribute in the variant description, or if there is no 257 Accept-Features header in the request. Otherwise, it is the 258 quality degradation factor for the features attribute, see 259 section 6.4 of [5]. 261 As an example, if a variant list contains the variant description 263 {"paper.html.en" 0.7 {type text/html} {language fr}} 265 and if the request contains the Accept headers 267 Accept: text/html:q=1.0, */*:q=0.8 268 Accept-Language: en;q=1.0, fr;q=0.5 270 the remote variant selection algorithm will compute an overall 271 quality for the variant as follows: 273 {"paper.html.fr" 0.7 {type text/html} {language fr}} 274 | | | 275 | | | 276 V V V 277 0.7 * 1.0 * 0.5 = 0.35 279 With the above Accept headers, the complete variant list 281 {"paper.html.en" 0.9 {type text/html} {language en}}, 282 {"paper.html.fr" 0.7 {type text/html} {language fr}}, 283 {"paper.ps.en" 1.0 {type application/postscript} {language en}} 285 would yield the following computations: 287 qs * qt * qc * ql * qf = Q 288 --- --- --- --- --- ---- 289 paper.html.en: 0.9 * 1.0 * 1.0 * 1.0 * 1.0 = 0.9 290 paper.html.fr: 0.7 * 1.0 * 1.0 * 0.5 * 1.0 = 0.35 291 paper.ps.en: 1.0 * 0.8 * 1.0 * 1.0 * 1.0 = 0.8 293 3.4 Definite and speculative quality values 295 A computed overall quality value can be either definite or 296 speculative. An overall quality value is definite if it was 297 computed without using any wildcard characters '*' in the Accept 298 headers, and without the need to use the absence of a particular 299 Accept header. An overall quality value is speculative otherwise. 301 As an example, in the previous section, the quality values of 302 paper.html.en and paper.html.fr are definite, and the quality value 303 of paper.ps.en is speculative because the type 304 application/postscript was matched to the range */*. 306 Definiteness can be defined more formally as follows. An overall 307 quality value Q is definite if the same quality value Q can be 308 computed after the request message is changed in the following way: 310 1. If an Accept, Accept-Charset, Accept-Language, or 311 Accept-Features header is missing from the request, add 312 this header with an empty field. 314 2. Delete any media ranges containing a wildcard character '*' 315 from the Accept header. Delete any wildcard '*' from the 316 Accept-Charset, Accept-Language, and Accept-Features 317 headers. 319 As another example, the overall quality factor for the variant 321 {"blah.html" 1 {language en-gb} {features blebber [x y]}} 323 is 1 and definite with the Accept headers 325 Accept-Language: en-gb, fr 326 Accept-Features: blebber, x, !y, * 328 and 330 Accept-Language: en, fr 331 Accept-Features: blebber, x, * 333 The overall quality factor is still 1, but speculative, with the 334 Accept headers 336 Accept-language: en-gb, fr 337 Accept-Features: blebber, !y, * 339 and 341 Accept-Language: fr, * 342 Accept-Features: blebber, x, !y, * 344 3.5 Determining the result 346 The best variant, as determined by the remote variant selection 347 algorithm, is the one variant with the highest overall quality 348 value, or, if there are multiple variants which share the highest 349 overall quality, the first variant in the list with this value. 351 The end result of the remote variant selection algorithm is 352 Choice_response if all of the following conditions are met 354 a. the overall quality value of the best variant is greater 355 than 0 357 b. the overall quality value of the best variant is a definite 358 quality value 360 c. the negotiable resource and the best variant resource are 361 neighbors. This last condition exists for security reasons: 362 it prevents some forms of spoofing, see section 14.2 of [5]. 364 In all other cases, the end result is List_response. 366 The requirement for definiteness above affects the interpretation 367 of Accept headers in a dramatic way. For example, it causes the 368 remote algorithm to interpret the header 370 Accept: image/gif;q=0.9, */*;q=1.0 372 as 374 `I accept image/gif with a quality of 0.9, and assign quality 375 factors up to 1.0 to other media types. If this information is 376 insufficient to make a choice on my behalf, do not make a choice 377 but send the list of variants'. 379 Without the requirement, the interpretation would have been 381 `I accept image/gif with a quality of 0.9, and all other media 382 types with a quality of 1.0'. 384 4 Use of the algorithm 386 This section discusses how user agents can use the remote algorithm 387 in an optimal way. This section is not normative, it is included 388 for informational purposes only. 390 4.1 Using quality factors to rank preferences 392 Using quality factors, a user agent can not only rank the elements 393 within a particular Accept header, it can also express precedence 394 relations between the different Accept headers. Consider for 395 example the following variant list: 397 {"paper.english" 1.0 {language en} {charset ISO-8859-1}}, 398 {"paper.greek" 1.0 {language el} {charset ISO-8859-7}} 400 and suppose that the user prefers "el" over "en", while the user 401 agent can render "ISO-8859-1" with a higher quality than 402 "ISO-8859-7". If the Accept headers are 404 Accept-Language: gr, en;q=0.8 405 Accept-Charset: ISO-8859-1, ISO-8859-7;q=0.6, * 407 then the remote variant selection algorithm would choose the 408 English variant, because this variant has the least overall quality 409 degradation. But if the Accept headers are 411 Accept-Language: gr, en;q=0.8 412 Accept-Charset: ISO-8859-1, ISO-8859-7;q=0.95, * 414 then the algorithm would choose the Greek variant. In general, the 415 Accept header with the biggest spread between its quality factors 416 gets the highest precedence. If a user agent allows the user to 417 set the quality factors for some headers, while other factors are 418 hard-coded, it should use a low spread on the hard-coded factors 419 and a high spread on the user-supplied factors, so that the user 420 settings take precedence over the built-in settings. 422 4.2 Construction of short requests 424 In a request on a transparently negotiated resource, a user agent 425 need not send a very long Accept header, which lists all of its 426 capabilities, to get optimal results. For example, instead of 427 sending 429 Accept: image/gif;q=0.9, image/jpeg;q=0.8, image/png;q=1.0, 430 image/tiff;q=0.5, image/ief;q=0.5, image/x-xbitmap;q=0.8, 431 application/plugin1;q=1.0, application/plugin2;q=0.9 433 the user agent can send 435 Accept: image/gif;q=0.9, */*;q=1.0 437 It can send this short header without running the risk of getting a 438 choice response with, say, an inferior image/tiff variant. For 439 example, with the variant list 441 {"x.gif" 1.0 {type image/gif}}, {"x.tiff" 1.0 {type image/tiff}}, 443 the remote algorithm will compute a definite overall quality of 0.9 444 for x.gif and a speculative overall quality value of 1.0 for 445 x.tiff. As the best variant has a speculative quality value, the 446 algorithm will not choose x.tiff, but return a list response, after 447 which the selection algorithm of the user agent will correctly 448 choose x.gif. The end result is the same as if the long Accept 449 header above had been sent. 451 Thus, user agents can vary the length of the Accept headers to get 452 an optimal tradeoff between the speed with which the first request 453 is transmitted, and the chance that the remote algorithm has enough 454 information to eliminate a second request. 456 4.2.1 Collapsing Accept header elements 458 This section discusses how a long Accept header which lists all 459 capabilities and preferences can be safely made shorter. The 460 remote variant selection algorithm is designed in such a way that 461 it is always safe to shorten an Accept or Accept-Charset header by 462 two taking two header elements `A;q=f' and `B;q=g' and replacing 463 them by a single element `P;q=m' where P is a wildcard pattern that 464 matches both A and B, and m is the maximum of f and g. Some 465 examples are 467 text/html;q=1.0, text/plain;q=0.8 --> text/*;q=1.0 468 image/*;q=0.8, application/*;q=0.7 --> */*;q=0.8 470 iso-8859-5;q=1.0, unicode-1-1;q=0.8 --> *;q=1.0 472 Note that every `;q=1.0' above is optional, and can be omitted: 474 iso-8859-7;q=0.6, * --> * 476 For Accept-Language, it is safe to collapse all language ranges 477 with the same primary tag into a wildcard: 479 en-us;q=0.9, en-gb;q=0.7, en;q=0.8, da --> *;q=0.9, da 481 It is also safe to collapse a language range into a wildcard, or to 482 replace it by a wildcard, if its primary tag appears only once: 484 *;q=0.9, da --> * 486 Finally, in the Accept-Features header, every feature expression 487 can be collapsed into a wildcard, or replaced by a wildcard: 489 colordepth<=5, * --> * 491 4.2.2 Omitting Accept headers 493 According to the HTTP/1.1 specification [1], the complete absence 494 of an Accept header from the request is equivalent to the presence 495 of `Accept: */*'. Thus, if the Accept header is collapsed to 496 `Accept: */*', a user agent may omit it entirely. An 497 Accept-Charset, Accept-Language, or Accept-Features header which 498 only contains `*' may also be omitted. 500 4.2.3 Dynamically lengthening requests 502 In general, a user agent capable of transparent content negotiation 503 can send short requests by default. Some short Accept headers 504 could be included for the benefit of existing servers which use 505 HTTP/1.0 style negotiation (see section 4.2 of [5]). An example is 507 GET /paper HTTP/1.1 508 Host: x.org 509 User-Agent: WuxtaWeb/2.4 510 Negotiate: 1.0 511 Accept-Language: en, *;q=0.9 513 If the Accept headers included in such a default request are not 514 suitable as input to the remote variant selection algorithm, the 515 user agent can disable the algorithm by sending `Negotiate: trans' 516 instead of `Negotiate: 1.0'. 518 If the user agent discovers, though the receipt of a list or choice 519 response, that a particular origin server contains transparently 520 negotiated resources, it could dynamically lengthen future requests 521 to this server, for example to 523 GET /paper/chapter1 HTTP/1.1 524 Host: x.org 525 User-Agent: WuxtaWeb/2.4 526 Negotiate: 1.0 527 Accept: text/html, application/postscript;q=0.8, */* 528 Accept-Language: en, fr;q=0.5, *;q=0.9 529 Accept-Features: tables, * 531 This will increase the chance that the remote variant selection 532 algorithm will have sufficient information to choose on behalf of 533 the user agent, thereby optimizing the negotiation process. A good 534 strategy for dynamic extension would be to extend the headers with 535 those media types, languages, charsets, and feature tags mentioned 536 in the variant lists of past responses from the server. 538 4.3 Differences between the local and the remote algorithm 540 A user agent can only optimize content negotiation though the use 541 of a remote algorithm if its local algorithm will generally make 542 the same choice. If a user agent receives a choice response 543 containing a variant X selected by the remote algorithm, while the 544 local algorithm would have selected Y, the user agent has two 545 options: 547 1. Retrieve Y in a subsequent request. This is sub-optimal 548 because it takes time. 550 2. Display X anyway. This is sub-optimal because it makes the 551 end result of the negotiation process dependent on factors 552 that can randomly change. For the next request on the same 553 resource, and intermediate proxy cache could return a list 554 response, which would cause the local algorithm to choose and 555 retrieve Y instead of X. Compared to a stable 556 representation, a representation which randomly switches 557 between X and Y (say, the version with and without frames) has 558 a very low subjective quality for most users. 560 As both alternatives above are unattractive, a user agent should 561 try to avoid the above situation altogether. The sections below 562 discuss how this can be done. 564 4.3.1 Avoiding major differences 566 If the user agent enables the remote algorithm in this 567 specification, it should generally use a local algorithm which 568 closely resembles the remote algorithm. The algorithm should for 569 example also use multiplication to combine quality factors. If the 570 user agent combines quality factors by addition, it would be more 571 advantageous to define a new remote variant selection algorithm, 572 with a new major version number, for use by this agent. 574 4.3.2 Working around minor differences 576 Even if a local algorithm uses multiplication to combine quality 577 factors, it could use an extended quality formulae like 579 Q = ( qs * qt * qc * ql * qf ) * q_adjust 581 in order to account for special interdependencies between 582 dimensions, which are due to limitations of the user agent. For 583 example, if the user agent, for some reason, cannot handle the 584 iso-8859-7 charset when rendering text/plain documents, the 585 q_adjust factor would be 0 when the text/plain - iso-8859-7 586 combination is present in the variant description, and 1 otherwise. 588 By selectively withholding information from the remote variant 589 selection algorithm, the user agent can ensure that the remote 590 algorithm will never make a choice if the local q_adjust is less 591 than 1. For example, to prevent the remote algorithm from ever 592 returning a text/plain - iso-8859-7 choice response, the user agent 593 should take care to never produce a request which exactly specifies 594 the quality factors of both text/plain and iso-8859-7. The 595 omission of either factor from a request will cause the overall 596 quality value of any text/plain - iso-8859-7 variant to be 597 speculative, and variants with speculative quality values can never 598 be returned in a choice response. 600 In general, if the local q_adjust does not equal 1 for a particular 601 combination X - Y - Z, then a remote choice can be prevented by 602 always omitting at least one of the elements of the combination 603 from the Accept headers, and adding a suitable wildcard pattern to 604 match the omitted element, if such a pattern is not already 605 present. 607 5 Security and privacy considerations 609 This specification introduces no security and privacy 610 considerations not already covered in [5]. See [5] for a 611 discussion of privacy risks connected to the sending of Accept 612 headers. 614 6 Acknowledgments 616 Work on HTTP content negotiation has been done since at least 1993. 617 The authors are unable to trace the origin of many of the ideas 618 incorporated in this document. This specification builds on an 619 earlier incomplete specification of content negotiation recorded in 620 [2]. Many members of the HTTP working group have contributed to 621 the negotiation model in this specification. The authors wish to 622 thank the individuals who have commented on earlier versions of 623 this document, including Brian Behlendorf, Daniel DuBois, Ted 624 Hardie, Larry Masinter, and Roy T. Fielding. 626 7 References 628 [1] R. Fielding, J. Gettys, J. C. Mogul, H. Frystyk, and 629 T. Berners-Lee. Hypertext Transfer Protocol -- HTTP/1.1. RFC 630 2068, HTTP Working Group, January, 1997. 632 [2] Roy T. Fielding, Henrik Frystyk Nielsen, and Tim Berners-Lee. 633 Hypertext Transfer Protocol -- HTTP/1.1. Internet-Draft 634 draft-ietf-http-v11-spec-01.txt, HTTP Working Group, January, 635 1996. 637 [3] T. Berners-Lee, R. Fielding, and H. Frystyk. Hypertext 638 Transfer Protocol -- HTTP/1.0. RFC 1945. MIT/LCS, UC Irvine, 639 May 1996. 641 [4] K. Holtman, A. Mutz. Feature Tag Registration Procedures. 642 Internet-Draft draft-ietf-http-feature-reg-00.txt, HTTP Working 643 Group, October 30, 1996. 645 [5] K. Holtman, A. Mutz. Transparent Content Negotiation in HTTP. 646 Internet-Draft draft-ietf-http-negotiation-00.txt, HTTP Working 647 Group. 649 8 Authors' addresses 651 Koen Holtman 652 Technische Universiteit Eindhoven 653 Postbus 513 654 Kamer HG 6.57 655 5600 MB Eindhoven (The Netherlands) 656 Email: koen@win.tue.nl 658 Andrew H. Mutz 659 Hewlett-Packard Company 660 1501 Page Mill Road 3U-3 661 Palo Alto CA 94304, USA 662 Fax +1 415 857 4691 663 Email: mutz@hpl.hp.com 665 Expires: August 5, 1997