Draft: rfc9114

Commentary: This PR covers questions asked during Auth48 which are n't pure copyediting , but seem to have a straightforward single - location fix . Individual commits , so it 's easy to pull one out if someone disagrees . 
 In , the RFC Editor asks : All HTTP/3 requests MUST include exactly one value for the " : method " , " : scheme " , and " : path " pseudo - header fields , unless it is a CONNECT request ; see Section 4.2 . All HTTP/3 requests MUST include exactly one value for the " : method " , " : scheme " , and " : path " pseudo - header fields , except for CONNECT requests ; see Section 4.2 . All HTTP/3 requests MUST include exactly one value for the " : method " , " : scheme " , and " : path " pseudo - header fields , unless the request is a CONNECT request ; see Section 4.2 . 
 Either A or B is better , but I have no preference . 
 Fixed in , but GitHub wo n't automatically close until it hits .
Paragraph (version A):
All HTTP/3 requests MUST include exactly one value for the ":method",
":scheme", and ":path" pseudo-header fields, unless it is a CONNECT
request; see connect.
Paragraph (version B):
All HTTP/3 requests MUST include exactly one value for the ":method",
":scheme", and ":path" pseudo-header fields, unless the request is a
CONNECT request; see connect.
Paragraph (version A):
Implementations SHOULD cancel requests by abruptly terminating any
directions of a stream that are still open.  This means resetting the
sending parts of streams and aborting reading on receiving parts of
streams; see Section 2.4 of QUIC-TRANSPORT.
Paragraph (version B):
Implementations SHOULD cancel requests by abruptly terminating any
directions of a stream that are still open.  To do so, an
implementation resets the sending parts of streams and aborts reading
on the receiving parts of streams; see Section 2.4 of QUIC-TRANSPORT.
Paragraph (version A):
QUIC streams can be either unidirectional, carrying data only from
initiator to receiver, or bidirectional.  Streams can be initiated by
either the client or the server.  For more detail on QUIC streams,
see Section 2 of QUIC-TRANSPORT.
Paragraph (version B):
QUIC streams can be either unidirectional, carrying data only from
initiator to receiver, or bidirectional, carrying data in both
directions.  Streams can be initiated by either the client or the
server.  For more detail on QUIC streams, see Section 2 of QUIC-
TRANSPORT.
Paragraph (version A):
The performance of HTTP/3 connections in the early phase of their
lifetime is sensitive to the creation and exchange of data on
unidirectional streams.  Endpoints that excessively restrict the
number of streams or the flow-control window of these streams will
increase the chance that the remote peer reaches the limit early and
becomes blocked.  In particular, implementations should consider that
remote peers may wish to exercise reserved stream behavior (stream-
grease) with some of the unidirectional streams they are permitted to
use.  To avoid blocking, the transport parameters sent by both
clients and servers MUST allow the peer to create at least one
unidirectional stream for the HTTP control stream plus the number of
unidirectional streams required by mandatory extensions (three being
the minimum number required for the base HTTP/3 protocol and QPACK),
and SHOULD provide at least 1,024 bytes of flow-control credit to
each stream.
Paragraph (version B):
The performance of HTTP/3 connections in the early phase of their
lifetime is sensitive to the creation and exchange of data on
unidirectional streams.  Endpoints that excessively restrict the
number of streams or the flow-control window of these streams will
increase the chance that the remote peer reaches the limit early and
becomes blocked.  In particular, implementations should consider that
remote peers may wish to exercise reserved stream behavior (stream-
grease) with some of the unidirectional streams they are permitted to
use.
Paragraph (version B):
Each endpoint needs to create at least one unidirectional stream for
the HTTP control stream.  QPACK requires two additional
unidirectional streams, and other extensions might require further
streams.  Therefore, the transport parameters sent by both clients
and servers MUST allow the peer to create at least three
unidirectional streams.  These transport parameters SHOULD also
provide at least 1,024 bytes of flow-control credit to each
unidirectional stream.
Paragraph (version B):
For fomatting reasons, setting names can be abbreviated by removing
the 'SETTING_' prefix.