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

Author: ID Bot

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

@@ -5110,9 +5110,9 @@ <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 the 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 server 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-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 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-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-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>
 </section>
 </div>
@@ -5121,9 +5121,9 @@ <h3 id="name-enhancement-link-relation">
         <h3 id="name-using-acme-with-merkle-tree">
 <a href="#section-9.2" class="section-number selfRef">9.2. </a><a href="#name-using-acme-with-merkle-tree" class="section-name selfRef">Using ACME with Merkle Tree Certificates</a>
         </h3>
-<p id="section-9.2-1">When downloading the certificate (<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>), ACME clients supporting Merkle Tree certificates SHOULD send "application/pem-certificate-chain-with-properties" in their Accept header (<span><a href="https://rfc-editor.org/rfc/rfc9110#section-12.5.1" class="relref">Section 12.5.1</a> of [<a href="#RFC9110" class="cite xref">RFC9110</a>]</span>). ACME servers issuing Merkle Tree certificates SHOULD then respond with that content type and include trust anchor ID information as described in <span><a href="https://datatracker.ietf.org/doc/html/draft-ietf-tls-trust-anchor-ids-04#section-7" class="relref">Section 7</a> of [<a href="#I-D.ietf-tls-trust-anchor-ids" class="cite xref">I-D.ietf-tls-trust-anchor-ids</a>]</span>. <a href="#use-in-tls" class="auto internal xref">Section 8</a> decribes the trust anchor ID assignments for standalone and landmark-relative certificates.<a href="#section-9.2-1" class="pilcrow">¶</a></p>
+<p id="section-9.2-1">When downloading the certificate (<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>), ACME clients supporting Merkle Tree certificates SHOULD send "application/pem-certificate-chain-with-properties" in their Accept header (<span><a href="https://rfc-editor.org/rfc/rfc9110#section-12.5.1" class="relref">Section 12.5.1</a> of [<a href="#RFC9110" class="cite xref">RFC9110</a>]</span>). ACME servers issuing Merkle Tree certificates SHOULD then respond with that content type and include trust anchor ID information as described in <span><a href="https://datatracker.ietf.org/doc/html/draft-ietf-tls-trust-anchor-ids-04#section-7" class="relref">Section 7</a> of [<a href="#I-D.ietf-tls-trust-anchor-ids" class="cite xref">I-D.ietf-tls-trust-anchor-ids</a>]</span>. <a href="#use-in-tls" class="auto internal xref">Section 8</a> describes the trust anchor ID assignments for standalone and landmark-relative certificates.<a href="#section-9.2-1" class="pilcrow">¶</a></p>
 <p id="section-9.2-2">When processing an order for a Merkle Tree certificate, the ACME server moves the order to the "valid" state after the corresponding entry is sequenced in the issuance log, cosignatures are collected, and the standalone certificate is available. The order's certificate URL then serves the standalone certificate, constructed as described in <a href="#standalone-certificates" class="auto internal xref">Section 6.3</a>.<a href="#section-9.2-2" class="pilcrow">¶</a></p>
-<p id="section-9.2-3">The standalone certificate response SHOULD additionally carry an enhancement URL (<a href="#enhancement-link-relation" class="auto internal xref">Section 9.1</a>) for the landmark-relative certificate, as described <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>. Before the landmark-relative certificate is available, the enhancement URL SHOULD return a HTTP 202 (Accepted) response. Once the next landmark is allocated, the ACME server constructs a landmark-relative certificate, as described in <a href="#landmark-relative-certificates" class="auto internal xref">Section 6.4</a>, and serves it from the enhancement URL.<a href="#section-9.2-3" class="pilcrow">¶</a></p>
+<p id="section-9.2-3">The standalone certificate response SHOULD additionally carry an enhancement URL (<a href="#enhancement-link-relation" class="auto internal xref">Section 9.1</a>) for the landmark-relative certificate, as described in <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>. Before the landmark-relative certificate is available, the enhancement URL SHOULD return an HTTP 202 (Accepted) response. Once the next landmark is allocated, the ACME server constructs a landmark-relative certificate, as described in <a href="#landmark-relative-certificates" class="auto internal xref">Section 6.4</a>, and serves it from the enhancement URL.<a href="#section-9.2-3" class="pilcrow">¶</a></p>
 </section>
 </div>
 </section>
