Script updating gh-pages from 36eba03. [ci skip]

http/hard_to_change_frames/draft-ietf-quic-http.html

@@ -1286,7 +1286,7 @@ <h1 id="rfc.section.9">
 <p id="rfc.section.9.p.2">This applies to the protocol elements defined in this document.  This does not affect the existing options for extending HTTP, such as defining new methods, status codes, or header fields.</p>
 <p id="rfc.section.9.p.3">Extensions are permitted to use new frame types (<a href="#frames" class="xref">Section 7.2</a>), new settings (<a href="#settings-parameters" class="xref">Section 7.2.4.1</a>), new error codes (<a href="#errors" class="xref">Section 8</a>), or new unidirectional stream types (<a href="#unidirectional-streams" class="xref">Section 6.2</a>).  Registries are established for managing these extension points: frame types (<a href="#iana-frames" class="xref">Section 11.2</a>), settings (<a href="#iana-settings" class="xref">Section 11.3</a>), error codes (<a href="#iana-error-codes" class="xref">Section 11.4</a>), and stream types (<a href="#iana-stream-types" class="xref">Section 11.5</a>).</p>
 <p id="rfc.section.9.p.4">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, such as the SETTINGS frame as the first frame of the control stream (see <a href="#control-streams" class="xref">Section 6.2.1</a>), an unknown frame type does not satisfy that requirement and SHOULD be treated as an error.</p>
-<p id="rfc.section.9.p.5">Extensions that could change the semantics of existing protocol components MUST be negotiated before being used.  For example, an extension that changes the layout of the HEADERS frame cannot be used until the peer has given a positive signal that this is acceptable.  Coordinating when such a revised layout comes into effect could prove complex.  As such, allocating a new identifiers for alternate versions of existing protocol elements is likely to be more effective.</p>
+<p id="rfc.section.9.p.5">Extensions that could change the semantics of existing protocol components MUST be negotiated before being used.  For example, an extension that changes the layout of the HEADERS frame cannot be used until the peer has given a positive signal that this is acceptable.  Coordinating when such a revised layout comes into effect could prove complex.  As such, allocating new identifiers for alternate versions of existing protocol elements is likely to be more effective.</p>
 <p id="rfc.section.9.p.6">This document doesn&#8217;t mandate a specific method for negotiating the use of an extension but notes that a setting (<a href="#settings-parameters" class="xref">Section 7.2.4.1</a>) could be used for that purpose.  If both peers set a value that indicates willingness to use the extension, then the extension can be used.  If a setting is used for extension negotiation, the default value MUST be defined in such a fashion that the extension is disabled if the setting is omitted.</p>
 <h1 id="rfc.section.10">
 <a href="#rfc.section.10">10.</a> <a href="#security-considerations" id="security-considerations">Security Considerations</a>

http/hard_to_change_frames/draft-ietf-quic-http.txt

@@ -1984,9 +1984,8 @@ Internet-Draft                   HTTP/3                    November 2019
    extension that changes the layout of the HEADERS frame cannot be used
    until the peer has given a positive signal that this is acceptable.
    Coordinating when such a revised layout comes into effect could prove
-   complex.  As such, allocating a new identifiers for alternate
-   versions of existing protocol elements is likely to be more
-   effective.
+   complex.  As such, allocating new identifiers for alternate versions
+   of existing protocol elements is likely to be more effective.
 
    This document doesn't mandate a specific method for negotiating the
    use of an extension but notes that a setting (Section 7.2.4.1) could
@@ -2010,6 +2009,7 @@ Internet-Draft                   HTTP/3                    November 2019
    Where HTTP/2 employs PADDING frames and Padding fields in other
    frames to make a connection more resistant to traffic analysis,
    HTTP/3 can either rely on transport-layer padding or employ the
+   reserved frame and stream types discussed in Section 7.2.9 and
 
 
 
@@ -2018,7 +2018,6 @@ Bishop                    Expires May 11, 2020                 [Page 36]
 Internet-Draft                   HTTP/3                    November 2019
 
 
-   reserved frame and stream types discussed in Section 7.2.9 and
    Section 6.2.3.  These methods of padding produce different results in
    terms of the granularity of padding, the effect of packet loss and
    recovery, and how an implementation might control padding.
@@ -2069,6 +2068,7 @@ Internet-Draft                   HTTP/3                    November 2019
 
 
 
+
 Bishop                    Expires May 11, 2020                 [Page 37]
 
 Internet-Draft                   HTTP/3                    November 2019