Script updating gh-pages from 29988cd. [ci skip]

Author: ID Bot

335-mikes-review/draft-ietf-oauth-status-list.html

@@ -1643,7 +1643,7 @@ <h2 id="name-terminology">
         <dd class="break"></dd>
 <dt id="section-3-1.11">Status:</dt>
         <dd style="margin-left: 1.5em" id="section-3-1.12">
-          <p id="section-3-1.12.1">The validity state of a Referenced Token as determined by the Issuer of said Token.<a href="#section-3-1.12.1" class="pilcrow">¶</a></p>
+          <p id="section-3-1.12.1">A Status describes the current state, mode, condition or stage of an entity that is represented by the Referenced Token as determined by the Status Issuer.<a href="#section-3-1.12.1" class="pilcrow">¶</a></p>
 </dd>
         <dd class="break"></dd>
 <dt id="section-3-1.13">Status List:</dt>
@@ -2410,7 +2410,7 @@ <h2 id="name-verification-and-processing">
         <h3 id="name-status-list-request">
 <a href="#section-8.1" class="section-number selfRef">8.1. </a><a href="#name-status-list-request" class="section-name selfRef">Status List Request</a>
         </h3>
-<p id="section-8.1-1">The default Status List request and response mechanism uses normal HTTP semantics and Content negotiation etc. as defined in <span>[<a href="#RFC9110" class="cite xref">RFC9110</a>]</span>.<a href="#section-8.1-1" class="pilcrow">¶</a></p>
+<p id="section-8.1-1">The default Status List request and response mechanism uses HTTP semantics and Content negotiation as defined in <span>[<a href="#RFC9110" class="cite xref">RFC9110</a>]</span>.<a href="#section-8.1-1" class="pilcrow">¶</a></p>
 <p id="section-8.1-2">The Status Provider <span class="bcp14">SHOULD</span> return the Status List Token in response to an HTTP GET request to the URI provided in the Referenced Token, unless the Relying Party and the Status Provider have alternative methods of distribution.<a href="#section-8.1-2" class="pilcrow">¶</a></p>
 <p id="section-8.1-3">The HTTP endpoint <span class="bcp14">SHOULD</span> support the use of Cross-Origin Resource Sharing (CORS) <span>[<a href="#CORS" class="cite xref">CORS</a>]</span> and/or other methods as appropriate to enable Browser-based clients to access it, unless ecosystems using this specification choose not to support Browser-based clients.<a href="#section-8.1-3" class="pilcrow">¶</a></p>
 <p id="section-8.1-4">The Relying Party <span class="bcp14">SHOULD</span> send the following Accept HTTP Header to indicate the requested response type unless the Content-Type of Status List Tokens in the respective ecosystem is known or the Relying Party supports both formats:<a href="#section-8.1-4" class="pilcrow">¶</a></p>

335-mikes-review/draft-ietf-oauth-status-list.txt

@@ -370,8 +370,9 @@ Table of Contents
       fetches the corresponding Status List Token to validate the status
       of that Referenced Token.  Also known as a Verifier.
 
-   Status:  The validity state of a Referenced Token as determined by
-      the Issuer of said Token.
+   Status:  A Status describes the current state, mode, condition or
+      stage of an entity that is represented by the Referenced Token as
+      determined by the Status Issuer.
 
    Status List:  An object in JSON or CBOR representation containing a
       compressed byte array that represents the statuses of many
@@ -1152,8 +1153,8 @@ d2                              # tag(18)
 
 8.1.  Status List Request
 
-   The default Status List request and response mechanism uses normal
-   HTTP semantics and Content negotiation etc. as defined in [RFC9110].
+   The default Status List request and response mechanism uses HTTP
+   semantics and Content negotiation as defined in [RFC9110].
 
    The Status Provider SHOULD return the Status List Token in response
    to an HTTP GET request to the URI provided in the Referenced Token,