On Thu, Jul 9, 2020, at 00:13, Victor Vasiliev wrote: > For what it's worth, I don't think we should define a new ALPN token > for that; using ALPN tokens for flags will eventually lead to > combinatorial explosion (e.g. "if we define h2_half_rtt, we have to > define h2c_half_rtt", etc), and can also lead to some really unpleasant > situations with Alt-Svc.
I'm not so firm on that. h2 was defined before 0-RTT, so there is no provision for carrying settings over into 0-RTT anyway, which is what would be required for thewebsocketprotocol CONNECT to work. You propose defining extensions to TLS to address this shortcoming in addition to the synchronization issue, but what that really is is a new version of h2 - one where SETTINGS does not appear in application data (mostly, I assume that updates are OK). This was discussed during the design of HTTP/2. But 0-RTT was too new to decide anything at that point and the view was that anything could be negotiated in one of two ways: SETTINGS (which takes time) or a new protocol version. It might seem a little early to be even contemplating a new version, but that wasn't the thinking at the time. h2c is dead, so we don't need to worry about that. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
