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

[Mike Bishop <[e-mail]>]

MikeBishop requested changes on this pull request.

I think this is a good improvement, but a few things need fixing before it merges.  Also, if you want GitHub to give you credit for the commits, the `user.email` needs to be an e-mail that GitHub has associated with your user account (verified or not).

>  
-The initial maximum size is determined by the corresponding setting when HTTP
-requests or responses are first permitted to be sent. For clients using 0-RTT
-data in HTTP/3, the table size is the remembered value of the setting, even if
-the server later specifies a larger maximum in its SETTINGS frame.  For HTTP/3
-servers and HTTP/3 clients when 0-RTT is not attempted or is rejected, the
-initial maximum table size is the value of the setting in the peer's SETTINGS
-frame.
+The initial dynamic table capacity is the value of the maximum dynamic table
+capacity when HTTP requests or responses are first permitted to be sent.  For
+HTTP/3 servers and HTTP/3 clients when 0-RTT is not attempted or is rejected,
+the initial maximum table capacity is zero.  For clients using 0-RTT data in

Good catch!  I like your proposed text, and this reflects the agreement we reached on #1530.

> -requests or responses are first permitted to be sent. For clients using 0-RTT
-data in HTTP/3, the table size is the remembered value of the setting, even if
-the server later specifies a larger maximum in its SETTINGS frame.  For HTTP/3
-servers and HTTP/3 clients when 0-RTT is not attempted or is rejected, the
-initial maximum table size is the value of the setting in the peer's SETTINGS
-frame.
+The initial dynamic table capacity is the value of the maximum dynamic table
+capacity when HTTP requests or responses are first permitted to be sent.  For
+HTTP/3 servers and HTTP/3 clients when 0-RTT is not attempted or is rejected,
+the initial maximum table capacity is zero.  For clients using 0-RTT data in
+HTTP/3, the initial table capacity is the remembered value of the setting, even
+if the server later specifies a different maximum dynamic table capacity in its
+SETTINGS frame.  It is not an error for the SETTINGS frame to contain a
+SETTINGS_MAXIMUM_DYNAMIC_TABLE_CAPACITY value lower than the initial table
+capacity on a 0-RTT connection; the maximum dynamic table capacity only limits
+subsequent table capacity changes.  However, if an endpoint receives a

HTTP/3 in general bars reducing the value of a setting while accepting 0-RTT, so (1) would be more consistent.  From 4.2.5.2 in H3:

> If 0-RTT data is accepted by the server, its SETTINGS frame MUST NOT reduce any limits or alter any values that might be violated by the client with its 0-RTT data.

>  
-The new maximum size MUST be lower than or equal to the limit determined by the
-protocol using QPACK.  A value that exceeds this limit MUST be treated as a
-connection error of type `HTTP_QPACK_ENCODER_STREAM_ERROR`.  In HTTP/3, this
-limit is the value of the SETTINGS_HEADER_TABLE_SIZE parameter (see
-{{configuration}}) received from the decoder.
+The new capacity MUST be lower than or equal to the limit described in
+{{maximum-dynamic-table-capacity}}.  On 1-RTT HTTP/3 connections, this limit is

True for all connections -- the setting has an initial value of (0 , previous) and then gets updated when the SETTINGS frame is received.

> @@ -780,9 +781,7 @@ end of a stream, it generates a Stream Cancellation instruction on the decoder
 stream.  Similarly, when an endpoint abandons reading of a stream it needs to
 signal this using the Stream Cancellation instruction.  This signals to the
 encoder that all references to the dynamic table on that stream are no longer
-outstanding.  A decoder with a maximum dynamic table size equal to zero MAY omit
-sending Stream Cancellations, because the encoder cannot have any dynamic table
-references.

...and therefore, we still want this text.

> @@ -1261,7 +1272,8 @@ Substantial editorial reorganization; no technical changes.
 - Largest Reference encoded modulo MaxEntries (#1763)
 - New Static Table (#1355)
 - Table Size Update with Insert Count=0 is a connection error (#1762)
-- Stream Cancellations are optional when SETTINGS_HEADER_TABLE_SIZE=0 (#1761)
+- Stream Cancellations are optional when
+  SETTINGS_MAXIMUM_DYNAMIC_TABLE_CAPACITY=0 (#1761)

Rather than retconning the changelog, it's probably more appropriate to add a current changelog entry that SETTINGS_HEADER_TABLE_SIZE was renamed.

-- 
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#pullrequestreview-186314467