which -> that where appropriate & related nit fixes

draft-ietf-quic-http.md

@@ -161,7 +161,7 @@ consumes a single QUIC stream.  Streams are independent of each other, so one
 stream that is blocked or suffers packet loss does not prevent progress on other
 streams.
 
-Server push is an interaction mode introduced in HTTP/2 {{?HTTP2}} which permits
+Server push is an interaction mode introduced in HTTP/2 {{?HTTP2}} that permits
 a server to push a request-response exchange to a client in anticipation of the
 client making the indicated request.  This trades off network usage against a
 potential latency gain.  Several HTTP/3 frames are used to manage server push,
@@ -291,7 +291,7 @@ draft-ietf-quic-transport-25.
 
 Non-compatible experiments that are based on these draft versions MUST append
 the string "-" and an experiment name to the identifier. For example, an
-experimental implementation based on draft-ietf-quic-http-09 which reserves an
+experimental implementation based on draft-ietf-quic-http-09 that reserves an
 extra stream for unsolicited transmission of 1980s pop music might identify
 itself as "h3-09-rickroll". Note that any label MUST conform to the "token"
 syntax defined in Section 5.4.1.1 of {{!SEMANTICS}}. Experimenters are
@@ -354,7 +354,7 @@ indicated port of whatever host is identified within the authority component.
 Because HTTP/3 does not use TCP, HTTP/3 cannot be used for direct access to the
 authoritative server for a resource identified by an "http" URI.  However,
 protocol extensions such as {{!ALTSVC=RFC7838}} permit the authoritative server
-to identify other services which are also authoritative and which might be
+to identify other services that are also authoritative and that might be
 reachable over HTTP/3.
 
 Prior to making requests for an origin whose scheme is not "https", the client
@@ -464,7 +464,7 @@ A server MAY send one or more PUSH_PROMISE frames (see {{frame-push-promise}})
 before, after, or interleaved with the frames of a response message. These
 PUSH_PROMISE frames are not part of the response; see {{server-push}} for more
 details.  These frames are not permitted in pushed responses; a pushed response
-which includes PUSH_PROMISE frames MUST be treated as a connection error of type
+that includes PUSH_PROMISE frames MUST be treated as a connection error of type
 H3_FRAME_UNEXPECTED.
 
 Frames of unknown types ({{extensions}}), including reserved frames
@@ -612,7 +612,7 @@ 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}}.
 
-If the ":scheme" pseudo-header field identifies a scheme which has a mandatory
+If the ":scheme" pseudo-header field identifies a scheme that has a mandatory
 authority component (including "http" and "https"), the request MUST contain
 either an ":authority" pseudo-header field or a "Host" header field.  If these
 fields are present, they MUST NOT be empty.  If both fields are present, they
@@ -637,7 +637,7 @@ included in an HTTP/1.1 status line.
 #### Field Compression
 
 HTTP/3 uses QPACK field compression as described in [QPACK], a variation of
-HPACK which allows the flexibility to avoid compression-induced head-of-line
+HPACK that allows the flexibility to avoid compression-induced head-of-line
 blocking.  See that document for additional details.
 
 To allow for better compression efficiency, the "Cookie" field {{!RFC6265}} MAY
@@ -660,8 +660,8 @@ in bytes plus an overhead of 32 bytes for each field.
 
 If an implementation wishes to advise its peer of this limit, it can be conveyed
 as a number of bytes in the SETTINGS_MAX_FIELD_SECTION_SIZE parameter. An
-implementation which has received this parameter SHOULD NOT send an HTTP message
-header which exceeds the indicated size, as the peer will likely refuse to
+implementation that has received this parameter SHOULD NOT send an HTTP message
+header that exceeds the indicated size, as the peer will likely refuse to
 process it.  However, because this limit is applied at each hop, messages below
 this limit are not guaranteed to be accepted.
 
@@ -679,7 +679,7 @@ In this context, "processed" means that some data from the stream was passed to
 some higher layer of software that might have taken some action as a result. The
 client can treat requests rejected by the server as though they had never been
 sent at all, thereby allowing them to be retried later on a new connection.
-Servers MUST NOT use the H3_REQUEST_REJECTED error code for requests which
+Servers MUST NOT use the H3_REQUEST_REJECTED error code for requests that
 were partially or fully processed.  When a server abandons a response after
 partial processing, it SHOULD abort its response stream with the error code
 H3_REQUEST_CANCELLED.
@@ -772,7 +772,7 @@ The TCP connection can be closed by either peer. When the client ends the
 request stream (that is, the receive stream at the proxy enters the "Data Recvd"
 state), the proxy will set the FIN bit on its connection to the TCP server. When
 the proxy receives a packet with the FIN bit set, it will terminate the send
