Re: [quicwg/base-drafts] Make transport parameter ID and length varint (#3294)

[Kazuho Oku <[e-mail]>]

> If I remember correctly, the main argument for giving up on the TLS notation was improved readability for people who are not familiar with TLS representation language.

Re moving away from TLS notation, my memory is consistent to what you describe.

> From the viewpoint of consistency in encoding, switching back to it would definitely be an improvement though.

I think you make a good point here. Assuming that we keep the status quo, it would be helpful to the readers if we explained why it is designed as such. Maybe something like following would be a good idea: _To encourage code reuse, the encoding and validation requirements of Transport Parameters follows that of TLS extensions (RFC 8446; section 4.2](https://tools.ietf.org/html/rfc8446#section-4.2))._

> That being said, I still don't understand why TLS should be involved with the encoding of a value that it never treats as anything other than an opaque blob.

This is the only case in QUIC where we need to skip an opaque value of unknown type. That's why we use a type-*length*-value. We are also required to check that each parameter appears at most once, and also that the length of known parameters are as expected.

These requirements happen to be exactly equivalent to what is required for TLS extensions. And therefore it is beneficial *if* the existing code in TLS stack can be reused. Considering that QUIC already has a pretty tight coupling with TLS, I do not think it is unnatural to endorse such reuse.

-- 
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/issues/3294#issuecomment-564442061