Script updating gh-pages from 23ea095. [ci skip]

Author: ID Bot

link-rel-enhancement/draft-ietf-plants-merkle-tree-certs.html

@@ -5110,7 +5110,7 @@ <h3 id="name-enhancement-link-relation">
 <a href="#section-9.1" class="section-number selfRef">9.1. </a><a href="#name-enhancement-link-relation" class="section-name selfRef">Enhancement Link Relation</a>
         </h3>
 <p id="section-9.1-1">This section introduces a new link relation <span>[<a href="#RFC8288" class="cite xref">RFC8288</a>]</span>, "enhancement". It identifies an optional substitute for the original context. This substitute may be preferable in some way (e.g. it may be smaller) but is optional. Consumers that accept the substitute are expected to also accept the original context, so it is not an error if the resource is unavailable.<a href="#section-9.1-1" class="pilcrow">¶</a></p>
-<p id="section-9.1-2">This is similar to the "alternate" link relation, except that it specifies the substitute is optional. In some applications, a client may fetch all alternates, so that it may forward one of the alternates to another party. For example, <span><a href="https://rfc-editor.org/rfc/rfc8555#section-7.4.2" class="relref">Section 7.4.2</a> of [<a href="#RFC8555" class="cite xref">RFC8555</a>]</span> describes how an ACME server uses the "alternate" link relation to serve multiple certificate chains for an ACME order. An ACME client might then fetch all of them and configure them in a TLS server, which presents them to TLS clients. Different TLS clients need different chains, so the ACME client would treat any unavailable alternate as an error.<a href="#section-9.1-2" class="pilcrow">¶</a></p>
+<p id="section-9.1-2">This is similar to the "alternate" link relation, except that it specifies the substitute is optional. In some applications, a client may fetch all alternates, so that it may forward one of the alternates to another party. For example, <span><a href="https://rfc-editor.org/rfc/rfc8555#section-7.4.2" class="relref">Section 7.4.2</a> of [<a href="#RFC8555" class="cite xref">RFC8555</a>]</span> describes how an ACME server uses the "alternate" link relation to serve multiple certificate chains for an ACME order. An ACME client might then fetch all of them and configure them in a TLS server, which presents them to TLS clients. Different TLS clients need different chains, so the ACME client might reasonably treat any unavailable alternate as an error.<a href="#section-9.1-2" class="pilcrow">¶</a></p>
 <p id="section-9.1-3">This behavior is not ideal for landmark-relative certificates, which are available asynchronously and should not block deployment of their corresponding standalone certificate. The "enhancement" link relation allows an ACME server to specify which chains are necessary to fulfill the ACME order and which are optional additions.<a href="#section-9.1-3" class="pilcrow">¶</a></p>
 <p id="section-9.1-4">When serving a certificate, an ACME server MAY provide one or more link relation header fields with relation "enhancement". Each such field SHOULD express a certificate chain that the ACME server expects to be redundant with (but potentially preferable to) either the original certificate chain or one of the chains served from an "alternate" relation. If the certificate chain is not yet available, the enhancement URL MAY serve an HTTP 202 (Accepted) response, with a Retry-After header (<span><a href="https://rfc-editor.org/rfc/rfc9110#section-10.2.3" class="relref">Section 10.2.3</a> of [<a href="#RFC9110" class="cite xref">RFC9110</a>]</span>) estimating when it will become available.<a href="#section-9.1-4" class="pilcrow">¶</a></p>
 <p id="section-9.1-5">ACME clients can fetch enhancement URLs to collect additional alternate certificate chains. If the resource is unavailable, the ACME client SHOULD NOT fail the overall transaction. If the resource returns an HTTP 202 (Accepted) response, the ACME client SHOULD retry the request later, incorporating any Retry-After header, but it SHOULD NOT block deployment of other chains on this process.<a href="#section-9.1-5" class="pilcrow">¶</a></p>

link-rel-enhancement/draft-ietf-plants-merkle-tree-certs.txt

@@ -2676,8 +2676,8 @@ Table of Contents
    serve multiple certificate chains for an ACME order.  An ACME client
    might then fetch all of them and configure them in a TLS server,
    which presents them to TLS clients.  Different TLS clients need
-   different chains, so the ACME client would treat any unavailable
-   alternate as an error.
+   different chains, so the ACME client might reasonably treat any
+   unavailable alternate as an error.
 
    This behavior is not ideal for landmark-relative certificates, which
    are available asynchronously and should not block deployment of their