Change:
This PR covers questions asked during Auth48 which aren'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:
Either A or B is better, but I have no preference.
Fixed in , but GitHub won't automatically close until it hits .

Discussion:
<del> Hypertext Transfer Protocol Version 3 (HTTP/3) </del> <ins> HTTP/3 </ins> Abstract

with a value of '*'; see Section 7.1 of SEMANTICS. All HTTP/3 requests MUST include exactly one value for the ":method", <del> ":scheme", and ":path" pseudo-header fields, unless it is a CONNECT request; see connect. </del> <ins> ":scheme", and ":path" pseudo-header fields, unless the request is a CONNECT request; see connect. </ins> If the ":scheme" pseudo-header field identifies a scheme that has a mandatory authority component (including "http" and "https"), the

cancelling a request it has already begun processing. Implementations SHOULD cancel requests by abruptly terminating any <del> 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. </del> <ins> 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. </ins> When the server cancels a request without performing any application processing, the request is considered "rejected".  The server SHOULD

stream, HTTP/3 does not make use of this feature. QUIC streams can be either unidirectional, carrying data only from <del> 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. </del> <ins> 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. </ins> When HTTP fields and data are sent over QUIC, the QUIC layer handles most of the stream management.  HTTP does not need to do any separate

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 <del> 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. </del> <ins> use. 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. </ins> Note that an endpoint is not required to grant additional credits to create more unidirectional streams if its peer consumes all the

The entries in iana-setting-table are registered by this document. <ins> For fomatting reasons, setting names can be abbreviated by removing the 'SETTING_' prefix. </ins> Each code of the format 0x1f * N + 0x21 for non-negative integer values of N (that is, 0x21, 0x40, ..., through 0x3ffffffffffffffe) MUST NOT be assigned by IANA and MUST NOT appear in the listing of