-stream that it sends to the client. TCP connections which remain half-closed in
+stream that it sends to the client. TCP connections that remain half-closed in
 a single direction are not invalid, but are often handled poorly by servers, so
 clients SHOULD NOT close a stream for sending while they still expect to receive
 data from the target of the CONNECT.
@@ -793,15 +793,15 @@ or 101 (Switching Protocols) informational status code (Section 10.2.2 of
 
 ## Server Push
 
-Server push is an interaction mode which permits a server to push a
+Server push is an interaction mode that permits a server to push a
 request-response exchange to a client in anticipation of the client making the
 indicated request.  This trades off network usage against a potential latency
 gain.  HTTP/3 server push is similar to what is described in HTTP/2 {{?HTTP2}},
 but uses different mechanisms.
 
 Each server push is identified by a unique Push ID. This Push ID is used in one
 or more PUSH_PROMISE frames (see {{frame-push-promise}}) that carry the request
-fields, then included with the push stream which ultimately fulfills those
+fields, then included with the push stream, which ultimately fulfills those
 promises. When the same Push ID is promised on multiple request streams, the
 decompressed request field sections MUST contain the same fields in the
 same order, and both the name and the value in each field MUST be exact
@@ -816,10 +816,10 @@ with a Push ID that is greater than the maximum Push ID as a connection error of
 type H3_ID_ERROR.
 
 The header section of the request message is carried by a PUSH_PROMISE frame
-(see {{frame-push-promise}}) on the request stream which generated the push.
+(see {{frame-push-promise}}) on the request stream that generated the push.
 This allows the server push to be associated with a client request.
 
-Not all requests can be pushed.  A server MAY push requests which have the
+Not all requests can be pushed.  A server MAY push requests that have the
 following properties:
 
 - cacheable; see Section 8.2.3 of {{!SEMANTICS}}
@@ -830,7 +830,7 @@ The server MUST include a value in the ":authority" pseudo-header field for
 which the server is authoritative; see {{connection-reuse}}.
 
 Clients SHOULD send a CANCEL_PUSH frame upon receipt of a PUSH_PROMISE frame
-carrying a request which is not cacheable, is not known to be safe, that
+carrying a request that is not cacheable, is not known to be safe, that
 indicates the presence of a request body, or for which it does not consider the
 server authoritative.
 
@@ -968,7 +968,7 @@ can be cleanly shut down without losing requests.
 
 A client has more flexibility in the value it chooses for the Push ID in a
 GOAWAY that it sends.  A value of 2^62 - 1 indicates that the server can
-continue fulfilling pushes which have already been promised, and the client can
+continue fulfilling pushes that have already been promised, and the client can
 continue granting push credit as needed; see {{frame-max-push-id}}. A smaller
 value indicates the client will reject pushes with Push IDs greater than or
 equal to this value.  Like the server, the client MAY send subsequent GOAWAY
@@ -995,7 +995,7 @@ An HTTP/3 implementation can immediately close the QUIC connection at any time.
 This results in sending a QUIC CONNECTION_CLOSE frame to the peer indicating
 that the application layer has terminated the connection.  The application error
 code in this frame indicates to the peer why the connection is being closed.
-See {{errors}} for error codes which can be used when closing a connection in
+See {{errors}} for error codes that can be used when closing a connection in
 HTTP/3.
 
 Before closing the connection, a GOAWAY frame MAY be sent to allow the client to
@@ -1007,11 +1007,11 @@ clients.
 
 For various reasons, the QUIC transport could indicate to the application layer
 that the connection has terminated.  This might be due to an explicit closure
-by the peer, a transport-level error, or a change in network topology which
+by the peer, a transport-level error, or a change in network topology that
 interrupts connectivity.
 
 If a connection terminates without a GOAWAY frame, clients MUST assume that any
-request which was sent, whether in whole or in part, might have been processed.
+request that was sent, whether in whole or in part, might have been processed.
 
 
 # Stream Mapping and Usage {#stream-mapping}
@@ -1091,14 +1091,14 @@ control stream as well as the unidirectional streams required by mandatory
 extensions (such as the QPACK encoder and decoder streams) first, and then
 create additional streams as allowed by their peer.
 
-If the stream header indicates a stream type which is not supported by the
+If the stream header indicates a stream type that is not supported by the
 recipient, the remainder of the stream cannot be consumed as the semantics are
 unknown. Recipients of unknown stream types MAY abort reading of the stream with
 an error code of H3_STREAM_CREATION_ERROR, but MUST NOT consider such streams
 to be a connection error of any kind.
 
 Implementations MAY send stream types before knowing whether the peer supports
-them.  However, stream types which could modify the state or semantics of
+them.  However, stream types that could modify the state or semantics of
 existing protocol components, including QPACK or other extensions, MUST NOT be
 sent until the peer is known to support them.
 
@@ -1115,7 +1115,7 @@ Each side MUST initiate a single control stream at the beginning of the
 connection and send its SETTINGS frame as the first frame on this stream.  If
 the first frame of the control stream is any other frame type, this MUST be
 treated as a connection error of type H3_MISSING_SETTINGS. Only one control
-stream per peer is permitted; receipt of a second stream which claims to be a
+stream per peer is permitted; receipt of a second stream claiming to be a
 control stream MUST be treated as a connection error of type
 H3_STREAM_CREATION_ERROR.  The sender MUST NOT close the control stream, and
 the receiver MUST NOT request that the sender close the control stream.  If
@@ -1176,8 +1176,7 @@ either the H3_NO_ERROR error code or a reserved error code
 
 HTTP frames are carried on QUIC streams, as described in {{stream-mapping}}.
 HTTP/3 defines three stream types: control stream, request stream, and push
-stream. This section describes HTTP/3 frame formats and the streams types on
-which they are permitted; see {{stream-frame-mapping}} for an overview.  A
+stream. This section describes HTTP/3 frame formats and their permitted stream types; see {{stream-frame-mapping}} for an overview.  A
 comparison between HTTP/2 and HTTP/3 frames is provided in {{h2-frames}}.
 
 | Frame          | Control Stream | Request Stream | Push Stream | Section                  |
@@ -1231,7 +1230,7 @@ H3_FRAME_ERROR.
 
 When a stream terminates cleanly, if the last frame on the stream was truncated,
 this MUST be treated as a connection error ({{errors}}) of type
-H3_FRAME_ERROR. Streams which terminate abruptly may be reset at any point in
+H3_FRAME_ERROR. Streams that terminate abruptly may be reset at any point in
 a frame.
 
 ## Frame Definitions {#frames}
@@ -1314,7 +1313,7 @@ CANCEL_PUSH Frame {
 
 The CANCEL_PUSH frame carries a Push ID encoded as a variable-length integer.
 The Push ID identifies the server push that is being cancelled; see
-{{frame-push-promise}}.  If a CANCEL_PUSH frame is received which references a
+{{frame-push-promise}}.  If a CANCEL_PUSH frame is received that references a
 Push ID greater than currently allowed on the connection, this MUST be treated
 as a connection error of type H3_ID_ERROR.
 
@@ -1344,7 +1343,7 @@ If an endpoint receives a SETTINGS frame on a different stream, the endpoint
 MUST respond with a connection error of type H3_FRAME_UNEXPECTED.
 
 SETTINGS parameters are not negotiated; they describe characteristics of the
-sending peer, which can be used by the receiving peer. However, a negotiation
+sending peer that can be used by the receiving peer. However, a negotiation
 can be implied by the use of SETTINGS - each peer uses SETTINGS to advertise a
 set of supported values. The definition of the setting would describe how each
 peer combines the two sets to conclude which choice will be used.  SETTINGS does
@@ -1401,7 +1400,7 @@ for more details.
 
 #### Initialization {#settings-initialization}
 
-An HTTP implementation MUST NOT send frames or requests which would be invalid
+An HTTP implementation MUST NOT send frames or requests that would be invalid
 based on its current understanding of the peer's settings.
 
 All settings begin at an initial value.  Each endpoint SHOULD use these initial
@@ -1443,7 +1442,7 @@ complying with those settings would not violate the server's current settings.
 A server MAY accept 0-RTT and subsequently provide different settings in its
 SETTINGS frame. If 0-RTT data is accepted by the server, its SETTINGS frame MUST
 NOT reduce any limits or alter any values that might be violated by the client
-with its 0-RTT data.  The server MUST include all settings which differ from
+with its 0-RTT data.  The server MUST include all settings that differ from
 their default values.  If a server accepts 0-RTT but then sends settings that
 are not compatible with the previously specified settings, this MUST be treated
 as a connection error of type H3_SETTINGS_ERROR. If a server accepts 0-RTT but
@@ -1588,7 +1587,7 @@ consider these frames to have any meaning upon receipt.
 The payload and length of the frames are selected in any manner the
 implementation chooses.
 
-Frame types which were used in HTTP/2 where there is no corresponding HTTP/3
+Frame types that were used in HTTP/2 where there is no corresponding HTTP/3
 frame have also been reserved ({{iana-frames}}).  These frame types MUST NOT be
 sent, and receipt MAY be treated as an error of type H3_FRAME_UNEXPECTED.
 
@@ -1609,7 +1608,7 @@ use of an error code in an unexpected context or receipt of an unknown error
 code MUST be treated as equivalent to H3_NO_ERROR.  However, closing a stream
 can have other effects regardless of the error code; see {{request-response}}.
 
-This section describes HTTP/3-specific error codes which can be used to express
+This section describes HTTP/3-specific error codes that can be used to express
 the cause of a connection or stream error.
 
 ## HTTP/3 Error Codes {#http-error-codes}
@@ -1622,7 +1621,7 @@ H3_NO_ERROR (0x100):
   there is no error to signal.
 
 H3_GENERAL_PROTOCOL_ERROR (0x101):
-: Peer violated protocol requirements in a way which doesn't match a more
+: Peer violated protocol requirements in a way that doesn't match a more
   specific error code, or endpoint declines to use the more specific error code.
 
 H3_INTERNAL_ERROR (0x102):
@@ -1635,7 +1634,7 @@ H3_CLOSED_CRITICAL_STREAM (0x104):
 : A stream required by the connection was closed or reset.
 
 H3_FRAME_UNEXPECTED (0x105):
-: A frame was received which was not permitted in the current state or on the
+: A frame was received that was not permitted in the current state or on the
   current stream.
 
 H3_FRAME_ERROR (0x106):
@@ -1737,7 +1736,7 @@ of establishing authority are discussed in Section 12.1 of {{!SEMANTICS}}.
 The use of ALPN in the TLS and QUIC handshakes establishes the target
 application protocol before application-layer bytes are processed.  Because all
 QUIC packets are encrypted, it is difficult for an attacker to control the
-plaintext bytes of an HTTP/3 connection which could be used in a cross-protocol
+plaintext bytes of an HTTP/3 connection, which could be used in a cross-protocol
 attack on a plaintext protocol.
 
 ## Intermediary Encapsulation Attacks
@@ -1789,7 +1788,7 @@ time.
 
 Processing capacity cannot be guarded as effectively as state capacity.
 
-The ability to send undefined protocol elements which the peer is required to
+The ability to send undefined protocol elements that the peer is required to
 ignore can be abused to cause a peer to expend additional processing time.  This
 might be done by setting multiple undefined SETTINGS parameters, unknown frame
 types, or unknown stream types.  Note, however, that some uses are entirely
@@ -2194,7 +2193,7 @@ not required.  This permits the removal of the Flags field from the generic
 frame layout.
 
 Frame payloads are largely drawn from {{?HTTP2}}. However, QUIC includes many
-features (e.g., flow control) which are also present in HTTP/2. In these cases,
+features (e.g., flow control) that are also present in HTTP/2. In these cases,
 the HTTP mapping does not re-implement them. As a result, several HTTP/2 frame
 types are not required in HTTP/3. Where an HTTP/2-defined frame is no longer
 used, the frame ID has been reserved in order to maximize portability between
@@ -2229,7 +2228,7 @@ endpoints remains in sync.
 Because this total ordering is not provided by QUIC, HTTP/3 uses a modified
 version of HPACK, called QPACK.  QPACK uses a single unidirectional stream to
 make all modifications to the dynamic table, ensuring a total order of updates.
-All frames which contain encoded fields merely reference the table state at a
+All frames that contain encoded fields merely reference the table state at a
 given time without modifying it.
 
 [QPACK] provides additional details.
@@ -2244,7 +2243,7 @@ IDs). Redefinition of the encoding of extension frame types might be necessary
 if the encoding includes a Stream ID.
 
 Because the Flags field is not present in generic HTTP/3 frames, those frames
-which depend on the presence of flags need to allocate space for flags as part
+that depend on the presence of flags need to allocate space for flags as part
 of their frame payload.
 
 Other than this issue, frame type HTTP/2 extensions are typically portable to
@@ -2316,7 +2315,7 @@ SETTINGS_HEADER_TABLE_SIZE:
 : See [QPACK].
 
 SETTINGS_ENABLE_PUSH:
-: This is removed in favor of the MAX_PUSH_ID which provides a more granular
+: This is removed in favor of the MAX_PUSH_ID, which provides a more granular
   control over server push.
 
 SETTINGS_MAX_CONCURRENT_STREAMS:
@@ -2338,7 +2337,7 @@ SETTINGS_MAX_HEADER_LIST_SIZE:
 
 In HTTP/3, setting values are variable-length integers (6, 14, 30, or 62 bits
 long) rather than fixed-length 32-bit fields as in HTTP/2.  This will often
-produce a shorter encoding, but can produce a longer encoding for settings which
+produce a shorter encoding, but can produce a longer encoding for settings that
 use the full 32-bit space.  Settings ported from HTTP/2 might choose to redefine
 their value to limit it to 30 bits for more efficient encoding, or to make use
 of the 62-bit space if more than 30 bits are required.

draft-ietf-quic-invariants.md

@@ -263,7 +263,7 @@ version numbers are potentially valid.
 
 The properties described in this document apply to all versions of QUIC. A
 protocol that does not conform to the properties described in this document is
-not QUIC.  Future documents might describe additional properties which apply to
+not QUIC.  Future documents might describe additional properties that apply to
 a specific QUIC version, or to a range of QUIC versions.