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

[Kazuho Oku <[e-mail]>]

@martinthomson Thank you for pointing out that it is necessary to use TP for negotiating some features, and also for moving the negotiation there.

@ekr 
> Well, as you acknowledge below, it is feature negotiation for features that need new frames.

I share this model, and see two issues with the proposed approach:
* The proposed approach has two ways of extending QUIC, one by assigning a new TransportParameterId and one by assigning one or more `extension_frame_identifier`. I think that we should better unify the two schemes.
* We might want to pass along some parameters for the extension being negotiated. However, the proposal does not allow an `ExtensionFrameMappings` to carry such parameters.

Considering the two, how about defining the frame types to be used for each extension as a direct member of `TransportParameter`, like below?

```
struct {
  TransportParameterId parameter;
  opaque value<0..2^16-1>;
  uint8 frame_types<0..128>;
} TransportParameter;
```

Then, we can simplify the procedure of adding new extensions, regardless of if it needs frame types or not. An extension would always have a new TransportParameterId, can have any argument passed by using `value`, and have any number of frame types being assigned. We will only need one IANA registry for TransportParameterIds.

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