Original text:
The SETTINGS frame (type=0x4) conveys configuration parameters that affect how endpoints communicate, such as preferences and constraints on peer behavior.  The SETTINGS frame is also used to acknowledge the <del> receipt of those parameters.  Individually, a SETTINGS parameter can also be referred to as a "setting". </del>  <del> SETTINGS parameters are not negotiated; they describe characteristics of the sending peer, which are used by the receiving peer.  Different values for the same parameter can be advertised by each peer.  For example, a client might set a high initial flow-control window, whereas a server might set a lower value to conserve resources. </del>  A SETTINGS frame MUST be sent by both endpoints at the start of a connection and MAY be sent at any other time by either endpoint over the lifetime of the connection.  Implementations MUST support all of <del> the parameters defined by this specification. </del>  Each parameter in a SETTINGS frame replaces any existing value for <del> that parameter.  Parameters are processed in the order in which they </del>  appear, and a receiver of a SETTINGS frame does not need to maintain <del> any state other than the current value of its parameters.  Therefore, </del>  the value of a SETTINGS parameter is the last value that is seen by a receiver. <del> SETTINGS parameters are acknowledged by the receiving peer.  To enable this, the SETTINGS frame defines the following flag: </del>  SETTINGS frames always apply to a connection, never a single stream. The stream identifier for a SETTINGS frame MUST be zero (0x0).  If an

Reviewer comments:
In the spirit of the naming simplications of the recent HTTP changes, we can talk about settings in this revision. This aligns better with HTTP/3, though that still uses "settings parameters" (with that ugly double-plural). cc NAME
I mean, it's not too late to Auth48 the same change into H3.... Not quite, anyway.

Revised text:
The SETTINGS frame (type=0x4) conveys configuration parameters that affect how endpoints communicate, such as preferences and constraints on peer behavior.  The SETTINGS frame is also used to acknowledge the  <ins> receipt of those settings.  Individually, a configuration parameter from a SETTINGS frame is referred to as a "setting". </ins>  <ins> Settings are not negotiated; they describe characteristics of the sending peer, which are used by the receiving peer.  Different values for the same setting can be advertised by each peer.  For example, a client might set a high initial flow-control window, whereas a server might set a lower value to conserve resources. </ins> A SETTINGS frame MUST be sent by both endpoints at the start of a connection and MAY be sent at any other time by either endpoint over the lifetime of the connection.  Implementations MUST support all of  <ins> the settings defined by this specification. </ins> Each parameter in a SETTINGS frame replaces any existing value for  <ins> that parameter.  Settings are processed in the order in which they </ins> appear, and a receiver of a SETTINGS frame does not need to maintain  <ins> any state other than the current value of each setting.  Therefore, </ins> the value of a SETTINGS parameter is the last value that is seen by a receiver.  <ins> SETTINGS frames are acknowledged by the receiving peer.  To enable this, the SETTINGS frame defines the ACK flag: </ins> SETTINGS frames always apply to a connection, never a single stream. The stream identifier for a SETTINGS frame MUST be zero (0x0).  If an