Original text:
A popular alternative strategy is to use HTTP cookies (RFC6265) to communicate some information about the user agent.  However, this approach is also not cache friendly, bound by same origin policy, and <del> imposes additional client-side latency by requiring JavaScript </del>  execution to create and manage HTTP cookies. <del> This document defines a set of new request header fields that allow user agent to perform proactive content negotiation (Section 3.4.1 of RFC7231) by indicating device and agent specific preferences, through a mechanism similar to the Accept header field which is used to indicate preferred response formats. Client Hints does not supersede or replace the User-Agent header field.  Existing device detection mechanisms can continue to use both mechanisms if necessary.  By advertising its capabilities within a request header field, Client Hints allows for cache friendly and proactive content negotiation. </del>  1.1.

Reviewer comments:
Suggested elaboration / re-focusing in the introduction to clarify how CH fits into things.
CI failed due to rfc-URL DNS failure; should be transient.
Feedback addressed, I think.
Thanks for working on this! A few comments...Looks great, thanks Mark! Based on recent direction and discussions, the sections that mention "defines initial set of hints" and reference to User-Agent header may need to be updated, but we'll tackle that in a separate thread.

Revised text:
A popular alternative strategy is to use HTTP cookies (RFC6265) to communicate some information about the user agent.  However, this approach is also not cache friendly, bound by same origin policy, and  <ins> often imposes additional client-side latency by requiring JavaScript </ins> execution to create and manage HTTP cookies.  <ins> Proactive content negotiation (Section 3.4.1 of RFC7231) offers an alternative approach; user agents use specified, well-defined request headers to advertise their capabilities and characteristics, so that servers can select (or formulate) an appropriate response. However, proactive content negotiation requires clients to send these request headers prolifically.  This causes performance concerns (because it creates "bloat" in requests), as well as privacy issues (because these request headers can be used to "fingerprint" - i.e., uniquely identify - the user agent). This document defines a new response header, Accept-CH, that allows an origin server to explicitly ask that clients send these headers in requests, for a period of time bounded by the Accept-CH-Lifetime response header.  It also defines guidelines for content negotiation mechanisms that use it, colloquially referred to as Client Hints. Client Hints mitigate the performance concerns by assuring that clients will only send the request headers when they're actually going to be used, and the privacy concerns by creating positive evicence of their use (the use of the response header). This document also defines an initial set of Client Hints. It does not supersede or replace the User-Agent header field. Existing device detection mechanisms can continue to use both mechanisms if necessary.  By advertising user agent capabilities within a request header field, Client Hints allow for cache friendly and proactive content negotiation. </ins> 1.1.