Extension frame design question

[Martin Thomson <[e-mail]>]

We agreed to add the ability to extend QUIC in Melbourne (I know, it's
so long ago, but it seems like just yesterday).  But we never never
sealed the deal.

While we agree in principle, and have agreed that the use of
extensions will be signaled during the handshake using transport
parameters (as opposed to the h2 model where they can just appear),
we're locked in disagreement about the precise colour to use.  Right
now there are three options:

1. As Victor originally proposed, provide a map from a large
identifier space to the smaller space of extension frame types.  PR
#1068 does that, mapping a 16-bit identifier into the 128-255 range of
frame types.  Cost: indirection, complexity.  Advantage: It has a PR
(i.e., nothing significant).

2. Use a varint for frame types. Cost: non-trivial change to the wire
format for frames; large(r) overhead for sending a frame unless you
get one of the privileged frame types that encode to a single octet
(and we have used 3/8 of those already, so we'd probably want to be
strict about registration policies in that space).  Advantage: simple.

3. A modification to PR #1068 proposed by Kazuho which would have
every transport parameter carry a list of frame types with it.  Cost:
similar indirection to PR #1068, and every transport parameter would
carry this list.  The advantage being that an extension that defines a
transport parameter would only touch a single transport parameter and
not have to register an extension frame type as well.

Now I prefer the first, but could live with either alternative if only
we could decide.  So I'm asking for help.