<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.29 (Ruby 3.4.4) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-httpapi-digest-fields-problem-types-03" category="info" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.31.0 -->
  <front>
    <title>HTTP Problem Types for Digest Fields</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-httpapi-digest-fields-problem-types-03"/>
    <author fullname="Marius Kleidl">
      <organization>Transloadit</organization>
      <address>
        <email>marius@transloadit.com</email>
      </address>
    </author>
    <author fullname="Lucas Pardue">
      <organization>Cloudflare</organization>
      <address>
        <email>lucas@lucaspardue.com</email>
      </address>
    </author>
    <author initials="R." surname="Polli" fullname="Roberto Polli">
      <organization>Par-Tec</organization>
      <address>
        <postal>
          <country>Italy</country>
        </postal>
        <email>robipolli@gmail.com</email>
      </address>
    </author>
    <date year="2025" month="December" day="10"/>
    <area>Web and Internet Transport</area>
    <workgroup>Building Blocks for HTTP APIs</workgroup>
    <keyword>next generation</keyword>
    <keyword>unicorn</keyword>
    <keyword>sparkling distributed ledger</keyword>
    <abstract>
      <?line 52?>

<t>This document specifies problem types that servers can use in responses to problems encountered while dealing with a request carrying integrity fields and integrity preference fields.</t>
    </abstract>
    <note removeInRFC="true">
      <name>About This Document</name>
      <t>
        The latest revision of this draft can be found at <eref target="https://ietf-wg-httpapi.github.io/digest-fields-problem-types/draft-ietf-httpapi-digest-fields-problem-types.html"/>.
        Status information for this document may be found at <eref target="https://datatracker.ietf.org/doc/draft-ietf-httpapi-digest-fields-problem-types/"/>.
      </t>
      <t>
        Discussion of this document takes place on the
        Building Blocks for HTTP APIs Working Group mailing list (<eref target="mailto:httpapi@ietf.org"/>),
        which is archived at <eref target="https://mailarchive.ietf.org/arch/browse/httpapi/"/>.
        Subscribe at <eref target="https://www.ietf.org/mailman/listinfo/httpapi/"/>.
      </t>
      <t>Source for this draft and an issue tracker can be found at
        <eref target="https://github.com/ietf-wg-httpapi/digest-fields-problem-types"/>.</t>
    </note>
  </front>
  <middle>
    <?line 56?>

<section anchor="introduction">
      <name>Introduction</name>
      <t><xref target="DIGEST"/> defines HTTP fields for exchanging integrity digests and preferences, but does not specify, require or recommend any specific behavior for error handling relating to integrity by design. The responsibility is instead delegated to applications. This draft defines a set of problem types (<xref target="PROBLEM"/>) that can be used by server applications to indicate that a problem was encountered while dealing with a request carrying integrity fields and integrity preference fields.</t>
      <t>For example, a request message may include content alongside <tt>Content-Digest</tt> and <tt>Repr-Digest</tt> fields that use a digest algorithm the server does not support. An application could decide to reject this request because it cannot validate the integrity. Using a problem type, the server can provide machine-readable error details to aid debugging or error reporting, as shown in the following example.</t>
      <sourcecode type="http-message"><![CDATA[
# NOTE: '\' line wrapping per RFC 8792

HTTP/1.1 400 Bad Request
Content-Type: application/problem+json
Want-Content-Digest: sha-512=3, sha-256=10

{
  "type": "https://iana.org/assignments/http-problem-types#\
    digest-unsupported-algorithms",
  "title": "Unsupported hashing algorithms",
  "unsupported-algorithms": [
    {
      "algorithm": "foo",
      "header": "Want-Content-Digest"
    }
  ]
}
]]></sourcecode>
    </section>
    <section anchor="conventions-and-definitions">
      <name>Conventions and Definitions</name>
      <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" 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>
      <?line -18?>

<t>Some examples in this document contain long lines that may be folded, as described in <xref target="RFC8792"/>.</t>
      <t>The terms "integrity fields" and "integrity preference fields" in this document are to be
interpreted as described in <xref target="DIGEST"/>.</t>
      <t>The term "problem type" in this document is to be
