<?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.39 (Ruby 3.4.9) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-httpapi-digest-fields-problem-types-06" category="std" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.34.0 -->
  <front>
    <title>HTTP Problem Types for Digest Fields</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-httpapi-digest-fields-problem-types-06"/>
    <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="2026" month="June" day="24"/>
    <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 53?>

<t>This document specifies HTTP problem types that servers can use in responses to problems encountered while dealing with a request carrying integrity fields and integrity preference fields. Using an HTTP problem type, the server can provide machine-readable error details to aid debugging or error reporting.</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 57?>

<section anchor="introduction">
      <name>Introduction</name>
      <t><xref target="DIGEST"/> and <xref target="UNENC-DIGEST"/> define HTTP fields for exchanging integrity digests and preferences, but do not specify, require, or recommend any specific behavior for error handling relating to integrity by design. The responsibility is instead delegated to applications. This document defines a set of HTTP 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 an HTTP 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>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"/> and updated in <xref target="UNENC-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>
      <t>Generally, clients that consume problem details cannot rely on the presence of any problem type field; see <xref section="3.1" sectionFormat="of" target="PROBLEM"/>. The problem types in this document define extension members (<xref section="3.2" sectionFormat="of" target="PROBLEM"/>) that are optional for servers to populate and send. While populating all extension members can improve the usefulness of the problem type response, omission of any extension member defined in this document has no special meaning.</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>The following example shows a request with the content <tt>{"title": "New Title"}</tt> (plus LF). The digest fields use the MD5 algorithm, which is not supported by the server as the algorithm is deprecated.</t>
        <figure>
          <name>A request with md5 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
Repr-Digest: md5=:Uwq9xB4MJtDTknVOSEE1WA==:
Content-Digest: md5=:Uwq9xB4MJtDTknVOSEE1WA==:
Unencoded-Digest: md5=:Uwq9xB4MJtDTknVOSEE1WA==:

