Yves: let's bump this

[assigned to f2f

Tess: this is a network protocol level optimisation of client hints, under the assumption client hints is a thing and works as it was designed. Say a client requests a website for the first time, send a GET request, with no client hints becuase you don't know what the server wants yet. In the 200 reply it can say here are the client hints I'm interested in. Right now if a browser spports client hints it might retry and send client hints for maybe a better website. So it tries again and gets a different result. But that roundtrip sucks performance wise so they were trying to figure out how to optimise that away most of the time. Combation of TSL level change and HTTP/2 and 3 level change that accomplish that. New Header called critical-ch that say which client hints would result in very different responses. Mechanism to expose than in the initial TLS handshake. When client first connects to server it can say it wants an ecrypted connection the server says right aware here are client hints, before the first HTTP request has been made. In the initial http GET it can include the client ints it would have asked for, removing the round trip. It's very sensible as an optimisation mechanism. Fundamentally questions about client hints in general as a mechanism, and any specific client hint may or may not have concerns related to it. I don't think that's relevant here. if you presume client hints are a thing, this is a straightforward optimisation to make them less costly in the common case. I don't remember TAG's position on client hints in general, but as optimisation it seems fine. I don't want to say it looks fine without Yves saying he's okay with it. Plenary? Proposed closed and getting Yves confirmation in plenary? ... They want to ship some of it and it's been a while.

Dan: we don't have a general position on client hints. In Feb 2019 we had a proposal about migrating high entropy http request headers to client hints which we responded positively to.

Tess: we don't necessarily need a position on underlying mechanism to be positive on it

Hadley: do we need to take a position on client hints?

Tess: we probably should. There are specific client hints being proposed I'm not okay with, but some that are fine. General mechanism seems fine. there's been a lot of back and forth.. people working on it are responsive. Biggest concerns have been / are being fixed.

Dan: what's the current implementation status on client hints itself?

Tess: probably out of date - I understand it's still a single engine thing. Mozilla's position overall was "non-harmful". We were initially opposed but they've been very responsive on specific feedback. No implementation in Safari.

Dan: would it make sense to say if the implementation s ory is okay to say it makes sense as a mechanism but there should be some rule about things shouldn't be implemented as a client hint if they can be x or are intended to be y. Adds complexity, not something developers expect, not easily configurable in servers. Finding? Design principle?

Tess: one of the advantages of client hints as infrastructure is the shift of passive fingerprinting into active fingerprinting. One arguement is that it's a good idea because it improves the stuation fingerprinting-wise. Specific client hints that make things worse fingerprinting-wise subvert the entire mechanism and probably shouldn't be done. Ultimately it doesn't come into this specific design review.

Dan: in the spirit of spinning things into design principles, we might want to open a design principle issue

Tess: makes sense as a design principle for i fyou're thinking about adding a new client hint we can offer guidence about when it is or isn't appropriate. That's the case for many other mechanisms... http header? Propose close and I'll file a design principles issue

Dan: I'm doing it.

Lea: when I was reviewing the compute pressure we were discussing adding a principle about designing APIs in a low level way so we're stuck on hardware, do we have that?

Tess: we should have that

Yves wanted to make sure they were talking to the right groups at IETF about this, and they are. Propose close.

Draft closing comment from @ylafon:

Thank you for those answers. From a TAG standpoint we are happy to let the discussion continue in the HTTPBis WG.