Change:
Addresses most of the open RFC Editor questions.
Need to update Buck's contact information to .
Fixed in .
This is a change in the RFC Editor diff that I don't think works; pulling out for separate discussion. Original: Proposed but incorrect: The intended reading is: For... HTTP/3 servers (always, regardless of 0-RTT) and HTTP/3 clients when 0-RTT is not attempted or is rejected URL maximum table capacity is 0.
Fixed in .
Should the following text be formatted using ? See the definition at . Original: Note: Padding schemes only provide limited protection against an attacker with these capabilities, potentially only forcing an increased number of guesses to learn the length associated with a given guess. Padding schemes also work directly against compression by increasing the number of bits that are transmitted. Original: Note: Simply removing entries corresponding to the field from the dynamic table can be ineffectual if the attacker has a reliable way of causing values to be reinstalled. For example, a request to load an image in a web browser typically includes the Cookie header field (a potentially highly valued target for this sort of attack), and websites can easily force an image to be loaded, thereby refreshing the entry in the dynamic table.
Probably yes.
Fixed in .
May we update "Huffman-coded" with "Huffman encoded" in this text to match other uses? Original: They begin with a single bit flag, denoted as 'H' in this document (indicating whether the string is Huffman-coded), followed by the Length encoded as a 7-bit prefix integer, and finally Length bytes of data.
Fixed in .

Discussion:
SETTINGS, the encoder must treat this as a connection error of type QPACK_DECODER_STREAM_ERROR. <del> For HTTP/3 servers and HTTP/3 clients when 0-RTT is not attempted or is rejected, the maximum table capacity is 0 until the encoder processes a SETTINGS frame with a non-zero value of SETTINGS_QPACK_MAX_TABLE_CAPACITY. </del> <ins> For clients not using 0-RTT data (whether 0-RTT is not attempted or is rejected) and for all HTTP/3 servers, the maximum table capacity is 0 until the encoder processes a SETTINGS frame with a non-zero value of SETTINGS_QPACK_MAX_TABLE_CAPACITY. </ins> When the maximum table capacity is zero, the encoder MUST NOT insert entries into the dynamic table and MUST NOT send any encoder

HPACK defines string literals to begin on a byte boundary.  They begin with a single bit flag, denoted as 'H' in this document <del> (indicating whether the string is Huffman-coded), followed by the </del> <ins> (indicating whether the string is Huffman encoded), followed by the </ins> Length encoded as a 7-bit prefix integer, and finally Length bytes of data.  When Huffman encoding is enabled, the Huffman table from Section B of RFC7541 is used without modification and Length

only provide a limited amount of protection for the length of that content. <del> Padding schemes only provide limited protection against an </del> <ins> Note: Padding schemes only provide limited protection against an </ins> attacker with these capabilities, potentially only forcing an increased number of guesses to learn the length associated with a given guess.  Padding schemes also work directly against

merge compression contexts that the original encoder had specifically kept separate. <del> Simply removing entries corresponding to the field from the dynamic table can be ineffectual if the attacker has a reliable way of causing values to be reinstalled.  For example, a request to load an image in a web browser typically includes the Cookie header field (a potentially highly valued target for this sort of attack), and websites can easily force an image to be loaded, thereby refreshing the entry in the dynamic table. </del> 7.1.3. Implementations can also choose to protect sensitive fields by not