<?xml version="1.0" encoding="utf-8"?>
<!-- 
     draft-rfcxml-general-template-standard-00
  
     This template includes examples of the most commonly used features of RFCXML with comments 
     explaining how to customise them. This template can be quickly turned into an I-D by editing 
     the examples provided. Look for [REPLACE], [REPLACE/DELETE], [CHECK] and edit accordingly.
     Note - 'DELETE' means delete the element or attribute, not just the contents.
     
     Documentation is at https://authors.ietf.org/en/templates-and-schemas
-->
<?xml-model href="rfc7991bis.rnc"?>  <!-- Required for schema validation and schema-aware editing -->
<!-- This third-party XSLT can be enabled for direct transformations in XML processors, including most browsers -->


<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<!-- If further character entities are required then they should be added to the DOCTYPE above.
     Use of an external entity file is not recommended. -->

<rfc
  xmlns:xi="http://www.w3.org/2001/XInclude"
  category="info"
  docName="draft-richardroda-420requesterimpaired-04"
  ipr="trust200902"
  obsoletes=""
  updates=""
  submissionType="IETF"
  xml:lang="en"
  version="3">
<!-- [REPLACE] 
       * docName with name of your draft
     [CHECK] 
       * category should be one of std, bcp, info, exp, historic
       * ipr should be one of trust200902, noModificationTrust200902, noDerivativesTrust200902, pre5378Trust200902
       * updates can be an RFC number as NNNN
       * obsoletes can be an RFC number as NNNN 
-->

  <front>
    <title abbrev="HTTP Requester Impairment Status Code">An HTTP Status Code to Report Requester Impairment</title>
    <!--  [REPLACE/DELETE] abbrev. The abbreviated title is required if the full title is longer than 39 characters -->

    <seriesInfo name="Internet-Draft" value="draft-richardroda-420requesterimpaired-04"/>
   
    <author fullname="Richard Roda" initials="RR" role="editor">
      <!-- [CHECK]
             * initials should not include an initial for the surname
             * role="editor" is optional -->
    <!-- Can have more than one author -->
      
    <!-- all of the following elements are optional -->
      <address>
        <email>richard_roda@hotmail.com</email>
        <uri>https://www.linkedin.com/in/richardroda/</uri>
      </address>
    </author>

    <date year="2023"/>
    <!-- On draft subbmission:
         * If only the current year is specified, the current day and month will be used.
         * If the month and year are both specified and are the current ones, the current day will
           be used
         * If the year is not the current one, it is necessary to specify at least a month and day="1" will be used.
    -->

    <area>Applications and Real-Time Area</area>
    <workgroup>HTTP</workgroup>
    <!-- "Internet Engineering Task Force" is fine for individual submissions.  If this element is 
          not present, the default is "Network Working Group", which is used by the RFC Editor as 
          a nod to the history of the RFC Series. -->

    <keyword>HTTP</keyword>
    <!-- [REPLACE/DELETE]. Multiple allowed.  Keywords are incorporated into HTML output files for 
         use by search engines. -->

    <abstract>
      <t>This document specifies a Hypertext Transfer Protocol (HTTP) status code for use when an operation or resource is denied due to requester impairment.</t>
    </abstract>
 
  </front>

  <middle>
    
    <section>
      <name>Introduction</name>
      <t>This document specifies a Hypertext Transfer Protocol (HTTP) status code for use when a request is denied because the requester is impaired.</t>
      <section>
        <name>Requirements Language</name>
        <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
          "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
          RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be
          interpreted as described in BCP 14 <xref target="RFC2119"/>
          <xref target="RFC8174"/> when, and only when, they appear in
          all capitals, as shown here.</t>
      </section>
      <!-- [CHECK] The 'Requirements Language' section is optional -->

    </section>
    
    <section>
      <name>420 Requester Impaired</name>
      <t>The status code 420 indicates that the server is denying the request as a consequence of evidence of requester impairment.</t>
      <t>The server in question might not be an origin server.  An intermediate proxy closer to the requester may be in a better position to assess potential requester impairment.  Such a proxy may refuse to forward the request and respond with this error code.</t>
      <t>There is no requirement that the requester be human.  Certain AI systems can exhibit behaviors such as giving hallucinated, incorrect, and differing answers for a given input.</t>
      <t>420 responses MUST include a Link header <xref target="RFC8288"/> with a relation type of "status".  This link is used by the remediated requester to obtain information about the server state and to signal to the server that the requester is remediated.  Requesters SHOULD use this link when remediated before making subsequent requests unless a bearer token is used as described under <xref target="Security"/> and the server does not require usage of the link.</t>
      <t>A 420 response is non-cacheable by default, i.e., unless otherwise indicated by the method definition or explicit cache controls; see <xref target="RFC9111"/>.</t>

      <!--
      <ol>
        <li>Ordered list item [REPLACE/DELETE]</li>
      </ol>
      
      <ul>
        <li>Bulleted list item [REPLACE/DELETE]</li>
      </ul>
-     -->
      <dl newline="true">
        <!-- Omit newline="true" if you want each definition to start on the same line as the corresponding term -->
        <dt>AI</dt>
        <dd>An artificial intelligence system that is capable of making independent decisions without direct human control.</dd>
        <dt>proxy</dt>
        <dd>A server with a primary purpose of forwarding requests to other servers to process.</dd>
      </dl>


      <figure>
        <name>Example Response in <xref target="RFC9457"/> Problem Details Format</name>
        <sourcecode type="text">
          <![CDATA[
HTTP/1.1 420 Requester Impaired
Link: <https://example.com/impaired/remediated>; rel="status"
Content-Type: application/problem+json
Content-Language: en
{ 
    "type": "https://example.com/erratic-requests",
    "title": "Requester Impaired: Erratic Behavior Detected.",
    "detail": "Erratic requests detected."
}
]]>
        </sourcecode>
        <!-- [CHECK] markers="true" means that the rendered file will have <CODE BEGINS> and <CODE ENDS> added -->
      </figure>

    </section>   
    
    <section anchor="IANA">
    <!-- All drafts are required to have an IANA considerations section. See RFC 8126 for a guide.-->
      <name>IANA Considerations</name>
      <t>IANA is asked to update the HTTP Status Codes Registry with the following entry:</t>
      <ul>
        <li>Code: 420</li>
        <li>Description: Requester Impaired</li>
        <li>Specification: This RFC</li>
      </ul>

    </section>
    
    <section anchor="Security">
      <!-- All drafts are required to have a security considerations section. See RFC 3552 for a guide. -->
      <name>Security Considerations</name>
      <t>The usage of the link resource provided by the Link header to assert requester remediation assumes a requester or proxy that is trustworthy enough to halt requests and only access the link resource after requester remediation.  If greater security is required, perhaps to enable an external system to remediate and validate the requester, a server MAY require an OAuth authorization <xref target="RFC7523"/> bearer token <xref target="RFC6750"/> to signal remediation of the requester.</t>
      <t>If a valid bearer token is required and missing, further requests SHOULD be rejected with a 403 Forbidden response code with the insufficient_scope error code and scope attribute naming the authorization token required as described in <xref target="RFC6750"/> section 3.1.  Once this authorization bearer token is validated the server MAY allow requests without using the Link provided in the 420 response, but MUST NOT respond to usage of the link as an error.</t>
    </section>
    
    <!-- NOTE: The Acknowledgements and Contributors sections are at the end of this template -->
  </middle>

  <back>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9111.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9457.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8288.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7523.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6750.xml"/>
        <!-- The recommended and simplest way to include a well known reference -->
        
      </references>
    </references>
 </back>
</rfc>