interpreted as described in <xref target="PROBLEM"/>.</t>
      <t>The terms "request", "response", "intermediary", "sender", "client", and "server" are from <xref target="HTTP"/>.</t>
      <t>The problem types in this document are defined using JSON <xref target="JSON"/>. They can be serialized into an equivalent XML format as outlined in <xref section="B" sectionFormat="of" target="PROBLEM"/>.</t>
    </section>
    <section anchor="problem-types">
      <name>Problem Types</name>
      <t>The following section defines three problem types to express common problems that occur when handling integrity or integrity preference fields on the server. These problem types use the <tt>digest-</tt> prefix in their type URI. Other problem types that are defined outside this document, yet specific to digest related problems, may reuse this prefix.</t>
      <t>Requests can include multiple integrity or integrity preference fields. For example, they may use the <tt>Content-Digest</tt> and <tt>Repr-Digest</tt> fields simultaneously or express preferences for content and representation digests at the same time. Therefore, similar problems can appear multiple times for one request. The problem types defined in this document allow expressing multiple appearances, while each time identifying the corresponding header that contained the problematic value.</t>
      <section anchor="unsupported-hashing-algorithms">
        <name>Unsupported Hashing Algorithms</name>
        <t>This section defines the "https://iana.org/assignments/http-problem-types#digest-unsupported-algorithms" problem type.
A server can use this problem type to communicate to the client that
one or more of the hashing algorithms referenced in the integrity or integrity preference fields present in the request
are not supported.</t>
        <t>For this problem type, the <tt>unsupported-algorithms</tt> extension member is defined, whose value is a JSON <xref target="JSON"/> array of entries identifying each unsupported algorithm.
Each entry in the array is a JSON object with the following members:</t>
        <ul spacing="normal">
          <li>
            <t>The <tt>algorithm</tt> member is a JSON string containing the algorithm key of the unsupported algorithm.</t>
          </li>
          <li>
            <t>The <tt>header</tt> member is a JSON string containing the name of the integrity or integrity preference field that referenced the unsupported algorithm.</t>
          </li>
        </ul>
        <t>The response can include the corresponding integrity preference field to indicate the server's algorithm support and preference.</t>
        <t>This problem type is a hint to the client about algorithm support, which the client could use to retry the request with different, supported, algorithms.</t>
        <t>Example:</t>
        <figure>
          <name>A request with sha-256 integrity fields, which are not supported by the server</name>
          <sourcecode type="http-message"><![CDATA[
POST /books HTTP/1.1
Host: foo.example
Content-Type: application/json
Accept: application/json
Accept-Encoding: identity
Repr-Digest: sha-256=:mEkdbO7Srd9LIOegftO0aBX+VPTVz7/CSHes2Z27gc4=:
Content-Digest: sha-256=:mEkdbO7Srd9LIOegftO0aBX+VPTVz7/CSHes2Z27gc4=:

{"title": "New Title"}
]]></sourcecode>
        </figure>
        <figure>
          <name>Response indicating the problem and advertising the supported algorithms</name>
          <sourcecode type="http-message"><![CDATA[
# NOTE: '\' line wrapping per RFC 8792

HTTP/1.1 400 Bad Request
Content-Type: application/problem+json
Want-Repr-Digest: sha-512=10, sha-256=0
Want-Content-Digest: sha-512=10, sha-256=0

{
  "type": "https://iana.org/assignments/http-problem-types#\
    digest-unsupported-algorithms",
  "title": "Unsupported hashing algorithms",
  "unsupported-algorithms": [
    {
      "algorithm": "sha-256",
      "header": "Repr-Digest"
    },
    {
      "algorithm": "sha-256",
      "header": "Content-Digest"
    }
  ]
}
]]></sourcecode>
        </figure>
        <t>This problem type can also be used when a request contains an integrity preference field with an unsupported algorithm. For example:</t>
        <figure>
          <name>A request with a sha-256 integrity preference field, which is not supported by the server</name>
          <sourcecode type="http-message"><![CDATA[
GET /items/123 HTTP/1.1
Host: foo.example
Want-Repr-Digest: sha=10

]]></sourcecode>
        </figure>
        <figure>
          <name>Response indicating the problem and advertising the supported algorithms</name>
          <sourcecode type="http-message"><![CDATA[
# NOTE: '\' line wrapping per RFC 8792

HTTP/1.1 400 Bad Request
Content-Type: application/problem+json

{
  "type": "https://iana.org/assignments/http-problem-types#\
    digest-unsupported-algorithms",
  "title": "Unsupported hashing algorithms",
  "unsupported-algorithms": [
    {
      "algorithm": "sha",
      "header": "Want-Repr-Digest"
    }
  ]
}
]]></sourcecode>
        </figure>
      </section>
      <section anchor="invalid-digest-values">
        <name>Invalid Digest Values</name>
        <t>This section defines the "https://iana.org/assignments/http-problem-types#digest-invalid-values" problem type. A server can use this problem type when responding to a request, whose integrity fields include a digest value, that cannot be generated by the corresponding hashing algorithm. For example, if the digest value of the <tt>sha-512</tt> hashing algorithm is not 64 bytes long, it cannot be a valid SHA-512 digest value and the server can skip computing the digest value. This problem type <bcp14>MUST NOT</bcp14> be used if the server is not able to parse the integrity fields according to <xref section="4.5" sectionFormat="of" target="STRUCTURED-FIELDS"/>, for example because of a syntax error in the field value.</t>
        <t>For this problem type, the <tt>invalid-digests</tt> extension member is defined, whose value is a JSON <xref target="JSON"/> array of entries identifying each invalid digest.
