Draft: rfc9114

Commentary: Removed one HTTP/2 reference which seems extraneous , and corrected the polarity of another . This by doing almost nothing ; speak now if you think more is warranted . 
 RFC Editor says : But fair enough -- are we overdoing it ? 
 Having looked at the references , they all seem reasonable with the possible exception of PUSH_PROMISE noting it behaves " as in HTTP/2 . " Most references to HTTP/2 occur either in the first two sections of the document or in the Appendix which specifically discusses the relationship between HTTP/2 and HTTP/3 . removes that one extraneous reference . Other than than , I plan to make no further changes to address this feedback unless someone wants to provide a more concrete list of places where the comparison is unnecessary . 
 Marginal : Section 4.1.1 and 4.1.1.1 seems to have some egregious use of phrasing similar to " Like HTTP/2 , ... " or " as in HTTP/2 " . You could possibly condense these to a sentence such as " Like HTTP/2 , HTTP/3 has additional considerations related to use of characters in field names , the Connect header field , and pseudo - header fields " . That could be inserted into to thefirst para of 4.1.1 , or the second para ( thus breaking the para so the next one starts with " Characters in field names " ) . 
 Fixed in .
Paragraph (version A):
HTTP messages carry metadata as a series of key-value pairs called
"HTTP fields"; see Sections RFC9110 and RFC9110 of RFC9110.  For a
listing of registered HTTP fields, see the "Hypertext Transfer
Protocol (HTTP) Field Name Registry" maintained at
<https://www.iana.org/assignments/http-fields/>.
Paragraph (version A):
Field names are strings containing a subset of ASCII characters.
Properties of HTTP field names and values are discussed in more
detail in RFC9110.  As in HTTP/2, characters in 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 .
Paragraph (version A):
Like HTTP/2, HTTP/3 does not use the Connection header field to
indicate connection-specific fields; in this protocol, connection-
specific metadata is conveyed by other means.  An endpoint MUST NOT
generate an HTTP/3 field section containing connection-specific
fields; any message containing connection-specific fields MUST be
treated as .
Paragraph (version B):
HTTP messages carry metadata as a series of key-value pairs called
"HTTP fields"; see Sections RFC9110 and RFC9110 of RFC9110.  For a
listing of registered HTTP fields, see the "Hypertext Transfer
Protocol (HTTP) Field Name Registry" maintained at
<https://www.iana.org/assignments/http-fields/>.  Like HTTP/2, HTTP/3
has additional considerations related to the use of characters in
field names, the Connection header field, and pseudo-header fields.
Paragraph (version B):
Field names are strings containing a subset of ASCII characters.
Properties of HTTP field names and values are discussed in more
detail in RFC9110.  Characters in 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 .
Paragraph (version B):
HTTP/3 does not use the Connection header field to indicate
connection-specific fields; in this protocol, connection-specific
metadata is conveyed by other means.  An endpoint MUST NOT generate
an HTTP/3 field section containing connection-specific fields; any
message containing connection-specific fields MUST be treated as .
Paragraph (version A):
The frame (type=0x05) is used to carry a promised request header
section from server to client on a , as in HTTP/2.
Paragraph (version B):
The frame (type=0x05) is used to carry a promised request header
section from server to client on a .