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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> wrote: >> >>> Can you just say “QUIC rules but use the minimum possible length”? >>> >> _______________________________________________ > TLS mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
