Re: Migrating some high-entropy HTTP headers to Client Hints.

Having worked with trying to shepherd a few of these (hints) through
implementation, my recommendation would be to:

   1. Spec the framework in the IETF draft: how to declare which hints you
   want to receive, how those prefs are stored, expected and recommended cache
   behaviors
   2. Spec the individual hints alongside relevant implementation specs
   (HTML, Fetch, or feature specific specs like NetInfo)
      - This eliminates all the corner+edge cases that Anne highlighted and
      allows us to iterate and define new hints as necessary

On that note, I think we're ~70% of the way there already. We have
in-flight PR's to update all the necessary plumbing in HTML and Fetch, we
already pulled out network related hints into NetInfo, and we can integrate
remaining hints into the HTML spec itself, which will also clarify all the
outstanding CH questions we have on GitHub. For User-Agent specifically, we
can+should define it directly in Fetch.

WDYT, reasonable?

On Mon, Jan 7, 2019 at 5:16 AM Anne van Kesteren <annevk@annevk.nl> wrote:

> Heya, happy new year,
>
> On Mon, Jan 7, 2019 at 10:14 AM Mike West <mkwst@google.com> wrote:
> > Since this group is currently responsible for both `User-Agent` and
> `Accept-Language`, I'd appreciate y'all's advice on how you'd like me to
> proceed.
>
> I don't really care strongly, but "reference from Fetch" seems too
> weak as there's a fair number of details that matter here that are
> still lingering for Client Hints. E.g., can they be set by developers,
> can they be observed by service workers, and how do they interact with
> CORS and the same-origin policy? Then for User-Agent and
> Accept-Language it would be nice if the primitives upon which those
> are built are defined in a central place so they can be reused by
> other consumers of that information. For this defining something in
> IETF-space is less than ideal as RFCs lend themselves much less to the
> inevitable refactoring you want to be doing. It's probably okay and
> you could maybe leave it up to some kind of integration standard to
> define "system language", "system architecture", ... (Which would be
> Fetch for browsers and browser-like user agents.)
>
> Hope that helps,
>
> Anne
>