I have no strong opinion on how this is formatted. I'd base my decision on what the maximum value cTLS needs to encode: If 2^22-1 is sufficient, let's keep it as is, otherwise let's change it to the QUIC format (or some other change to increase the max value). I do like that the existing scheme, compared to QUIC varints, is more efficient for values 64-127 and just as efficient for the rest.
On Mon, Oct 5, 2020 at 8:09 PM Eric Rescorla <e...@rtfm.com> wrote: > I don't have a strong opinion on whether to require a minimal encoding, > but if we're not going to use QUIC's encoding as-is, then I would rather > stick with the existing scheme, which has twice as large a range for the 1 > byte encoding and is thus more compact for a range of common cases. > > -Ekr > > > On Mon, Oct 5, 2020 at 7:31 PM Marten Seemann <martenseem...@gmail.com> > wrote: > >> In that case, why use QUIC's encoding at all? It would just put the >> burden on the receiver to check that the minimal encoding was used. >> Would it instead make more sense to modify QUIC's encoding, such that the >> 2-byte encoding doesn't encode the numbers from 0 to 16383, but the numbers >> from 64 to (16383 + 64), and equivalently for 4 and 8-byte encodings? >> >> On Tue, Oct 6, 2020 at 9:22 AM Salz, Rich <rs...@akamai.com> wrote: >> >>> Can you just say “QUIC rules but use the minimum possible length”? >>> >> _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
