Re: [w3ctag/design-reviews] Client Hint Reliability mechanisms (#549)

> But there doesn't appear to be any indication in syntax that this is an encoding of ACCEPT_CH. How is the client to know that?

None of that is the actual syntax. TLS, HTTP/2, and HTTP/3 are all binary protocols, so the actual syntax would be a hex readout of bytes, which isn't useful. :-)

This part is a protocol extension implemented by TLS and HTTP serving software, not the JavaScript/CSS APIs that are normally in explainers. We simply felt the explainer format was a useful way to convey, at a high level, how the pieces fit together. In particular, those diagrams are just shorthand patterned after the usual style in [TLS-related specifications](https://tools.ietf.org/html/rfc8446#section-2). The point is to convey what is sent in which round-trip.

As with other protocol extensions, the nitty gritty wire formats are in the protocol specifications, linked to from the explainer. Web developers don't interact with them, just as web developers don't parse TLS ClientHello messages. Though, for folks unfamiliar with how the IETF does things, draft versions are immutable, so any particular link may be stale. As the details here evolve, you'll need to check at the top of the page to make sure you're looking at the latest draft. At the moment, these are the latest ones:
https://tools.ietf.org/html/draft-vvv-tls-alps-01
https://tools.ietf.org/html/draft-vvv-httpbis-alps-01
https://tools.ietf.org/html/draft-davidben-http-client-hint-reliability-02

> Did you discuss your proposal with the IETF httpbis WG?

Yup. The documents were presented a few IETFs ago and we've started discussions at the httpbis and tls WGs for the HTTP and TLS portions, respectively.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/549#issuecomment-768621365