Hello Rory,
Sorry for not answering earlier. Many thanks for your detailed response.
One main additional comment inline below, about the utility and
frequency of new versions.
On 2023-10-06 01:34, Rory Hewitt wrote:
Hey Martin,
Some ordered response which roughly match up to your comments, since adding
inline gets really difficult to read after a while :)
1. Yes, I'll mention that this will follow the 'normal' path of IETF
registries (IANA does clerical, IETF does technical).
2. I certainly didn't mean to overstep by suggesting myself as a designated
expert - I'll ensure this section is appropriately vague. But I want to
clarify that the HTTP Archive folks already have all the info we need in
terms of a representative web sample that we can query. The last thing I
would want is for this proposal to be mired in "we need people to do this
complex, time-consuming bit of work, so let's not do it at all". The data
is there and is freely available and is regularly updated.
3. Using "a year" was an example of the timeframe I think makes sense.
There doesn't need to be a schedule as such - new updates to tables and
versions get published when they get published. As noted above, the HTTP
Archive data could be used and I believe a new version of that is published
annually as a BigQuery, so that would be the optimal cadence for
determining whether new headers should be appended to existing table
versions. If the prevalence of the new headers are significant (FSVO
'significant'), such that a new table version would actually make sense,
that would be a decision for the registry maintainers. My gut feeling is
that appending new headers would likely happen every year or so, with a new
version being published every 2-3 years. But that's just a gut feeling -
like I say, there's no schedule.
I can agree with appending about every year or so. Newly defined header
fields could become popular, or existing header fields could suddenly
soar in popularity.
However, I have strong doubts about using a new version every 2-3 years.
That has several reasons:
1) We don't have exact data; the relative frequency of the entries is
just a guess. Statistical fluctuations occur, and as Roy has said, the
data we have access to doesn't cover all of HTTP/3 usage. Changing the
order, and then changing back a few years later just produces
unnecessary churn.
2) Whether some header field name or header field is in a table makes a
big difference (roughly 10~20 bytes to 1~2, i.e. one order of
magnitude). On the other hand, whether an entry is e.g. number 50 or
number 60 in most cases doesn't change the number of bytes used to
encode that entry, and in the rest of cases, just adds or removes a
single byte. So the performance gains of a new version are really minimal.
3) The overhead of new versions, ranging from registry updates to
implementations and memory, are more serious than those for just appending.
4) Entries never get removed (see point 5 below). So we have to carry
old entries around anyway, even if (in the extreme) their occurrence
went down to 0 (e.g. because a new header field took over from an older
one). That also makes cutting new versions less attractive.
All that makes me guess that a new version every 10 years or so might
make more sense, if at all.
That then in turn raises the question of whether we need the "new
version" mechanism at all, and whether we need it now or can wait for
five or ten years down the line to define it.
Regards, Martin.
4. Ah, you saw my bit about deprecation. I added that, then took it out,
then added it, then took it out. It should probably be taken out. Since
we're just talking about a registry, there's no downside to keeping every
prior version in the registry.
5. Good point! 99 is the default value for Version 0. Since each new
version will effectively start out as a re-ordered version of the latest
update of the prior version, then the default value for each version will
be different (but always >= 99). The specific default value for each
version will obviously be available in the registry.
6. Supporting a number of entries less than the default is a really
interesting case that I've been noodling on. Using your scenario, if a
micro client in the year 2030 says that it supports 5,30 and the server
says that it only supports version 2, then they will both use the first 30
entries in Version 2. I guess this could result in sub-optimal performance,
if there is a significant difference between the first 30 entries in v2 and
the first 30 entries in v5, but realistically, I think the first few
entries (10? 20? 30?) are unlikely to change significantly - they're just
really commonly used. Entry 0 (":authority") is probably always going to be
number 1 :) Another option would be there to be different Types of tables
(Type would be higher than Version) so that e.g. micro clients can always
use a different table which works for them and the servers they think they
are likely to contact. But that migth be getting even more complex for
little benefit.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
