I don't know that the assumption that it starts as a re-ordering is going to be valid. Certainly we have at least one instance (the erratum you reported, Rory!) where we've found something in a static table that's simply invalid; I'd expect we drop that line in any versioned update, even if we have to keep it while extending. Similarly, fields that are lists of capabilities (e.g. Content-Encoding) are likely to have a new 1-2 top values that replace the old ones. I'd expect we generate the table de novo each time we do so, while hoping that many values remain the same over time.
I also do think there are interesting possibilities here for domain-specific tables which aren't a contiguous list of ongoing improvements. (Clients might also like not to remember the decades-old versions other than the fallback version zero.) That might suggest something more like the TLS supported_versions (https://datatracker.ietf.org/doc/html/rfc8446#section-4.2.1) extension, in which the sender could indicate "I know the first 104 entries of version 0, the first 72 entries of version 1, and the first 32 entries of version 61932." This also allows us more flexibility for doing draft version support during development, similar to QUIC versions that embedded draft numbers. Roy, to your comment a while back that the HTTP Archive isn't representative: It absolutely isn't, and yet it's the best resource we had at the time and what we used. If there's a more representative resource to be used in the future, please do suggest it when we start trying to build a new table. Thanks, Mike ________________________________ From: Rory Hewitt <rory.hew...@gmail.com> Sent: Tuesday, October 17, 2023 2:21 PM To: Martin J. Dürst <due...@it.aoyama.ac.jp> Cc: HTTP Working Group <ietf-http...@w3.org>; TLS List <tls@ietf.org>; Hewitt, Rory <rhewitt=40akamai....@dmarc.ietf.org> Subject: 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
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
