idnits 2.17.1 draft-grigorik-http-client-hints-00.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 15, 2013) is 4053 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-03) exists of draft-fielding-http-key-02 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p1-messaging-22 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p2-semantics-22 ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group I. Grigorik 3 Internet-Draft March 15, 2013 4 Intended status: Informational 5 Expires: September 16, 2013 7 HTTP Client Hints 8 draft-grigorik-http-client-hints-00 10 Abstract 12 An increasing diversity of connected device form factors and software 13 capabilities has created a need to deliver varying, or optimized 14 content for each device. 16 Client Hints can be used as input to proactive content negotiation; 17 just as the Accept header allowed clients to indicate what formats 18 they prefer, Client Hints allow clients to indicate a list of device 19 and agent specific preferences. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on September 16, 2013. 38 Copyright Notice 40 Copyright (c) 2013 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.1. Notational Conventions . . . . . . . . . . . . . . . . . . 3 57 2. The "CH" Request Header Field . . . . . . . . . . . . . . . . . 3 58 2.1. Hint Syntax . . . . . . . . . . . . . . . . . . . . . . . . 4 59 2.2. Pre-defined Hints . . . . . . . . . . . . . . . . . . . . . 4 60 2.2.1. dh . . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 2.2.2. dw . . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 2.2.3. dpr . . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 2.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 2.4. Server opt-in with Hop and Origin Hints . . . . . . . . . . 5 65 2.5. Interaction with Caches . . . . . . . . . . . . . . . . . . 6 66 2.6. Relationship to the User-Agent Request Header . . . . . . . 6 67 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 68 3.1. The CH Request Header Field . . . . . . . . . . . . . . . . 6 69 3.2. The HTTP Hints . . . . . . . . . . . . . . . . . . . . . . 7 70 3.3. The HTTP Client Hints Registry . . . . . . . . . . . . . . 7 71 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 72 5. Normative References . . . . . . . . . . . . . . . . . . . . . 8 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 75 1. Introduction 77 There are thousands of different devices accessing the web, each with 78 different device capabilities and preference information. These 79 device capabilities include hardware and software characteristics, as 80 well as dynamic user and client preferences. 82 One way to infer some of these capabilities is through User-Agent 83 (UA) detection against an established database of client signatures. 84 However, this technique requires acquiring such a database, 85 integrating it into the serving path, and keeping it up to date. 86 However, even once this infrastructure is deployed, UA sniffing has 87 the following limitations: 89 o UA detection requires an external device database 90 o UA detection cannot reliably identify all static variables 91 o UA detection cannot infer any dynamic client preferences 92 o UA detection is not cache friendly 94 A popular alternative strategy is to use HTTP cookies to communicate 95 some information about the client. However, this approach is also 96 not cache friendly, bound by same origin policy, and imposes 97 additional client-side latency by requiring JavaScript execution to 98 create and manage HTTP cookies. 100 This document defines a new request Client Hint header field, "CH", 101 that allows the client to perform proactive content negotiation 102 [I-D.ietf-httpbis-p2-semantics] by indicating a list of device and 103 agent specific preferences, through a mechanism similar to the Accept 104 header which is used to indicate prefered response formats. 106 1.1. Notational Conventions 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 110 document are to be interpreted as described in [RFC2119]. 112 This document uses the Augmented Backus-Naur Form (ABNF) notation of 113 [RFC5234] with the list rule extension defined in 114 [I-D.ietf-httpbis-p1-messaging], Appendix B. It includes by 115 reference the OWS, field-name and quoted-string rules from that 116 document, and the parameter rule from 117 [I-D.ietf-httpbis-p2-semantics]. 119 2. The "CH" Request Header Field 121 The "CH" request header field describes an example list of client 122 preferences that the server can use to adapt and optimize the 123 resource to satisfy a given request. The CH field-value is a comma- 124 delimited list of header fields, and the field-name values are case 125 insensitive. 127 CH = #client-hint 128 client-hint = parameter 130 2.1. Hint Syntax 132 Hints are allowed to have a numeric value. However, where possible, 133 they can can be defined as flags (i.e., as a hint name only), so that 134 the hints don't consume too much space in client requests. 136 Hints can be defined as one of two types: 138 o Boolean - indicated by the presence of the hint name. If the hint 139 name is absent in the last message containing the client hint 140 header field, it is considered false. 141 o Numeric - value indicated by the digits after "=", up to the first 142 non-digit character. If the hint does not have an argument, its 143 value is assumed to be 0. 145 Note that HTTP/1.1 allows headers with comma-separated values to be 146 conveyed using multiple instances of the same header; as a result, 147 the hints are collected from all instances of the CH header on the 148 message in question before being considered complete. 150 2.2. Pre-defined Hints 152 The client controls which header fields are communicated within the 153 CH header, based on its default settings, or based on user 154 configuration and preferences. The user may be given the choice to 155 enable, disable, or override specific hints. For example, to allow 156 the request for low-resolution images or other content type's while 157 roaming on a foreign network, even while on a high-bandwidth link. 159 The client and server, or an intermediate proxy, may use an 160 additional mechanism to negotiate which fields should be reported to 161 allow for efficient content adaption. 163 This document defines the following hint names: 165 2.2.1. dh 167 o Description: device-width in secondary orientation, in density 168 independent pixels. 170 o Value Type: number 172 2.2.2. dw 174 o Description: device-width in primary orientation, in density 175 independent pixels. 176 o Value Type: number 178 2.2.3. dpr 180 o Description: Device Pixel Ratio (dpr), is the ratio between 181 physical pixels and density independent pixels on the device. 182 o Value Type: number 184 Other client hints may be communicated by the client. The decision 185 as to which specific hints will be sent is made by the client. 187 2.3. Examples 189 For example, given the following request header: 191 CH: dh=598, dw=384, dpr=2.0 193 The server knows that the client's screen height is 598px, width is 194 384px, as measured by density independent pixels on the device, and 195 that the device pixel ratio is 2.0. 197 2.4. Server opt-in with Hop and Origin Hints 199 CH is an optional header which may be sent by the client when making 200 a request to the server. The client may decide to always send the 201 header, or use an optional opt-in mechanism, such as a predefined 202 list of origins, user specified list of origins, or any other forms 203 of opt-in. 205 For example, the server may advertise its support for Client Hints 206 via Hop and/or Origin Hint ([I-D.nottingham-http-browser-hints]): 208 OH: ch 210 When a client receives the Hop or Origin Hint header indicating 211 support for Client Hint adaptation, it should append the CH header to 212 subsequent requests to the same origin server. Further, the client 213 may remember this hint and automatically append the CH header for all 214 future requests to the same origin. 216 2.5. Interaction with Caches 218 Client Hints may be combined with Key ([I-D.fielding-http-key]) to 219 enable fine-grained control of the cache key for improved cache 220 efficiency. For example, the server may return the following set of 221 instructions: 223 Key: CH;pr=dw[320:640] 225 Above example indicates that the cache key should be based on the CH 226 header, and the asset should be cached and made available for any 227 client whose device width (dw) falls between 320 and 640 px. 229 Key: CH;pr=dpr[1.5:] 231 Above examples indicates that the cache key should be based on the CH 232 header, and the asset should be cached and made available for any 233 client whose device pixel ratio (dpr) is 1.5, or higher. 235 In absence of support for fine-grained control of the cache key via 236 the Key header field, Vary response header can be used to indicate 237 that served resource has been adapted based on specified Client Hint 238 preferences. 240 Vary: CH 242 2.6. Relationship to the User-Agent Request Header 244 Client Hints does not supersede or replace User-Agent. Existing 245 device detection mechanisms can continue to use both mechanisms if 246 necessary. By advertising its capabilities within a request header, 247 Client Hints allows for cache friendly and proactive content 248 negotiation. 250 3. IANA Considerations 252 3.1. The CH Request Header Field 254 This document defines the "CH" HTTP request field, and registers it 255 in the Permanent Message Headers registry. 257 o Header field name: CH 258 o Applicable protocol: HTTP 259 o Status: Informational 260 o Author/Change controller: Ilya Grigorik, ilya@igvita.com 261 o Specification document(s): [this document] 262 o Related information: for Client Hints 264 3.2. The HTTP Hints 266 This document registers the "ch" HTTP Hint 267 ([I-D.nottingham-http-browser-hints]), as defined in section 2.1: 269 o Hint Name: ch 270 o Hint Type: origin, hop 271 o Description: When present, this hint indicates support for Client- 272 Hints adaptation. 273 o Value Type: numeric 274 o Contact: ilya@igvita.com 275 o Specification: this document 277 3.3. The HTTP Client Hints Registry 279 This document establishes the HTTP Client Hints Registry. 281 New hints are registered using Expert Review (see [RFC5226]), by 282 sending e-mail to iana@iana.org (or using other mechanisms, as 283 established by IANA). 285 New hints are expected to be implemented in at least one client in 286 common use. The Expert MAY use their judgement in determining what 287 "common" is, and when something is considered to be implemented. 289 New hints MUST be optional; they cannot place requirements upon 290 implementations. Specifically, new hints MUST NOT make communication 291 non-conformant with HTTP itself; i.e., this is not a mechanism for 292 changing the HTTP protocol in incompatible ways. 294 See section 2.1 for constraints on the syntax of hint names and hint 295 values. 297 Registration requests MUST use the following template: 299 o Hint Name: [name of hint] 300 o Hint Value: ["boolean" or "numeric"] 301 o Description: [description of hint] 302 o Contact: [e-mail address(es)] 303 o Specification: [optional; reference or URI to more info] 304 o Notes: [optional] 306 The initial contents of the registry are defined in section 2.2. 308 4. Security Considerations 310 The client controls which header fields are communicated and when. 311 In cases such as incognito or anonymous profile browsing, the header 312 can be omitted if necessary. 314 5. Normative References 316 [I-D.fielding-http-key] 317 Fielding, R. and M. Nottingham, "The Key HTTP Response 318 Header Field", draft-fielding-http-key-02 (work in 319 progress), February 2013. 321 [I-D.ietf-httpbis-p1-messaging] 322 Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 323 (HTTP/1.1): Message Syntax and Routing", 324 draft-ietf-httpbis-p1-messaging-22 (work in progress), 325 February 2013. 327 [I-D.ietf-httpbis-p2-semantics] 328 Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 329 (HTTP/1.1): Semantics and Content", 330 draft-ietf-httpbis-p2-semantics-22 (work in progress), 331 February 2013. 333 [I-D.nottingham-http-browser-hints] 334 Nottingham, M., "HTTP Origin and Hop Hints", 335 draft-nottingham-http-browser-hints-05 (work in progress), 336 February 2013. 338 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 339 Requirement Levels", BCP 14, RFC 2119, March 1997. 341 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 342 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 343 May 2008. 345 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 346 Specifications: ABNF", STD 68, RFC 5234, January 2008. 348 Author's Address 350 Ilya Grigorik 352 Email: ilya@igvita.com 353 URI: http://www.igvita.com/