Code change:
MUST terminate the connection with a ConnectionErrorHandler of type COMPRESSION_ERROR if it does not decompress a field block. <ins> A decoding error in a field block MUST be treated as a ConnectionErrorHandler of type COMPRESSION_ERROR. 4.3.1. Field compression is stateful.  Each endpoint has an HPACK encoder context and an HPACK decoder context that are used for encoding and decoding all field blocks.  COMPRESSION defines the dynamic table, which is the primary state for each context. The dynamic table has a maximum size that is set by an HPACK decoder. An endpoint communicates the size chosen by its HPACK decoder context using the SETTINGS_HEADER_TABLE_SIZE setting; see SettingValues. When a connection is established, the dynamic table size for the HPACK decoder and encoder at both endpoints starts at 4,096 bytes, the initial value of the SETTINGS_HEADER_TABLE_SIZE setting. Any change to the maximum value set using SETTINGS_HEADER_TABLE_SIZE takes effect when the endpoint SettingsSync.  The HPACK encoder at that endpoint can set the dynamic table to any size up to the maximum value set by the decoder.  An HPACK encoder declares the size of the dynamic table with a Dynamic Table Size Update instruction (COMPRESSION). Once an endpoint acknowledges a change to SETTINGS_HEADER_TABLE_SIZE that reduces the maximum below the current size of the dynamic table, its HPACK encoder MUST start the next field block with a Dynamic Table Size Update instruction that sets the dynamic table to a size that is less than or equal to the reduced maximum; see COMPRESSION. An endpoint MUST treat a field block that follows an acknowledgment of the reduction to the maximum dynamic table size as a ConnectionErrorHandler of type COMPRESSION_ERROR if it does not start with an conformant Dynamic Table Size Update instruction. </ins> 5. A "stream" is an independent, bidirectional sequence of frames

Related discussion:
text: This reverts commit 290e381719b2fefe4e6182d3be288c48e8f5fd7e. See for most of the discussion. The key change here is to address by only requiring that the change be signaled when the table size is reduced. When I dug more into this, it's a more disruptive change, so I've made a bunch of additional changes in support of that.
I have one suggestion about a point that seems to be possible to infer from all this but is not explicitly written and may condition the sequencing of operations. Do we want to support multiple settings updates on this parameter, hence announce in the middle of a communication that we changed our local decoder size ? It seems to me that this is the case but it does not appear in the original text where it more likely sounds like the initial size. If we want to support repeated size changes from the decoder, then I agree that it's better to consider that 4096 is initial and that the setting changes it and Kazuho's wording sounds fine. But then it possibly ought to be explicitly mentioned such as: This makes sure that it's safe for an encoder to only process the settings frame once and to send a single DTSU instead of one per SETTINGS frame.
NAME I struggled a little with your text, because I think that is what this already says. However, to address your question about settings changes, I don't think that we do really want multiple settings changes, but that is the protocol we have. So multiple settings changes are possible and implied by the design of SETTINGS. Multiple changes are possible within the same SETTINGS frame, in case you were interested. The designers of this protocol seemed to love unnecessary complexity. There are some good reasons, but it's not clear that those reasons are sufficiently strong to justify the headaches they cause. I would really like it if implementations could just signal once in the preface, handle the preface from their peer and be done with settings. That's how HTTP/3 works and while we might have been forced into it there by the complexities of the QUIC integration, it turned out to be a good outcome in my view. Here, however, we need to deal with the fact that the protocol permits changes.