<?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-02" category="info" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.28.1 -->
  <front>
    <title>HTTP Problem Types for Digest Fields</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-httpapi-digest-fields-problem-types-02"/>
    <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="June" day="11"/>
    <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+t9mlof26XrMS5d39j0TNIbSWOkirCpzY72
uweMrTEeGgX7kVEgxgI+ori2zmoikLHSkof446izA//B7mpH592Dmhclo57Q
bS+A3bU9X0VGRCYxbRbrRHg3bfbQ41pwWPW16DEeBewoioWORMy6mkdmrHRc
8yZKXw+0SsYwbieRYSCjAdsJlX9tWUEc6pwdARuuxRRGB22P1Vkk3sVsICKh
eQyHwaYkkr7S9NWMub4OcaVAmljLXhKLgIUiGAjt3YgogQ0ztiJZxiyraq9h
qzjsBc7D9hGXIbQ71j9HOTSUHmAX1/7QdZl2s4kjsUneiEY6rIkNzZ5WEyOa
bo0mzh3IeJj0UBoo2MkglW1ziWxxXgiCMHGBamV+wy7ckGrZSs37KVVjGI/C
mufxJB4qjbKBnTDWT8LQ6mjthGuZGPZLKGQQ1qgXTs8j+Z5E17baECoOyka9
wvF1RBOfx3l3w1ej2gISx4nPDTvjOkjEIgq7oUqCPkhAlAiEOO05fY5pbml9
GYEunzfYmQpDWaV4rkD3Y2U7F5GEzdS7wi/RA77JMU54PsAWRw3++SqJYrTv
o5iHU8+LlB7BOjekpntHL/YvurCVg92n2w83oOXs/HTneP/ENm1tP4ami+75
5W738nx/r35wtH+8d2E7H223oBOV2f5utXA+fHvy+OkmLv7zxelL6nqyuf3U
89C/ZKQ9r16vM94DC+J+7HndoTQMfE8yAvcANiZ8CRphmNMHMhPD4iGHTqFv
hDbM5xFLjABeMi3A4sFHwAiVTjFMRHR2ocE+J0MZChYITpY7AWVlHKb9laAv
9LnWU2yXMHqgZTxlVh3Js+SNYy36sFrkC9ffsMcYySAIheetoRfSKkh88hve
bGb5e3sLlPsygv2R7bvF0ReId/6QR4MycWsSlnpO06wz8DXAJFgmUimTput0
DKkFuk8tQO7AwgDmTlM2+qwnhvxGQj+R1Bo+gWpAvNACbBu/AOvyLfRgF8LI
QdRg3aFIGSx7MsRekBVocCx4AKNCMeDoAmE+H49D6ZOWGpyIMkWLz47PQXox
U/2KXP85mzm9u739zkoZpdsTKOAAN2OFXiJgNxzgT2Hn8GzZCf9C4j8gGfLR
OBTrhSVHwhg+EODFgVmRHyaBAEOElUC5eaiigZHQcrVrm+o2Jl8RvatzMdZZ
i9sIHQ+VnTvlgFUgasM5gIUgH8eeXDeSMYbAButERZ6hMwhRZj6SB/5p8Vb4
MSwBkkr33hM+J7siIeBqN8C2wHJZ5PxosEuDXOMlYa4X94NChM4bpDbiEKIi
UYewHXAY7vQwEDG4KxIml7i1XjIgc8g0VQs8CjQBgw0zQzWJ0OaRTB8cnprg
aCcDkMjff//NMLbUnQzAKl+edvfb7MEfDxiIX7CJBpbgpDFsEdwTQ4fleWia
zVajxbY2NtgOqPa5ZYiXSqlLobrAzqY7+PdvDZj7aw5jyhJtw3Z5fbu1+ezh
On3d3H70DNykNwP3WEN21YohlUfcBm+Dloee0FDwLkfFtT/Ir7u4mURO1iKo
ZzphautEAJEgUrjMB4HhmyGJrTL4joXa7HciN6NPGJf14cJ9pWg29QxBskJj
8wJW2GB0C59/ercoJHSXMAQQk7Vm1P09dBOSfmNIEAxgGUNcZiDUX150ESri
/yhR/H6+/+/LI4hL+P3isHN8nH3x3IiLw9PL4738Wz5z9/TkZP/lnp0MrazU
5NVOOm+gB3dVOz3rHp2+7BzXrN4VIxWEfVTdnrULDS4CecyNB97TB3Ao0IGw
nd2z//6ntcVms3+Avm22Wk8hJNgfT1qPt+DHZCgiS01F4dT9BBWfeqBvgmtc
hYchWNRYQhw3BVsYgk8Cvf/X78iZP9vsh54/bm396BrwwKXGlGelRuLZfMvc
ZMvEBU0LyGTcLLVXOF3eb+dN6XfK90LjDz+RCddbT376EUDEhRqJ1PbNvHTQ
5XJoRY9Ltu88KbrlHrmPQATEypK4ZjOHYm5vG1YPQbQAKGrVAFGz+rEkRCxT
Ga+sMtU9pNihsAVWK7raBWtLs9LSWbAtH89FADSIFFHhd1prBPka11P8bTCJ
0/jND6XN5ogN1unX6IB9rUZACH1qRqUc8xfyxeKEAEIduigEkLAI/geLIBCZ
prgAaEHqKN/TiTB2RAxREEQqXOrXk2NmwSYeXiVxSKvS2TtjTELlO7aDOKTI
ibVytmw3nYcYIwjWZVgmHmpRPRTsRLwDthuApwDEVJSjUVI85fuJJuvOAViu
PUovQxvgGQqxldhhqvQxbuOYKxcdrmgZOKwNmFLTOHZ5ftRgp9CgFwHsoiCA
dwRVSqJaZ1MR5+gSDu1ACWFJEWSHXidL08JuSxq3G+C1i60WxacIaZSEsQRL
XpklDVbCX+gviWLGhpUBlpFInEdCJSYksqkcCwCc4HMG42ApgCYwBn5ZdJXh
9tgKCtI5FsuRIFnBMkrDJoES5uu5YiAHnJPPGICzLDkViRSZWSheFlgqp3lr
QrVND4Fqlq1taXGbUVhgLACbEU0msTwDWQUlBEMErdq6Aipi2AjvALr1rQj8
810BH3yEiwlGpLU1VgQehw54dDJw4dK+ecMS9wdFy+FQiWsNr1MEqAXlzMeg
UqMFY+GHkK+y7CCHRwzwUDIgoJHC1KtP3fPYimXaE6SgdWV7d7qVznNagIWv
IsYXgUtD5s5gofjVYpZcgW6AHmO1DrIVrLZh8HDqhHqhgC0kSWznZV8MLkKD
mcGpYX8a8/Si3pA2Fajm7Gh4+9iHk6bpsexSOQ3Vo5SEcrQyxrfbNG1IuskS
rrJ1rwpHcMtgaQ7mOC1N1TnPmhBZOqndsVVHxOr8yhSwhpMuvKKkrT0VFGXJ
prxCNi5KznPeWpdRLKXOaUx5YAoMcuQrRYiGs9mSrRBPQPHjipnwHoSP+SXJ
6/jD4kibl5IlYlKK6lFQeasMgezTJmB+xpr1gqnB1vZtJGgvyALPTgELN3tK
XdsiDGZ63qHCHA2SmIaLIUtyPcrxOr4vxvGdHfX9yFfI+7YziHjqFaJNO8sB
26P966B3+vhCB0+Pj07FoB+fbvCdX79/ddZ99f5xc/fiUJjN3zYfD/ytZ21v
UVb5Ect4szwlfCkmrEs/bDY2azPqe1brlNnuaM0VR1IpzrkjLNfkOgXL/59T
8jkBYD7e2sgT8o3lqXt56DeTursjLUrfCxxzafv6xy30oRJArnTnqUtzbil1
p6mfQS/EA9CnWJq0b4GDNKhu8w6KIFZoVFZRJAReqABaH45FiGVe09YNozt8
cxGLLvJAL/bBAckYIF+ztflwmRNaqLZUN1pqqXyBrVbPkFqtNF+t0X5LFnZn
cWzexD67Wazh9QSVctM74FcI7z4HCpeWTp3wYxV9sxXQN9lnAcpghp8qewpO
56r1KRLKauREfj27T0CFBwfgbnZzna/kOFUVqCSZ0mK7IokU7125kHE1v0hq
cI+2gGoM7MWS1Hqhxt7DfVvpXBx2cJUyCZR0pbJuruUYk5RxkulFcYq7gCnx
Na0IZo7Qncat6jZJ5Xm8SePaVIr+2c2ID1xLRTObXTjl2WpsIzPmbgxvb9fd
dRdxMbtjgLHgtabgfd+5an9a2SeHm2aSy9KbVNdc8v258xpHznH660poPm3O
UshNyrl+mQWpkBxpLTg48ZVIQ86QjHiU3wjZKuWYNGkytMaZiQofgYA0NCXS
tIHFuYhLa5Bunydhlj7bquUDrLeEfhLaig2qpIPsKQPKJtRx2YjrpJJOMehi
gjOC+f30hm0iwxDC47UIp2RLU+IiKHkCGYIx/STM0rdGtcKYWgfW9U0BnmSq
k9aermYQT2AWhpOJ0mFQu71i/xyHiWHHB9/Ze+LCWcAbgcWBR411EiFzAltK
MknPIIkozlPKnH9FUZdd0qJbtrPLVdHNB1KshXC9/eakw0fbrZ/fN9+edrrd
R833N4f6+NXg9E33xcG0FTx68bM8Peyq4V9blOdU2bMKcsIDVtQ/dRh3MhLd
38NN69O/FdRUid5ltHS0wPjdmIonXiH/AI5/KP/Iuq1jwe5SXFwUV++PqFzF
1t1VZ6ej6xSF9qhjB6FOpBnx2Kfo/rlh1Cin9VVAKcuo7JEB7W0eDGXczLZm
/S2wtU9xXJTyLvQ+9pa/UEr/QMwvMuYLxf0Cya8y9t9Zgs4ic6rcjmMrkykL
l1+DOtHtXkGQD8ycCtkIUzXVwrUdR7Jos8zGIMhQ5y8qc1zZajy5A1l+IdQz
rwAZPK1ey9By9KyBhwADMoMplmpLnCmYSCkPJ2O9UeBueRxz/xqfvfFe4lI9
eoXl3tQBj+i2SHMfr3hoNFZEj/oF8IPPw4S8Ia+00LCy50tyMKSUxEIbvJCN
ymeCbbpaSXoz7CCFJVSo51a3eWeBdw5K4eGDgC7hAFdATstxFr7YdM+MQcQG
pn8qHPXrm9/uwFEL7/mI4cuR2Kowq6hbCLWwhlPRsS8IuKiyfP5Lc+OvaevJ
Sbhz8Sp6PXg7ef8o/G3/9duzZniwfXjwtHezf/DkgPf2Bs+qiIsYef9aValA
lRlNT9DrDXezUJbEt4K4FgT6Muo6ucP5uHEL4uF9q7+V6IBj7qcDqxWS71Xl
mne5tpDFICwkpDK7Link7s3YnjR+qMg/lp8XWocUCn5ddEYeZGVDDDsW/KFi
+RQTCo4N0YCDLdktmUS7GuX+wBJpeCdKCwVD3FOE4htW0F+AIgN8lEMXZflD
DvBeCo4ay4G7jQNGaGmu8Y1XhqFo+6BS5AyHdgBuNLjjwF5+bQer2JJXWA5S
ih7U2vvr7C2HitDZvLbl8bQqRAwz8zd7d4VEQ4Ut8L64abRh8W4M8MujBfJQ
56ZkMY5G2YvLQrgoPAbG0OdQ5FygW2NHnZedOYWgRkQC5toKQYuBNLHQ1fej
Ke6zOG7BH8/U3FSIQbCjH1J7n0wmjRVt/kf7JuLcLuMKEP00n7nz6UJxF6Ar
7v1O22uzT/pGApamPxyCdT/0auM8fWWO/cgoA4aQoJEFNB8cKg5yFw/YMpsV
iTqMWiAOEJyQWOEFy1JeVQvMn5xHZQIF3txRQv8YlpTzZUfqvpxYlCN+cm7M
EylwZElG/DFcmY9lyziDf37RAxfg/Q8CqCAY+jYAAA==

-->

</rfc>
