Code change:
For example: <del> When a client receives an HTTP response advertising support for provided list of Clients Hints, it SHOULD process it as origin (RFC6454) opt-in to receive Client Hint header fields advertised in the field-value, for subsequent same-origin requests. The opt-in MUST be delivered over a secure transport. The opt-in SHOULD be persisted and bound to the origin to enable delivery of Client Hints on subsequent requests to the server's origin, and MUST NOT be persisted for an origin that isn't HTTPS. For example, based on the Accept-CH example above, which is received in response to a user agent navigating to "https://example.com", and delivered over a secure transport: a user agent will have to persist an Accept-CH preference bound to "https://example.com" and use it for user agent navigations to "https://example.com" and any same-origin </del> <ins> When a client receives an HTTP response containing "Accept-CH", it indicates that the origin opts-in to receive the indicated request header fields for subsequent same-origin requests.  The opt-in MUST be ignored if delivered over non-secure transport or for an origin with a scheme different from HTTPS.  It SHOULD be persisted and bound to the origin to enable delivery of Client Hints on subsequent requests to the server's origin. For example: Based on the Accept-CH example above, which is received in response to a user agent navigating to "https://example.com", and delivered over a secure transport: a user agent will have to persist an Accept- CH preference bound to "https://example.com" and use it for user agent navigations to "https://example.com" and any same-origin </ins> resource requests initiated by the page constructed from the navigation's response.  This preference will not extend to resource requests initiated to "https://example.com" from other origins. 3.2. <del> When selecting an optimized response based on one or more Client Hints, and if the resource is cacheable, the server needs to generate a Vary response header field (RFC7234) to indicate which hints can affect the selected response and whether the selected response is </del> <ins> When selecting a response based on one or more Client Hints, and if the resource is cacheable, the server needs to generate a Vary response header field (RFC7234) to indicate which hints can affect the selected response and whether the selected response is </ins> appropriate for a later request. Above example indicates that the cache key needs to include the Sec-

Related discussion:
text: LGTM! thx
Some of this is very nit-picky; feel free to do what you like with it... ^ There's something weird going on with tense in this sentence. "Such techniques are expensive... are not portable... and make it hard..." The third doesn't fit with the first two. "Client Hints mitigate the performance concerns..." probably just "Client Hints mitigate performance concerns..." Likewise for "the privacy concerns" below. "This document defines the Client Hints infrastructure, a framework that enables servers to opt-in to specific proactive content negotiation features, which will enable them to adapt their content accordingly." --> "This document defines Client Hints, a framework that enables servers to opt-in to specific proactive content negotiation features, adapting their content accordingly." as a normative reference probably isn't going to fly, given its status. Why is it normative? maybe instead: Be aware that HTTP doesn't require presence of when proactive conneg is in use; if the response is truly uncacheable, it isn't necessary. maybe instead: instead: BTW, nothing is said about precedence between the two different mechanisms; separate issue? The reference to 6454 is spurious, and it's pretty indirect. Perhaps: It's kind of weird to have this list just appear. Perhaps turn these into prose? Put "For example" above the example to introduce it. Limits CH to just "optimisation." Probably should just be:
Thanks for reviewing! :) PR underway The here is conditional on cacheability. Is that OK? We're now considering removing http-equiv support for this: URL Maybe it's best to simply remove that reference here?
Ah, I missed that, sorry. WRT http-equiv; that might be best, then.