Open MikeBishop opened 8 years ago
The unsolicited certs is the feature that really pushed this in this direction. Those seem to be useful, particularly when it comes to latency.
I'm almost wondering whether there's value in, say, an EXTENDED_SETTINGS extension that provides TLV settings values. The more I try to create extensions in HTTP/2, the more I feel like the fixed 32-bit values are a mite constrained for communicating anything useful. I don't want to build it in this doc (enough frames already!), but a normative reference might simplify the machinery here. If we could just send an array, then use the same codepoints TLS does, we become much more future-proof and can make the negotiation and PROOF frames match. Not as compact, but still....
I tend to prefer the EXTENDED_SETTINGS option, it allows the reuse of the TLS IANA registries and should require less maintenance when useful new TLS 1.3 extensions are inevitably introduced.
I think that we sorted this one out with the split.
Personal opinion, plus Andrei's feedback:
I really dislike the bitmap approach -- I'd much rather use the TLS IANA codepoints that exist. It's more extensible, better layered (can just relay uninterpreted data to the crypto components)
This would simplify the SETTINGS value and reconcile it with the algorithm field on the PROOF.