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

[Martin Thomson <[e-mail]>]

Just to clear something up: this establishes what frames mean.  It is NOT feature negotiation.  If, as in @kazuho's example, we want to add a new packet number encryption scheme, we could do that with a new transport parameter.  It makes no sense to do this.

If we want to add simple feature negotiation, then we would do that with empty extensions, or as @ekr suggests with a single "feature list" extension.  Again, it makes no sense to use this mechanism for that unless those features also use frames.

And there I can see the potential for duplication and overlap: if a feature needs to negotiate use of frames, then it can use this mechanism and it probably doesn't need a separate negotiation mechanism.  If the feature doesn't use frames, then it can use its own mechanism (or a feature list extension if we added that).  But if the new feature also has parameters, it needs to use both this mechanism and a separate transport parameter.  This mechanism does in a sense overlap with a feature's own negotiation, or a feature list mechanism if you think of it that way.  I don't think that's such a big problem though.

I'm undecided on the varint idea.  It seems to critically depend on also having a length field on every frame.  I suspect that this is what @ekr wants, but I have heard pretty strong opposition to that notion from others.

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