Original text:
*Note:* This registry will not exist until SEMANTICS is approved. *RFC Editor*, please remove this note prior to publication. <del> As in previous versions of HTTP, field names are strings containing a subset of ASCII characters that are compared in a case-insensitive fashion.  Properties of HTTP field names and values are discussed in more detail in Section 5.1 of SEMANTICS.  As in HTTP/2, characters in </del>  field names MUST be converted to lowercase prior to their encoding. A request or response containing uppercase characters in field names MUST be treated as malformed (malformed). 4.1.1.2. <del> HTTP/3 uses QPACK field compression as described in QPACK, a variation of HPACK that allows the flexibility to avoid compression- induced head-of-line blocking.  See that document for additional details. </del>  To allow for better compression efficiency, the "Cookie" field (RFC6265) MAY be split into separate field lines, each with one or permit these streams to open, an HTTP/3 server SHOULD configure non- zero minimum values for the number of permitted streams and the initial stream flow control window.  So as to not unnecessarily limit <del> parallelism, at least 100 requests SHOULD be permitted at a time. </del>  HTTP/3 does not use server-initiated bidirectional streams, though an extension could define a use for these streams.  Clients MUST treat

Reviewer comments:
NAME said
NAME said
Honestly, this whole sentence is a bit awkward. I'll improve that.
NAME said
I have to say, this is a little odd. HTTP requires case insensitive comparison, but by calling it out here, the juxtaposition is weird. As we force lowercase, we could just strike: "that are compared in a case-insensitive fashion"
The first is a statement of fact about what SEMANTICS requires. However, I agree that we reduce confusion and lose nothing by making the statement less explicit. Interested parties can read SEMANTICS.
Yes, the proposed text addresses my comments. Thanks for the updates.

Revised text:
*Note:* This registry will not exist until SEMANTICS is approved. *RFC Editor*, please remove this note prior to publication.  <ins> Field names are strings containing a subset of ASCII characters. Properties of HTTP field names and values are discussed in more detail in Section 5.1 of SEMANTICS.  As in HTTP/2, characters in </ins> field names MUST be converted to lowercase prior to their encoding. A request or response containing uppercase characters in field names MUST be treated as malformed (malformed). 4.1.1.2.  <ins> QPACK describes a variation of HPACK that gives an encoder some control over how much head-of-line blocking can be caused by compression.  This allows an encoder to balance compression efficiency with latency.  HTTP/3 uses QPACK to compress header and trailer sections, including the pseudo-header fields present in the header section. </ins> To allow for better compression efficiency, the "Cookie" field (RFC6265) MAY be split into separate field lines, each with one or permit these streams to open, an HTTP/3 server SHOULD configure non- zero minimum values for the number of permitted streams and the initial stream flow control window.  So as to not unnecessarily limit  <ins> parallelism, at least 100 request streams SHOULD be permitted at a time. </ins> HTTP/3 does not use server-initiated bidirectional streams, though an extension could define a use for these streams.  Clients MUST treat