{"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, md5=0
Want-Content-Digest: sha-512=10, md5=0
Want-Unencoded-Digest: sha-512=10, md5=0

{
  "type": "https://iana.org/assignments/http-problem-types#\
    digest-unsupported-algorithms",
  "title": "Unsupported hashing algorithms",
  "unsupported_algorithms": [
    {
      "algorithm": "md5",
      "header": "Repr-Digest"
    },
    {
      "algorithm": "md5",
      "header": "Content-Digest"
    },
    {
      "algorithm": "md5",
      "header": "Unencoded-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 md5 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: md5=10

]]></sourcecode>
        </figure>
        <figure>
          <name>Response indicating the problem</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": "md5",
      "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 cannot be used if the server is not able to parse the integrity fields and obtain a value according to <xref section="4.5" sectionFormat="of" target="STRUCTURED-FIELDS"/>, for example because of a syntax error.</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="mismatched-digest-values">
        <name>Mismatched Digest Values</name>
        <t>This section defines the "https://iana.org/assignments/http-problem-types#digest-mismatched-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>mismatched_digests</tt> extension member is defined, whose value is a JSON <xref target="JSON"/> array of entries identifying each mismatched 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 mismatched 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 mismatched 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 mismatched 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-mismatched-values",
  "title": "Mismatched digest values",
  "mismatched_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>All security considerations from <xref section="5" sectionFormat="of" target="PROBLEM"/>, <xref section="6" sectionFormat="of" target="DIGEST"/>, and <xref section="7" sectionFormat="of" target="UNENC-DIGEST"/> apply as well.</t>
      <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, server operators could assess the risk of disclosing error details
and prefer a general problem type over a more specific one.</t>
      <t>There is no method defined for the server to communicate a digest value that it
calculated for the purpose of validation. Such information 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-mismatched-values-problem-type">
        <name>Registration of "digest-mismatched-values" Problem Type</name>
        <dl>
          <dt>Type URI:</dt>
          <dd>
            <t>https://iana.org/assignments/http-problem-types#digest-mismatched-values</t>
          </dd>
          <dt>Title:</dt>
          <dd>
            <t>Mismatched Digest Values</t>
          </dd>
          <dt>Recommended HTTP status code:</dt>
          <dd>
            <t>400</t>
          </dd>
          <dt>Reference:</dt>
          <dd>
            <t><xref target="mismatched-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="UNENC-DIGEST">
        <front>
          <title>HTTP Unencoded Digest</title>
          <author fullname="Lucas Pardue" initials="L." surname="Pardue">
            <organization>Cloudflare</organization>
          </author>
          <author fullname="Mike West" initials="M." surname="West">
            <organization>Google</organization>
          </author>
          <date day="17" month="June" year="2026"/>
          <abstract>
            <t>   The Repr-Digest and Content-Digest integrity fields are subject to
   HTTP content coding considerations.  There are some use cases that
   benefit from the unambiguous exchange of integrity digests of
   unencoded representation.  The Unencoded-Digest and Want-Unencoded-
   Digest fields complement existing integrity fields for this purpose.

   This document updates the definitions of the terms "Integrity fields"
   and "Integrity preference fields" originally defined in RFC 9530.

            </t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-unencoded-digest-05"/>
      </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>
    </references>
  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA91bbXMTORL+Pr9C5Xxgty52CJAs+I4rAkkgLCFU4sDu3l5d
5BnZFhmPjDQTY1LZ337dLWlGM+MkZpdlt+ADJKOXbvXr0y3R7XajXOap6LPO
i8HgDXuj1TAVUzZYzIRhI6XZrhwLk7N9KdLEdKKY52Ks9KLPTJ5EUaLijE9h
eaL5KO9KkY+6kzyf8ZnsJrSyO6KV3ZnduZvjzt2725EphlNpjFQZfuqzg73B
PmNrjKdGATsyS8RMwF9Z3llnHZHIXGnJU/zlYOcp/APMdQ6OB/udKCumQ6H7
UQLM9aNYZUZkpjB9lutCRBd9dj/iWnDY9Z0YMp4l7CDLhc5EzgaaZ2amdN6J
5kqfj7UqZjDvaSHTRGZj9jRV8bmVBAlo580BSOFcLGB20o9Yl2XiY87GIhOa
53AY/FRkMlaafjQzrs9T3CmRJtdyWOQiYalIxkJHFyIrgGHGViTLmBVV5x2w
itOe4zr8PuUyhe9O9E9QDz2lxzjEdTxxQ6a/sYEz8ZO8ED0/bQM/bAy1mhux
4fbYwLVjmU+KIWoDFTsfe91u3KBbXJeCIkweUG2s79mNe1LdtNPG5xlVb5JP
004U8SKfKI26AU4YGxVpam20c8i1LAz7MRUySTs0CqfnmfxEqutba0gVB2Oj
UeHkOqWFT/JquBeraWcJiVdFzA17w3VSiGUUnqWqSEagAVEjkOKyJ/T3jNbW
9pcZ2PJxj71RaSqbFI8V2H6u7OAyksBMdyDiGj2Qm5zhgidj/OKowZ9YFVmO
7n2Q83QRRZnSU9jngsx09+D53skAWNl/9mjr/l34cvp67/Wzrv9+0N3tNXQ2
lKZbZCKLVSISpz1Y9+b46OmrvUO71YOtH+DTyeD49Nng9Hhvt7t/sPdq98QO
bm9twiA6gf19cxPpwk8Pf3h0D5l6eXL0moYe3tt6FEUyG1UsR1G322V8CJ7H
4zyKBhNpGMSsYgphBXxTxBIsyVgfc8ZEPmZYPuEwQ+gLoQ2LecYKI0ARTAsI
FxBgYIbySwzDAxYYU8C55xOZCpYITm4/B0tnHJZ9KDCOxlzrBX6XMHusZb5g
1pYpLFUfZ1qMYLcsFm68x04NrgNOWtyuA7fCMUu8wuCFTASEBXD0THQh+CUc
pjOhNYSUROSgdDoBlwn8OizGY9wcxuwMLTAmwqeeFeFUJkkqomgNI6dWSRFT
rIsuL63ur66I/8vL0CDgYyJGQN9y7M6JMU18jCc8G9flYI3DCqI6vllnEDNB
aSxTXmWLdZKn1IKygBZgvqDRBJYuvFZjNhQTfiFhfFQeC4gmpBUtIEThDyCC
ioMhMCGMHGc9NgCBOlXLoUxxFEwHHDEHUcKsVIw5RnIU4WyWypiczeDC0MTs
+eFMoJ2cqdEyS/vu8tK5w9XV99buUIdDgSaXIFNOsyEhy3iCvwq7hpfbzvlX
Mcgo2idV8uksBUVUW06FMXyM1gdCy+K0AEuEpJyjQHiqsrFB2zx7Zj91LcI4
I3pnx2Kmyy+OEToeuh93NgK7AAaBc0xDw08UCJOMpJih9fbYThbKDGNbirqL
kTzIT4v3Is5hC9CY530oYk6eTkrA3S5AbImVsqjk8Re5I4jZMDNR8wxjEZIZ
QRRXc5ztNAF6+e233xgG367TBLjt66PBXp/d+fUOS9Eh5xoEg4tmwCLETobR
NIrwKBubvU324O5d9hQM/diKJfK6GhD+CIS64Q7+j/cG4sE7DnPqegWgOOHd
rc17j++v04/3trYfQwyPLiF2d1BcnRAn8IxbRGLQD9GHDCGSeqpf+5WSlQMD
ReY0DhmmtAzTWScCiG6Rwmk1CcKAmZDyGpODjf4XjPXZf4jcJf0N88ox3Hik
FK2mkQloVmj8vEQUNsNewd//ja5QSRhPYQrAQOvT6AG7GDEk/R5FJ2oqvF6N
1XgYXdCpOHxFnyK9Ol9BxxuSaUDSJZOBsBYD+BTo0RClXfq8uuphTgTTFhqS
WKcZAjrEUeeGINBpMwXQBi15KCJcp2EJirzNQy1xFLOEwimN1HNIwCLrhG62
hLY0K5Euw239+C4GYIXhszz+THtNoQDheoG/G6xKNP4Up9KWJyQm6/AdEsBI
qykQQn8qqdSj/lK52XQB4qDYgsgGNsF/YBNMSQufGYAW1ELyE50I40bGMCFC
rMKtfjp8xSwKwsOrIk9pVzr7zgyrKvmRPcV0FEpirV79Waar8GIE5fwypeUT
LZqHAk7ERxC7AcgEKVllFUIiw1RxXGjIRyKrUnFlXRDobjA1prIgrpI4TJM+
Rm6cc+YiwxltA4e1wVJqmsdOjw967Ag+6GWgL1QEyI6SVU1V62wh8gpnwKFd
WiJUIZLy0OvkiVpYtmAHyw3I2sVViyx9jpwWaS7B01cWSY/VMnCOBoIUSzGs
nGKNROI8E6owKZH1egyQGAGpMpHDVpCWYA78ZvNrCeByqyioT1gup4J0Bdso
xGtACQvQyjBQApBQBHwrBYCrLDmVCZ+bLSirK8zrqe1NaLb+EGhm5d6WFrfQ
0kIjAXmZaDKJ/QYAmAQNJwhbtA0FVJXb6O4gmo29CAErrkAOMQKGArPwc+oJ
pCmgVRsoTLnSAJPlSXz6d3gDjGjhbd2KF/QNrorYNjy8Vd0/wR8EuPWJ8877
kLxrfr1EaC1hOZQuPoJmsSEDCA4bKgRNq43v1Tb+vnIWNcMZPCWF+ZIJqyM1
K9AhyFYwavbYO5K3G7ApOF1Cl7xiirDJGjIYNFS8Gdoj8JA3TlTWZFANuJaS
F1hz6+sNBjABgEfr1XCUqYAKmsqftTUWYocXDjvslPjAlZXt+Cg+H9fcjGhq
p+5FOyHGDGJMIBnQAgZibEgRhFXWqskcSYEROhiobaq08LJtwyNWBoHE486V
w7YLEX6dc2ZsyIVgXSSunmidwaLps+XY7KytYVlGBXRvBWIhh8TvvJ5SwXg1
REs4NfCnsQ8Quj8FhYBqJY5etIdjuGjhj2W3qmioIdUWVGzVYbqz8T4U1uSb
Z+W+Z8ER3DbYMoQ1Ltj4qFSVP+di4bV2DauOiA1dK1PA3pLfeEVN23gQGMoN
TEVBeS1qObAddG+iWKuBPTS4YwIBOfKNpkLP+WzNV0gmYPh5w034EFBAe0tK
HvEknGkLTPJErC7RPAKTt8aQyBExAeuXiMb0mrDLZXcq+kxQZJeW5RPy2WVV
7LwWczagX67O2HeztDDs1f73Nhc4rOK800OFw92tigt/NGnqLoq9iKC05aZh
jeR6IGVUSLKsDn1zdDJgG0Olzm3PDWvN6IXCKhHKqJ476w3VJlWZO3EsZvmS
gQDZ9Nk02XrcP51/ePTx6YPDl/nu4Dx7e3Syt7f5bufx437UrFJvmX5a9jBX
XBAtVweVfZd9RmOPOzt1fcKerT6MV0YrYNa1AVv/xXV/Tfq+6N+8u06Suntz
b6AxrS3t9sRvpoEAx1nWQAjE6RoH65+/ydIGxO/Yp6mQdiujsuljH9ddbPY5
xQdbDMU8AZPNpfFjy0IhWnQ7SlO5kBpV9kepmgz6mTaRYTPlptRhu6DZNQkq
rKv6S/zq+R6EMZlD+bKxee/+TaGs7Rlovdj/ujEQ8EYoaPK/WoT+S2PCt+6f
Tc3+AZdAPa3h1Qr1mv2V+1uErX9GdSEtnS7h4mZVwVaoKsjlAoiGDShvvx50
t64TPMIrm/gWlvv7DjRjcGl3kV5ZcqMCbyq20QKRFrLWKDgYe+ZSyFl7E+9G
2w+Aag7SxYbqenAHMES2rXJOXuzgLnUSGNIaPX9zLmdYe82KUtvhEndR1Axt
jhgFNncWt6djka4NsLbm2jSuJMJ7GzWkxjD3/MUgRq+qqqZ/0NtC6bRuXq+u
1t01ncWe/lIEi2pmFhBgP9qLiVtqNmdo/3ONoT+7WHPknJz/XlXaly3EgoKr
3oeqi8C3ohxpLTgE5pVIQyFUTHlW3VTZDjo1ekBR1jVLVWFHC7ShqTtADCwv
sFythnRHvEjLnoDtqN/Bvk8aU2cIOziaLjHJalXbrTFQ2RLLDVK7MUyiWLVN
Yf3I3//NZZpCyjvHBhv60oKkCBZdQEFhzKhIy5r0D5VhEwGrMEXMlU6TWglm
L7ODs2DbaSggnOa6yGzdRMoyxdAgiSyv6uRKfqGq6wFpadV1uipauaXwWorw
+z8f7vDp1ubLTxvvj3YGg+2NTxcv9Ku346OfB8/3F5vJ9vOX8ujFQE0+PKCy
qCme25CQI9Q0fx8wrhUkxrr792xE/1aQUCN11xHQwRLnd3MakfgWxOMkfltV
Ug7bwILDtay4LKt+PkpytwnuDr08HV31KfRHnTv8dCjNlOfxRPz5EGpakvob
oajyAQSx1gZCpSxL1my0BXmNKIuLWhWFsce+PQgueW7J+JVcvlbSryj+LfP+
tT31Mit7w3YCW5lMXbX8HIyJbp0DNd4xLQOq9QBLsQfXyRzJor8ym3+g4mxf
oFcAcrP38BoI+ZUQT0v/5f1b8+KLdsvsVRUggNJbwtZzTTCBf9Qbn+ipFwoi
Lc9zHp/jjRUfFq6ZQc/E3BtEEBFdYmoe480jzcYW78EowD34fk3IC4pIS72q
fFclxxMqDyyqwXcCWf1MwKZre/gHCw5NWEJBf7rJ5rUN6xaKwsMnCd0NA6SA
YprjKnwZ6+/e4B9Y/qUg1E8//3INhFp6/UwCvxmErYqwAtNCkHVva7tpYl8R
auGzqf7xjxt3Pyw2Hx6mT0/eZu/G7+efttNf9t69f7OR7m+92H80vNjbf7jP
h7vjx02sRXJcBWvhOZdgLWw3lT4zFPTmyF2U1BXxrWCtdo6vw63D5ZHHTWtn
whVAF4i+QlWNxABzfnVDMPh5prBaf/mzWletuEsYe41BaijIcJ65opC7t2w7
UHwZPxjXBv1zKZ9WtmovDdaDkW0YifzLsHX35tgP/oDLGg+Q0VAWmMHm4Ang
sbvSxKmiUF1/fGljYyr4eRgXI6gNJ/6iK3yNEcRYhCUOPpUXkBJ9fFqFJkuk
Fx0qLRRMcY91wne+4EuAicb4bI3uIKunThBIFcg7l2N30Qna0NKcm3WfkNQM
Ram0PwaYOcXniZ2IDCfXHDyqbkbB/237La3nTUWXffaJQPnqSWUux2oH9CG/
Q7ZIyhcWo5pMmi8RluFXmUdLIOms0DNlm0/uKS7CUHZSUMenymBOlpiI7eqo
lXbX2MHO652WZdJHhCXm3OpBi7E0udDNB7Yeg1pQueR/THXcUsiIcJ5/+fAz
n897K4agf9sXJ8d2G9cJGfnC6tqHISEXoBX3yK0f9dkXfYECW9P/FoN9b3sT
c+wf5eM4CsqALxRooAmth/iOk9ytBn65vAyJOsAcEAdvJlgYvNq5UVbNNvcX
l1GdQCCbaxr5v0cknoYjaUl9riSWVKtfXBgtGoE8ri/Mf49IAkq3SwX/88oQ
3D/6PzoqZDfrOAAA

-->

</rfc>
