idnits 2.17.1 draft-ietf-httpbis-client-hints-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([2], [3], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 26, 2018) is 2272 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 570 -- Looks like a reference, but probably isn't: '2' on line 572 -- Looks like a reference, but probably isn't: '3' on line 574 ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) ** Obsolete normative reference: RFC 7231 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 7234 (Obsoleted by RFC 9111) Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HTTP Working Group I. Grigorik 3 Internet-Draft Google 4 Intended status: Experimental January 26, 2018 5 Expires: July 30, 2018 7 HTTP Client Hints 8 draft-ietf-httpbis-client-hints-05 10 Abstract 12 An increasing diversity of Web-connected devices and software 13 capabilities has created a need to deliver optimized content for each 14 device. 16 This specification defines an extensible and configurable set of HTTP 17 request header fields, colloquially known as Client Hints, to address 18 this. They are intended to be used as input to proactive content 19 negotiation; just as the Accept header field allows user agents to 20 indicate what formats they prefer, Client Hints allow user agents to 21 indicate device and agent specific preferences. 23 Note to Readers 25 Discussion of this draft takes place on the HTTP working group 26 mailing list (ietf-http-wg@w3.org), which is archived at 27 https://lists.w3.org/Archives/Public/ietf-http-wg/ [1]. 29 Working Group information can be found at http://httpwg.github.io/ 30 [2]; source code and issues list for this draft can be found at 31 https://github.com/httpwg/http-extensions/labels/client-hints [3]. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at https://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on July 30, 2018. 50 Copyright Notice 52 Copyright (c) 2018 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 68 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 4 69 2. Client Hint Request Header Fields . . . . . . . . . . . . . . 4 70 2.1. Sending Client Hints . . . . . . . . . . . . . . . . . . 4 71 2.2. Server Processing of Client Hints . . . . . . . . . . . . 4 72 2.2.1. Advertising Support via Accept-CH Header Field . . . 5 73 2.2.2. The Accept-CH-Lifetime Header Field . . . . . . . . . 5 74 2.2.3. Interaction with Caches . . . . . . . . . . . . . . . 6 75 3. Client Hints . . . . . . . . . . . . . . . . . . . . . . . . 6 76 3.1. The DPR Header Field . . . . . . . . . . . . . . . . . . 6 77 3.1.1. Confirming Selected DPR . . . . . . . . . . . . . . . 7 78 3.2. The Width Header Field . . . . . . . . . . . . . . . . . 7 79 3.3. The Viewport-Width Header Field . . . . . . . . . . . . . 7 80 3.4. The Save-Data Header Field . . . . . . . . . . . . . . . 8 81 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 8 82 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 83 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 84 6.1. Accept-CH . . . . . . . . . . . . . . . . . . . . . . . . 10 85 6.2. Accept-CH-Lifetime . . . . . . . . . . . . . . . . . . . 10 86 6.3. Content-DPR . . . . . . . . . . . . . . . . . . . . . . . 10 87 6.4. DPR . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 88 6.5. Save-Data . . . . . . . . . . . . . . . . . . . . . . . . 10 89 6.6. Viewport-Width . . . . . . . . . . . . . . . . . . . . . 11 90 6.7. Width . . . . . . . . . . . . . . . . . . . . . . . . . . 11 91 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 92 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 93 8.1. Normative References . . . . . . . . . . . . . . . . . . 11 94 8.2. Informative References . . . . . . . . . . . . . . . . . 12 95 8.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 12 96 Appendix A. Interaction with Key Response Header Field . . . . . 13 97 Appendix B. Changes . . . . . . . . . . . . . . . . . . . . . . 13 98 B.1. Since -00 . . . . . . . . . . . . . . . . . . . . . . . . 13 99 B.2. Since -01 . . . . . . . . . . . . . . . . . . . . . . . . 13 100 B.3. Since -02 . . . . . . . . . . . . . . . . . . . . . . . . 13 101 B.4. Since -03 . . . . . . . . . . . . . . . . . . . . . . . . 14 102 B.5. Since -04 . . . . . . . . . . . . . . . . . . . . . . . . 14 103 B.6. Since -05 . . . . . . . . . . . . . . . . . . . . . . . . 14 104 B.7. Since -06 . . . . . . . . . . . . . . . . . . . . . . . . 14 105 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 107 1. Introduction 109 There are thousands of different devices accessing the web, each with 110 different device capabilities and preference information. These 111 device capabilities include hardware and software characteristics, as 112 well as dynamic user and client preferences. 114 One way to infer some of these capabilities is through User-Agent 115 (Section 5.5.3 of [RFC7231]) header field detection against an 116 established database of client signatures. However, this technique 117 requires acquiring such a database, integrating it into the serving 118 path, and keeping it up to date. However, even once this 119 infrastructure is deployed, user agent sniffing has numerous 120 limitations: 122 o User agent detection cannot reliably identify all static variables 123 o User agent detection cannot infer any dynamic client preferences 124 o User agent detection requires an external device database 125 o User agent detection is not cache friendly 127 A popular alternative strategy is to use HTTP cookies ([RFC6265]) to 128 communicate some information about the user agent. However, this 129 approach is also not cache friendly, bound by same origin policy, and 130 imposes additional client-side latency by requiring JavaScript 131 execution to create and manage HTTP cookies. 133 This document defines a set of new request header fields that allow 134 user agent to perform proactive content negotiation (Section 3.4.1 of 135 [RFC7231]) by indicating device and agent specific preferences, 136 through a mechanism similar to the Accept header field which is used 137 to indicate preferred response formats. 139 Client Hints does not supersede or replace the User-Agent header 140 field. Existing device detection mechanisms can continue to use both 141 mechanisms if necessary. By advertising its capabilities within a 142 request header field, Client Hints allows for cache friendly and 143 proactive content negotiation. 145 1.1. Notational Conventions 147 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 148 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 149 "OPTIONAL" in this document are to be interpreted as described in BCP 150 14 [RFC2119] [RFC8174] when, and only when, they appear in all 151 capitals, as shown here. 153 This document uses the Augmented Backus-Naur Form (ABNF) notation of 154 [RFC5234] with the list rule extension defined in [RFC7230], 155 Appendix B. It includes by reference the DIGIT rule from [RFC5234] 156 and the OWS and field-name rules from [RFC7230]. 158 2. Client Hint Request Header Fields 160 A Client Hint request header field is a HTTP header field that is 161 used by HTTP clients to indicate configuration data that can be used 162 by the server to select an appropriate response. Each one conveys 163 client preferences that the server can use to adapt and optimize the 164 response. 166 2.1. Sending Client Hints 168 Clients control which Client Hints are sent in requests, based on 169 their default settings, user configuration, and server preferences. 170 The client and server can use an opt-in mechanism outlined below to 171 negotiate which fields should be sent to allow for efficient content 172 adaption, and optinally use additional mechanisms to negotiate 173 delegation policies that control access of third parties to same 174 fields. 176 Implementers should be aware of the passive fingerprinting and 177 network information disclosure implications when implementing support 178 for Client Hints, and follow the considerations outlined in "Security 179 Considerations" section of this document. 181 2.2. Server Processing of Client Hints 183 When presented with a request that contains one or more client hint 184 header fields, servers can optimize the response based upon the 185 information in them. When doing so, and if the resource is 186 cacheable, the server MUST also generate a Vary response header field 187 (Section 7.1.4 of [RFC7231]) to indicate which hints can affect the 188 selected response and whether the selected response is appropriate 189 for a later request. 191 Further, depending on the hint used, the server can generate 192 additional response header fields to convey related values to aid 193 client processing. For example, this specification defines the 194 "Content-DPR" response header field that needs to be returned by the 195 server when the "DPR" hint is used to select the response. 197 2.2.1. Advertising Support via Accept-CH Header Field 199 Servers can advertise support for Client Hints using the Accept-CH 200 header field or an equivalent HTML meta element with http-equiv 201 attribute ([HTML5]). 203 Accept-CH = #field-name 205 For example: 207 Accept-CH: DPR, Width, Viewport-Width 209 When a client receives an HTTP response advertising support for 210 Client Hints, it should process it as origin ([RFC6454]) opt-in to 211 receive Client Hint header fields advertised in the field-value. The 212 opt-in MUST be delivered over a secure transport. 214 For example, based on Accept-CH example above, a user agent could 215 append DPR, Width, and Viewport-Width header fields to all same- 216 origin resource requests initiated by the page constructed from the 217 response. 219 2.2.2. The Accept-CH-Lifetime Header Field 221 Servers can ask the client to remember the set of Client Hints that 222 the server supports for a specified period of time, to enable 223 delivery of Client Hints on subsequent requests to the server's 224 origin ([RFC6454]). 226 Accept-CH-Lifetime = #delta-seconds 228 When a client receives an HTTP response that contains Accept-CH- 229 Lifetime header field, the field-value indicates that the Accept-CH 230 preference SHOULD be persisted and bound to the origin, and be 231 considered stale after response's age ([RFC7234], section 4.2) is 232 greater than the specified number of seconds. The preference MUST be 233 delivered over a secure transport, and MUST NOT be persisted for an 234 origin that isn't HTTPS. 236 Accept-CH: DPR, Width 237 Accept-CH: Viewport-Width 238 Accept-CH-Lifetime: 86400 240 For example, based on the Accept-CH and Accept-CH-Lifetime example 241 above, which is received from "https://bar.example.com" in response 242 to a resource request initiated by "https://foo.example.com", both 243 delivered over a secure transport: a user agent SHOULD persist an 244 Accept-CH preference bound to "https://foo.example.com", for requests 245 initiated to "https://bar.example.com" from 246 "https://foo.example.com", for up to 86400 seconds (1 day). This 247 preference SHOULD NOT extend to requests initiated to 248 "https://bar.example.com" from other origins. 250 If Accept-CH-Lifetime occurs in a message more than once, the last 251 value overrides all previous occurrences. 253 2.2.3. Interaction with Caches 255 When selecting an optimized response based on one or more Client 256 Hints, and if the resource is cacheable, the server needs to generate 257 a Vary response header field ([RFC7234]) to indicate which hints can 258 affect the selected response and whether the selected response is 259 appropriate for a later request. 261 Vary: DPR 263 Above example indicates that the cache key needs to include the DPR 264 header field. 266 Vary: DPR, Width 268 Above example indicates that the cache key needs to include the DPR 269 and Width header fields. 271 3. Client Hints 273 3.1. The DPR Header Field 275 The "DPR" request header field is a number that indicates the 276 client's current Device Pixel Ratio (DPR), which is the ratio of 277 physical pixels over CSS px (Section 5.2 of [CSSVAL]) of the layout 278 viewport (Section 9.1.1 of [CSS2]) on the device. 280 DPR = 1*DIGIT [ "." 1*DIGIT ] 282 If DPR occurs in a message more than once, the last value overrides 283 all previous occurrences. 285 3.1.1. Confirming Selected DPR 287 The "Content-DPR" response header field is a number that indicates 288 the ratio between physical pixels over CSS px of the selected image 289 response. 291 Content-DPR = 1*DIGIT [ "." 1*DIGIT ] 293 DPR ratio affects the calculation of intrinsic size of image 294 resources on the client - i.e. typically, the client automatically 295 scales the natural size of the image by the DPR ratio to derive its 296 display dimensions. As a result, the server MUST explicitly indicate 297 the DPR of the selected image response whenever the DPR hint is used, 298 and the client MUST use the DPR value returned by the server to 299 perform its calculations. In case the server returned Content-DPR 300 value contradicts previous client-side DPR indication, the server 301 returned value MUST take precedence. 303 Note that DPR confirmation is only required for image responses, and 304 the server does not need to confirm the resource width as this value 305 can be derived from the resource itself once it is decoded by the 306 client. 308 If Content-DPR occurs in a message more than once, the last value 309 overrides all previous occurrences. 311 3.2. The Width Header Field 313 The "Width" request header field is a number that indicates the 314 desired resource width in physical px (i.e. intrinsic size of an 315 image). The provided physical px value is a number rounded to the 316 smallest following integer (i.e. ceiling value). 318 Width = 1*DIGIT 320 If the desired resource width is not known at the time of the request 321 or the resource does not have a display width, the Width header field 322 can be omitted. If Width occurs in a message more than once, the 323 last value overrides all previous occurrences. 325 3.3. The Viewport-Width Header Field 327 The "Viewport-Width" request header field is a number that indicates 328 the layout viewport width in CSS px. The provided CSS px value is a 329 number rounded to the smallest following integer (i.e. ceiling 330 value). 332 Viewport-Width = 1*DIGIT 334 If Viewport-Width occurs in a message more than once, the last value 335 overrides all previous occurrences. 337 3.4. The Save-Data Header Field 339 The "Save-Data" request header field consists of one or more tokens 340 that indicate client's preference for reduced data usage, due to high 341 transfer costs, slow connection speeds, or other reasons. 343 Save-Data = sd-token *( OWS ";" OWS [sd-token] ) 344 sd-token = token 346 This document defines the "on" sd-token value, which is used as a 347 signal indicating explicit user opt-in into a reduced data usage mode 348 on the client, and when communicated to origins allows them to 349 deliver alternate content honoring such preference - e.g. smaller 350 image and video resources, alternate markup, and so on. New token 351 and extension token values can be defined by updates to this 352 specification. 354 If Save-Data occurs in a message more than once, the last value 355 overrides all previous occurrences. 357 4. Examples 359 For example, given the following request header fields: 361 DPR: 2.0 362 Width: 320 363 Viewport-Width: 320 365 The server knows that the device pixel ratio is 2.0, that the 366 intended display width of the requested resource is 160 CSS px (320 367 physical pixels at 2x resolution), and that the viewport width is 320 368 CSS px. 370 If the server uses above hints to perform resource selection for an 371 image asset, it must confirm its selection via the Content-DPR 372 response header to allow the client to calculate the appropriate 373 intrinsic size of the image response. The server does not need to 374 confirm resource width, only the ratio between physical pixels and 375 CSS px of the selected image resource: 377 Content-DPR: 1.0 379 The Content-DPR response header field indicates to the client that 380 the server has selected resource with DPR ratio of 1.0. The client 381 can use this information to perform additional processing on the 382 resource - for example, calculate the appropriate intrinsic size of 383 the image resource such that it is displayed at the correct 384 resolution. 386 5. Security Considerations 388 The request header fields defined in this specification, and those 389 that extend it, expose information about the user's environment to 390 enable proactive content negotiation. Such information may reveal 391 new information about the user and implementers ought to consider the 392 following considerations, recommendations, and best practices. 394 Transmitted Client Hints header fields SHOULD NOT provide new 395 information that is otherwise not available to the application via 396 other means, such as using HTML, CSS, or JavaScript. Further, 397 sending highly granular data, such as image and viewport width may 398 help identify users across multiple requests. Reducing the set of 399 field values that can be expressed, or restricting them to an 400 enumerated range where the advertised value is close but is not an 401 exact representation of the current value, can improve privacy and 402 reduce risk of linkability by ensuring that the same value is sent by 403 multiple users. However, such precautions can still be insufficient 404 for some types of data, especially data that can change over time. 406 Implementers ought to consider both user and server controlled 407 mechanisms and policies to control which Client Hints header fields 408 are advertised: 410 o Implementers SHOULD restrict delivery of some or all Client Hints 411 header fields to the opt-in origin only, unless the opt-in origin 412 has explicitly delegated permission to another origin to request 413 Client Hints header fields. 414 o Implementers MAY provide user choice mechanisms so that users may 415 balance privacy concerns with bandwidth limitations. However, 416 implementers should also be aware that explaining the privacy 417 implications of passive fingerprinting or network information 418 disclosure to users may be challenging. 419 o Implementations specific to certain use cases or threat models MAY 420 avoid transmitting some or all of Client Hints header fields. For 421 example, avoid transmission of header fields that can carry higher 422 risks of linkability. 424 Implementers SHOULD support Client Hints opt-in mechanisms and MUST 425 clear persisted opt-in preferences when site data, browsing history, 426 browsing cache, or similar, are cleared. 428 6. IANA Considerations 430 This document defines the "Accept-CH", "DPR", "Save-Data", "Viewport- 431 Width", and "Width" HTTP request fields, "Accept-CH", "Accept-CH- 432 Lifetime", and "Content-DPR" HTTP response field, and registers them 433 in the Permanent Message Header Fields registry. 435 6.1. Accept-CH 437 o Header field name: Accept-CH 438 o Applicable protocol: HTTP 439 o Status: standard 440 o Author/Change controller: IETF 441 o Specification document(s): Section 2.2.1 of this document 442 o Related information: for Client Hints 444 6.2. Accept-CH-Lifetime 446 o Header field name: Accept-CH-Lifetime 447 o Applicable protocol: HTTP 448 o Status: standard 449 o Author/Change controller: IETF 450 o Specification document(s): Section 2.2.2 of this document 451 o Related information: for Client Hints 453 6.3. Content-DPR 455 o Header field name: Content-DPR 456 o Applicable protocol: HTTP 457 o Status: standard 458 o Author/Change controller: IETF 459 o Specification document(s): Section 3.1.1 of this document 460 o Related information: for Client Hints 462 6.4. DPR 464 o Header field name: DPR 465 o Applicable protocol: HTTP 466 o Status: standard 467 o Author/Change controller: IETF 468 o Specification document(s): Section 3.1 of this document 469 o Related information: for Client Hints 471 6.5. Save-Data 473 o Header field name: Save-Data 474 o Applicable protocol: HTTP 475 o Status: standard 476 o Author/Change controller: IETF 477 o Specification document(s): Section 3.4 of this document 478 o Related information: for Client Hints 480 6.6. Viewport-Width 482 o Header field name: Viewport-Width 483 o Applicable protocol: HTTP 484 o Status: standard 485 o Author/Change controller: IETF 486 o Specification document(s): Section 3.3 of this document 487 o Related information: for Client Hints 489 6.7. Width 491 o Header field name: Width 492 o Applicable protocol: HTTP 493 o Status: standard 494 o Author/Change controller: IETF 495 o Specification document(s): Section 3.2 of this document 496 o Related information: for Client Hints 498 7. Acknowledgements 500 Thanks to Mark Nottingham, Julian Reschke, Chris Bentzel, Yoav Weiss, 501 Ben Greenstein, Tarun Bansal, Roy Fielding, Vasiliy Faronov, Ted 502 Hardie, Jonas Sicking, and numerous other members of the IETF HTTP 503 Working Group for invaluable help and feedback. 505 8. References 507 8.1. Normative References 509 [CSS2] Bos, B., Celic, T., Hickson, I., and H. Lie, "Cascading 510 Style Sheets Level 2 Revision 1 (CSS 2.1) Specification", 511 W3C Recommendation REC-CSS2-20110607, June 2011, 512 . 514 [CSSVAL] Atkins, T. and E. Etemad, "CSS Values and Units Module 515 Level 3", World Wide Web Consortium CR CR-css-values- 516 3-20160929, September 2016, 517 . 519 [HTML5] Hickson, I., Berjon, R., Faulkner, S., Leithead, T., 520 Navara, E., O'Connor, T., and S. Pfeiffer, "HTML5", 521 World Wide Web Consortium Recommendation REC- 522 html5-20141028, October 2014, 523 . 525 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 526 Requirement Levels", BCP 14, RFC 2119, 527 DOI 10.17487/RFC2119, March 1997, 528 . 530 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 531 Specifications: ABNF", STD 68, RFC 5234, 532 DOI 10.17487/RFC5234, January 2008, 533 . 535 [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, 536 DOI 10.17487/RFC6454, December 2011, 537 . 539 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 540 Protocol (HTTP/1.1): Message Syntax and Routing", 541 RFC 7230, DOI 10.17487/RFC7230, June 2014, 542 . 544 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 545 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 546 DOI 10.17487/RFC7231, June 2014, 547 . 549 [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, 550 Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", 551 RFC 7234, DOI 10.17487/RFC7234, June 2014, 552 . 554 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 555 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 556 May 2017, . 558 8.2. Informative References 560 [KEY] Fielding, R. and M. Nottingham, "The Key HTTP Response 561 Header Field", draft-ietf-httpbis-key-01 (work in 562 progress), March 2016. 564 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 565 DOI 10.17487/RFC6265, April 2011, 566 . 568 8.3. URIs 570 [1] https://lists.w3.org/Archives/Public/ietf-http-wg/ 572 [2] http://httpwg.github.io/ 574 [3] https://github.com/httpwg/http-extensions/labels/client-hints 576 Appendix A. Interaction with Key Response Header Field 578 Client Hints may be combined with Key response header field ([KEY]) 579 to enable fine-grained control of the cache key for improved cache 580 efficiency. For example, the server can return the following set of 581 instructions: 583 Key: DPR;partition=1.5:2.5:4.0 585 Above example indicates that the cache key needs to include the value 586 of the DPR header field with three segments: less than 1.5, 1.5 to 587 less than 2.5, and 4.0 or greater. 589 Key: Width;div=320 591 Above example indicates that the cache key needs to include the value 592 of the Width header field and be partitioned into groups of 320: 593 0-320, 320-640, and so on. 595 Appendix B. Changes 597 B.1. Since -00 599 o Issue 168 (make Save-Data extensible) updated ABNF. 600 o Issue 163 (CH review feedback) editorial feedback from httpwg 601 list. 602 o Issue 153 (NetInfo API citation) added normative reference. 604 B.2. Since -01 606 o Issue 200: Moved Key reference to informative. 607 o Issue 215: Extended passive fingerprinting and mitigation 608 considerations. 609 o Changed document status to experimental. 611 B.3. Since -02 613 o Issue 239: Updated reference to CR-css-values-3 614 o Issue 240: Updated reference for Network Information API 615 o Issue 241: Consistency in IANA considerations 616 o Issue 250: Clarified Accept-CH 618 B.4. Since -03 620 o Issue 284: Extended guidance for Accept-CH 621 o Issue 308: Editorial cleanup 622 o Issue 306: Define Accept-CH-Lifetime 624 B.5. Since -04 626 o Issue 361: Removed Downlink 627 o Issue 361: Moved Key to appendix, plus other editorial feedback 629 B.6. Since -05 631 o Issue 372: Scoped CH opt-in and delivery to secure transports 632 o Issue 373: Bind CH opt-in to origin 634 B.7. Since -06 636 o None 638 Author's Address 640 Ilya Grigorik 641 Google 643 Email: ilya@igvita.com 644 URI: https://www.igvita.com/