Re: [TLS] New Internet Draft: The qpack_static_table_version TLS extension

My general thoughts, in no particular order: * I’d be more excited about using a generic mechanism to agree on SETTINGS pre-handshake (e.g., ALPS) than using a protocol-specific TLS extension for just this feature. Therefore, HTTP WG for this particular use-case, but if there were to be a

Re: [TLS] New Internet Draft: The qpack_static_table_version TLS extension

Some thoughts: - Putting it into a TLS extension seems like a layering violation. At that point during the handshake, we don't know yet which ALPN will be negotiated. In the best case scenario, this would render the qpack_static_table_version extension useless, but things might get

Re: [TLS] New Internet Draft: The qpack_static_table_version TLS extension

More thoughts: (note that I'm trying to get emails sent from my personal email (rory.hew...@gmail.com) but for now, it's this work email. But a random email may pop up from that email address out of order...) * It sounds like there are some concerns (possibly sign

Re: [TLS] TLSFlags ambiguity

Nice catch! I agree those don't match. I think bit zero should be the least-significant bit. That is, we should leave the examples as-is and then fix the specification text. Ordering bits MSB first doesn't make much sense. Unlike bytes, there is no inherent order to bits in memory, so the most nat