Re: [TLS] New Internet Draft: The qpack_static_table_version TLS extension

Hey Martin,

That's a fair point, and I appreciate you bringing it up.

What I wanted to clarify was that every 3 years, whoever is doing the
sampling and appending of new entries should determine whether the new
entries are sufficiently popular that re-ordering the table makes sense.
They can certainly decide that it doesn't make sense to create an entire
new registry just because entry 123 should actually be at position 98. As a
consequence, I agree that creating a new table every 3 years doesn't
necessarily make sense.

Indeed, the most common scenario is almost certainly that new field strings
are appended to the table every year or so, but while they are 'somewhat'
popular (more popular than the last entry in the table, at least), they're
not 'really' popular - they're not going to be so popular that they
displace the low-order numbers in the table and make a real difference. So
no new version is required.

However...

Since the web traffic was originally sampled in 2018 to create that initial
QPACK table, things have changed considerably. I suspect that some of the
Client Hints header strings (Accept-CH etc.) have probably become very
popular and will continue to do so - possibly to a point where it may make
sense that a new registry be created with the table being reordered.

Additionally, the current QPACK table contains some entries that are, shall
we say, weird. For example, many of the CORS entries (73-82) contain
invalid values. While the point of the QPACK table is to aid compression
(and therefore commonly-used fields, even if they are technically invalid,
should be included), I'm surprised that some valid values are not included
in there.

I wouldn't be surprised if we sampled traffic today (5 years after the
original sample) we found a) a number of frequently-used headers which
don't exist in the current static table; and b) that some of the headers in
that table should be re-ordered because it would make an actual difference.
Which would certainly mean appending those new fields, but very likely
(again IMO) in re-ordering the table and creating a second registry.

Finally, while it may be the case that a new version is only needed every
10 years, it makes sense to me to define the process for creating that
version now, even if it's not needed for a while.

Thoughts?

Rory