Script updating gh-pages from 355d1e5. [ci skip]

ianswett-pto-per-pn-space/draft-ietf-quic-http.html

@@ -384,7 +384,7 @@
 
   <meta name="dct.creator" content="Bishop, M., Ed." />
   <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-quic-http-latest" />
-  <meta name="dct.issued" scheme="ISO8601" content="2019-10-31" />
+  <meta name="dct.issued" scheme="ISO8601" content="2019-11-01" />
   <meta name="dct.abstract" content="The QUIC transport protocol has several features that are desirable in a transport for HTTP, such as stream multiplexing, per-stream flow control, and low-latency connection establishment.  This document describes a mapping of HTTP semantics over QUIC.  This document also identifies HTTP/2 features that are subsumed by QUIC, and describes how HTTP/2 extensions can be ported to HTTP/3." />
   <meta name="description" content="The QUIC transport protocol has several features that are desirable in a transport for HTTP, such as stream multiplexing, per-stream flow control, and low-latency connection establishment.  This document describes a mapping of HTTP semantics over QUIC.  This document also identifies HTTP/2 features that are subsumed by QUIC, and describes how HTTP/2 extensions can be ported to HTTP/3." />
 
@@ -405,10 +405,10 @@
 </tr>
 <tr>
 <td class="left">Intended status: Standards Track</td>
-<td class="right">October 31, 2019</td>
+<td class="right">November 01, 2019</td>
 </tr>
 <tr>
-<td class="left">Expires: May 3, 2020</td>
+<td class="left">Expires: May 4, 2020</td>
 <td class="right"></td>
 </tr>
 
@@ -428,7 +428,7 @@ <h1 id="rfc.status"><a href="#rfc.status">Status of This Memo</a></h1>
 <p>This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.</p>
 <p>Internet-Drafts are working documents of the Internet Engineering Task Force (IETF).  Note that other groups may also distribute working documents as Internet-Drafts.  The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.</p>
 <p>Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time.  It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."</p>
-<p>This Internet-Draft will expire on May 3, 2020.</p>
+<p>This Internet-Draft will expire on May 4, 2020.</p>
 <h1 id="rfc.copyrightnotice"><a href="#rfc.copyrightnotice">Copyright Notice</a></h1>
 <p>Copyright (c) 2019 IETF Trust and the persons identified as the document authors.  All rights reserved.</p>
 <p>This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document.  Please review these documents carefully, as they describe your rights and restrictions with respect to this document.  Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.</p>
@@ -1136,7 +1136,7 @@ <h4 id="rfc.section.7.2.4.2">
 <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 H3_SETTINGS_ERROR.</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 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 then sends a SETTINGS frame that omits a setting value that the client understands (apart from reserved setting identifiers) that was previously specified to have a non-default value, this MUST be treated as a connection error of type H3_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>
@@ -1666,12 +1666,12 @@ <h2 id="rfc.references.1">
 <tr>
 <td class="reference"><b id="QPACK">[QPACK]</b></td>
 <td class="top">
-<a title="Google, Inc">Krasic, C.</a>, <a title="Akamai Technologies">Bishop, M.</a> and <a title="Facebook">A. Frindell</a>, "<a href="https://tools.ietf.org/html/draft-ietf-quic-qpack">QPACK: Header Compression for HTTP over QUIC</a>", Internet-Draft draft-ietf-quic-qpack, October 2019.</td>
+<a title="Google, Inc">Krasic, C.</a>, <a title="Akamai Technologies">Bishop, M.</a> and <a title="Facebook">A. Frindell</a>, "<a href="https://tools.ietf.org/html/draft-ietf-quic-qpack">QPACK: Header Compression for HTTP over QUIC</a>", Internet-Draft draft-ietf-quic-qpack, November 2019.</td>
 </tr>
 <tr>
 <td class="reference"><b id="QUIC-TRANSPORT">[QUIC-TRANSPORT]</b></td>
 <td class="top">
-<a title="Fastly">Iyengar, J.</a> and <a title="Mozilla">M. Thomson</a>, "<a href="https://tools.ietf.org/html/draft-ietf-quic-transport">QUIC: A UDP-Based Multiplexed and Secure Transport</a>", Internet-Draft draft-ietf-quic-transport, October 2019.</td>
+<a title="Fastly">Iyengar, J.</a> and <a title="Mozilla">M. Thomson</a>, "<a href="https://tools.ietf.org/html/draft-ietf-quic-transport">QUIC: A UDP-Based Multiplexed and Secure Transport</a>", Internet-Draft draft-ietf-quic-transport, November 2019.</td>
 </tr>
 <tr>
 <td class="reference"><b id="RFC0793">[RFC0793]</b></td>
@@ -1763,6 +1763,8 @@ <h2 id="rfc.appendix.A.1">
 <a href="#rfc.appendix.A.1">A.1.</a> <a href="#h2-streams" id="h2-streams">Streams</a>
 </h2>
 <p id="rfc.section.A.1.p.1">HTTP/3 permits use of a larger number of streams (2^62-1) than HTTP/2.  The considerations about exhaustion of stream identifier space apply, though the space is significantly larger such that it is likely that other limits in QUIC are reached first, such as the limit on the connection flow control window.</p>
+<p id="rfc.section.A.1.p.2">In contrast to HTTP/2, stream concurrency in HTTP/3 is managed by QUIC.  QUIC considers a stream closed when all data has been received and sent data has been acknowledged by the peer.  HTTP/2 considers a stream closed when the frame containing the END_STREAM bit has been committed to the transport. As a result, the stream for an equivalent exchange could remain &#8220;active&#8221; for a longer period of time.  HTTP/3 servers might choose to permit a larger number of concurrent client-initiated bidirectional streams to achieve equivalent concurrency to HTTP/2, depending on the expected usage patterns.</p>
+<p id="rfc.section.A.1.p.3">Due to the presence of other unidirectional stream types, HTTP/3 does not rely exclusively on the number of concurrent unidirectional streams to control the number of concurrent in-flight pushes.  Instead, HTTP/3 clients use the MAX_PUSH_ID frame to control the number of pushes received from an HTTP/3 server.</p>
 <h2 id="rfc.appendix.A.2">
 <a href="#rfc.appendix.A.2">A.2.</a> <a href="#h2-frames" id="h2-frames">HTTP Frame Types</a>
 </h2>