idnits 2.17.1 draft-ietf-http-rvsa-v10-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-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 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 679 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. ** 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 151: '...mplement this definition, a server MAY...' RFC 2119 keyword, line 178: '...s header, the algorithm MUST interpret...' RFC 2119 keyword, line 196: '... variant MAY be returned in a c...' RFC 2119 keyword, line 202: '... response MUST be returned, all...' 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 (March 23, 1997) is 9896 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 626, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 630, 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-01 ** Downref: Normative reference to an Experimental draft: draft-ietf-http-negotiation (ref. '5') Summary: 12 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: September 23, 1997 March 23, 1997 5 HTTP Remote Variant Selection Algorithm -- RVSA/1.0 7 draft-ietf-http-rvsa-v10-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 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 This revision was made to resynchronise this document with the main 139 transparent content negotiation specification [5]. This revision 140 makes no semantical changes to the remote variant selection 141 algorithm. 143 2 Terminology and notation 145 This specification uses the terminology and notation of the HTTP 146 transparent content negotiation specification [5]. 148 3 The remote variant selection algorithm 150 This section defines the remote variant selection algorithm with 151 the version number 1.0. To implement this definition, a server MAY 152 run any algorithm which gives equal results. 154 Note: According to [5], servers are always free to return a list 155 response instead of running a remote algorithm. Therefore, 156 whenever a server may run a remote algorithm, it may also run a 157 partial implementation of the algorithm, provided that the 158 partial implementation always returns List_Response when it 159 cannot compute the real result. 161 3.1 Input 163 The algorithm is always run for a particular request on a 164 particular transparently negotiable resource. It takes the 165 following information as input. 167 1. The variant list of the resource, as present in the Alternates 168 header of the resource. 170 2. (Partial) Information about capabilities and preferences of the 171 user agent for this particular request, as given in the Accept- 172 headers of the request. 174 If a fallback variant description 176 {"fallback.html"} 178 is present in the Alternates header, the algorithm MUST interpret 179 it as the variant description 181 {"fallback.html" 0.00000000000000000001} 183 The extremely low source quality value ensures that the fallback 184 variant only gets chosen if all other options are exhausted. 186 3.2 Output 188 As its output, the remote variant selection algorithm and will 189 yield the appropriate action to be performed. There are two 190 possibilities: 192 Choice_response 194 The Accept- headers contain sufficient information to make a 195 choice on behalf of the user agent possible, and the best 196 variant MAY be returned in a choice response. 198 List_response 200 The Accept- headers do not contain sufficient information to 201 make a choice on behalf of the user agent possible. A list 202 response MUST be returned, allowing the user agent to make the 203 choice itself. 205 3.3 Computing overall quality values 207 As a first step in the remote variant selection algorithm, the 208 overall qualities of the individual variants in the list are 209 computed. 211 The overall quality Q of a variant is the value 213 Q = qs * qt * qc * ql * qf 215 where the factors qs, qt, qc, ql, and qf are determined as follows. 217 qs Is the source quality factor in the variant description. 219 qt The media type quality factor is 1 if there is no type 220 attribute in the variant description, or if there is no 221 Accept header in the request. Otherwise, it is the quality 222 assigned by the Accept header to the media type in the type 223 attribute. 225 Note: If a type is matched by none of the elements of an 226 Accept header, the Accept header assigns the quality factor 227 0 to that type. 229 qc The charset quality factor is 1 if there is no charset 230 attribute in the variant description, or if there is no 231 Accept-Charset header in the request. Otherwise, the charset 232 quality factor is the quality assigned by the Accept-Charset 233 header to the charset in the charset attribute, see section 234 8.2 of [5]. 236 ql The language quality factor is 1 if there is no language 237 attribute in the variant description, or if there is no 238 Accept-Language header in the request. Otherwise, the 239 language quality factor is the highest quality factor 240 assigned by the Accept-Language header to any one of the 241 languages listed in the language attribute. 243 qf The features quality factor is 1 if there is no features 244 attribute in the variant description, or if there is no 245 Accept-Features header in the request. Otherwise, it is the 246 quality degradation factor for the features attribute, see 247 section 6.4 of [5]. 249 As an example, if a variant list contains the variant description 251 {"paper.html.en" 0.7 {type text/html} {language fr}} 253 and if the request contains the Accept- headers 255 Accept: text/html:q=1.0, */*:q=0.8 256 Accept-Language: en;q=1.0, fr;q=0.5 258 the remote variant selection algorithm will compute an overall 259 quality for the variant as follows: 261 {"paper.html.fr" 0.7 {type text/html} {language fr}} 262 | | | 263 | | | 264 V V V 265 0.7 * 1.0 * 0.5 = 0.35 267 With the above Accept- headers, the complete variant list 269 {"paper.html.en" 0.9 {type text/html} {language en}}, 270 {"paper.html.fr" 0.7 {type text/html} {language fr}}, 271 {"paper.ps.en" 1.0 {type application/postscript} {language en}} 273 would yield the following computations: 275 qs * qt * qc * ql * qf = Q 276 --- --- --- --- --- ---- 277 paper.html.en: 0.9 * 1.0 * 1.0 * 1.0 * 1.0 = 0.9 278 paper.html.fr: 0.7 * 1.0 * 1.0 * 0.5 * 1.0 = 0.35 279 paper.ps.en: 1.0 * 0.8 * 1.0 * 1.0 * 1.0 = 0.8 281 3.4 Definite and speculative quality values 283 A computed overall quality value can be either definite or 284 speculative. An overall quality value is definite if it was 285 computed without using any wildcard characters '*' in the Accept- 286 headers, and without the need to use the absence of a particular 287 Accept- header. An overall quality value is speculative otherwise. 289 As an example, in the previous section, the quality values of 290 paper.html.en and paper.html.fr are definite, and the quality value 291 of paper.ps.en is speculative because the type 292 application/postscript was matched to the range */*. 294 Definiteness can be defined more formally as follows. An overall 295 quality value Q is definite if the same quality value Q can be 296 computed after the request message is changed in the following way: 298 1. If an Accept, Accept-Charset, Accept-Language, or 299 Accept-Features header is missing from the request, add 300 this header with an empty field. 302 2. Delete any media ranges containing a wildcard character '*' 303 from the Accept header. Delete any wildcard '*' from the 304 Accept-Charset, Accept-Language, and Accept-Features 305 headers. 307 As another example, the overall quality factor for the variant 309 {"blah.html" 1 {language en-gb} {features blebber [x y]}} 311 is 1 and definite with the Accept- headers 313 Accept-Language: en-gb, fr 314 Accept-Features: blebber, x, !y, * 316 and 318 Accept-Language: en, fr 319 Accept-Features: blebber, x, * 321 The overall quality factor is still 1, but speculative, with the 322 Accept- headers 324 Accept-language: en-gb, fr 325 Accept-Features: blebber, !y, * 327 and 329 Accept-Language: fr, * 330 Accept-Features: blebber, x, !y, * 332 3.5 Determining the result 334 The best variant, as determined by the remote variant selection 335 algorithm, is the one variant with the highest overall quality 336 value, or, if there are multiple variants which share the highest 337 overall quality, the first variant in the list with this value. 339 The end result of the remote variant selection algorithm is 340 Choice_response if all of the following conditions are met 342 a. the overall quality value of the best variant is greater 343 than 0 345 b. the overall quality value of the best variant is a definite 346 quality value 348 c. the variant resource is a neighbor of the negotiable 349 resource. This last condition exists to ensure that a 350 security-related restriction on the generation of choice 351 responses is met, see sections 10.2 and 14.2 of [5]. 353 In all other cases, the end result is List_response. 355 The requirement for definiteness above affects the interpretation 356 of Accept- headers in a dramatic way. For example, it causes the 357 remote algorithm to interpret the header 359 Accept: image/gif;q=0.9, */*;q=1.0 361 as 363 `I accept image/gif with a quality of 0.9, and assign quality 364 factors up to 1.0 to other media types. If this information is 365 insufficient to make a choice on my behalf, do not make a choice 366 but send the list of variants'. 368 Without the requirement, the interpretation would have been 370 `I accept image/gif with a quality of 0.9, and all other media 371 types with a quality of 1.0'. 373 4 Use of the algorithm 375 This section discusses how user agents can use the remote algorithm 376 in an optimal way. This section is not normative, it is included 377 for informational purposes only. 379 4.1 Using quality factors to rank preferences 381 Using quality factors, a user agent can not only rank the elements 382 within a particular Accept- header, it can also express precedence 383 relations between the different Accept- headers. Consider for 384 example the following variant list: 386 {"paper.english" 1.0 {language en} {charset ISO-8859-1}}, 387 {"paper.greek" 1.0 {language el} {charset ISO-8859-7}} 389 and suppose that the user prefers "el" over "en", while the user 390 agent can render "ISO-8859-1" with a higher quality than 391 "ISO-8859-7". If the Accept- headers are 393 Accept-Language: gr, en;q=0.8 394 Accept-Charset: ISO-8859-1, ISO-8859-7;q=0.6, * 396 then the remote variant selection algorithm would choose the 397 English variant, because this variant has the least overall quality 398 degradation. But if the Accept- headers are 400 Accept-Language: gr, en;q=0.8 401 Accept-Charset: ISO-8859-1, ISO-8859-7;q=0.95, * 403 then the algorithm would choose the Greek variant. In general, the 404 Accept- header with the biggest spread between its quality factors 405 gets the highest precedence. If a user agent allows the user to 406 set the quality factors for some headers, while other factors are 407 hard-coded, it should use a low spread on the hard-coded factors 408 and a high spread on the user-supplied factors, so that the user 409 settings take precedence over the built-in settings. 411 4.2 Construction of short requests 413 In a request on a transparently negotiated resource, a user agent 414 need not send a very long Accept- header, which lists all of its 415 capabilities, to get optimal results. For example, instead of 416 sending 418 Accept: image/gif;q=0.9, image/jpeg;q=0.8, image/png;q=1.0, 419 image/tiff;q=0.5, image/ief;q=0.5, image/x-xbitmap;q=0.8, 420 application/plugin1;q=1.0, application/plugin2;q=0.9 422 the user agent can send 424 Accept: image/gif;q=0.9, */*;q=1.0 426 It can send this short header without running the risk of getting a 427 choice response with, say, an inferior image/tiff variant. For 428 example, with the variant list 430 {"x.gif" 1.0 {type image/gif}}, {"x.tiff" 1.0 {type image/tiff}}, 432 the remote algorithm will compute a definite overall quality of 0.9 433 for x.gif and a speculative overall quality value of 1.0 for 434 x.tiff. As the best variant has a speculative quality value, the 435 algorithm will not choose x.tiff, but return a list response, after 436 which the selection algorithm of the user agent will correctly 437 choose x.gif. The end result is the same as if the long Accept- 438 header above had been sent. 440 Thus, user agents can vary the length of the Accept- headers to get 441 an optimal tradeoff between the speed with which the first request 442 is transmitted, and the chance that the remote algorithm has enough 443 information to eliminate a second request. 445 4.2.1 Collapsing Accept- header elements 447 This section discusses how a long Accept- header which lists all 448 capabilities and preferences can be safely made shorter. The 449 remote variant selection algorithm is designed in such a way that 450 it is always safe to shorten an Accept or Accept-Charset header by 451 two taking two header elements `A;q=f' and `B;q=g' and replacing 452 them by a single element `P;q=m' where P is a wildcard pattern that 453 matches both A and B, and m is the maximum of f and g. Some 454 examples are 456 text/html;q=1.0, text/plain;q=0.8 --> text/*;q=1.0 457 image/*;q=0.8, application/*;q=0.7 --> */*;q=0.8 459 iso-8859-5;q=1.0, unicode-1-1;q=0.8 --> *;q=1.0 461 Note that every `;q=1.0' above is optional, and can be omitted: 463 iso-8859-7;q=0.6, * --> * 465 For Accept-Language, it is safe to collapse all language ranges 466 with the same primary tag into a wildcard: 468 en-us;q=0.9, en-gb;q=0.7, en;q=0.8, da --> *;q=0.9, da 470 It is also safe to collapse a language range into a wildcard, or to 471 replace it by a wildcard, if its primary tag appears only once: 473 *;q=0.9, da --> * 475 Finally, in the Accept-Features header, every feature expression 476 can be collapsed into a wildcard, or replaced by a wildcard: 478 colordepth<=5, * --> * 480 4.2.2 Omitting Accept- headers 482 According to the HTTP/1.1 specification [1], the complete absence 483 of an Accept header from the request is equivalent to the presence 484 of `Accept: */*'. Thus, if the Accept header is collapsed to 485 `Accept: */*', a user agent may omit it entirely. An 486 Accept-Charset, Accept-Language, or Accept-Features header which 487 only contains `*' may also be omitted. 489 4.2.3 Dynamically lengthening requests 491 In general, a user agent capable of transparent content negotiation 492 can send short requests by default. Some short Accept- headers 493 could be included for the benefit of existing servers which use 494 HTTP/1.0 style negotiation (see section 4.2 of [5]). An example is 496 GET /paper HTTP/1.1 497 Host: x.org 498 User-Agent: WuxtaWeb/2.4 499 Negotiate: 1.0 500 Accept-Language: en, *;q=0.9 502 If the Accept- headers included in such a default request are not 503 suitable as input to the remote variant selection algorithm, the 504 user agent can disable the algorithm by sending `Negotiate: trans' 505 instead of `Negotiate: 1.0'. 507 If the user agent discovers, though the receipt of a list or choice 508 response, that a particular origin server contains transparently 509 negotiated resources, it could dynamically lengthen future requests 510 to this server, for example to 512 GET /paper/chapter1 HTTP/1.1 513 Host: x.org 514 User-Agent: WuxtaWeb/2.4 515 Negotiate: 1.0 516 Accept: text/html, application/postscript;q=0.8, */* 517 Accept-Language: en, fr;q=0.5, *;q=0.9 518 Accept-Features: tables, * 520 This will increase the chance that the remote variant selection 521 algorithm will have sufficient information to choose on behalf of 522 the user agent, thereby optimizing the negotiation process. A good 523 strategy for dynamic extension would be to extend the headers with 524 those media types, languages, charsets, and feature tags mentioned 525 in the variant lists of past responses from the server. 527 4.3 Differences between the local and the remote algorithm 529 A user agent can only optimize content negotiation though the use 530 of a remote algorithm if its local algorithm will generally make 531 the same choice. If a user agent receives a choice response 532 containing a variant X selected by the remote algorithm, while the 533 local algorithm would have selected Y, the user agent has two 534 options: 536 1. Retrieve Y in a subsequent request. This is sub-optimal 537 because it takes time. 539 2. Display X anyway. This is sub-optimal because it makes the 540 end result of the negotiation process dependent on factors 541 that can randomly change. For the next request on the same 542 resource, and intermediate proxy cache could return a list 543 response, which would cause the local algorithm to choose and 544 retrieve Y instead of X. Compared to a stable 545 representation, a representation which randomly switches 546 between X and Y (say, the version with and without frames) has 547 a very low subjective quality for most users. 549 As both alternatives above are unattractive, a user agent should 550 try to avoid the above situation altogether. The sections below 551 discuss how this can be done. 553 4.3.1 Avoiding major differences 555 If the user agent enables the remote algorithm in this 556 specification, it should generally use a local algorithm which 557 closely resembles the remote algorithm. The algorithm should for 558 example also use multiplication to combine quality factors. If the 559 user agent combines quality factors by addition, it would be more 560 advantageous to define a new remote variant selection algorithm, 561 with a new major version number, for use by this agent. 563 4.3.2 Working around minor differences 565 Even if a local algorithm uses multiplication to combine quality 566 factors, it could use an extended quality formulae like 568 Q = ( qs * qt * qc * ql * qf ) * q_adjust 570 in order to account for special interdependencies between 571 dimensions, which are due to limitations of the user agent. For 572 example, if the user agent, for some reason, cannot handle the 573 iso-8859-7 charset when rendering text/plain documents, the 574 q_adjust factor would be 0 when the text/plain - iso-8859-7 575 combination is present in the variant description, and 1 otherwise. 577 By selectively withholding information from the remote variant 578 selection algorithm, the user agent can ensure that the remote 579 algorithm will never make a choice if the local q_adjust is less 580 than 1. For example, to prevent the remote algorithm from ever 581 returning a text/plain - iso-8859-7 choice response, the user agent 582 should take care to never produce a request which exactly specifies 583 the quality factors of both text/plain and iso-8859-7. The 584 omission of either factor from a request will cause the overall 585 quality value of any text/plain - iso-8859-7 variant to be 586 speculative, and variants with speculative quality values can never 587 be returned in a choice response. 589 In general, if the local q_adjust does not equal 1 for a particular 590 combination X - Y - Z, then a remote choice can be prevented by 591 always omitting at least one of the elements of the combination 592 from the Accept- headers, and adding a suitable wildcard pattern to 593 match the omitted element, if such a pattern is not already 594 present. 596 5 Security and privacy considerations 598 This specification introduces no security and privacy 599 considerations not already covered in [5]. See [5] for a 600 discussion of privacy risks connected to the sending of Accept- 601 headers. 603 6 Acknowledgments 605 Work on HTTP content negotiation has been done since at least 1993. 606 The authors are unable to trace the origin of many of the ideas 607 incorporated in this document. This specification builds on an 608 earlier incomplete specification of content negotiation recorded in 609 [2]. Many members of the HTTP working group have contributed to 610 the negotiation model in this specification. The authors wish to 611 thank the individuals who have commented on earlier versions of 612 this document, including Brian Behlendorf, Daniel DuBois, Ted 613 Hardie, Larry Masinter, and Roy T. Fielding. 615 7 References 617 [1] R. Fielding, J. Gettys, J. C. Mogul, H. Frystyk, and 618 T. Berners-Lee. Hypertext Transfer Protocol -- HTTP/1.1. RFC 619 2068, HTTP Working Group, January, 1997. 621 [2] Roy T. Fielding, Henrik Frystyk Nielsen, and Tim Berners-Lee. 622 Hypertext Transfer Protocol -- HTTP/1.1. Internet-Draft 623 draft-ietf-http-v11-spec-01.txt, HTTP Working Group, January, 624 1996. 626 [3] T. Berners-Lee, R. Fielding, and H. Frystyk. Hypertext 627 Transfer Protocol -- HTTP/1.0. RFC 1945. MIT/LCS, UC Irvine, 628 May 1996. 630 [4] K. Holtman, A. Mutz. Feature Tag Registration Procedures. 631 Internet-Draft draft-ietf-http-feature-reg-00.txt, HTTP Working 632 Group, October 30, 1996. 634 [5] K. Holtman, A. Mutz. Transparent Content Negotiation in HTTP. 635 Internet-Draft draft-ietf-http-negotiation-01.txt, HTTP Working 636 Group. 638 8 Authors' addresses 640 Koen Holtman 641 Technische Universiteit Eindhoven 642 Postbus 513 643 Kamer HG 6.57 644 5600 MB Eindhoven (The Netherlands) 645 Email: koen@win.tue.nl 647 Andrew H. Mutz 648 Hewlett-Packard Company 649 1501 Page Mill Road 3U-3 650 Palo Alto CA 94304, USA 651 Fax +1 415 857 4691 652 Email: mutz@hpl.hp.com 654 Expires: September 23, 1997