Fix nits; remove references to SETTINGS from QPACK

draft-ietf-quic-http.md

@@ -390,7 +390,7 @@ A receiver MAY treat the presence of duplicate setting identifiers as a
 connection error of type HTTP_SETTINGS_ERROR.
 
 Each parameter consists of a setting identifier and a value, both encoded as
-QUCI variable-length integers, as shown in {{fig-ext-settings}}. A settings
+QUIC variable-length integers, as shown in {{fig-ext-settings}}. A settings
 block consisting of all settings sent by an endpoint is encoded by concatenating
 the encodings of its settings parameters. A client sends its settings block
 as the param field of an ApplicationParameter struct with the alpn field
@@ -1083,10 +1083,6 @@ comparison between HTTP/2 and HTTP/3 frames is provided in {{h2-frames}}.
 | Reserved       | Yes            | Yes            | Yes         | {{frame-reserved}}       |
 {: #stream-frame-mapping title="HTTP/3 frames and stream type overview"}
 
-Certain frames can only occur as the first frame of a particular stream type;
-these are indicated in {{stream-frame-mapping}} with a (1).  Specific guidance
-is provided in the relevant section.
-
 Note that, unlike QUIC frames, HTTP/3 frames can span multiple packets.
 
 ## Frame Layout
@@ -1478,9 +1474,7 @@ Implementations MUST ignore unknown or unsupported values in all extensible
 protocol elements.  Implementations MUST discard frames and unidirectional
 streams that have unknown or unsupported types.  This means that any of these
 extension points can be safely used by extensions without prior arrangement or
-negotiation.  However, where a known frame type is required to be in a specific
-location, an unknown frame type does not satisfy that requirement and SHOULD be
-treated as an error.
+negotiation.
 
 Extensions that could change the semantics of existing protocol components MUST
 be negotiated before being used.  For example, an extension that changes the

draft-ietf-quic-qpack.md

@@ -479,15 +479,15 @@ it can choose to use a lower dynamic table capacity (see
 For clients using 0-RTT data in HTTP/3, the server's maximum table capacity is
 the remembered value of the setting, or zero if the value was not previously
 sent.  When the client's 0-RTT value of the SETTING is 0, the server MAY set it
-to a non-zero value in its SETTINGS frame. If the remembered value is non-zero,
-the server MUST send the same non-zero value in its SETTINGS frame.  If it
+to a non-zero value in its settings. If the remembered value is non-zero,
+the server MUST send the same non-zero value in its settings.  If it
 specifies any other value, or omits SETTINGS_QPACK_MAX_TABLE_CAPACITY from
-SETTINGS, the encoder must treat this as a connection error of type
+settings, the encoder must treat this as a connection error of type
 `HTTP_QPACK_DECODER_STREAM_ERROR`.
 
 For HTTP/3 servers and HTTP/3 clients when 0-RTT is not attempted or is
-rejected, the maximum table capacity is 0 until the encoder processes a SETTINGS
-frame with a non-zero value of SETTINGS_QPACK_MAX_TABLE_CAPACITY.
+rejected, the maximum table capacity is 0 until the encoder processes settings
+with a non-zero value of SETTINGS_QPACK_MAX_TABLE_CAPACITY.
 
 When the maximum table capacity is 0, the encoder MUST NOT insert entries into
 the dynamic table, and MUST NOT send any encoder instructions on the encoder
@@ -1103,7 +1103,7 @@ represented as a 4-bit prefix string literal, then the value, represented as an
 
 #  Configuration
 
-QPACK defines two settings which are included in the HTTP/3 SETTINGS frame.
+QPACK defines two HTTP/3 settings.
 
   SETTINGS_QPACK_MAX_TABLE_CAPACITY (0x1):
   : The default value is zero.  See {{table-dynamic}} for usage.  This is

draft-ietf-quic-transport.md

@@ -1539,7 +1539,7 @@ application protocol.
 
 Each application protocol MAY specify use of application parameters to be sent
 by one of or both the client and server. If not specified, an application
-parameter MUST NOT be sent for tht application's ALPN. For each application
+parameter MUST NOT be sent for that application's ALPN. For each application
 protocol that the client supports, it fills out an ApplicationParameter struct
 with the ALPN for that protocol in the alpn field, and the application-specific
 parameter in the param field. The ApplicationParameter structs generated