Each entry in the array is a JSON object with the following members:</t>
        <ul spacing="normal">
          <li>
            <t>The <tt>algorithm</tt> member is a JSON string containing the algorithm key.</t>
          </li>
          <li>
            <t>The <tt>header</tt> member is a JSON string containing the name of the integrity field that contained the invalid digest value.</t>
          </li>
          <li>
            <t>The <tt>reason</tt> member is a JSON string containing a human-readable description why the value is considered invalid.</t>
          </li>
        </ul>
        <t>This problem type indicates a fault in the sender's calculation or encoding of the digest value. A retry of the same request without modification will likely not yield a successful response.</t>
        <t>The following example shows a request with the content <tt>{"hello": "world"}</tt> (plus LF), but the digest has been truncated. The subsequent response indicates the invalid SHA-512 digest.</t>
        <figure>
          <name>A request with a sha-512 integrity field, whose digest has been truncated to 32 bytes</name>
          <sourcecode type="http-message"><![CDATA[
PUT /items/123 HTTP/1.1
Host: foo.example
Content-Type: application/json
Repr-Digest: sha-512=:YMAam51Jz/jOATT6/zvHrLVgOYTGFy1d6GJiOHTohq4:

{"hello": "world"}
]]></sourcecode>
        </figure>
        <figure>
          <name>Response indicating that the provided digest is too short</name>
          <sourcecode type="http-message"><![CDATA[
# NOTE: '\' line wrapping per RFC 8792

HTTP/1.1 400 Bad Request
Content-Type: application/problem+json

{
  "type": "https://iana.org/assignments/http-problem-types#\
    digest-invalid-values",
  "title": "Invalid digest values",
  "invalid-digests": [
    {
      "algorithm": "sha-512",
      "header": "Repr-Digest",
      "reason": "digest value is not 64 bytes long"
    }
  ]
}
]]></sourcecode>
        </figure>
      </section>
      <section anchor="mismatching-digest-values">
        <name>Mismatching Digest Values</name>
        <t>This section defines the "https://iana.org/assignments/http-problem-types#digest-mismatching-values" problem type. A server can use this problem type when responding to a request, whose integrity fields include a digest value that does not match the digest value that the server calculated for the request content or representation.</t>
        <t>For this problem type, the <tt>mismatching-digests</tt> extension member is defined, whose value is a JSON <xref target="JSON"/> array of entries identifying each mismatching digest.
Each entry in the array is a JSON object with the following members:</t>
        <ul spacing="normal">
          <li>
            <t>The <tt>algorithm</tt> member is a JSON string containing the algorithm key of the hashing algorithm.</t>
          </li>
          <li>
            <t>The <tt>provided-digest</tt> member is a JSON string containing the digest value taken from the request's integrity fields. The digest value is serialized as a byte sequence as described in <xref section="4.1.8" sectionFormat="of" target="STRUCTURED-FIELDS"/>.</t>
          </li>
          <li>
            <t>The <tt>header</tt> member is a JSON string containing the name of the integrity field that contained the mismatching digest value.</t>
          </li>
        </ul>
        <t>The problem type intentionally does not include the digest value calculated by the server to avoid attackers abusing this information for oracle attacks.</t>
        <t>If the sender receives this problem type, the request might be modified unintentionally by an intermediary. The sender could use this information to retry the request without modification to address temporary transmission issues.</t>
        <t>The following example shows a request with the content <tt>{"hello": "woXYZ"}</tt> (plus LF), but the representation digest for <tt>{"hello": "world"}</tt> (plus LF). The subsequent response indicates the mismatching SHA-256 digest value.</t>
        <figure>
          <name>A request with a sha-256 integrity field, which does not belong to the representation</name>
          <sourcecode type="http-message"><![CDATA[
PUT /items/123 HTTP/1.1
Host: foo.example
Content-Type: application/json
Repr-Digest: sha-256=:RK/0qy18MlBSVnWgjwz6lZEWjP/lF5HF9bvEF8FabDg=:

{"hello": "woXYZ"}
]]></sourcecode>
        </figure>
        <figure>
          <name>Response indicating the mismatching digests</name>
          <sourcecode type="http-message"><![CDATA[
# NOTE: '\' line wrapping per RFC 8792

HTTP/1.1 400 Bad Request
Content-Type: application/problem+json

{
  "type": "https://iana.org/assignments/http-problem-types#\
    digest-mismatching-values",
  "title": "Mismatching digest values",
  "mismatching-digests": [
    {
      "algorithm": "sha-256",
      "provided-digest": ":RK/0qy18MlBSVnWgjwz6lZEWjP/lF5HF9bvEF8FabDg=:",
      "header": "Repr-Digest"
    }
  ]
}
]]></sourcecode>
        </figure>
      </section>
    </section>
    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t>Disclosing error details could leak information
