Hello Rory,
Just a few questions/comments below.
On 2023-10-05 06:12, Rory Hewitt wrote:
A few upcoming changes for version-01:
1. A published version of the QPACK static table (see #2 for publishing
details) will have a Length and a Version, and the QSTVExtension will be
defined like this:
struct {
uint8 StaticTableVersion;
uint8 StaticTableLength;
} qpack_static_table_version;
where:
StaticTableVersion - the version of the table. Initial version is 0.
StaticTableLength - the maximum number of entries supported in the table.
Initial length is 99
So the first version of the table (currently defined in Appendix A in RFC
2904 (https://www.rfc-editor.org/rfc/rfc9204.html#name-static-table-2) will
be 0,99.
2. I will specify that a new IETF registry should be created (and
*nominally* maintained by IANA) with myself and others as designated
experts.
Two points:
1) Can you say what you mean by *nominally*? If it's just that IANA does
the clerical work, but none of the technical work, then please note that
all IANA registries work that way.
2) As far as I understand, designated experts are usually appointed by
the IESG, with the responsible Area Director making a proposal. It's of
course very good to have volunteers! But there's also some argument to
having the proposers of new registrations and the approving expert(s)
being different people (additional pair of eyes,...).
On an ongoing basis, we will sample traffic (likely from the HTTP
Archive, since they already do significant web traffic sampling). Where new
HTTP field names or name/value combinations (collectively 'header lines')
have become more prevalent than the current last entry in the latest table
, they will be appended as new entries in the table, increasing its length.
Additionally, on an ongoing basis, new Versions of the table will be
created. This will involve re-ordering the table to ensure that the entries
are ordered in the most efficient manner possible.
Example
=======
The initial table is 0,99 (Version 0, Length 99) and is published in the
registry.
A year from now, we re-sample traffic and discover 12 new header lines
which are more common than "x-frame-options: sameorigin" (entry 99 in the
current table). These 12 header lines are ordered by prevalence to each
other and appended as entries in the table in the registry - this is
referred to as 0,111 (Version 0, Length 111) and REPLACES table 0,99 in the
registry.
A year after that, we re-sample traffic again and discover 5 new prevalent
header lines, so we order these entries and append them, giving table
0,116, which REPLACES table 0,111.
A year makes sense as a basic pacer. But there may be times where change
is faster or slower (and there's times when humans are faster or
slower). Is "year" here just an example, or a specific proposal?
Crucially, there is no reordering of entries in Version 0 - only appending
of new entries.
At that point, we ALSO reorder ALL the table entries in order of total
prevalence and increment the Version, giving 1,116 and publish that as a
separate table in the registry.
So now we have two published tables:
* 0,116 - Version 0 with 116 entries. Entries 0-98 are in the same order as
the current QPACK table. Entries 99-111 are ordered by prevalence with one
another, but not with any prevalence order to entries 0-98. Same goes for
entries 112-116 - ordered in relationship to one another but with
relationship to entries 0-111.
* 1,116 - Version 1 with 116 entries. All entries are ordered by prevalence
compared to every other entry.
Is the expectation that new versions also happen at a constant pace? Or
do you expect to use some kind of entropy calculation so that new
versions only get created if the reordering leads to "significant"
savings? [some entries in entries 99-111 may be more prevalent than some
of the later entries up to entry 98, but not by much.]
Over time, the registry could end up containing multiple Versions. Older
versions MAY be deprecated if we can reasonably determine that they are no
longer used (TBD). Only one table per Version will be published at any time.
Clients and servers MUST always support Version 0. They MAY also support
other Versions as long as they support all intermediate versions between
Version 0 and the Version for which they advertise support in
qpack_static_table_version. This allows both client and server to simply
downgrade to a shared supported Version without the client needing to
advertise multiple supported Versions (c.f. TLS cipher suites) and possibly
missing intermediate versions.
How does "they support all intermediate versions between Version 0 and
the Version for which they advertise support" work together with
deprecation?
Client and servers can still negotiate both the highest Version the support
and the Length (number of entries) within that Version in a manner similar
to that in version-00 of the I-D as follows:
<snip>
3. A client or server can specify any positive value for StaticTableLength.
A negative value is invalid and the default value (99) MUST be assumed by
the receiver.
Is 99 the default value for version 0 only, or for all versions?
Thus a client or server which may have very limited memory and/or which
expects to send/receive only a few known headers can specify 0,30,
indicating that they support only the first 30 entries in Version 0 of the
static table and any other header lines must be specified in the dynamic
table.
Interesting. What if a few decades from now, a client or server only
wants to support the first 30 entries in a new version?
Regards, Martin.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
