- From: Lucas Pardue <lucaspardue.24.7@gmail.com>
- Date: Mon, 20 Jul 2020 20:10:19 +0100
- To: Victor Vasiliev <vasilvv@google.com>
- Cc: "tls@ietf.org" <tls@ietf.org>, HTTP Working Group <ietf-http-wg@w3.org>
Received on Monday, 20 July 2020 19:10:48 UTC
Hi Victor, It seems my brain skipped over "ALPS in HTTPS" [1] when you mentioned in your original email. I was reading it in the context of David Benjamin's thread on Client Hint Reliability [2]. There's a couple of things that surprised me when reading both drafts: 1. ALPS in HTTPS actually supports more than just exchanging Settings Parameters, it can actually hold a series of frames. It's just that ALPS only defines SETTINGS to be allowed, and Client Hints Reliability wants to add more in the shape of a new ACCEPT_CH frame. I'm not sure I like the idea of supporting any old frame in the TLS handshake, SETTINGS are at least reasoned about in terms of how they are remembered for the purposes of 0-RTT. 2. ALPS in HTTPS makes it mandatory to support some settings to disable static and Huffman header compression. That seems pretty onerous. If there was interest in prototyping something like ACCEPT_CH-in-handhsake it requires a modification of a QPACK dependency. On the other hand, if you don't make these settings mandatory, then you won't achieve your objective of removing the mandatory parts of HPACK/QPACK. To me this is a signal that ALPN is a better option to negotiate a profile of H2/H3 that modifies mandatory compression behaviour. Cheers Lucas [1] https://tools.ietf.org/html/draft-vvv-httpbis-alps-00 [2] https://lists.w3.org/Archives/Public/ietf-http-wg/2020JulSep/0054.html
Received on Monday, 20 July 2020 19:10:48 UTC