Script updating gh-pages from cda3547. [ci skip]

ianswett-max-streams/draft-ietf-quic-transport.html

@@ -1291,7 +1291,7 @@ <h2 id="rfc.section.4.4">
 <h2 id="rfc.section.4.5">
 <a href="#rfc.section.4.5">4.5.</a> <a href="#controlling-concurrency" id="controlling-concurrency">Controlling Concurrency</a>
 </h2>
-<p id="rfc.section.4.5.p.1">An endpoint limits the cumulative number of incoming streams a peer can open.  Only streams with a stream ID less than (max_stream * 4 + initial_stream_id_for_type) can be opened (see <a href="#long-packet-types" class="xref">Table 5</a>).  Initial limits are set in the transport parameters (see <a href="#transport-parameter-definitions" class="xref">Section 18.1</a>) and subsequently limits are advertised using MAX_STREAMS frames (<a href="#frame-max-streams" class="xref">Section 19.11</a>). Separate limits apply to unidirectional and bidirectional streams.  If the maximum stream ID that can be opened is greater than 2^62 - 1, then the receiver MUST interpret it as no stream limit and the receiver MUST NOT close the connection.</p>
+<p id="rfc.section.4.5.p.1">An endpoint limits the cumulative number of incoming streams a peer can open.  Only streams with a stream ID less than (max_stream * 4 + initial_stream_id_for_type) can be opened (see <a href="#long-packet-types" class="xref">Table 5</a>).  Initial limits are set in the transport parameters (see <a href="#transport-parameter-definitions" class="xref">Section 18.1</a>) and subsequently limits are advertised using MAX_STREAMS frames (<a href="#frame-max-streams" class="xref">Section 19.11</a>). Separate limits apply to unidirectional and bidirectional streams.  When a MAX_STREAMS frame permits more streams than can be expressed by the stream ID (i.e. greater than 2^60 - 1), all valid Stream IDs of that type can be used.</p>
 <p id="rfc.section.4.5.p.2">Endpoints MUST NOT exceed the limit set by their peer.  An endpoint that receives a STREAM frame with a stream ID exceeding the limit it has sent MUST treat this as a stream error of type STREAM_LIMIT_ERROR (<a href="#error-handling" class="xref">Section 11</a>).</p>
 <p id="rfc.section.4.5.p.3">A receiver cannot renege on an advertisement. That is, once a receiver advertises a stream limit using the MAX_STREAMS frame, advertising a smaller limit has no effect.  A receiver MUST ignore any MAX_STREAMS frame that does not increase the stream limit.</p>
 <p id="rfc.section.4.5.p.4">As with stream and connection flow control, this document leaves when and how many streams to advertise to a peer via MAX_STREAMS to implementations.  Implementations might choose to increase limits as streams close to keep the number of streams available to peers roughly consistent.</p>

ianswett-max-streams/draft-ietf-quic-transport.txt

@@ -1217,9 +1217,9 @@ Internet-Draft           QUIC Transport Protocol           February 2019
    limits are set in the transport parameters (see Section 18.1) and
    subsequently limits are advertised using MAX_STREAMS frames
    (Section 19.11).  Separate limits apply to unidirectional and
-   bidirectional streams.  If the maximum stream ID that can be opened
-   is greater than 2^62 - 1, then the receiver MUST interpret it as no
-   stream limit and the receiver MUST NOT close the connection.
+   bidirectional streams.  When a MAX_STREAMS frame permits more streams
+   than can be expressed by the stream ID (i.e. greater than 2^60 - 1),
+   all valid Stream IDs of that type can be used.
 
    Endpoints MUST NOT exceed the limit set by their peer.  An endpoint
    that receives a STREAM frame with a stream ID exceeding the limit it