@@ -5507,7 +5507,7 @@ <h3 id="name-link-relation-type">
           <dd class="break"></dd>
 <dt id="section-13.5-2.3">Description:</dt>
           <dd style="margin-left: 1.5em" id="section-13.5-2.4">
-            <p id="section-13.5-2.4.1">Refers to an optional substitute for this context. Consumers that accept the substitute are expected to also accept this the original context, so it is not an error if the substitute is unavailable.<a href="#section-13.5-2.4.1" class="pilcrow">¶</a></p>
+            <p id="section-13.5-2.4.1">Refers to an optional substitute for this context. Consumers that accept the substitute are expected to also accept the original context, so it is not an error if the substitute is unavailable.<a href="#section-13.5-2.4.1" class="pilcrow">¶</a></p>
 </dd>
           <dd class="break"></dd>
 <dt id="section-13.5-2.5">Reference:</dt>

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

@@ -2670,10 +2670,10 @@ Table of Contents
 
    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 the one of the
+   may fetch all alternates, so that it may forward one of the
    alternates to another party.  For example, Section 7.4.2 of [RFC8555]
    describes how an ACME server uses the "alternate" link relation to
-   server multiple certificate chains for an ACME order.  An ACME client
+   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
@@ -2683,15 +2683,15 @@ Table of Contents
    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:
+   to fulfill the ACME order and which are optional additions.
 
    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 MAY serve an HTTP 202 (Accepted) response, with a
+   the enhancement URL MAY serve an HTTP 202 (Accepted) response, with a
    Retry-After header (Section 10.2.3 of [RFC9110]) estimating when it
    will become available.
 
@@ -2710,8 +2710,9 @@ Table of Contents
    (Section 12.5.1 of [RFC9110]).  ACME servers issuing Merkle Tree
    certificates SHOULD then respond with that content type and include
    trust anchor ID information as described in Section 7 of
-   [I-D.ietf-tls-trust-anchor-ids].  Section 8 decribes the trust anchor
-   ID assignments for standalone and landmark-relative certificates.
+   [I-D.ietf-tls-trust-anchor-ids].  Section 8 describes the trust
+   anchor ID assignments for standalone and landmark-relative
+   certificates.
 
    When processing an order for a Merkle Tree certificate, the ACME
    server moves the order to the "valid" state after the corresponding
@@ -2722,11 +2723,12 @@ Table of Contents
 
    The standalone certificate response SHOULD additionally carry an
    enhancement URL (Section 9.1) for the landmark-relative certificate,
-   as described Section 7.4.2 of [RFC8555].  Before the landmark-
+   as described in Section 7.4.2 of [RFC8555].  Before the landmark-
    relative certificate is available, the enhancement URL SHOULD return
-   a HTTP 202 (Accepted) response.  Once the next landmark is allocated,
-   the ACME server constructs a landmark-relative certificate, as
-   described in Section 6.4, and serves it from the enhancement URL.
+   an HTTP 202 (Accepted) response.  Once the next landmark is
+   allocated, the ACME server constructs a landmark-relative
+   certificate, as described in Section 6.4, and serves it from the
+   enhancement URL.
 
 10.  Deployment Considerations
 
@@ -3358,8 +3360,8 @@ Table of Contents
 
    Description:  Refers to an optional substitute for this context.
       Consumers that accept the substitute are expected to also accept
-      this the original context, so it is not an error if the substitute
-      is unavailable.
+      the original context, so it is not an error if the substitute is
+      unavailable.
 
    Reference:  [this-RFC], Section 9.1