idnits 2.17.00 (12 Aug 2021) /tmp/idnits40397/draft-holtman-http-alternates-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 (2022-05-14) 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) 2022 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 718 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 too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 88 has weird spacing: '...variant incl...' == Line 565 has weird spacing: '... in the varia...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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) -- Looks like a reference, but probably isn't: 'Ref' on line 82 == Unused Reference: '3' is defined on line 508, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 516, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2068 (ref. '1') (Obsoleted by RFC 2616) == Outdated reference: draft-ietf-http-v11-spec has been published as RFC 2068 ** Downref: Normative reference to an Informational RFC: RFC 1945 (ref. '3') == Outdated reference: draft-ietf-http-negotiation has been published as RFC 2295 ** Downref: Normative reference to an Experimental draft: draft-ietf-http-negotiation (ref. '4') Summary: 12 errors (**), 0 flaws (~~), 9 warnings (==), 3 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: May 15, 1998 Ted Hardie, NASA NIC 5 The Alternates Header Field 7 draft-holtman-http-alternates-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. Though this 31 work originated in the HTTP working group and comments 32 should continue to be directed to that group, the authors 33 expect that the proposed header will have considerable use 34 outside of HTTP. Discussions about its potential uses 35 outside of HTTP are particularly sought by the authors. 36 Send comments to the HTTP working group at 37 . Discussions of the working 38 group are archived at 39 . General 40 discussions about HTTP and the applications which use HTTP 41 should take place on the mailing list. 43 ABSTRACT 45 This document proposes a header, Alternates, which is intended 46 to provide a common method for Internet-based application 47 protocols to indicate that a particular resource exists in 48 multiple forms. The Alternates header provides a 49 machine-readable indication of the bases on which the 50 different forms vary and how the the recipient of the header 51 can select among them. 53 1 Introduction 55 Where a particular content provider has created more than 56 one representation of a specific resource, the provider may 57 wish to indicate the existance of the different representations, 58 or "variants", to those who might want to select among them. 59 Rather than consuming bandwidth by sending all available variants, 60 the content provider can employ the Alternates header to 61 indicate what variants are available, the bases on which 62 the variants differ, and how to select a specific variant. 64 The functionality of the Alternates header is similar to 65 that of the Multipart/Alternative MIME type[Ref] where the 66 Multipart/Alternative object has all external message bodies. 67 The Alternates header differs in that it does not rank 68 the alternatives. Instead, it provides information which 69 allows the recipient to decide among them based on the 70 provider's estimation of their quality, local capabilities, 71 and preferences. 73 2 Terminology 75 The words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and 76 "MAY" in this document are to be interpreted as described in 77 RFC 2119 [Ref]. 79 3 Notation 81 The version of BNF used in this document is taken from [Ref], and 82 many of the nonterminals used are defined in [Ref]. 84 4.1 Definition 86 The Alternates header field describes all available 87 variants for a specific resource. The description for each 88 variant includes an URI from which this 89 variant can be retrieved. 91 Alternates = "Alternates" ":" variant-list 93 variant-list = 1#( variant-description ; see section 5 94 | fallback-variant 95 | negotiation-directive ) 97 fallback-variant = "{" <"> URI <"> "}" 99 negotiation-directive = token [ "=" ( token | quoted-string ) ] 101 An example is 103 Alternates: {"http://x.org/paper.1" 0.9 {type text/html} {language en}}, 104 {"http://x.org/paper.2" 0.7 {type text/html} {language fr}}, 105 {"ftp://x.org/pub/paper.3" 1.0 {type application/postscript} 106 {language en}}, 107 {"http://x.org/paper.html.en"}, x=y 109 A variant list may contain multiple differing descriptions of the 110 same variant. This can be convenient if the variant uses 111 conditional rendering constructs, or if the variant resource 112 returns multiple representations using a multipart media type. 114 Only one fallback-variant field may be present. If the variant 115 selection algorithm of the user agent finds that all variants 116 described by variant-description fields are unacceptable, then it 117 SHOULD choose the fallback variant, if present, as the best 118 variant. 120 This specification does not define any specific negotiation 121 directives for the Alternates header field. User agents SHOULD 122 ignore all negotiation directives they do not understand. If a 123 proxy receives an Alternates header field with an unknown 124 negotiation directive, it SHOULD, whenever possible, forward the 125 response towards the user agent instead of trying to take part in a 126 negotiation process itself. 128 4.2 Length of variant lists 130 As a general rule, variant lists in Alternates header fields should 131 be as short as possible. The use of multiple differing descriptions 132 of the same variant is supported, but should be limited to those 133 resources which cannot easily be expressed without the use of 134 condititional constructs or multipart media types. It is expected 135 that a typical negotiable resource will have 2 to 10 variants. 136 In situations where many more variants are available, more sophisticated 137 methods than the Alternates header field should be used. 139 5 Variant descriptions 141 5.1 Syntax 143 A variant can be described in a machine-readable way with a variant 144 description. 146 variant-description = 147 "{" <"> URI <"> source-quality *variant-attribute"}" 149 source-quality = qvalue 151 variant-attribute = "{" "type" media-type "}" 152 | "{" "charset" charset "}" 153 | "{" "language" 1#language-tag "}" 154 | "{" "length" 1*DIGIT "}" 155 | extension-attribute 157 extension-attribute = "{" extension-name extension-value "}" 158 extension-name = token 159 extension-value = *( token | quoted-string | LWS 160 | extension-specials ) 162 extension-specials = 163 and "}"> 165 Examples are 167 {"http://x.org/paper.2" 0.7 {type text/html} {language fr}} 169 {"http://x.org/paper.5" 0.9 {type text/html} {length 1002}} 171 {"http://x.org/paper.1" 0.001} 173 The various attributes which can be present in a variant 174 description are covered in the subsections below. Each attribute 175 may appear only once in a variant description. 177 5.2 URI 179 The URI attribute gives the URI of the resource from which the 180 variant can be retrieved with a GET request. It must be an 181 absolute URI, in order to allow for this header to be passed 182 to other MIME transport protocols without transformation. 183 The variant resource may vary the content it sends (on the Cookie 184 request header field, for example), but SHOULD NOT engage 185 in content negotiation itself. 187 5.3 Source-quality 189 The source-quality attribute gives the quality of the variant, as a 190 representation of the negotiable resource, when this variant is 191 rendered with a perfect rendering engine on the best possible 192 output medium. 194 If the source-quality is less than 1, it often expresses a quality 195 degradation caused by a lossy conversion to a particular data 196 format. For example, a picture originally in JPEG form would have 197 a lower source quality when translated to the XBM format, and a 198 much lower source quality when translated to an ASCII-art variant. 199 Note however, that degradation is a function of the source; an 200 original piece of ASCII-art may degrade in quality if it is 201 captured in JPEG form. 203 Servers should use the following table a guide when assigning 204 source quality values: 206 1.000 perfect representation 207 0.900 threshold of noticeable loss of quality 208 0.800 noticeable, but acceptable quality reduction 209 0.500 barely acceptable quality 210 0.300 severely degraded quality 211 0.000 completely degraded quality 213 In the source-quality values, servers should not account for the 214 size of the variant and its impact on transmission and rendering 215 delays; the size of the variant should be stated in the length 216 attribute and any size-dependent calculations should be done by a 217 variant selection algorithm in the user agent. 219 5.4 Type, charset, language, and length 221 The type attribute of a variant description carries the same 222 information as its Content-Type response header field counterpart 223 defined in [1], except for any charset information, which MUST be 224 carried in the charset attribute. For, example, the header field 226 Content-Type: text/html; charset=ISO-8859-4 228 has the counterpart attributes 230 {type text/html} {charset ISO-8859-4} 232 The language and length attributes carry the same information as 233 their Content-* response header field counterparts in [1]. The 234 length attribute, if present, MUST thus reflect the length of the 235 variant alone, and not the total size of the variant and any 236 objects inlined or embedded by the variant. 238 Though all of these attributes are optional, it is often desirable 239 to include as many attributes as possible, as this will increase 240 the quality of the negotiation process. 242 Note: A server is not required to maintain a one-to-one 243 correspondence between the attributes in the variant description 244 and the Content-* header fields in the variant response. For 245 example, if the variant description contains a language 246 attribute, the response does not necessarily have to contain a 247 Content-Language header field. If a Content-Language header 248 field is present, it does not have to contain an exact copy of 249 the information in the language attribute. 251 5.5 Extension-attribute 253 The extension-attribute allows future specifications to 254 incrementally define new dimensions of negotiation, and eases 255 content negotiation experiments. User agents conforming to this 256 specification SHOULD treat all variants with extension attributes 257 they do not recognize as unusable. Proxies SHOULD NOT do any 258 negotiation processing for a response if an extension attribute 259 unknown to them is present in the variant list. They SHOULD 260 forward the response unchanged towards the user agent instead. 262 The extension names "features" and "description" are reserved by 263 this specification for use in transparent content negotiation [4]. 265 6 Use of the Alternates header field 267 This section defines conventions and guidelines for the use of the 268 Alternates header field. 270 6.1 Use accompanying a variant 272 A resource provider may provide a recipient with a particular 273 variant together with an Alternates header field which notifies 274 the recipient that multiple variants are available. An HTTP 275 example of such an exchange is: 277 HTTP/1.1 200 OK 278 Date: Tue, 11 Jun 1996 20:05:31 GMT 279 Content-Type: text/html 280 Content-Language: en 281 Last-Modified: Mon, 10 Jun 1996 10:01:14 GMT 282 Content-Length: 5327 283 Alternates: {"http://x.org/paper.1" 0.9 {type text/html} {language en}}, 284 {"http://x.org/paper.2" 0.7 {type text/html} {language fr}}, 285 {"http://x.org/paper.3" 1.0 {type application/postscript} 286 {language en}} 287 Content-Location: http://x.org/paper.1 288 Vary: * 289 Expires: Thu, 01 Jan 1980 00:00:00 GMT 290 Cache-Control: max-age=604800 292 A paper about .... 294 In this response, the Content-Location header field tells the user 295 agent which variant was included. The Vary, Expires, and 296 Cache-Control header fields ensure proper handling of the response 297 by HTTP/1.0 and HTTP/1.1 caches. 299 When detecting that an Alternates header field is present, a user 300 agent MAY choose to use a variant selection algorithm to select the 301 best variant of the negotiable resource. If the best variant is 302 not the same one as the one identified by the Content-Location 303 header field, the user agent MAY use the URI indicated for the 304 best version to obtain it. 306 6.2 Use when a variant is not present 308 A content provider may also inform a potential recipient that 309 multiple variants exist without providing any particular variant. 310 In such exchanges, the content provider should omit the 311 Content-Location header. A message body MAY accompany the 312 headers used to convey this information. An SMTP example 313 of such an exchange is: 315 220 ESMTP spoken here 316 EHLO mail.x.org 317 250-mail.y.org Hello mail.x.org, pleased to meet you 318 MAIL FROM: lists@mail.x.org 319 250 lists@mail.x.org... Sender ok 320 RCPT TO: exploder-lists@mail.y.org 321 250 exploder-lists@mail.y.org... Recipient ok 322 DATA 323 354 Enter mail, end with "."on a line by itself 324 To: exploder-lists@mail.y.org 325 From: lists@mail.x.org 326 Date: Tue, 11 Jun 1996 20:02:21 GMT 327 Content-Type: text/htm 328 Content-Length: 227 329 Alternates: {"http://x.org/paper.1" 0.9 {type text/html} {language en}}, 330 {"http://x.org/paper.2" 0.7 {type text/html} {language fr}}, 331 {"http://x.org/paper.3" 1.0 {type application/postscript} 332 {language en}} 333 Vary: * 335 <h1>Multiple Choices:</h1> 336 <ul> 337 <li><a href=paper.1>HTML, English version</a> 338 <li><a href=paper.2>HTML, French version</a> 339 <li><a href=paper.3>Postscript, English version</a> 340 </ul> 341 . 342 250 XAA13385 Message accepted for delivery 344 On receipt of such a message, the user agent MAY use a variant 345 selection algorithm to select the best variant of the negotiable 346 resource, and retrieve this variant. For compatibility with user 347 agents which are not capable of handling the Alternates header 348 field, any message body should normally allow the user to select 349 the best variant manually. 351 6.3 Use of redirection to optimize availability 353 HTTP and related protocols allow an origin server to indicate 354 that a resource is available but is not at the URL by which it 355 was requested. As an optimization, the Alternates header can 356 be used in combination with this redirection to allow an origin 357 server to indicate the availability of variant resources without 358 including a resource or excluding user agents which do not support 359 the Alternates header. By providing the fallback variant's URL 360 in the location header, the origin server can ensure that all user 361 agents will have access to that variant, while the full list of 362 variants is provided in the Alternates header for more capable 363 user agents. 365 An example of this usage in an HTTP response is: 367 HTTP/1.1 302 Moved Temporarily 368 Date: Tue, 11 Jun 1996 20:05:31 GMT 369 Content-Type: text/html 370 Alternates: {"http://x.org/paper.1" 0.9 {type text/html} {language en}}, 371 {"http://x.org/paper.2" 0.7 {type text/html} {language fr}}, 372 {"http://x.org/paper.3" 1.0 {type application/postscript} 373 {language en}} 374 Location: http://x.org/paper.1 375 Content-Length: 67 377 This document is available <a href="http://x.org/paper.1">here</a>. 379 Note the use of a Location header field instead of a 380 Content-Location header field. On receipt of such a response, 381 user agents which understand the Alternates header SHOULD use 382 a variant selection algorithm to select the best variant of the 383 negotiable resource, and retrieve this variant. When the Alternates 384 header is used in protocols which do not provide redirection, the 385 method outlined in section 6.1 should be used when the content 386 provider wishes to ensure at least one variant is made available 387 to all recipients. 389 6.4 User agent guidelines 391 Summarizing the three sections above, if an Alternates header field 392 is present in the response, then 394 * a recipient SHOULD use its variant selection algorithm to 395 choose and retrieve the best variant if a Content-Location 396 header field is absent, 398 * and MAY use its variant selection algorithm to choose and 399 retrieve the best variant if a Content-Location header field 400 is present. 402 6.4.1 Interactive user agent guidelines 404 For user agents which provide direct interaction with users, the 405 following guidelines apply: 407 1. The user agent SHOULD make available though its user interface 408 some indication that the resource being displayed is a 409 negotiated resource instead of a plain resource. It SHOULD 410 also allow the user to examine the variant list included in the 411 Alternates header field. Such a notification and review 412 mechanism is needed because of privacy considerations, see 413 section 7.1. 415 2. If the user agent shows the URI of the displayed information to 416 the user, it SHOULD be the negotiable resource URI, not the 417 variant URI that is shown. This encourages third parties, who 418 want to refer to the displayed information in their own 419 documents, to refer to the negotiable resource as a whole, 420 rather than to the variant resource which happens to be 421 shown. This abstract referencing is vital for the interoperability 422 of content across sites. The user agent SHOULD also, however, 423 provide a means for reviewing the URI of the particular variant 424 which is currently being displayed. 426 3. Similarly, if the user agent stores a reference to the 427 displayed information for future use, for example in a hotlist, 428 it SHOULD store the negotiable resource URI, not the variant 429 URI. 431 6.4.2 Non-interactive user agent guidelines 433 Devices like printers, fax machines, or text processors may also be 434 the recipients of the Alternates header. Since such devices 435 typically function without direct interaction with a human operator, 436 the user agent guidelines given above do not directly apply. 437 Many of the same principals, however, can be employed. For 438 example, a device which generates a log report or cover sheet 439 which contains information about the information received could 440 provide the same information described above in that form. 442 6.5 Negotiation on content encoding 444 Negotiation on the content encoding of a response is orthogonal to 445 content negotiation based on the Alternates header field. 447 6.6 Role of proxies 449 This specification does not define mechanisms by which proxies can 450 use the Alternates header field, but does allow other 451 specifications to define such mechanisms. To ensure extensibility 452 of the Alternates header field, this specification does however 453 define, in section 4.1 and section 5.5, that a proxy should not 454 engage in a negotiation process when encountering an Alternates 455 header field which has a component unknown to it. 457 7 Security and privacy considerations 459 7.1 Variants hiding the source of displayed material. 461 The Variants header may be used to allow a 462 user to select among variants available from more than 463 one location. In such cases, users may make incorrect 464 asssumptions about the origin of particular resources. 465 The guidlines given in 6.4 alleviate this problem to 466 a degree, but some implementors of the Alternates header 467 may wish to provide further warnings or filters. 469 7.2 User agent choices revealing information of a private nature 471 The automatic selection and retrieval of a variant by a user agent 472 will reveal a preference for this variant to the server. A 473 malicious service author could provide a page with `fake' 474 negotiability as a means of obtaining privacy-sensitive information. 475 Such a plot would, however, be visible to an alert victim if the list 476 of available variants and their properties is reviewed through a 477 mechanism as described in section 6.4.1. 479 7.3 Security holes revealed by negotiation 481 Malicious servers could use content negotiation as a means of 482 obtaining information about security holes which may be present in 483 user agents. 485 8 Acknowledgments 487 Work on HTTP content negotiation has been done since at least 1993. 488 This specification builds on an earlier incomplete specification of 489 the Alternates header field recorded in [2]. The authors wish to 490 thank the individuals who have contributed to the work on content 491 negotiation in the HTTP working group, including Brian Behlendorf, 492 Daniel DuBois, Martin J. Duerst, Roy T. Fielding, Jim Gettys, Yaron 493 Goland, Dirk van Gulik, Graham Klyne, Scott Lawrence, 494 Larry Masinter, Jeffrey Mogul, Henrik Frystyk Nielsen, Frederick 495 G.M. Roeber, Paul Sutton, and Klaus Weide. 497 9 References 499 [1] R. Fielding, J. Gettys, J. C. Mogul, H. Frystyk, and 500 T. Berners-Lee. Hypertext Transfer Protocol -- HTTP/1.1. RFC 501 2068, HTTP Working Group, January 1997. 503 [2] Roy T. Fielding, Henrik Frystyk Nielsen, and Tim Berners-Lee. 504 Hypertext Transfer Protocol -- HTTP/1.1. Internet-Draft 505 draft-ietf-http-v11-spec-01.txt, HTTP Working Group, January 506 1996. 508 [3] T. Berners-Lee, R. Fielding, and H. Frystyk. Hypertext 509 Transfer Protocol -- HTTP/1.0. RFC 1945. MIT/LCS, UC Irvine, 510 May 1996. 512 [4] K. Holtman, A. Mutz. Transparent Content Negotiation in HTTP. 513 Internet-Draft draft-ietf-http-negotiation-04.txt, HTTP Working 514 Group, September 1997. 516 [5] S. Bradner. Key words for use in RFCs to Indicate Requirement 517 Levels. RFC 2119. Harvard University, March 1997. 519 10 Authors' addresses 521 Koen Holtman 522 Technische Universiteit Eindhoven 523 Postbus 513 524 Kamer HG 6.57 525 5600 MB Eindhoven (The Netherlands) 526 Email: koen@win.tue.nl 528 Andrew H. Mutz 529 Hewlett-Packard Company 530 1501 Page Mill Road 3U-3 531 Palo Alto CA 94304, USA 532 Fax +1 415 857 4691 533 Email: mutz@hpl.hp.com 535 Ted Hardie 536 NASA NIC 537 Mail Stop 204-14 538 NASA Ames Research Center 539 Moffett Field, CA 94035 540 Email: hardie@nic.nasa.gov 542 11 Appendix: Example of a variant selection algorithm 544 A negotiating user agent will choose the best variant from a 545 variant list with a variant selection algorithm. This appendix 546 contains an example of such an algorithm. 548 The inputs of the algorithm are a variant list from an Alternates 549 header field, and an agent-side configuration database, which 550 contains 552 - a collection of quality values assigned to media types, 553 languages, and charsets for the current request, following the 554 model of the corresponding HTTP/1.1 [1] Accept- header fields, 556 - a table which lists `forbidden' combinations of media types and 557 charsets, i.e. combinations which cannot be displayed because 558 of some internal user agent limitation. 560 The output of the algorithm is either the best variant, or the 561 conclusion that none of the variants are acceptable. 563 11.1 Computing overall quality values 565 As a first step in the variant selection algorithm, the 566 overall qualities associated with all variant descriptions in the 567 list are computed. 569 The overall quality Q of a variant description is the value 571 Q = round5( qs * qt * qc * ql * qa ) 573 where rounds5 is a function which rounds a floating point value to 574 5 decimal places after the point. It is assumed that the user 575 agent can run on multiple platforms: the rounding function makes 576 the algorithm independent of the exact characteristics of the 577 underlying floating point hardware. 579 The factors qs, qt, qc, ql, and qa are determined as follows. 581 qs Is the source quality factor in the variant description. 583 qt The media type quality factor is 1 if there is no type 584 attribute in the variant description. Otherwise, it is the 585 quality value assigned to this type by the configuration 586 database. If the database does not assign a value, then the 587 factor is 0. 589 qc The charset quality factor is 1 if there is no charset 590 attribute in the variant description. Otherwise, it is the 591 quality value assigned to this charset by the configuration 592 database. If the database does not assign a value, then the 593 factor is 0. 595 ql The language quality factor is 1 if there is no language 596 attribute in the variant description. Otherwise, it is the 597 highest quality value the configuration database assigns to 598 any of the languages listed in the language attribute. If 599 the database does not assign a value to any of the languages 600 listed, then the factor is 0. 602 qa The quality adjustment factor is 0 if the variant description 603 lists a media type - charset combination which is `forbidden' 604 by the table, and 1 otherwise. 606 As an example, if a variant list contains the variant description 608 {"paper.2" 0.7 {type text/html} {language fr}} 610 and if the configuration database contains the quality value 611 assignments 613 types: text/html;q=1.0, type application/postscript;q=0.8 614 languages: en;q=1.0, fr;q=0.5 616 then the variant selection algorithm will compute the overall 617 quality for the variant description as follows: 619 {"paper.2" 0.7 {type text/html} {language fr}} 620 | | | 621 | | | 622 V V V 623 round5 ( 0.7 * 1.0 * 0.5 ) = 0.35000 625 With same configuration database, the variant list 627 {"paper.1" 0.9 {type text/html} {language en}}, 628 {"paper.2" 0.7 {type text/html} {language fr}}, 629 {"paper.3" 1.0 {type application/postscript} {language en}} 631 would yield the following computations: 633 round5 ( qs * qt * qc * ql * qa ) = Q 634 --- --- --- --- --- 635 paper.1: 0.9 * 1.0 * 1.0 * 1.0 * 1.0 = 0.90000 636 paper.1: 0.7 * 1.0 * 1.0 * 0.5 * 1.0 = 0.35000 637 paper.3: 1.0 * 0.8 * 1.0 * 1.0 * 1.0 = 0.80000 639 11.2 Determining the result 641 Using all computed overall quality values, the end result of the 642 variant selection algorithm is determined as follows. 644 If all overall quality values are 0, then the best variant is the 645 fallback variant, if there is one in the Alternates header field, 646 else the result is the conclusion that none of the variants are 647 acceptable. 649 If at least one overall quality value is greater than 0, then the 650 best variant is the variant which has the description with the 651 highest overall quality value, or, if there are multiple variant 652 descriptions which share the highest overall quality value, the 653 variant of the first variant description in the list which has this 654 highest overall quality value. 656 11.3 Ranking dimensions 658 Consider the following variant list: 660 {"paper.greek" 1.0 {language el} {charset ISO-8859-7}}, 661 {"paper.english" 1.0 {language en} {charset ISO-8859-1}} 663 It could be the case that the user prefers the language "el" over 664 "en", while the user agent can render "ISO-8859-1" better than 665 "ISO-8859-7". The result is that in the language dimension, the 666 first variant is best, while the second variant is best in the 667 charset dimension. In this situation, it would be preferable to 668 choose the first variant as the best variant: the user settings in 669 the language dimension should take precedence over the hard-coded 670 values in the charset dimension. 672 To express this ranking between dimensions, the user agent 673 configuration database should have a higher spread in the quality 674 values for the language dimension than for the charset dimension. 675 For example, with 677 languages: el;q=1.0, en-gb;q=0.7, en;q=0.6, da;q=0, ... 679 charsets: ISO-8859-1;q=1.0, ISO-8859-7;q=0.95, 680 ISO-8859-5;q=0.97, unicode-1-1;q=0, ... 682 the first variant will have an overall quality of 0.95000, while 683 the second variant will have an overall quality 0.70000. This 684 makes the first variant the best variant. 686 Expires: May 15, 1998