Original text:
There are thousands of different devices accessing the web, each with different device capabilities and preference information.  These device capabilities include hardware and software characteristics, as <del> well as dynamic user and client preferences. One way to infer some of these capabilities is through User-Agent (Section 5.5.3 of RFC7231) header field detection against an established database of client signatures.  However, this technique requires acquiring such a database, integrating it into the serving path, and keeping it up to date.  However, even once this infrastructure is deployed, user agent sniffing has numerous limitations: User agent detection cannot reliably identify all static variables User agent detection cannot infer any dynamic client preferences User agent detection requires an external device database User agent detection is not cache friendly 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 often imposes additional client-side latency by requiring JavaScript execution to create and manage HTTP cookies. </del>  Proactive content negotiation (Section 3.4.1 of RFC7231) offers an alternative approach; user agents use specified, well-defined request

Reviewer comments:
Based on discussion at IETF 105, removing explicit lifetime in favor of implicit opt-in registration and persistence. NAME can you please take a look? In particular, current language states the preference should be persisted but doesn't explicitly state for what the lifetime is.. Modulo, in privacy section we do talk about MUST criteria for clearing it. Any suggestions or recommendations for how to best approach this?
LGTM

Revised text:
There are thousands of different devices accessing the web, each with different device capabilities and preference information.  These device capabilities include hardware and software characteristics, as  <ins> well as dynamic user and client preferences.  Applications that want to allow the server to optimize content delivery and user experience based on such capabilities have, historically, had to rely on passive identification (e.g., by matching User-Agent (Section 5.5.3 of RFC7231) header field against an established database of client signatures), used HTTP cookies and URL parameters, or use some combination of these and similar mechanisms to enable ad hoc content negotiation. Such techniques are expensive to setup and maintain, are not portable across both applications and servers, and make it hard to reason for both client and server about which data is required and is in use during the negotiation: User agent detection cannot reliably identify all static variables, cannot infer dynamic client preferences, requires external device database, is not cache friendly, and is reliant on a passive fingerprinting surface. Cookie based approaches are not portable across applications and servers, impose additional client-side latency by requiring JavaScript execution, and are not cache friendly. URL parameters, similar to cookie based approaches, suffer from lack of portability, and are hard to deploy due to a requirement to encode content negotiation data inside of the URL of each resource. </ins> Proactive content negotiation (Section 3.4.1 of RFC7231) offers an alternative approach; user agents use specified, well-defined request