Re: [quicwg/base-drafts] Extension frames (#1068)

[ekr <[e-mail]>]

I'm not a huge fan of this design, for two reasons:

1. The mapping seems complex, and really only serves to save a few bytes. As I think I observed in Melbourne, given that QUIC already has variable length integers and we are only presently defining a very small number of frame types, why don't simply declare the frame type to be a varint. Then we will have an unlimited number of extension frame types, and we can assign low (hence short) frame types to anything that becomes a standard (thus not paying any bytes there) and non-standard frame types can just use longer numbers, without any mapping.

2. Because this design couples frame type negotiation and its code point, that means that if you want to negotiate parameters for the use of extension frames, you then need a separate transport parameters negotiation for *that*

I'm certainly sympathetic for people's desire to not have a bunch of transport parameters messages whose only purpose is to signal "I support feature X" (this is kind of an annoyance in TLS) but I think that can actually be dealt with in a cleaner way: Simply have TP contain a list of numbers (varints) which define the features that you are advertising. This wouldn't be the only way to do things and so if you had a feature that needed negotiation, you could still do it that way, but simple features could be indicated this way.




-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/1068#issuecomment-378596154