Script updating gh-pages from 5bc5864. [ci skip]

draft-ietf-quic-http.html

@@ -1122,12 +1122,16 @@ <h4 id="rfc.section.7.2.4.1">
 <p id="rfc.section.7.2.4.1.p.4">Because the setting has no defined meaning, the value of the setting can be any value the implementation selects.</p>
 <p id="rfc.section.7.2.4.1.p.5">Additional settings can be defined by extensions to HTTP/3; see <a href="#extensions" class="xref">Section 9</a> for more details.</p>
 <h4 id="rfc.section.7.2.4.2">
-<a href="#rfc.section.7.2.4.2">7.2.4.2.</a> <a href="#initialization" id="initialization">Initialization</a>
+<a href="#rfc.section.7.2.4.2">7.2.4.2.</a> <a href="#settings-initialization" id="settings-initialization">Initialization</a>
 </h4>
-<p id="rfc.section.7.2.4.2.p.1">An HTTP implementation MUST NOT send frames or requests which would be invalid based on its current understanding of the peer&#8217;s settings.  All settings begin at an initial value, and are updated upon receipt of a SETTINGS frame.  For servers, the initial value of each client setting is the default value.</p>
-<p id="rfc.section.7.2.4.2.p.2">For clients using a 1-RTT QUIC connection, the initial value of each server setting is the default value. When a 0-RTT QUIC connection is being used, the initial value of each server setting is the value used in the previous session.  Clients MUST store the settings the server provided in the session being resumed and MUST comply with stored settings until the current server settings are received.  A client can use these initial values to send requests before the server&#8217;s SETTINGS frame has arrived.  This removes the need for a client to wait for the SETTINGS frame before sending requests.</p>
-<p id="rfc.section.7.2.4.2.p.3">A server can remember the settings that it advertised, or store an integrity-protected copy of the values in the ticket and recover the information when accepting 0-RTT data. A server uses the HTTP/3 settings values in determining whether to accept 0-RTT data.</p>
-<p id="rfc.section.7.2.4.2.p.4">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 MAY omit settings from its SETTINGS frame which are unchanged from the initial value.</p>
+<p id="rfc.section.7.2.4.2.p.1">An HTTP implementation MUST NOT send frames or requests which would be invalid based on its current understanding of the peer&#8217;s settings.</p>
+<p id="rfc.section.7.2.4.2.p.2">All settings begin at an initial value.  Each endpoint SHOULD use these initial values to send messages before the peer&#8217;s SETTINGS frame has arrived, as packets carrying the settings can be lost or delayed.  When the SETTINGS frame arrives, any settings are changed to their new values.</p>
+<p id="rfc.section.7.2.4.2.p.3">This removes the need to wait for the SETTINGS frame before sending messages.  Endpoints MUST NOT require any data to be received from the peer prior to sending the SETTINGS frame; settings MUST be sent as soon as the transport is ready to send data.</p>
+<p id="rfc.section.7.2.4.2.p.4">For servers, the initial value of each client setting is the default value.</p>
+<p id="rfc.section.7.2.4.2.p.5">For clients using a 1-RTT QUIC connection, the initial value of each server setting is the default value.  1-RTT keys will always become available prior to SETTINGS arriving, even if the server sends SETTINGS immediately. Clients SHOULD NOT wait indefinitely for SETTINGS to arrive before sending requests, but SHOULD process received datagrams in order to increase the likelihood of processing SETTINGS before sending the first request.</p>
+<p id="rfc.section.7.2.4.2.p.6">When a 0-RTT QUIC connection is being used, the initial value of each server setting is the value used in the previous session. Clients SHOULD store the settings the server provided in the connection where resumption information was provided, but MAY opt not to store settings in certain cases (e.g., if the session ticket is received before the SETTINGS frame). A client MUST comply with stored settings &#8211; or default values, if no values are stored &#8211; when attempting 0-RTT. Once a server has provided new settings, clients MUST comply with those values.</p>
+<p id="rfc.section.7.2.4.2.p.7">A server can remember the settings that it advertised, or store an integrity-protected copy of the values in the ticket and recover the information when accepting 0-RTT data. A server uses the HTTP/3 settings values in determining whether to accept 0-RTT data.  If the server cannot determine that the settings remembered by a client are compatible with its current settings, it MUST NOT accept 0-RTT data.  Remembered settings are compatible if a client complying with those settings would not violate the server&#8217;s current settings.</p>
+<p id="rfc.section.7.2.4.2.p.8">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 their default values.  If a server accepts 0-RTT, but then sends a SETTINGS frame which reduces a setting the client understands or omits a value that was previously specified to have a non-default value, this MUST be treated as a connection error of type HTTP_SETTINGS_ERROR.</p>
 <h3 id="rfc.section.7.2.5">
 <a href="#rfc.section.7.2.5">7.2.5.</a> <a href="#frame-push-promise" id="frame-push-promise">PUSH_PROMISE</a>
 </h3>