such as the presence of intermediaries or the server's implementation details.
Moreover, they can be used to fingerprint the server.</t>
      <t>To mitigate these risks, a server could assess the risk of disclosing error details
and prefer a general problem type over a more specific one.</t>
      <t>When a server informs the client about mismatching digest values, it should not expose
the calculated digest to avoid exposing information that can be abused for oracle attacks.</t>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <t>IANA is asked to register the following entries in the "HTTP Problem Types" registry at <eref target="https://www.iana.org/assignments/http-problem-types">https://www.iana.org/assignments/http-problem-types</eref>.</t>
      <section anchor="registration-of-digest-unsupported-algorithms-problem-type">
        <name>Registration of "digest-unsupported-algorithms" Problem Type</name>
        <dl>
          <dt>Type URI:</dt>
          <dd>
            <t>https://iana.org/assignments/http-problem-types#digest-unsupported-algorithms</t>
          </dd>
          <dt>Title:</dt>
          <dd>
            <t>Unsupported Hashing Algorithms</t>
          </dd>
          <dt>Recommended HTTP status code:</dt>
          <dd>
            <t>400</t>
          </dd>
          <dt>Reference:</dt>
          <dd>
            <t><xref target="unsupported-hashing-algorithms"/> of this document</t>
          </dd>
        </dl>
      </section>
      <section anchor="registration-of-digest-invalid-values-problem-type">
        <name>Registration of "digest-invalid-values" Problem Type</name>
        <dl>
          <dt>Type URI:</dt>
          <dd>
            <t>https://iana.org/assignments/http-problem-types#digest-invalid-values</t>
          </dd>
          <dt>Title:</dt>
          <dd>
            <t>Invalid Digest Values</t>
          </dd>
          <dt>Recommended HTTP status code:</dt>
          <dd>
            <t>400</t>
          </dd>
          <dt>Reference:</dt>
          <dd>
            <t><xref target="invalid-digest-values"/> of this document</t>
          </dd>
        </dl>
      </section>
      <section anchor="registration-of-digest-mismatching-values-problem-type">
        <name>Registration of "digest-mismatching-values" Problem Type</name>
        <dl>
          <dt>Type URI:</dt>
          <dd>
            <t>https://iana.org/assignments/http-problem-types#digest-mismatching-values</t>
          </dd>
          <dt>Title:</dt>
          <dd>
            <t>Mismatching Digest Values</t>
          </dd>
          <dt>Recommended HTTP status code:</dt>
          <dd>
            <t>400</t>
          </dd>
          <dt>Reference:</dt>
          <dd>
            <t><xref target="mismatching-digest-values"/> of this document</t>
          </dd>
        </dl>
      </section>
    </section>
  </middle>
  <back>
    <references anchor="sec-normative-references">
      <name>Normative References</name>
      <reference anchor="DIGEST">
        <front>
          <title>Digest Fields</title>
          <author fullname="R. Polli" initials="R." surname="Polli"/>
          <author fullname="L. Pardue" initials="L." surname="Pardue"/>
          <date month="February" year="2024"/>
          <abstract>
            <t>This document defines HTTP fields that support integrity digests. The Content-Digest field can be used for the integrity of HTTP message content. The Repr-Digest field can be used for the integrity of HTTP representations. Want-Content-Digest and Want-Repr-Digest can be used to indicate a sender's interest and preferences for receiving the respective Integrity fields.</t>
            <t>This document obsoletes RFC 3230 and the Digest and Want-Digest HTTP fields.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="9530"/>
        <seriesInfo name="DOI" value="10.17487/RFC9530"/>
      </reference>
      <reference anchor="PROBLEM">
        <front>
          <title>Problem Details for HTTP APIs</title>
          <author fullname="M. Nottingham" initials="M." surname="Nottingham"/>
          <author fullname="E. Wilde" initials="E." surname="Wilde"/>
          <author fullname="S. Dalal" initials="S." surname="Dalal"/>
          <date month="July" year="2023"/>
          <abstract>
            <t>This document defines a "problem detail" to carry machine-readable details of errors in HTTP response content to avoid the need to define new error response formats for HTTP APIs.</t>
            <t>This document obsoletes RFC 7807.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="9457"/>
        <seriesInfo name="DOI" value="10.17487/RFC9457"/>
      </reference>
      <reference anchor="STRUCTURED-FIELDS">
        <front>
          <title>Structured Field Values for HTTP</title>
          <author fullname="M. Nottingham" initials="M." surname="Nottingham"/>
          <author fullname="P-H. Kamp" surname="P-H. Kamp"/>
          <date month="September" year="2024"/>
          <abstract>
            <t>This document describes a set of data types and associated algorithms that are intended to make it easier and safer to define and handle HTTP header and trailer fields, known as "Structured Fields", "Structured Headers", or "Structured Trailers". It is intended for use by specifications of new HTTP fields.</t>
            <t>This document obsoletes RFC 8941.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="9651"/>
        <seriesInfo name="DOI" value="10.17487/RFC9651"/>
      </reference>
      <reference anchor="HTTP">
        <front>
          <title>HTTP Semantics</title>
          <author fullname="R. Fielding" initials="R." role="editor" surname="Fielding"/>
          <author fullname="M. Nottingham" initials="M." role="editor" surname="Nottingham"/>
          <author fullname="J. Reschke" initials="J." role="editor" surname="Reschke"/>
          <date month="June" year="2022"/>
          <abstract>
            <t>The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes.</t>
            <t>This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230.</t>
          </abstract>
        </front>
        <seriesInfo name="STD" value="97"/>
        <seriesInfo name="RFC" value="9110"/>
        <seriesInfo name="DOI" value="10.17487/RFC9110"/>
      </reference>
      <reference anchor="RFC8792">
        <front>
          <title>Handling Long Lines in Content of Internet-Drafts and RFCs</title>
          <author fullname="K. Watsen" initials="K." surname="Watsen"/>
          <author fullname="E. Auerswald" initials="E." surname="Auerswald"/>
          <author fullname="A. Farrel" initials="A." surname="Farrel"/>
          <author fullname="Q. Wu" initials="Q." surname="Wu"/>
          <date month="June" year="2020"/>
          <abstract>
            <t>This document defines two strategies for handling long lines in width-bounded text content. One strategy, called the "single backslash" strategy, is based on the historical use of a single backslash ('\') character to indicate where line-folding has occurred, with the continuation occurring with the first character that is not a space character (' ') on the next line. The second strategy, called the "double backslash" strategy, extends the first strategy by adding a second backslash character to identify where the continuation begins and is thereby able to handle cases not supported by the first strategy. Both strategies use a self-describing header enabling automated reconstitution of the original content.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="8792"/>
        <seriesInfo name="DOI" value="10.17487/RFC8792"/>
      </reference>
      <reference anchor="JSON">
        <front>
          <title>The JavaScript Object Notation (JSON) Data Interchange Format</title>
          <author fullname="T. Bray" initials="T." role="editor" surname="Bray"/>
          <date month="December" year="2017"/>
          <abstract>
            <t>JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data.</t>
            <t>This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance.</t>
          </abstract>
        </front>
        <seriesInfo name="STD" value="90"/>
        <seriesInfo name="RFC" value="8259"/>
        <seriesInfo name="DOI" value="10.17487/RFC8259"/>
      </reference>
      <reference anchor="RFC2119">
        <front>
          <title>Key words for use in RFCs to Indicate Requirement Levels</title>
          <author fullname="S. Bradner" initials="S." surname="Bradner"/>
          <date month="March" year="1997"/>
          <abstract>
            <t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
          </abstract>
        </front>
        <seriesInfo name="BCP" value="14"/>
        <seriesInfo name="RFC" value="2119"/>
        <seriesInfo name="DOI" value="10.17487/RFC2119"/>
      </reference>
      <reference anchor="RFC8174">
        <front>
          <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
          <author fullname="B. Leiba" initials="B." surname="Leiba"/>
          <date month="May" year="2017"/>
          <abstract>
            <t>RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
          </abstract>
        </front>
        <seriesInfo name="BCP" value="14"/>
        <seriesInfo name="RFC" value="8174"/>
        <seriesInfo name="DOI" value="10.17487/RFC8174"/>
      </reference>
    </references>
  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA91b63YaORL+30+hxT+ys2PAOHYunMlM8C32jB17bZxM5nKO
RbcAxU2LkbpNCMfzLPss+2RbVVJfwQTnJNmc5AcB3Uqq61cluV6ve7GMQ9Fm
tcNu94ydadULxYh1p2NhWF9pticHwsTsQIowMDXP57EYKD1tMxn1lecFyo/4
COYHmvfjuhRxvz6M4zEfy3pAU+t9mlof26XrMS5d33jomaQ3ksZIFWFTmx3t
dw8YW2M8NAr2I6NAjAV8RHFtndVEIGOlJQ/xx1FnB/6D3dWOzrsHNS9KRj2h
214Au2t7voqMiExi2izWifBu2uyhx7XgsOpr0WM8CthRFAsdiZh1NY/MWOm4
5k2Uvh5olYxh3E4iw0BGA7YTKv/asoI41Dk7AjZciymMDtoeq7NIvIvZQERC
8xgOg01JJH2l6asZc30d4kqBNLGWvSQWAQtFMBDauxFRAhtmbEWyjFlW1V7D
VnHYC5yH7SMuQ2h3rH+OcmgoPcAurv2h6zLtZhNHYpO8EY10WBMbmj2tJkY0
3RpNnDuQ8TDpoTRQsJNBKtvmEtnivBAEYeIC1cr8hl24IdWylZr3U6rGMB6F
Nc/jSTxUGmUDO2Gsn4Sh1dHaCdcyMeyXUMggrFEvnJ5H8j2Jrm21IVQclI16
hePriCY+j/Puhq9GtQUkjhOfG3bGdZCIRRR2Q5UEfZCAKBEIcdpz+hzT3NL6
MgJdPm+wMxWGskrxXIHux8p2LiIJm6l3hV+iB3yTY5zwfIAtjhr881USxWjf
RzEPp54XKT2CdW5ITfeOXuxfdGErB7tPtx9uQMvZ+enO8f6JbdrafgxNF93z
y93u5fn+Xv3gaP9478J2PtpuQScqs/3dauF8+Pbk8dNNXPzni9OX1PVkc/up
56F/yUh7Xr1eZ7wHFsT92PO6Q2kY+J5kBO4BbEz4EjTCMKcPZCaGxUMOnULf
CG2YzyOWGAG8ZFqAxYOPgBEqnWKYiOjsQoN9ToYyFCwQnCx3AsrKOEz7K0Ff
6HOtp9guYfRAy3jKrDqSZ8kbx1r0YbXIF66/YY8xkkEQCs9bQy+kVZD45De8
2czy9/YWKPdlBPsj23eLoy8Q7/whjwZl4tYkLPWcplln4GuASbBMpFImTdfp
GFILdJ9agNyBhQHMnaZs9FlPDPmNhH4iqTV8AtWAeKEF2DZ+AdblW+jBLoSR
g6jBukORMlj2ZIi9ICvQ4FjwAEaFYsDRBcJ8Ph6H0ictNTgRZYoWnx2fg/Ri
pvoVuf5zNnN6d3v7nZUySrcnUMABbsYKvUTAbjjAn8LO4dmyE/6FxH9AMuSj
cSjWC0uOhDF8IMCLA7MiP0wCAYYIK4Fy81BFAyOh5WrXNtVtTL4ielfnYqyz
FrcROh4qO3fKAatA1IZzAAtBPo49uW4kYwyBDdaJijxDZxCizHwkD/zT4q3w
Y1gCJJXuvSd8TnZFQsDVboBtgeWyyPnRYJcGucZLwlwv7geFCJ03SG3EIURF
og5hO+Aw3OlhIGJwVyRMLnFrvWRA5pBpqhZ4FGgCBhtmhmoSoc0jmT44PDXB
0U4GIJG///6bYWypOxmAVb487e632YM/HjAQv2ATDSzBSWPYIrgnhg7L89A0
m61Gi21tbLAdUO1zyxAvlVKXQnWBnU138O/fGjD31xzGlCXahu3y+nZr89nD
dfq6uf3oGbhJbwbusYbsqhVDKo+4Dd4GLQ89oaHgXY6Ka3+QX3dxM4mcrEVQ
z3TC1NaJACJBpHCZDwLDN0MSW2XwHQu12e9EbkafMC7rw4X7StFs6hmCZIXG
5gWssMHoFj7/9G5RSOguYQggJmvNqPt76CYk/caQIBjAMoa4zECov7zoIlTE
/1Gi+P18/9+XRxCX8PvFYef4OPviuREXh6eXx3v5t3zm7unJyf7LPTsZWlmp
yauddN5AD+6qdnrWPTp92TmuWb0rRioI+6i6PWsXGlwE8pgbD7ynD+BQoANh
O7tn//1Pa4vNZv8AfdtstZ5CSLA/nrQeb8GPyVBElpqKwqn7CSo+9UDfBNe4
Cg9DsKixhDhuCrYwBJ8Eev+v35Ezf7bZDz1/3Nr60TXggUuNKc9KjcSz+Za5
yZaJC5oWkMm4WWqvcLq8386b0u+U74XGH34iE663nvz0I4CICzUSqe2beemg
y+XQih6XbN95UnTLPXIfgQiIlSVxzWYOxdzeNqwegmgBUNSqAaJm9WNJiFim
Ml5ZZap7SLFDYQusVnS1C9aWZqWls2BbPp6LAGgQKaLC77TWCPI1rqf422AS
p/GbH0qbzREbrNOv0QH7Wo2AEPrUjEo55i/ki8UJAYQ6dFEIIGER/A8WQSAy
TXEB0ILUUb6nE2HsiBiiIIhUuNSvJ8fMgk08vErikFals3fGmITKd2wHcUiR
E2vlbNluOg8xRhCsy7BMPNSieijYiXgHbDcATwGIqShHo6R4yvcTTdadA7Bc
e5RehjbAMxRiK7HDVOlj3MYxVy46XNEycFgbMKWmcezy/KjBTqFBLwLYRUEA
7wiqlES1zqYiztElHNqBEsKSIsgOvU6WpoXdljRuN8BrF1stik8R0igJYwmW
vDJLGqyEv9BfEsWMDSsDLCOROI+ESkxIZFM5FgA4wecMxsFSAE1gDPyy6CrD
7bEVFKRzLJYjQbKCZZSGTQIlzNdzxUAOOCefMQBnWXIqEikys1C8LLBUTvPW
hGqbHgLVLFvb0uI2o7DAWAA2I5pMYnkGsgpKCIYIWrV1BVTEsBHeAXTrWxH4
57sCPvgIFxOMSGtrrAg8Dh3w6GTgwqV984Yl7g+KlsOhEtcaXqcIUAvKmY9B
pUYLxsIPIV9l2UEOjxjgoWRAQCOFqVefuuexFcu0J0hB68r27nQrnee0AAtf
RYwvApeGzJ3BQvGrxSy5At0APcZqHWQrWG3D4OHUCfVCAVtIktjOy74YXIQG
M4NTw/405ulFvSFtKlDN2dHw9rEPJ03TY9mlchqqRykJ5WhljG+3adqQdJMl
XGXrXhWO4JbB0hzMcVqaqnOeNSGydFK7Y6uOiNX5lSlgDSddeEVJW3sqKMqS
TXmFbFyUnOe8tS6jWEqd05jywBQY5MhXihANZ7MlWyGegOLHFTPhPQgf80uS
1/GHxZE2LyVLxKQU1aOg8lYZAtmnTcD8jDXrBVODre3bSNBekAWenQIWbvaU
urZFGMz0vEOFORokMQ0XQ5bkepTjdXxfjOM7O+r7ka+Q921nEPHUK0SbdpYD
tkf710Hv9PGFDp4eH52KQT8+3eA7v37/6qz76v3j5u7FoTCbv20+Hvhbz9re
oqzyI5bxZnlK+FJMWJd+2Gxs1mbU96zWKbPd0ZorjqRSnHNHWK7JdQqW/z+n
5HMCwHy8tZEn5BvLU/fy0G8mdXdHWpS+Fzjm0vb1j1voQyWAXOnOU5fm3FLq
TlM/g16IB6BPsTRp3wIHaVDd5h0UQazQqKyiSAi8UAG0PhyLEMu8pq0bRnf4
5iIWXeSBXuyDA5IxQL5ma/PhMie0UG2pbrTUUvkCW62eIbVaab5ao/2WLOzO
4ti8iX12s1jD6wkq5aZ3wK8Q3n0OFC4tnTrhxyr6Ziugb7LPApTBDD9V9hSc
zlXrUySU1ciJ/Hp2n4AKDw7A3ezmOl/JcaoqUEkypcV2RRIp3rtyIeNqfpHU
4B5tAdUY2IslqfVCjb2H+7bSuTjs4CplEijpSmXdXMsxJinjJNOL4hR3AVPi
a1oRzByhO41b1W2SyvN4k8a1qRT9s5sRH7iWimY2u3DKs9XYRmbM3Rje3q67
6y7iYnbHAGPBa03B+75z1f60sk8ON80kl6U3qa655Ptz5zWOnOP015XQfNqc
pZCblHP9MgtSITnSWnBw4iuRhpwhGfEovxGyVcoxadJkaI0zExU+AgFpaEqk
aQOLcxGX1iDdPk/CLH22VcsHWG8J/SS0FRtUSQfZUwaUTajjshHXSSWdYtDF
BGcE8/vpDdtEhiGEx2sRTsmWpsRFUPIEMgRj+kmYpW+NaoUxtQ6s65sCPMlU
J609Xc0gnsAsDCcTpcOgdnvF/jkOE8OOD76z98SFs4A3AosDjxrrJELmBLaU
ZJKeQRJRnKeUOf+Koi67pEW3bGeXq6KbD6RYC+F6+81Jh4+2Wz+/b7497XS7
j5rvbw718avB6Zvui4NpK3j04md5ethVw7+2KM+psmcV5IQHrKh/6jDuZCS6
v4eb1qd/K6ipEr3LaOlogfG7MRVPvEL+ARz/UP6RdVvHgt2luLgort4fUbmK
rburzk5H1ykK7VHHDkKdSDPisU/R/XPDqFFO66uAUpZR2SMD2ts8GMq4mW3N
+ltga5/iuCjlXeh97C1/oZT+gZhfZMwXivsFkl9l7L+zBJ1F5lS5HcdWJlMW
Lr8GdaLbvYIgH5g5FbIRpmqqhWs7jmTRZpmNQZChzl9U5riy1XhyB7L8Qqhn
XgEyeFq9lqHl6FkDDwEGZAZTLNWWOFMwkVIeTsZ6o8Dd8jjm/jU+e+O9xKV6
9ArLvakDHtFtkeY+XvHQaKyIHvUL4Aefhwl5Q15poWFlz5fkYEgpiYU2eCEb
lc8E23S1kvRm2EEKS6hQz61u884C7xyUwsMHAV3CAa6AnJbjLHyx6Z4Zg4gN
TP9UOOrXN7/dgaMW3vMRw5cjsVVhVlG3EGphDaeiY18QcFFl+fyX5sZf09aT
k3Dn4lX0evB28v5R+Nv+67dnzfBg+/Dgae9m/+DJAe/tDZ5VERcx8v61qlKB
KjOanqDXG+5moSyJbwVxLQj0ZdR1cofzceMWxMP7Vn8r0QHH3E8HVisk36vK
Ne9ybSGLQVhISGV2XVLI3ZuxPWn8UJF/LD8vtA4pFPy66Iw8yMqGGHYs+EPF
8ikmFBwbogEHW7JbMol2Ncr9gSXS8E6UFgqGuKcIxTesoL8ARQb4KIcuyvKH
HOC9FBw1lgN3GweM0NJc4xuvDEPR9kGlyBkO7QDcaHDHgb382g5WsSWvsByk
FD2otffX2VsOFaGzeW3L42lViBhm5m/27gqJhgpb4H1x02jD4t0Y4JdHC+Sh
zk3JYhyNsheXhXBReAyMoc+hyLlAt8aOOi87cwpBjYgEzLUVghYDaWKhq+9H
U9xncdyCP56puakQg2BHP6T2PplMGiva/I/2TcS5XcYVIPppPnPn04XiLkBX
3Pudttdmn/SNBCxNfzgE637o1cZ5+soc+5FRBgwhQSMLaD44VBzkLh6wZTYr
EnUYtUAcIDghscILlqW8qhaYPzmPygQKvLmjhP4xLCnny47UfTmxKEf85NyY
J1LgyJKM+GO4Mh/LlnEG//yiBy7A+x8fILHy+jYAAA==

-->

</rfc>
