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

[Kazuho Oku <[e-mail]>]

I do not have a strong opinion on if we should use TP for negotiating extensions, however I agree with @ekr that doing some negotiation in TP and some by using frames seems awkward to me. It might make sense to do all in TP or do all in frames (as we have done in HTTP/2).

I have two other concerns about the proposed approach.

The first concern is the approach expecting an extension to always introduce a new frame type. I wonder if that assumption would always be true. Consider the case when we would have a different PNE mechanism. Use of the mechanism needs to be negotiated. However, it would not introduce a new frame; since it just changes how the packet is formatted. Therefore, I'd prefer defining a mapping that maps a feature to *zero* or more frame IDs, rather than a one-to-one mapping.

The second concern is frame_type getting ossified. Consider the case when we adopt the first extension named Foo. Implementations that only support Foo will likely assign 0x80 as the frame_type (endpoints can unilaterally declare the mapping). The same frame_type (0x80) will be used to designate the same extension, when sending *and* receiving. My fear is that I doubt if we can be sure that all the implementations will work correctly even in case different frame_types are assigned for sending and receiving the extension in such scenario. However, unless all implementations succeed in implementing it correctly, the frame_type will become ossified. Therefore, I'd prefer greasing the frame_type.

-- 
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-378663899