Re: [quicwg/base-drafts] Clean up text on Maximum Table Size. (#2115)

[Bence Béky <[e-mail]>]

Hi Martin, I think that's a great option.  Please help me with the nomenclature here.  There are three distinct quantities at play:

A: The sum of the size of the entries in the dynamic table.

B: The amount of memory the decoder is required for dynamic table entries.  Oldest entries that do not fit in B will be evicted.  This quantity can be changed unilaterally by the encoder as long as it does not exceed C.

C: Hard limit on B.  In HTTP/3, this is set by the decoder via SETTINGS_HEADER_TABLE_SIZE.

All three quantities have to be discussed in the spec, and a compliant optimal decoder needs to keep track of all three of them.  Therefore I feel strongly that they need consistent and distinct names (or phrases) for them.

Currently the spec consistently uses "(dynamic) table size" for A (for example, first sentence of 3.2.2) and "maximum (dynamic) table size" or "maximum size of the dynamic table" for C (for example, when calculating MaxEntries or in 4.4.3 when talking about omitting stream cancellations).  For B, the spec sometimes uses "table size", sometimes "maximum table size", sometimes within the same section, like 4.3.4.

What I drafted up was A: "table size", B: "Maximum Table Size", C: "limit on Maximum Table Size".  Another option you are proposing, if I understand you correctly, is B: "table size", C: "maximum table size".  Then we need to find something for A, like "table load" or "table utilization" or "table memory footprint", or just write out "sum of size of entries" every time.  I'm fine with that.

A third option could be A: "table size" (which I think is the conventional meaning of "size"); C: "maximum table size", and find something for B, like "table capacity".

I do not have a strong opinion on any of these names, as long as the text is clean and unambiguous.  Please tell me what your preference is.  Thanks.

As for the reordering of large chunks of text, sorry for mixing that in with this PR.  I'll draft a separate PR for that and rebase this one on that.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2115#issuecomment-446721184