@@ -1251,7 +1255,7 @@ <h2 id="rfc.section.8.1">
 <dt>HTTP_ID_ERROR (0x109):</dt>
 <dd style="margin-left: 8">A Stream ID or Push ID was used incorrectly, such as exceeding a limit, reducing a limit, or being reused.</dd>
 <dt>HTTP_SETTINGS_ERROR (0x10A):</dt>
-<dd style="margin-left: 8">An endpoint detected an error in the payload of a SETTINGS frame: a duplicate setting was detected, a client-only setting was sent by a server, or a server-only setting by a client.</dd>
+<dd style="margin-left: 8">An endpoint detected an error in the payload of a SETTINGS frame.</dd>
 <dt>HTTP_MISSING_SETTINGS (0x10B):</dt>
 <dd style="margin-left: 8">No SETTINGS frame was received at the beginning of the control stream.</dd>
 <dt>HTTP_REQUEST_REJECTED (0x10C):</dt>
@@ -1807,7 +1811,7 @@ <h3 id="rfc.appendix.A.2.4">
 <h2 id="rfc.appendix.A.3">
 <a href="#rfc.appendix.A.3">A.3.</a> <a href="#h2-settings" id="h2-settings">HTTP/2 SETTINGS Parameters</a>
 </h2>
-<p id="rfc.section.A.3.p.1">An important difference from HTTP/2 is that settings are sent once, at the beginning of the connection, and thereafter cannot change.  This eliminates many corner cases around synchronization of changes.</p>
+<p id="rfc.section.A.3.p.1">An important difference from HTTP/2 is that settings are sent once, as the first frame of the control stream, and thereafter cannot change.  This eliminates many corner cases around synchronization of changes.</p>
 <p id="rfc.section.A.3.p.2">Some transport-level options that HTTP/2 specifies via the SETTINGS frame are superseded by QUIC transport parameters in HTTP/3. The HTTP-level options that are retained in HTTP/3 have the same value as in HTTP/2.</p>
 <p id="rfc.section.A.3.p.3">Below is a listing of how each HTTP/2 SETTINGS parameter is mapped:</p>
 <p></p>
@@ -1828,6 +1832,7 @@ <h2 id="rfc.appendix.A.3">
 </dl>
 <p id="rfc.section.A.3.p.5">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 use the full 32-bit space.  Settings ported from HTTP/2 might choose to redefine the format of their settings to avoid using the 62-bit encoding.</p>
 <p id="rfc.section.A.3.p.6">Settings need to be defined separately for HTTP/2 and HTTP/3. The IDs of settings defined in <a href="#HTTP2" class="xref">[HTTP2]</a> have been reserved for simplicity.  Note that the settings identifier space in HTTP/3 is substantially larger (62 bits versus 16 bits), so many HTTP/3 settings have no equivalent HTTP/2 code point. See <a href="#iana-settings" class="xref">Section 11.4</a>.</p>
+<p id="rfc.section.A.3.p.7">As QUIC streams might arrive out-of-order, endpoints are advised to not wait for the peers&#8217; settings to arrive before responding to other streams.  See <a href="#settings-initialization" class="xref">Section 7.2.4.2</a>.</p>
 <h2 id="rfc.appendix.A.4">
 <a href="#rfc.appendix.A.4">A.4.</a> <a href="#http2-error-codes" id="http2-error-codes">HTTP/2 Error Codes</a>
 </h2>