<?xml version='1.0' encoding='utf-8'?> 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.6.36 (Ruby 3.2.2) -->
<?rfc tocindent="yes"?>
<?rfc strict="yes"?>
<?rfc compact="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc docmapping="yes"?>

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-httpbis-digest-headers-13" number="9530" submissionType="IETF" category="std" consensus="true" updates="" obsoletes="3230" tocInclude="true" sortRefs="true" symRefs="true" xml:lang="en" version="3">

  <!-- xml2rfc v2v3 conversion 3.17.4 -->
  <front>
    <title>Digest Fields</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-digest-headers-13"/> name="RFC" value="9530"/>
    <author initials="R." surname="Polli" fullname="Roberto Polli">
      <organization>Team Digitale, Italian Government</organization>
      <address>
        <postal>
          <country>Italy</country>
        </postal>
        <email>robipolli@gmail.com</email>
      </address>
    </author>
    <author initials="L." surname="Pardue" fullname="Lucas Pardue">
      <organization>Cloudflare</organization>
      <address>
        <email>lucaspardue.24.7@gmail.com</email>
        <email>lucas@lucaspardue.com</email>
      </address>
    </author>
    <date year="2023" month="July" day="10"/> month="February" year="2024"/>
    <area>Applications and Real-Time</area>
    <workgroup>HTTP</workgroup>
    <keyword>Digest</keyword>
    <abstract>
      <?line 87?>
<t>This document defines HTTP fields that support integrity digests. The
Content-Digest
<tt>Content-Digest</tt> field can be used for the integrity of HTTP message content. The
Repr-Digest
<tt>Repr-Digest</tt> field can be used for the integrity of HTTP representations.
Want-Content-Digest
<tt>Want-Content-Digest</tt> and Want-Repr-Digest <tt>Want-Repr-Digest</tt> 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 <tt>Digest</tt> and Want-Digest <tt>Want-Digest</tt> HTTP
fields.</t>
    </abstract>
    <note removeInRFC="true">
      <name>About This Document</name>
      <t>
        Status information for this document may be found at <eref target="https://datatracker.ietf.org/doc/draft-ietf-httpbis-digest-headers/"/>.
      </t>
      <t>
        Discussion of this document takes place on the
        HTTP Working Group mailing list (<eref target="mailto:ietf-http-wg@w3.org"/>),
        which is archived at <eref target="https://lists.w3.org/Archives/Public/ietf-http-wg/"/>.
        Working Group information can be found at <eref target="https://httpwg.org/"/>.
      </t>
      <t>Source for this draft and an issue tracker can be found at
        <eref target="https://github.com/httpwg/http-extensions/labels/digest-headers"/>.</t>
    </note>
  </front>
  <middle>
    <?line 99?>
<section anchor="introduction">
      <name>Introduction</name>
      <t>HTTP does not define the means to protect the data integrity of content or
representations. When HTTP messages are transferred between endpoints, lower layer lower-layer
features or properties such as TCP checksums or TLS records <xref target="TLS"/> target="RFC8446"/> can provide some integrity protection. However, transport-oriented integrity provides a
limited utility because it is opaque to the application layer and only covers
the extent of a single connection. HTTP messages often travel over a chain of
separate connections. In between connections connections, there is a possibility for
data corruption. An HTTP integrity mechanism can provide
the means for endpoints, or applications using HTTP, to detect data corruption
and make a choice about how to act on it. An example use case is to aid
fault detection and diagnosis across system boundaries.</t>
      <t>This document defines two digest integrity mechanisms for HTTP.
First, content integrity, which acts on conveyed content (<xref section="6.4" sectionFormat="of" target="RFC9110"/>).
Second, representation data integrity, which acts on representation data (<xref section="8.1" sectionFormat="of" target="RFC9110"/>). This supports advanced use cases cases, such as validating the
integrity of a resource that was reconstructed from parts retrieved using
multiple requests or connections.</t>
      <t>This document obsoletes RFC 3230 <xref target="RFC3230"/> and therefore the Digest <tt>Digest</tt> and Want-Digest <tt>Want-Digest</tt> HTTP
fields; see <xref target="obsolete-3230"/>.</t>
      <section anchor="document-structure">
        <name>Document Structure</name>
        <t>This document is structured as follows:</t>
        <ul spacing="normal">
          <li>
            <t>New request and response header and trailer field definitions.
            </t>
            <ul spacing="normal">
              <li>
                <xref target="content-digest"/> (Content-Digest),</li> (<tt>Content-Digest</tt>),</li>
              <li>
                <xref target="representation-digest"/> (Repr-Digest), (<tt>Repr-Digest</tt>), and</li>
              <li>
                <xref target="want-fields"/> (Want-Content-Digest (<tt>Want-Content-Digest</tt> and Want-Repr-Digest).</li> <tt>Want-Repr-Digest</tt>).</li>
            </ul>
          </li>
          <li>
            <t>Considerations specific to representation data integrity.
            </t>
            <ul spacing="normal">
              <li>
                <xref target="state-changing-requests"/> (State-changing requests),</li>
              <li>
                <xref target="digest-and-content-location"/> (Content-Location),</li>
              <li>
                <xref target="resource-representation"/> contains worked examples of Representation representation data
in message exchanges, and</li>
              <li>
                Appendixes <xref target="examples-unsolicited"/> target="examples-unsolicited" format="counter"/> and <xref target="examples-solicited"/> target="examples-solicited" format="counter"/> contain worked examples
of Repr-Digest <tt>Repr-Digest</tt> and Want-Repr-Digest <tt>Want-Repr-Digest</tt> fields in message exchanges.</li>
            </ul>
          </li>
          <li>
            <xref target="algorithms"/> presents hash algorithm considerations and defines
registration procedures for future entries.</li>
        </ul>
      </section>
      <section anchor="concept-overview">
        <name>Concept Overview</name>
        <t>The HTTP fields defined in this document can be used for HTTP integrity. Senders
choose a hashing algorithm and calculate a digest from an input related to the
HTTP message. The algorithm identifier and digest are transmitted in an HTTP
field. Receivers can validate the digest for integrity purposes. Hashing
algorithms are registered in the "Hash Algorithms for HTTP Digest Fields" registry (see
<xref target="establish-hash-algorithm-registry"/>).</t>
        <t>Selecting the data on which digests are calculated depends on the use case of the
HTTP messages. This document provides different fields for HTTP representation
data and HTTP content.</t>
        <t>There are use cases where a simple digest of the HTTP content bytes is
required. The <tt>Content-Digest</tt> request and response header and trailer field is
defined to support digests of content (<xref section="6.4" sectionFormat="of" target="RFC9110"/>); see
<xref target="content-digest"/>.</t>
        <t>For more advanced use cases, the <tt>Repr-Digest</tt> request and response header
and trailer field (<xref target="representation-digest"/>) is defined. It contains a digest value
computed by applying a hashing algorithm to selected representation data
(<xref section="8.1" sectionFormat="of" target="RFC9110"/>).

Basing <tt>Repr-Digest</tt> on the selected
representation makes it straightforward to apply it to use cases where the
message content requires some sort of manipulation to be considered as
representation of the resource or the content conveys a partial representation of a resource,
such as Range Requests range requests (see <xref section="14" sectionFormat="of" target="RFC9110"/>).</t>
<t><tt>Content-Digest</tt> and <tt>Repr-Digest</tt> support hashing algorithm agility.
The <tt>Want-Content-Digest</tt> and <tt>Want-Repr-Digest</tt> fields allow
endpoints to express interest in <tt>Content-Digest</tt> and <tt>Repr-Digest</tt> <tt>Repr-Digest</tt>, respectively, and to express algorithm preferences in either.</t>
        <t><tt>Content-Digest</tt> and <tt>Repr-Digest</tt> are collectively termed
Integrity fields.
"Integrity fields".
<tt>Want-Content-Digest</tt> and <tt>Want-Repr-Digest</tt> are
collectively termed Integrity "Integrity preference fields.</t> fields".</t>
        <t>Integrity fields are tied to the <tt>Content-Encoding</tt>
and <tt>Content-Type</tt> header fields. Therefore, a given resource may have multiple
different digest values when transferred with HTTP.</t>
        <t>Integrity fields apply to HTTP message content or HTTP representations. They do
not apply to HTTP messages or fields. However, they can be combined with other
mechanisms that protect metadata, such as digital signatures, in order to
protect the phases of an HTTP exchange in whole or in part. For example, HTTP
Message Signatures <xref target="SIGNATURES"/> target="RFC9421"/> could be used to sign Integrity fields, thus
providing coverage for HTTP content or representation data.</t>
        <t>This specification does not define means for authentication, authorization, or privacy.</t>
      </section>
      <section anchor="obsolete-3230">
        <name>Obsoleting RFC 3230</name>
        <t><xref target="RFC3230"/> defined the <tt>Digest</tt> and <tt>Want-Digest</tt> HTTP fields for HTTP integrity.
It also coined the term terms "instance" and "instance manipulation" in order to
explain concepts that are now more universally defined, and implemented, as HTTP
semantics concepts, such as selected representation data (<xref section="8.1"
sectionFormat="of" target="RFC9110"/>).</t> target="RFC9110"/>), that are now more universally defined and implemented as HTTP
semantics.</t>
        <t>Experience has shown that implementations of <xref target="RFC3230"/> have interpreted the
meaning of "instance" inconsistently, leading to interoperability issues. The
most common issue relates to the mistake of calculating the digest using (what
we now call) message content, rather than using (what we now call)
representation data as was originally intended. Interestingly, time has also
shown that a digest of message content can be beneficial for some use cases. So cases, so
it is difficult to detect if non-conformance to <xref target="RFC3230"/> is intentional or
unintentional.</t>
        <t>In order to address potential inconsistencies and ambiguity across
implementations of <tt>Digest</tt> and <tt>Want-Digest</tt>, this document obsoletes
<xref target="RFC3230"/>. The Integrity fields (Sections <xref format="counter" target="content-digest"/> and
<xref format="counter" target="representation-digest"/>) and Integrity preference fields (<xref target="want-fields"/>)
defined in this document are better aligned with current HTTP semantics and
have names that more clearly articulate the intended usages.</t>
      </section>
      <section anchor="notational-conventions">
        <name>Notational Conventions</name>
        <t>The
        <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 BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
    when, and only when, they appear in all capitals, as shown here.</t> here.
        </t>
        <?line -18?>
<t>This document uses the Augmented BNF defined in <xref target="RFC5234"/> and updated by
<xref target="RFC7405"/>. This includes the rules: rules CR (carriage return), LF (line feed), and CRLF (CR LF).</t>
        <t>This document uses the following terminology from <xref section="3" sectionFormat="of" target="STRUCTURED-FIELDS"/> target="RFC8941"/> to specify syntax and parsing:
Boolean, Byte Sequence, Dictionary, Integer, and List.</t>
        <t>The definitions "representation", "selected representation", "representation
data", "representation metadata", "user agent", and "content" in this document are to be
interpreted as described in <xref target="RFC9110"/>.</t>
        <t>This document uses the line folding strategies
described in <xref target="FOLDING"/>.</t> target="RFC8792"/>.</t>
        <t>Hashing algorithm names respect the casing used in their definition document (e.g., SHA-1, CRC32c).</t>
        <t>HTTP messages indicate hashing algorithms using an Algorithm Key (<contact fullname="algorithms"/>).
Where the document refers to an Algorithm Key in prose, it is quoted (e.g., "sha", "crc32c").</t>

        <t>The term "checksum" describes the output of the application of applying an algorithm
        to a sequence of bytes, whereas "digest" is only used in relation to
        the value contained in the fields.</t>
        <t>Integrity fields:
<t>"Integrity fields" is the collective term for <tt>Content-Digest</tt> and <tt>Repr-Digest</tt></t>
        <t>Integrity
<tt>Repr-Digest</tt>.</t>
<t>"Integrity preference fields: fields" is the collective term for <tt>Want-Repr-Digest</tt>
and <tt>Want-Content-Digest</tt></t> <tt>Want-Content-Digest</tt>.</t>
      </section>
    </section>
    <section anchor="content-digest">
      <name>The Content-Digest <tt>Content-Digest</tt> Field</name>
      <t>The <tt>Content-Digest</tt> HTTP field can be used in requests and responses to
communicate digests that are calculated using a hashing algorithm applied to
the actual message content (see <xref section="6.4" sectionFormat="of" target="RFC9110"/>). It is a
<tt>Dictionary</tt>
Dictionary (see <xref section="3.2" sectionFormat="of" target="STRUCTURED-FIELDS"/>) target="RFC8941"/>),
where each:</t>
      <ul spacing="normal">
        <li>key conveys the hashing algorithm (see <xref target="algorithms"/>)
used to compute the digest;</li>
        <li>value is a <tt>Byte Sequence</tt> Byte Sequence (<xref section="3.3.5" sectionFormat="of" target="STRUCTURED-FIELDS"/>), target="RFC8941"/>) that
conveys an encoded version of the byte output produced by the digest
calculation.</li>
      </ul>
      <t>For example:</t>
      <sourcecode type="http-message"><![CDATA[
NOTE: '\' line wrapping per RFC 8792

Content-Digest: \
  sha-512=:YMAam51Jz/jOATT6/zvHrLVgOYTGFy1d6GJiOHTohq4yP+pgk4vf2aCs\
  yRZOtw8MjkM7iw7yZ/WkppmM44T3qg==:
]]></sourcecode>
      <t>The <tt>Dictionary</tt> Dictionary type can be used, for example, to attach multiple digests
calculated using different hashing algorithms in order to support a population
of endpoints with different or evolving capabilities. Such an approach could
support transitions away from weaker algorithms (see <xref target="sec-agility"/>).</t>
      <sourcecode type="http-message"><![CDATA[
NOTE: '\' line wrapping per RFC 8792

Content-Digest: \
  sha-256=:d435Qo+nKZ+gLcUHn7GQtQ72hiBVAgqoLsZnZPiTGPk=:,\
  sha-512=:YMAam51Jz/jOATT6/zvHrLVgOYTGFy1d6GJiOHTohq4yP+pgk4vf2aCs\
  yRZOtw8MjkM7iw7yZ/WkppmM44T3qg==:
]]></sourcecode>
      <t>A recipient <bcp14>MAY</bcp14> ignore any or all digests. Application-specific behavior or
local policy <bcp14>MAY</bcp14> set additional constraints on the processing and validation
practices of the conveyed digests.
The security considerations covers cover some of the issues related to
ignoring digests (see <xref target="sec-agility"/>)
and validating multiple digests (see <xref target="sec-exhaustion"/>).</t>
      <t>A sender <bcp14>MAY</bcp14> send a digest without
knowing whether the recipient supports a given hashing algorithm, or even knowing
that algorithm. A sender <bcp14>MAY</bcp14> send a digest if it knows the recipient will ignore it.</t>
      <t><tt>Content-Digest</tt> can be sent in a trailer section.
In this case,
<tt>Content-Digest</tt> <bcp14>MAY</bcp14> be merged into the header section; see <xref section="6.5.1" sectionFormat="of" target="RFC9110"/>.</t>
    </section>
    <section anchor="representation-digest">
      <name>The Repr-Digest <tt>Repr-Digest</tt> Field</name>
      <t>The <tt>Repr-Digest</tt> HTTP field can be used in requests and responses to
communicate digests that are calculated using a hashing algorithm applied to
the entire selected representation data (see <xref section="8.1" sectionFormat="of" target="RFC9110"/>).</t>
      <t>Representations take into account the effect of the HTTP semantics on
messages. For example, the content can be affected by Range Requests range requests or methods methods, such as HEAD, while the way the content is transferred "on the wire" is
dependent on other transformations (e.g., transfer codings for HTTP/1.1 - HTTP/1.1; see
<xref section="6.1" sectionFormat="of" target="RFC9112"/>). To help illustrate HTTP representation concepts,
several examples are provided in <xref target="resource-representation"/>.</t>
      <t>When a message has no representation data data, it is still possible to assert that no
representation data was sent by computing the digest on an empty
string (see <xref target="usage-in-signatures"/>).</t>
      <t><tt>Repr-Digest</tt> is a <tt>Dictionary</tt> Dictionary (see <xref section="3.2" sectionFormat="of" target="STRUCTURED-FIELDS"/>) target="RFC8941"/>), where each:</t>
      <ul spacing="normal">
        <li>key conveys the hashing algorithm (see <xref target="algorithms"/>)
used to compute the digest;</li>
        <li>value is a <tt>Byte Sequence</tt>, Byte Sequence that conveys an encoded version of the byte
output produced by the digest calculation.</li>
      </ul>
      <t>For example:</t>
      <sourcecode type="http-message"><![CDATA[
NOTE: '\' line wrapping per RFC 8792

Repr-Digest: \
  sha-512=:YMAam51Jz/jOATT6/zvHrLVgOYTGFy1d6GJiOHTohq4yP+pgk4vf2aCs\
  yRZOtw8MjkM7iw7yZ/WkppmM44T3qg==:
]]></sourcecode>
      <t>The <tt>Dictionary</tt> Dictionary type can be used, for example, used to attach multiple digests
calculated using different hashing algorithms in order to support a population
of endpoints with different or evolving capabilities. Such an approach could
support transitions away from weaker algorithms (see <xref target="sec-agility"/>).</t>
      <sourcecode type="http-message"><![CDATA[
NOTE: '\' line wrapping per RFC 8792

Repr-Digest: \
  sha-256=:d435Qo+nKZ+gLcUHn7GQtQ72hiBVAgqoLsZnZPiTGPk=:,\
  sha-512=:YMAam51Jz/jOATT6/zvHrLVgOYTGFy1d6GJiOHTohq4yP+pgk4vf2aCs\
  yRZOtw8MjkM7iw7yZ/WkppmM44T3qg==:
]]></sourcecode>
      <t>A recipient <bcp14>MAY</bcp14> ignore any or all digests. Application-specific behavior or
local policy <bcp14>MAY</bcp14> set additional constraints on the processing and validation
practices of the conveyed digests.
The security considerations covers cover some of the issues related to
ignoring digests (see <xref target="sec-agility"/>)
and validating multiple digests (see <xref target="sec-exhaustion"/>).</t>
      <t>A sender <bcp14>MAY</bcp14> send a digest without knowing whether the recipient supports a given hashing algorithm, or even knowing that algorithm. A sender <bcp14>MAY</bcp14> send a digest if it knows the recipient will ignore it.</t>
      <t><tt>Repr-Digest</tt> can be sent in a trailer section.
In this case,
<tt>Repr-Digest</tt> <bcp14>MAY</bcp14> be merged into the header section; see <xref section="6.5.1" sectionFormat="of" target="RFC9110"/>.</t>
      <section anchor="state-changing-requests">
        <name>Using Repr-Digest <tt>Repr-Digest</tt> in State-Changing Requests</name>
        <t>When the representation enclosed in a state-changing request
does not describe the target resource,
the representation digest <bcp14>MUST</bcp14> be computed on the
representation data.
This is the only possible choice because representation digest requires complete
representation metadata (see <xref target="representation-digest"/>).</t>
        <t>In responses,</t>
        <ul spacing="normal">
          <li>if the representation describes the status of the request,
<tt>Repr-Digest</tt> <bcp14>MUST</bcp14> be computed on the enclosed representation
 (see <xref target="post-referencing-status"/>);</li>
          <li>if there is a referenced resource resource, <tt>Repr-Digest</tt>
          <bcp14>MUST</bcp14> be computed on the selected representation of
          the referenced resource even if that is different from the target
          resource.
 That  This might or might not result in computing
          <tt>Repr-Digest</tt> on the enclosed representation.</li>
        </ul>
        <t>The latter case is done according to the HTTP semantics of the given
method, for example example, using the <tt>Content-Location</tt> header field (see <xref section="8.7" sectionFormat="of" target="RFC9110"/>).
In contrast, the <tt>Location</tt> header field does not affect <tt>Repr-Digest</tt> because
it is not representation metadata.</t>
        <t>For example, in <tt>PATCH</tt> PATCH requests, the representation digest
will be computed on the patch document
because the representation metadata refers to the patch document and not
to
the target resource (see <xref section="2" sectionFormat="of" target="PATCH"/>). target="RFC5789"/>).
In responses, instead, the representation digest will be computed on the selected
representation of the patched resource.</t>
      </section>
      <section anchor="digest-and-content-location">
        <name>Repr-Digest
        <name><tt>Repr-Digest</tt> and Content-Location in Responses</name>
        <t>When a state-changing method returns the <tt>Content-Location</tt> header field, the
enclosed representation refers to the resource identified by its value and
<tt>Repr-Digest</tt> is computed accordingly.
An example is given in <xref target="post-not-request-uri"/>.</t>
      </section>
    </section>
    <section anchor="want-fields">
      <name>Integrity preference fields</name> Preference Fields</name>
      <t>Senders can indicate their interest in Integrity fields and hashing algorithm
preferences using the
<tt>Want-Content-Digest</tt> or <tt>Want-Repr-Digest</tt> HTTP fields. These can be used in both
requests and responses.</t>

<t><tt>Want-Content-Digest</tt> indicates that the sender would like to
receive (via the <tt>Content-Digest</tt> field) a content digest on messages
associated with the request URI and representation metadata, using
the <tt>Content-Digest</tt> field.</t>
      <t><tt>Want-Repr-Digest</tt> metadata.

   <tt>Want-Repr-Digest</tt> indicates that the sender would like to receive
   (via the <tt>Repr-Digest</tt> field) a representation digest on messages
   associated with the request URI and representation metadata, using
the <tt>Repr-Digest</tt> field.</t> metadata.
</t>

      <t>If <tt>Want-Content-Digest</tt> or <tt>Want-Repr-Digest</tt> are used in a response, it
indicates that the server would like the client to provide the respective
Integrity field on future requests.</t>
      <t>Integrity preference fields are only a hint. The receiver of the field can
ignore it and send an Integrity field using any algorithm or omit the field
entirely,
entirely; for example example, see <xref target="ex-server-selects-unsupported-algorithm"/>. It is not
a protocol error if preferences are ignored. Applications that use Integrity
fields and Integrity preferences can define expectations or constraints that
operate in addition to this specification. Ignored preferences are an
application-specific concern.</t>
      <t><tt>Want-Content-Digest</tt> and <tt>Want-Repr-Digest</tt> are of type <tt>Dictionary</tt> Dictionary
where each:</t>
      <ul spacing="normal">
        <li>key conveys the hashing algorithm (see <xref target="algorithms"/>);</li>
        <li>value is an <tt>Integer</tt> (<xref section="3.3.1" sectionFormat="of" target="STRUCTURED-FIELDS"/>) target="RFC8941"/>)
that conveys an ascending, relative, weighted preference.
It must be in the range 0 to 10 inclusive.
1 is the least preferred, 10 is the most preferred,
and a value of 0 means "not acceptable".</li>
      </ul>
      <t>Examples:</t>
      <sourcecode type="http-message"><![CDATA[
Want-Repr-Digest: sha-256=1
Want-Repr-Digest: sha-512=3, sha-256=10, unixsum=0
Want-Content-Digest: sha-256=1
Want-Content-Digest: sha-512=3, sha-256=10, unixsum=0
]]></sourcecode>
    </section>
    <section anchor="algorithms">
      <name>Hash Algorithm Considerations and Registration</name>
      <t>There are a wide variety of hashing algorithms that can be used for the purposes
of integrity. The choice of algorithm depends on several factors such as the
integrity use case, implementation needs or constraints, or application design
and workflows.</t>
      <t>An initial set of algorithms will be registered with IANA in the "Hash
Algorithms for HTTP Digest Fields" registry; see
<xref target="establish-hash-algorithm-registry"/>. Additional algorithms can be registered
in accordance with the policies set out in this section.</t>
      <t>Each algorithm has a status field, which field that is intended to provide an aid to
implementation selection.</t>
      <t>Algorithms with a status value of "Active" are suitable for many purposes and
it is <bcp14>RECOMMENDED</bcp14> that applications use these algorithms. These can be used in
adversarial situations where hash functions might need to provide resistance to
collision, first-preimage first-preimage, and second-preimage attacks.

   For adversarial situations, selecting which selection of the acceptable "Active" algorithms are acceptable
   will depend on the level of protection the circumstances demand. More
   considerations are presented in <xref target="sec-agility"/>.</t>
      <t>Algorithms with a status value of "Deprecated" either provide none of these
properties,
properties or are known to be weak (see <xref target="NO-MD5"/> target="RFC6151"/> and <xref target="NO-SHA"/>). target="RFC6194"/>). These
algorithms <bcp14>MAY</bcp14> be used to preserve integrity against corruption, but <bcp14>MUST NOT</bcp14> be
used in a potentially adversarial setting; setting, for example, when signing Integrity
fields' values for authenticity.

   Permitting the use of these algorithms can help some applications, for example, applications (such as
   those that previously used <xref target="RFC3230"/>, are migrating to this specification
   (<xref target="migrating"/>), and have existing stored collections of computed digest values
   values) avoid undue operational overhead caused by recomputation using
   other more-secure algorithms.

Such applications are not
exempt from the requirements in this section. Furthermore, applications without
such legacy or history ought to follow the guidance for using algorithms with
the status value "Active".</t>
      <t>Discussion of algorithm agility is presented in <xref target="sec-agility"/>.</t>
      <t>Registration requests for the "Hash Algorithms for HTTP Digest Fields" registry
use the Specification Required policy (<xref section="4.6" sectionFormat="of" target="RFC8126"/>). Requests
should use the following template:</t>
      <ul spacing="normal">
        <li>Algorithm Key: the
<dl>
        <dt>Algorithm Key:</dt><dd>The Structured Fields key value used in
<tt>Content-Digest</tt>, <tt>Repr-Digest</tt>, <tt>Want-Content-Digest</tt>, or <tt>Want-Repr-Digest</tt>
 field Dictionary member keys</li>
        <li>
          <t>Status: the keys.</dd>
        <dt>Status:</dt><dd>The status of the algorithm. The options are:
          </t>
          <ul are:</dd>
	<dt></dt><dd>
<dl spacing="normal">
            <li>"Active" - for algorithms
            <dt>"Active":</dt><dd>Algorithms without known problems,</li>
            <li>"Provisional" - for unproven algorithms,</li>
            <li>"Deprecated" - for deprecated problems</dd>
            <dt>"Provisional":</dt><dd>Unproven algorithms</dd>
            <dt>"Deprecated":</dt><dd>Deprecated or insecure algorithms,</li>
          </ul>
        </li>
        <li>Description: a algorithms</dd>
          </dl>
	</dd>
        <dt>Description:</dt><dd>A short description of the algorithm</li>
        <li>Reference(s): pointer(s) algorithm.</dd>
        <dt>Reference(s):</dt><dd>Pointer(s) to the primary document(s) defining the Algorithm
Key and technical details of the algorithm</li>
      </ul> algorithm.</dd>
      </dl>
      <t>When reviewing registration requests, the designated expert(s) should pay
attention to the requested status. The status value should reflect
standardization status and the broad opinion of relevant interest groups such as
the IETF or security-related SDOs. Standards Development Organizations (SDOs). The "Active" status is not suitable for an
algorithm that is known to be weak, broken, or experimental. If a registration
request attempts to register such an algorithm as "Active", the designated
expert(s) should suggest an alternative status of "Deprecated" or "Provisional".</t>
      <t>When reviewing registration requests, the designated expert(s) cannot use a
status of "Deprecated" or "Provisional" as grounds for rejection.</t>
      <t>Requests to update or change the fields in an existing registration are
permitted. For example, this could allow for the transition of an algorithm
status from "Active" to "Deprecated" as the security environment evolves.</t>
    </section>
    <section anchor="security">
      <name>Security Considerations</name>
      <section anchor="sec-limitations">
        <name>HTTP Messages Are Not Protected In in Full</name>
        <t>This document specifies a data integrity mechanism that protects HTTP
representation data or content, but not HTTP header and trailer fields, from
certain kinds of corruption.</t>
        <t>Integrity fields are not intended to be a general protection against malicious tampering with
HTTP messages.
In the absence of additional
  security mechanisms, an on-path, on-path malicious actor can either remove
  a digest value entirely or recalculate and substitute it with a new digest
value. value computed over
  manipulated representation data or content.
This attack can be mitigated by combining mechanisms described in this
document with other approaches such
as transport-layer security Transport Layer Security (TLS) or digital signatures (for example, HTTP Message
Signatures <xref target="SIGNATURES"/>).</t> target="RFC9421"/>).</t>
      </section>
      <section anchor="end-to-end-integrity">
        <name>End-to-End Integrity</name>
        <t>Integrity fields can help detect representation data or content modification due to implementation errors,
undesired "transforming proxies" (see <xref section="7.7" sectionFormat="of" target="RFC9110"/>) target="RFC9110"/>),
or other actions as the data passes across multiple hops or system boundaries.
Even a simple mechanism for end-to-end representation data integrity is valuable
because a user agent can validate that resource retrieval succeeded before handing off to an
HTML parser, video player, etc. etc., for parsing.</t>
        <t>Note that using these mechanisms alone does not provide end-to-end integrity of HTTP messages over
multiple hops, hops since metadata could be manipulated at any stage. Methods to protect
metadata are discussed in <xref target="usage-in-signatures"/>.</t>
      </section>
      <section anchor="usage-in-signatures">
        <name>Usage in Signatures</name>
        <t>Digital signatures are widely used together with checksums to provide the
certain identification of the origin of a message <xref target="NIST800-32"/>. target="FIPS186-5"/>. Such signatures
can protect one or more HTTP fields and there are additional considerations when
Integrity fields are included in this set.</t>
        <t>There are no restrictions placed on the type or format of digital signature that
Integrity fields can be used with. One possible approach is to combine them with
HTTP Message Signatures <xref target="SIGNATURES"/>.</t> target="RFC9421"/>.</t>
        <t>Digests explicitly
depend on the "representation metadata" (e.g., the values of <tt>Content-Type</tt>,
<tt>Content-Encoding</tt>
<tt>Content-Encoding</tt>, etc.). A signature that protects Integrity fields but not other
"representation metadata" can expose the communication to tampering. For
example, an actor could manipulate the <tt>Content-Type</tt> field-value and cause a
digest validation failure at the recipient, preventing the application from
accessing the representation. Such an attack consumes the resources of both
endpoints. See also <xref target="digest-and-content-location"/>.</t>

        <t>Signatures are likely to be deemed an adversarial setting when applying
Integrity fields; see <xref target="algorithms"/>. <tt>Repr-Digest</tt> offers an interesting
possibility when combined with signatures. In the scenario where there is no
content to send, the digest of an empty string can be included in the message
and, if signed, can help the recipient detect if content was added either as a result of accident or purposeful manipulation. The opposite scenario is also
supported; including an Integrity field for content, content and signing it, it can help a
recipient detect where the content was removed.</t>
<t>Any mangling of Integrity fields, including digests' de-duplication fields might affect signature validation. Examples of such mangling include de-duplicating digests or combining different field values (see <xref section="5.2" sectionFormat="of" target="RFC9110"/>)
might affect signature validation.</t> target="RFC9110"/>).</t>
      </section>
      <section anchor="usage-in-trailer-fields">
        <name>Usage in Trailer Fields</name>
        <t>Before sending Integrity fields in a trailer section, the sender
should consider that intermediaries are explicitly allowed to drop any trailer
(see <xref section="6.5.2" sectionFormat="of" target="RFC9110"/>).</t>
        <t>When Integrity fields are used in a trailer section, the field-values are received after the content.
Eager processing of content before the trailer section prevents digest validation, possibly leading to
processing of invalid data.</t>
        <t>One of the benefits of using Integrity fields in a trailer section is that it
allows hashing of bytes as they are sent. However, it is possible to
design a hashing algorithm that requires processing of content in such a way
that would negate these benefits. For example, Merkle Integrity Content Encoding
<xref target="I-D.thomson-http-mice"/> requires content to be processed in reverse order.
This means the complete data needs to be available, which means there is
negligible processing difference in sending an Integrity field in a header or versus
a trailer section.</t>
      </section>
      <section anchor="variations-within-content-encoding">
       <name>Variations Within Content Encoding</name> within Content-Encoding</name>
        <t>Content coding mechanisms can support different encoding parameters, meaning that the same input content can produce different outputs. For example, GZIP supports multiple compression levels. Such encoding parameters are generally not communicated as representation metadata. For instance, different compression levels would all use the same "Content-Encoding: gzip" field. Other examples include where encoding relies on nonces or timestamps, such as the aes128gcm content coding defined in <xref target="RFC8188"/>.</t>
        <t>Since it is possible for there to be variation within content coding, the checksum conveyed by the integrity Integrity fields cannot be used to provide a proof of integrity "at rest"
unless the whole content is persisted.</t>
      </section>
      <section anchor="sec-agility">
        <name>Algorithm Agility</name>
        <t>The security properties of hashing algorithms are not fixed.
Algorithm Agility agility (see <xref target="RFC7696"/>) is achieved by providing implementations with flexibility
to choose hashing algorithms from the IANA Hash Algorithms for HTTP Digest Fields registry; see
<xref target="establish-hash-algorithm-registry"/>.</t>
        <t>Transition from weak algorithms is supported
by negotiation of hashing algorithm using <tt>Want-Content-Digest</tt> or <tt>Want-Repr-Digest</tt> (see <xref target="want-fields"/>)
or by sending multiple digests from which the receiver chooses.
A receiver that depends on a digest for security will be vulnerable
to attacks on the weakest algorithm it is willing to accept.
Endpoints are advised that sending multiple values consumes resources,
which resources that may be wasted if the receiver ignores them (see <xref target="representation-digest"/>).</t>
        <t>While algorithm agility allows the migration to stronger algorithms algorithms,
it does not prevent the use of weaker algorithms.
Integrity fields do not provide any mitigations for downgrade or substitution
attacks (see Section 1 of <xref target="RFC6211"/>) target="RFC6211" sectionFormat="of" section="1"/>) of the hashing algorithm.
To protect against such attacks, endpoints could restrict their set of supported algorithms
to stronger ones and protect the fields value fields' values by using TLS and/or digital signatures.</t>
      </section>
      <section anchor="sec-exhaustion">
        <name>Resource exhaustion</name> Exhaustion</name>
        <t>Integrity fields field validation consumes computational resources.
In order to avoid resource exhaustion, implementations can restrict
validation of the algorithm types, the number of validations, or the size of content.
In these cases, skipping validation entirely or ignoring validation failure of a more-preferred algorithm
leaves the possibility of a downgrade attack (see <xref target="sec-agility"/>).</t>
      </section>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <section anchor="http-field-name-registration">
        <name>HTTP Field Name Registration</name>
        <t>IANA is asked to update has updated the
"Hypertext Transfer Protocol (HTTP) Field Name Registry" registry
(<xref target="RFC9110"/>) according to
<xref target="RFC9110"/> as shown in the table below:</t>
        <table>
	  <name>Hypertext Transfer Protocol (HTTP) Field
   Name Registry Update</name>
          <thead>
            <tr>
              <th align="left">Field Name</th>
              <th align="left">Status</th>
              <th align="left">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">Content-Digest</td> align="left"><tt>Content-Digest</tt></td>
              <td align="left">permanent</td>
              <td align="left">
                <xref target="content-digest"/> of this document</td> RFC 9530</td>
            </tr>
            <tr>
              <td align="left">Repr-Digest</td> align="left"><tt>Repr-Digest</tt></td>
              <td align="left">permanent</td>
              <td align="left">
                <xref target="representation-digest"/> of this document</td> RFC 9530</td>
            </tr>
            <tr>
              <td align="left">Want-Content-Digest</td> align="left"><tt>Want-Content-Digest</tt></td>
              <td align="left">permanent</td>
              <td align="left">
                <xref target="want-fields"/> of this document</td> RFC 9530</td>
            </tr>
            <tr>
              <td align="left">Want-Repr-Digest</td> align="left"><tt>Want-Repr-Digest</tt></td>
              <td align="left">permanent</td>
              <td align="left">
                <xref target="want-fields"/> of this document</td> RFC 9530</td>
            </tr>
            <tr>
              <td align="left">Digest</td> align="left"><tt>Digest</tt></td>
              <td align="left">obsoleted</td>
              <td align="left">
                <xref target="RFC3230"/>, <xref target="obsolete-3230"/> of this document</td> RFC 9530</td>
            </tr>
            <tr>
              <td align="left">Want-Digest</td> align="left"><tt>Want-Digest</tt></td>
              <td align="left">obsoleted</td>
              <td align="left">
                <xref target="RFC3230"/>, <xref target="obsolete-3230"/> of this document</td> RFC 9530</td>
            </tr>
          </tbody>
        </table>
      </section>
      <section anchor="establish-hash-algorithm-registry">
        <name>Establish
        <name>Creation of the Hash Algorithms for HTTP Digest Fields Registry</name>
        <t>IANA is requested to create has created the new "Hash Algorithms for HTTP Digest Fields"
registry at <eref target="https://www.iana.org/assignments/http-digest-hash-alg/">https://www.iana.org/assignments/http-digest-hash-alg/</eref> brackets="angle" target="https://www.iana.org/assignments/http-digest-hash-alg/"/> and
populate
populated it with the entries in <xref target="iana-hash-algorithm-table"/>. The procedure for
new registrations is provided in <xref target="algorithms"/>.</t>
        <table anchor="iana-hash-algorithm-table">
          <name>Initial Hash Algorithms</name>
          <thead>
            <tr>
              <th align="left">Algorithm Key</th>
              <th align="left">Status</th>
              <th align="left">Description</th>
              <th align="left">Reference(s)</th> align="left">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">sha-512</td>
              <td align="left">Active</td>
              <td align="left">The SHA-512 algorithm.</td>
              <td align="left">
                <xref target="RFC6234"/>, <xref target="RFC4648"/>, this document.</td> RFC 9530</td>
            </tr>
            <tr>
              <td align="left">sha-256</td>
              <td align="left">Active</td>
              <td align="left">The SHA-256 algorithm.</td>
              <td align="left">
                <xref target="RFC6234"/>, <xref target="RFC4648"/>, this document.</td> RFC 9530</td>
            </tr>
            <tr>
              <td align="left">md5</td>
              <td align="left">Deprecated</td>
              <td align="left">The MD5 algorithm. It is vulnerable to collision attacks; see <xref target="NO-MD5"/> target="RFC6151"/> and <xref target="CMU-836068"/></td>
              <td align="left">
                <xref target="RFC1321"/>, <xref target="RFC4648"/>, this document.</td> RFC 9530</td>
            </tr>
            <tr>
              <td align="left">sha</td>
              <td align="left">Deprecated</td>
              <td align="left">The SHA-1 algorithm. It is vulnerable to collision attacks; see <xref target="NO-SHA"/> target="RFC6194"/> and <xref target="IACR-2020-014"/></td>
              <td align="left">
                <xref target="RFC3174"/>, <xref target="RFC4648"/>, <xref target="RFC6234"/> this document.</td> target="RFC6234"/>, RFC 9530</td>
            </tr>
            <tr>
              <td align="left">unixsum</td>
              <td align="left">Deprecated</td>
              <td align="left">The algorithm used by the UNIX "sum" command.</td>
              <td align="left">
                <xref target="RFC4648"/>, <xref target="RFC6234"/>, <xref target="UNIX"/>, this document.</td> RFC&nbsp;9530</td>
            </tr>
            <tr>
              <td align="left">unixcksum</td>
              <td align="left">Deprecated</td>
              <td align="left">The algorithm used by the UNIX "cksum" command.</td>
              <td align="left">
                <xref target="RFC4648"/>, <xref target="RFC6234"/>, <xref target="UNIX"/>, this document.</td> RFC&nbsp;9530</td>
            </tr>
            <tr>
              <td align="left">adler</td>
              <td align="left">Deprecated</td>
              <td align="left">The ADLER32 algorithm.</td>
              <td align="left">
                <xref target="RFC1950"/>, this document.</td> RFC 9530</td>
            </tr>
            <tr>
              <td align="left">crc32c</td>
              <td align="left">Deprecated</td>
              <td align="left">The CRC32c algorithm.</td>
              <td align="left">
                <xref target="RFC9260"/> appendix A, this document.</td> align="left"><xref target="RFC9260" sectionFormat="of" section="A"/>, RFC 9530</td>
            </tr>
          </tbody>
        </table>
      </section>
      <section anchor="deprecate-the-hypertext-transfer-protocol-http-digest-algorithm-values-registry">
        <name>Deprecate the Hypertext Transfer Protocol (HTTP) Digest Algorithm Values Registry</name>
        <t>IANA is requested to deprecate has deprecated the "Hypertext Transfer Protocol (HTTP) Digest
Algorithm Values" registry at
<eref target="https://www.iana.org/assignments/http-dig-alg/http-dig-alg.xhtml">https://www.iana.org/assignments/http-dig-alg/http-dig-alg.xhtml</eref> brackets="angle" target="https://www.iana.org/assignments/http-dig-alg/"/> and replace replaced the note on this that registry with the following text:</t>
        <ul empty="true">
          <li>
            <t>"This
            <blockquote>This registry is deprecated since it lists the algorithms that can be used
with the Digest <tt>Digest</tt> and Want-Digest <tt>Want-Digest</tt> fields defined in <xref target="RFC3230"/><eref target="https://www.iana.org/">https://www.iana.org/</eref>, target="RFC3230"/>, which has been obsoleted by
[rfc-to-be-this-document].
RFC 9530. While registration is not closed, new registrations
are encouraged to use the [Hash <eref target="https://www.iana.org/assignments/http-digest-hash-alg/">Hash Algorithms for HTTP Digest
Fields]<eref target="https://www.iana.org/assignments/http-digest-hash-alg/">https://www.iana.org/assignments/http-digest-hash-alg/</eref>
Fields</eref> registry
instead.</t>
          </li>
        </ul> instead.</blockquote>
      </section>
    </section>
  </middle>
  <back>

    <displayreference target="RFC9110" to="HTTP"/>
    <displayreference target="RFC9112" to="HTTP/1.1"/>
    <displayreference target="RFC8792" to="FOLDING"/>
    <displayreference target="RFC8941" to="STRUCTURED-FIELDS"/>
    <displayreference target="RFC5789" to="PATCH"/>
    <displayreference target="RFC6151" to="NO-MD5"/>
    <displayreference target="RFC6194" to="NO-SHA"/>
    <displayreference target="RFC9421" to="SIGNATURES"/>
    <displayreference target="RFC8446" to="TLS"/>
    <displayreference target="I-D.thomson-http-mice" to="MICE"/>

    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <reference anchor="RFC1321">
          <front>
            <title>The MD5 Message-Digest Algorithm</title>
            <author fullname="R. Rivest" initials="R." surname="Rivest"/>
            <date month="April" year="1992"/>
            <abstract>
              <t>This document describes the MD5 message-digest algorithm. The algorithm takes as input a message of arbitrary length and produces as output a 128-bit "fingerprint" or "message digest" of the input. This memo provides information for the Internet community. It does not specify an Internet standard.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="1321"/>
          <seriesInfo name="DOI" value="10.17487/RFC1321"/>
        </reference>
        <reference anchor="RFC3174">
          <front>
            <title>US Secure Hash Algorithm 1 (SHA1)</title>
            <author fullname="D. Eastlake 3rd" initials="D." surname="Eastlake 3rd"/>
            <author fullname="P. Jones" initials="P." surname="Jones"/>
            <date month="September" year="2001"/>
            <abstract>
              <t>The purpose of this document is to make the SHA-1 (Secure Hash Algorithm 1) hash algorithm conveniently available to the Internet community. This memo provides information for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3174"/>
          <seriesInfo name="DOI" value="10.17487/RFC3174"/>
        </reference>
        <reference anchor="RFC1950">
          <front>
            <title>ZLIB Compressed Data Format Specification version 3.3</title>
            <author fullname="P. Deutsch" initials="P." surname="Deutsch"/>
            <author fullname="J-L. Gailly" surname="J-L. Gailly"/>
            <date month="May" year="1996"/>
            <abstract>
              <t>This specification defines a lossless compressed data format. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="1950"/>
          <seriesInfo name="DOI" value="10.17487/RFC1950"/>
        </reference>
        <reference anchor="RFC4648">
          <front>
            <title>The Base16, Base32, and Base64 Data Encodings</title>
            <author fullname="S. Josefsson" initials="S." surname="Josefsson"/>
            <date month="October" year="2006"/>
            <abstract>
              <t>This document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4648"/>
          <seriesInfo name="DOI" value="10.17487/RFC4648"/>
        </reference>
        <reference anchor="RFC5234">
          <front>
            <title>Augmented BNF for Syntax Specifications: ABNF</title>
            <author fullname="D. Crocker" initials="D." role="editor" surname="Crocker"/>
            <author fullname="P. Overell" initials="P." surname="Overell"/>
            <date month="January" year="2008"/>
            <abstract>
              <t>Internet technical specifications often need to define a formal syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="68"/>
          <seriesInfo name="RFC" value="5234"/>
          <seriesInfo name="DOI" value="10.17487/RFC5234"/>
        </reference>
        <reference anchor="RFC6234">
          <front>
            <title>US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)</title>
            <author fullname="D. Eastlake 3rd" initials="D." surname="Eastlake 3rd"/>
            <author fullname="T. Hansen" initials="T." surname="Hansen"/>
            <date month="May" year="2011"/>
            <abstract>
              <t>Federal Information Processing Standard, FIPS</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6234"/>
          <seriesInfo name="DOI" value="10.17487/RFC6234"/>
        </reference>
        <reference anchor="RFC7405">
          <front>
            <title>Case-Sensitive String Support in ABNF</title>
            <author fullname="P. Kyzivat" initials="P." surname="Kyzivat"/>
            <date month="December" year="2014"/>
            <abstract>
              <t>This document extends the base definition of ABNF (Augmented Backus-Naur Form) to include a way to specify US-ASCII string literals that are matched in a case-sensitive manner.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7405"/>
          <seriesInfo name="DOI" value="10.17487/RFC7405"/>
        </reference>
        <reference anchor="FOLDING">
          <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="RFC9110">
          <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="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>
        <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="February" year="2021"/>
            <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 that wish to use a common syntax that is more restrictive than traditional HTTP field values.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8941"/>
          <seriesInfo name="DOI" value="10.17487/RFC8941"/>
        </reference>
        <reference anchor="RFC8126">
          <front>
            <title>Guidelines for Writing an IANA Considerations Section in RFCs</title>
            <author fullname="M. Cotton" initials="M." surname="Cotton"/>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <author fullname="T. Narten" initials="T." surname="Narten"/>
            <date month="June" year="2017"/>
            <abstract>
              <t>Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA).</t>
              <t>To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry.</t>
              <t>This is the third edition of this document; it obsoletes RFC 5226.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="26"/>
          <seriesInfo name="RFC" value="8126"/>
          <seriesInfo name="DOI" value="10.17487/RFC8126"/>
        </reference>

<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1321.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3174.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1950.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4648.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5234.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6234.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7405.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8792.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9110.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8941.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/>

      </references>
      <references>

        <name>Informative References</name>
        <reference anchor="RFC3230">
          <front>
            <title>Instance Digests in HTTP</title>
            <author fullname="J. Mogul" initials="J." surname="Mogul"/>
            <author fullname="A. Van Hoff" initials="A." surname="Van Hoff"/>
            <date month="January" year="2002"/>
            <abstract>
              <t>HTTP/1.1 defines a Content-MD5 header that allows a server to include a digest of the response body. However, this is specifically defined to cover the body of the actual message, not the contents of the full file (which might be quite different, if the response is a Content-Range, or uses a delta encoding). Also, the Content-MD5 is limited to one specific digest algorithm; other algorithms, such as SHA-1 (Secure Hash Standard), may be more appropriate in some circumstances. Finally, HTTP/1.1 provides no explicit mechanism by which a client may request a digest. This document proposes HTTP extensions that solve these problems. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3230"/>
          <seriesInfo name="DOI" value="10.17487/RFC3230"/>
        </reference>
        <reference anchor="RFC9112">
          <front>
            <title>HTTP/1.1</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)

<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3230.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9112.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5789.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6151.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6194.xml"/>

<!-- I-D.ietf-httpbis-message-signatures is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document specifies the HTTP/1.1 message syntax, message parsing, connection management, and related security concerns.</t>
              <t>This document obsoletes portions of now RFC 7230.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="99"/>
          <seriesInfo name="RFC" value="9112"/>
          <seriesInfo name="DOI" value="10.17487/RFC9112"/>
        </reference>
        <reference anchor="PATCH">
          <front>
            <title>PATCH Method for HTTP</title>
            <author fullname="L. Dusseault" initials="L." surname="Dusseault"/>
            <author fullname="J. Snell" initials="J." surname="Snell"/>
            <date month="March" year="2010"/>
            <abstract>
              <t>Several applications extending the Hypertext Transfer Protocol (HTTP) require a feature to do partial resource modification. The existing HTTP PUT method only allows a complete replacement of a document. This proposal adds a new HTTP method, PATCH, to modify an existing HTTP resource. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5789"/>
          <seriesInfo name="DOI" value="10.17487/RFC5789"/>
        </reference>
        <reference anchor="NO-MD5">
          <front>
            <title>Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms</title>
            <author fullname="S. Turner" initials="S." surname="Turner"/>
            <author fullname="L. Chen" initials="L." surname="Chen"/>
            <date month="March" year="2011"/>
            <abstract>
              <t>This document updates the security considerations for the MD5 message digest algorithm. It also updates the security considerations for HMAC-MD5. This document is not an Internet Standards Track specification; it is published for informational purposes.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6151"/>
          <seriesInfo name="DOI" value="10.17487/RFC6151"/>
        </reference>
        <reference anchor="NO-SHA">
          <front>
            <title>Security Considerations for the SHA-0 and SHA-1 Message-Digest Algorithms</title>
            <author fullname="T. Polk" initials="T." surname="Polk"/>
            <author fullname="L. Chen" initials="L." surname="Chen"/>
            <author fullname="S. Turner" initials="S." surname="Turner"/>
            <author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
            <date month="March" year="2011"/>
            <abstract>
              <t>This document includes security considerations for the SHA-0 and SHA-1 message digest algorithm. This document is not an Internet Standards Track specification; it is published for informational purposes.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6194"/>
          <seriesInfo name="DOI" value="10.17487/RFC6194"/>
        </reference> 9421 -->
 <reference anchor="SIGNATURES"> anchor="RFC9421" target="https://www.rfc-editor.org/info/rfc9421">
<front>
<title>HTTP Message Signatures</title>
<author initials="A." surname="Backman" fullname="Annabelle Backman" initials="A." surname="Backman"> role="editor">
<organization>Amazon</organization>
</author>
<author initials="J." surname="Richer" fullname="Justin Richer" initials="J." surname="Richer"> role="editor">
<organization>Bespoke Engineering</organization>
</author>
<author fullname="Manu Sporny" initials="M." surname="Sporny"> surname="Sporny" fullname="Manu Sporny">
<organization>Digital Bazaar</organization>
</author>
<date day="2" month="May" year="2023"/>
            <abstract>
              <t>   This document describes a mechanism for creating, encoding, and
   verifying digital signatures or message authentication codes over
   components of an HTTP message.  This mechanism supports use cases
   where the full HTTP message may not be known to the signer, and where
   the message may be transformed (e.g., by intermediaries) before
   reaching the verifier.  This document also describes a means for
   requesting that a signature be applied to a subsequent HTTP message
   in an ongoing HTTP exchange.

              </t>
            </abstract> month='February' year='2024'/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-message-signatures-17"/> name="RFC" value="9421"/>
<seriesInfo name="DOI" value="10.17487/RFC9421"/>
</reference>

        <reference anchor="UNIX">
          <front>
            <title>The Single UNIX Specification, Version 2 - 6 Vol Set for UNIX 98</title>
            <author>
              <organization>The Open Group</organization>
            </author>
            <date year="1997" month="February"/> year="1998" month="January"/>
          </front>
        </reference>

        <reference anchor="NIST800-32" target="https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-32.pdf"> anchor="FIPS186-5" target="https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-5.pdf">
          <front>
            <title>Introduction to Public Key Technology and the Federal PKI Infrastructure</title>
            <title>Digital Signature Standard (DSS)</title>
            <author>
              <organization>National Institute of Standards and Technology, U.S. Department of Commerce</organization> Technology (NIST)</organization>
            </author>
            <date year="2001" year="2023" month="February"/>
          </front>
	  <seriesInfo name="FIPS PUB" value="186-5"/>
	  <seriesInfo name="DOI" value="10.6028/NIST.FIPS.186-5"/>
        </reference>

        <reference anchor="CMU-836068" target="https://www.kb.cert.org/vuls/id/836068/">
          <front>
            <title>MD5 Vulnerable vulnerable to collision attacks</title>
            <author>
              <organization>Carnegie Mellon University, Software Engineering Institute</organization>
            </author>
            <date year="2008" month="December" day="31"/> month="December"/>
          </front>
        </reference>

        <reference anchor="IACR-2020-014" target="https://eprint.iacr.org/2020/014.pdf">
          <front>
            <title>SHA-1 is a Shambles</title>
            <author initials="G." surname="Leurent">
              <organization>Inria, France</organization>
            </author>
            <author initials="T." surname="Peyrin">
              <organization>Nanyang Technological University, Singapore; Temasek Laboratories, Singapore</organization>
            </author>
            <date year="2020" month="January" day="05"/>
          </front>
        </reference>
        <reference anchor="TLS">
          <front>
            <title>The Transport Layer Security (TLS) Protocol Version 1.3</title>
            <author fullname="E. Rescorla" initials="E." surname="Rescorla"/>
            <date month="August" year="2018"/>
            <abstract>
              <t>This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.</t>
              <t>This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8446"/>
          <seriesInfo name="DOI" value="10.17487/RFC8446"/>
        </reference>
        <reference anchor="I-D.thomson-http-mice">
          <front>
            <title>Merkle Integrity Content Encoding</title>
            <author fullname="Martin Thomson" initials="M." surname="Thomson">
              <organization>Mozilla</organization>
            </author>
            <author fullname="Jeffrey Yasskin" initials="J." surname="Yasskin">
              <organization>Google</organization>
            </author>
            <date day="13" month="August" year="2018"/>
            <abstract>
              <t>   This memo introduces a content-coding for HTTP that provides
   progressive integrity for message contents.  This integrity
   protection can be evaluated on a partial representation, allowing a
   recipient to process a message as it is delivered while retaining
   strong integrity protection.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-thomson-http-mice-03"/>
        </reference>
        <reference anchor="RFC8188">
          <front>
            <title>Encrypted Content-Encoding for HTTP</title>
            <author fullname="M. Thomson" initials="M." surname="Thomson"/>
            <date month="June" year="2017"/>
            <abstract>
              <t>This memo introduces a content coding for HTTP that allows message payloads to be encrypted.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8188"/>
          <seriesInfo name="DOI" value="10.17487/RFC8188"/>
        </reference>
        <reference anchor="RFC7696">
          <front>
            <title>Guidelines for Cryptographic Algorithm Agility and Selecting Mandatory-to-Implement Algorithms</title>
            <author fullname="R. Housley" initials="R." surname="Housley"/>
            <date month="November" year="2015"/>
            <abstract>
              <t>Many IETF protocols use cryptographic algorithms to provide confidentiality, integrity, authentication, or digital signature. Communicating peers must support a common set of cryptographic algorithms for these mechanisms to work properly. This memo provides guidelines to ensure that protocols have the ability to migrate from one mandatory-to-implement algorithm suite to another over time.</t>
            </abstract> month="January"/>
          </front>
          <seriesInfo name="BCP" value="201"/>
          <seriesInfo name="RFC" value="7696"/>
          <seriesInfo name="DOI" value="10.17487/RFC7696"/>
        </reference>
        <reference anchor="RFC6211">
          <front>
            <title>Cryptographic Message Syntax (CMS) Algorithm Identifier Protection Attribute</title>
            <author fullname="J. Schaad" initials="J." surname="Schaad"/>
            <date month="April" year="2011"/>
            <abstract>
              <t>The Cryptographic Message Syntax (CMS), unlike X.509/PKIX certificates, is vulnerable to algorithm substitution attacks. In an algorithm substitution attack, the attacker changes either the algorithm being used or the parameters of the algorithm in order to change the result of a signature verification process. In X.509 certificates, the signature algorithm is protected because it is duplicated in the TBSCertificate.signature field with the proviso that the validator is to compare both fields as part of the signature validation process. This document defines a new attribute that contains a copy of the relevant algorithm identifiers so that they are protected by the signature or authentication process. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6211"/>
          <seriesInfo name="DOI" value="10.17487/RFC6211"/>
        </reference>
        <reference anchor="RFC9260">
          <front>
            <title>Stream Control Transmission Protocol</title>
            <author fullname="R. Stewart" initials="R." surname="Stewart"/>
            <author fullname="M. Tüxen" initials="M." surname="Tüxen"/>
            <author fullname="K. Nielsen" initials="K." surname="Nielsen"/>
            <date month="June" year="2022"/>
            <abstract>
              <t>This document describes the Stream Control Transmission Protocol (SCTP) and obsoletes RFC 4960. It incorporates the specification of the chunk flags registry from RFC 6096 and the specification of the I bit of DATA chunks from RFC 7053. Therefore, RFCs 6096 and 7053 are also obsoleted by this document. In addition, RFCs 4460 and 8540, which describe errata for SCTP, are obsoleted by this document.</t>
              <t>SCTP was originally designed to transport Public Switched Telephone Network (PSTN) signaling messages over IP networks. It is also suited to be used for other applications, for example, WebRTC.</t>
              <t>SCTP is a reliable transport protocol operating on top of a connectionless packet network, such as IP. It offers the following services to its users:</t>
              <t>The design of SCTP includes appropriate congestion avoidance behavior and resistance to flooding and masquerade attacks.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9260"/>
          <seriesInfo name="DOI" value="10.17487/RFC9260"/>
        </reference>
        <reference anchor="RFC7396">
          <front>
            <title>JSON Merge Patch</title>
            <author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
            <author fullname="J. Snell" initials="J." surname="Snell"/>
            <date month="October" year="2014"/>
            <abstract>
              <t>This specification defines the JSON merge patch format and processing rules. The merge patch format is primarily intended for use with the HTTP PATCH method as a means of describing a set of modifications to a target resource's content.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7396"/>
          <seriesInfo name="DOI" value="10.17487/RFC7396"/>
        </reference>
        <reference anchor="RFC7807">
          <front>
            <title>Problem Details for HTTP APIs</title>
            <author fullname="M. Nottingham" initials="M." surname="Nottingham"/>
            <author fullname="E. Wilde" initials="E." surname="Wilde"/>
            <date month="March" year="2016"/>
            <abstract>
              <t>This document defines a "problem detail" as a way to carry machine- readable details of errors in a HTTP response to avoid the need to define new error response formats for HTTP APIs.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7807"/>
          <seriesInfo name="DOI" value="10.17487/RFC7807"/>
        </reference>

<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml"/>

<!-- [I-D.thomson-http-mice] IESG state	Expired -->

<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.thomson-http-mice.xml"/>

<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8188.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7696.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6211.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9260.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7396.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9457.xml"/>

       </references>
      </references>
    <?line 722?>

<section anchor="resource-representation">
      <name>Resource Representation and Representation Data</name>
      <t>This section
      <t>The following examples show how representation metadata, content
transformations, and method impacts on methods impact the message and content. These examples a
not exhaustive.</t>
      <t>Unless otherwise indicated, the examples are based on the JSON object <tt>{"hello":
"world"}</tt> followed by an LF. When the content contains non-printable characters
(e.g., when it is encoded) encoded), it is shown as a sequence of hex-encoded bytes.</t>
      <t>Consider a client that wishes to upload a JSON object using the PUT method.

It
could do this using the application/json content type <tt>Content-Type</tt> without any content
coding.</t>
      <figure>
        <name>Request containing Containing a JSON object Object without any content coding</name> Any Content Coding</name>
        <sourcecode type="http-message"><![CDATA[
PUT /entries/1234 HTTP/1.1
Host: foo.example
Content-Type: application/json
Content-Length: 19

{"hello": "world"}
]]></sourcecode>
      </figure>
      <t>However, the use of content coding is quite common. The client could also upload
the same data with a gzip GZIP coding (<xref section="8.4.1.3" sectionFormat="of" target="RFC9110"/>). Note that in
this case, the <tt>Content-Length</tt> contains a larger value due to the coding
overheads.</t>
      <figure anchor="ex-put-gz">
        <name>Request containing Containing a gzip-encoded GZIP-Encoded JSON object</name> Object</name>
        <sourcecode type="http-message"><![CDATA[
PUT /entries/1234 HTTP/1.1
Host: foo.example
Content-Type: application/json
Content-Encoding: gzip
Content-Length: 39

1F 8B 08 00 88 41 37 64 00 FF
AB 56 CA 48 CD C9 C9 57 B2 52
50 2A CF 2F CA 49 51 AA E5 02
00 D9 E4 31 E7 13 00 00 00
]]></sourcecode>
      </figure>
      <t>Sending the gzip coded GZIP-coded data without indicating it via <tt>Content-Encoding</tt> means
that the content is malformed. In this case, the server can reply with an error.</t>
      <figure>
        <name>Request containing malformed Containing Malformed JSON</name>
        <sourcecode type="http-message"><![CDATA[
PUT /entries/1234 HTTP/1.1
Host: foo.example
Content-Type: application/json

Content-Length: 39

1F 8B 08 00 88 41 37 64 00 FF
AB 56 CA 48 CD C9 C9 57 B2 52
50 2A CF 2F CA 49 51 AA E5 02
00 D9 E4 31 E7 13 00 00 00
]]></sourcecode>
      </figure>
      <figure>
        <name>An error response Error Response for a malformed content</name> Malformed Content</name>
        <sourcecode type="http-message"><![CDATA[
HTTP/1.1 400 Bad Request
]]></sourcecode>
      </figure>
      <t>A Range-Request affects the transferred message content. In this example, the
client is accessing the resource at <tt>/entries/1234</tt>, which is the JSON object
<tt>{"hello": "world"}</tt> followed by an LF. However, the client has indicated a
preferred content coding and a specific byte range.</t>
      <figure>
        <name>Request for partial content</name> Partial Content</name>
        <sourcecode type="http-message"><![CDATA[
GET /entries/1234 HTTP/1.1
Host: foo.example
Accept-Encoding: gzip
Range: bytes=1-7
]]></sourcecode>
      </figure>

      <t>The server satisfies the client request by responding with a partial
representation (equivalent to the first 10 bytes of the JSON object displayed in whole
in <xref target="ex-put-gz"/>).</t>
      <figure>
        <name>Partial response Response from a gzip-encoded representation</name> GZIP-Encoded Representation</name>
        <sourcecode type="http-message"><![CDATA[
HTTP/1.1 206 Partial Content
Content-Encoding: gzip
Content-Type: application/json
Content-Range: bytes 0-9/39

1F 8B 08 00 A5 B4 BD 62 02 FF
]]></sourcecode>
      </figure>
      <t>Aside from content coding or range requests, the method can also affect the
transferred message content. For example, the response to a HEAD request does
not carry content content, but in this example case does include a Content-Length; includes <tt>Content-Length</tt>; see
<xref section="8.6" sectionFormat="of" target="RFC9110"/>.</t>
      <figure>
        <name>HEAD request</name> Request</name>
        <sourcecode type="http-message"><![CDATA[
HEAD /entries/1234 HTTP/1.1
Host: foo.example
Accept: application/json
Accept-Encoding: gzip
]]></sourcecode>
      </figure>
      <figure>
        <name>Response to HEAD request (empty content)</name> Request (Empty Content)</name>
        <sourcecode type="http-message"><![CDATA[
HTTP/1.1 200 OK
Content-Type: application/json
Content-Encoding: gzip
Content-Length: 39
]]></sourcecode>
      </figure>
      <t>Finally, the semantics of a response might decouple the target URI
from the enclosed representation. In the example below, the client issues a POST
request directed to <tt>/authors/</tt> <tt>/authors/</tt>, but the response includes a <tt>Content-Location</tt>
header field indicating that indicates the enclosed representation refers to the
resource available at <tt>/authors/123</tt>. Note that <tt>Content-Length</tt> is not sent
in this example.</t>
      <figure>
        <name>POST request</name> Request</name>
        <sourcecode type="http-message"><![CDATA[
POST /authors/ HTTP/1.1
Host: foo.example
Accept: application/json
Content-Type: application/json

{"author": "Camilleri"}
]]></sourcecode>
      </figure>
      <figure>
        <name>Response with Content-Location header</name> Header</name>
        <sourcecode type="http-message"><![CDATA[
HTTP/1.1 201 Created
Content-Type: application/json
Content-Location: /authors/123
Location: /authors/123

{"id": "123", "author": "Camilleri"}
]]></sourcecode>
      </figure>
    </section>
    <section anchor="examples-unsolicited">
      <name>Examples of Unsolicited Digest</name> <tt>Digest</tt></name>
      <t>The following examples demonstrate interactions where a server responds with a
<tt>Content-Digest</tt> or <tt>Repr-Digest</tt> fields field, even though the client did not solicit one using
<tt>Want-Content-Digest</tt> or <tt>Want-Repr-Digest</tt>.</t>
      <t>Some examples include JSON objects in the content.
For presentation purposes, objects that fit completely within the line-length limits
are presented on a single line using compact notation with no leading space.
Objects that would exceed line-length limits are presented across multiple lines
(one line per key-value pair) with 2 two spaces of leading indentation.</t>
      <t>Checksum mechanisms defined in this document are media-type agnostic
and do not provide canonicalization algorithms for specific formats.
Examples are calculated inclusive of any space.
While examples can include both fields,
<tt>Content-Digest</tt> and <tt>Repr-Digest</tt> can be returned independently.</t>
      <section anchor="example-full-representation">
        <name>Server Returns Full Representation Data</name>
        <t>In this example, the message content conveys complete representation data.
This means that in the response, <tt>Content-Digest</tt> and <tt>Repr-Digest</tt>
are both computed over the JSON object <tt>{"hello": "world"}</tt> followed by an LF, and thus LF; thus, they have the same value.</t>
        <figure>
          <name>GET request Request for an item</name> Item</name>
          <sourcecode type="http-message"><![CDATA[
GET /items/123 HTTP/1.1
Host: foo.example
]]></sourcecode>
        </figure>
        <figure>
          <name>Response with identical Repr-Digest Identical <tt>Repr-Digest</tt> and Content-Digest</name> <tt>Content-Digest</tt></name>
          <sourcecode type="http-message"><![CDATA[
NOTE: '\' line wrapping per RFC 8792

HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 19
Content-Digest: \
  sha-256=:RK/0qy18MlBSVnWgjwz6lZEWjP/lF5HF9bvEF8FabDg=:
Repr-Digest: \
  sha-256=:RK/0qy18MlBSVnWgjwz6lZEWjP/lF5HF9bvEF8FabDg=:

{"hello": "world"}
]]></sourcecode>
        </figure>
      </section>
      <section anchor="server-returns-no-representation-data">
        <name>Server Returns No Representation Data</name>
        <t>In this example, a HEAD request is used to retrieve the checksum
of a resource.</t>
        <t>The response <tt>Content-Digest</tt> field-value is computed on empty content.
<tt>Repr-Digest</tt> is calculated over the JSON object
<tt>{"hello": "world"}</tt> followed by an LF, which is not shown because there is no content.</t>
        <figure>
          <name>HEAD request Request for an item</name> Item</name>
          <sourcecode type="http-message"><![CDATA[
HEAD /items/123 HTTP/1.1
Host: foo.example
]]></sourcecode>
        </figure>
        <figure>
          <name>Response with both Content-Digest Both <tt>Content-Digest</tt> and Digest; empty content</name> <tt>Digest</tt> (Empty Content)</name>
          <sourcecode type="http-message"><![CDATA[
NOTE: '\' line wrapping per RFC 8792

HTTP/1.1 200 OK
Content-Type: application/json
Content-Digest: \
  sha-256=:47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=:
Repr-Digest: \
  sha-256=:RK/0qy18MlBSVnWgjwz6lZEWjP/lF5HF9bvEF8FabDg=:
]]></sourcecode>
        </figure>
      </section>
      <section anchor="server-returns-partial-representation-data">
        <name>Server Returns Partial Representation Data</name>
        <t>In this example, the client makes a range request and the server responds with
partial content.</t>
        <figure>
          <name>Request for partial content</name> Partial Content</name>
          <sourcecode type="http-message"><![CDATA[
GET /items/123 HTTP/1.1
Host: foo.example
Range: bytes=10-18
]]></sourcecode>
        </figure>
        <figure>
          <name>Partial response Response with both Content-Digest Both <tt>Content-Digest</tt> and Repr-Digest</name> <tt>Repr-Digest</tt></name>
          <sourcecode type="http-message"><![CDATA[
NOTE: '\' line wrapping per RFC 8792

HTTP/1.1 206 Partial Content
Content-Type: application/json
Content-Range: bytes 10-18/19
Content-Digest: \
  sha-256=:jjcgBDWNAtbYUXI37CVG3gRuGOAjaaDRGpIUFsdyepQ=:
Repr-Digest: \
  sha-256=:RK/0qy18MlBSVnWgjwz6lZEWjP/lF5HF9bvEF8FabDg=:

"world"}
]]></sourcecode>
        </figure>
        <t>In the response message above, note that the
<tt>Repr-Digest</tt> and <tt>Content-Digests</tt> are different.
The <tt>Repr-Digest</tt> field-value is calculated across the entire JSON object
<tt>{"hello": "world"}</tt> followed by an LF, and the field is</t> appears as follows:</t>
        <sourcecode type="http-message"><![CDATA[
NOTE: '\' line wrapping per RFC 8792

Repr-Digest: \
  sha-256=:RK/0qy18MlBSVnWgjwz6lZEWjP/lF5HF9bvEF8FabDg=:
]]></sourcecode>
        <t>However, since the message content is constrained to bytes 10-18,
the <tt>Content-Digest</tt> field-value is calculated over the
sequence  <tt>"world"}</tt> followed by an LF, thus resulting in</t> in the following:</t>
        <sourcecode type="http-message"><![CDATA[
NOTE: '\' line wrapping per RFC 8792

Content-Digest: \
  sha-256=:jjcgBDWNAtbYUXI37CVG3gRuGOAjaaDRGpIUFsdyepQ=:
]]></sourcecode>
      </section>
      <section anchor="client-and-server-provide-full-representation-data">
        <name>Client and Server Provide Full Representation Data</name>
        <t>The request contains a <tt>Repr-Digest</tt> field-value calculated on the enclosed
representation. It also includes an <tt>Accept-Encoding: br</tt> header field that advertises that the
client supports Brotli encoding.</t>
        <t>The response includes a <tt>Content-Encoding: br</tt> that indicates the selected
representation is Brotli-encoded. The <tt>Repr-Digest</tt> field-value is therefore
different compared to the request.</t>
        <t>For presentation purposes, the response body is displayed as a sequence of
hex-encoded bytes because it contains non-printable characters.</t>
        <figure>
          <name>PUT Request with Digest</name> <tt>Digest</tt></name>
          <sourcecode type="http-message"><![CDATA[
NOTE: '\' line wrapping per RFC 8792

PUT /items/123 HTTP/1.1
Host: foo.example
Content-Type: application/json
Accept-Encoding: br
Repr-Digest: \
  sha-256=:RK/0qy18MlBSVnWgjwz6lZEWjP/lF5HF9bvEF8FabDg=:

{"hello": "world"}
]]></sourcecode>
        </figure>
        <figure>
          <name>Response with Digest <tt>Digest</tt> of encoded response</name> Encoded Response</name>
          <sourcecode type="http-message"><![CDATA[
NOTE: '\' line wrapping per RFC 8792

HTTP/1.1 200 OK
Content-Type: application/json
Content-Location: /items/123
Content-Encoding: br
Content-Length: 23
Repr-Digest: \
  sha-256=:d435Qo+nKZ+gLcUHn7GQtQ72hiBVAgqoLsZnZPiTGPk=:

8B 08 80 7B 22 68 65 6C 6C 6F
22 3A 20 22 77 6F 72 6C 64 22
7D 0A 03
]]></sourcecode>
        </figure>
      </section>
      <section anchor="client-provides-full-representation-data-server-provides-no-representation-data">
        <name>Client Provides Full Representation Data, Data and Server Provides No Representation Data</name>
        <t>The request <tt>Repr-Digest</tt> field-value is calculated on the enclosed content, which
is the JSON object <tt>{"hello": "world"}</tt> followed by an LF</t> LF.</t>
        <t>The response <tt>Repr-Digest</tt> field-value
depends on the representation metadata header fields, including
<tt>Content-Encoding: br</tt> br</tt>, even when the response does not contain content.</t>
        <sourcecode type="http-message"><![CDATA[
NOTE: '\' line wrapping per RFC 8792

PUT /items/123 HTTP/1.1
Host: foo.example
Content-Type: application/json
Content-Length: 19
Accept-Encoding: br
Repr-Digest: \
  sha-256=:RK/0qy18MlBSVnWgjwz6lZEWjP/lF5HF9bvEF8FabDg==:

{"hello": "world"}
]]></sourcecode>
        <figure>
          <name>Empty response Response with Digest</name> <tt>Digest</tt></name>
          <sourcecode type="http-message"><![CDATA[
HTTP/1.1 204 No Content
Content-Type: application/json
Content-Encoding: br
Repr-Digest: sha-256=:d435Qo+nKZ+gLcUHn7GQtQ72hiBVAgqoLsZnZPiTGPk=:
]]></sourcecode>
        </figure>
      </section>
      <section anchor="client-and-server-provide-full-representation-data-1">
        <name>Client and Server Provide Full Representation Data</name>
        <t>The response contains two digest values using different algorithms.</t>
        <t>For presentation purposes, the response body is displayed as a sequence of
hex-encoded bytes because it contains non-printable characters.</t>
        <figure>
          <name>PUT Request with Digest</name> <tt>Digest</tt></name>
          <sourcecode type="http-message"><![CDATA[
NOTE: '\' line wrapping per RFC 8792

PUT /items/123 HTTP/1.1
Host: foo.example
Content-Type: application/json
Accept-Encoding: br
Repr-Digest: \
  sha-256=:RK/0qy18MlBSVnWgjwz6lZEWjP/lF5HF9bvEF8FabDg==:

{"hello": "world"}
]]></sourcecode>
        </figure>
        <figure>
          <name>Response with Digest <tt>Digest</tt> of Encoded Content</name>
          <sourcecode type="http-message"><![CDATA[
NOTE: '\' line wrapping per RFC 8792

HTTP/1.1 200 OK
Content-Type: application/json
Content-Encoding: br
Content-Location: /items/123
Repr-Digest: \
  sha-256=:d435Qo+nKZ+gLcUHn7GQtQ72hiBVAgqoLsZnZPiTGPk=:,\
  sha-512=:db7fdBbgZMgX1Wb2MjA8zZj+rSNgfmDCEEXM8qLWfpfoNY0sCpHAzZbj\
  09X1/7HAb7Od5Qfto4QpuBsFbUO3dQ==:

8B 08 80 7B 22 68 65 6C 6C 6F
22 3A 20 22 77 6F 72 6C 64 22
7D 0A 03
]]></sourcecode>
        </figure>
      </section>
      <section anchor="post-not-request-uri">
        <name>POST Response does not Does Not Reference the Request URI</name>
        <t>The request <tt>Repr-Digest</tt> field-value is computed on the enclosed representation
(see <xref target="state-changing-requests"/>), which is the JSON object <tt>{"title": "New
Title"}</tt> followed by an LF.</t>
        <t>The representation enclosed in the response is a multiline JSON object followed by an LF.
It refers to the resource identified by
<tt>Content-Location</tt> (see <xref section="6.4.2" sectionFormat="of" target="RFC9110"/>);
thus, an application can thus use <tt>Repr-Digest</tt> in association with the resource
referenced by <tt>Content-Location</tt>.</t>
        <figure>
          <name>POST Request with Digest</name> <tt>Digest</tt></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=:

{"title": "New Title"}
]]></sourcecode>
        </figure>
        <figure>
          <name>Response with Digest <tt>Digest</tt> of Resource</name>
          <sourcecode type="http-message"><![CDATA[
HTTP/1.1 201 Created
Content-Type: application/json
Content-Location: /books/123
Location: /books/123
Repr-Digest: sha-256=:uVSlinTTdQUwm2On4k8TJUikGN1bf/Ds8WPX4oe0h9I=:

{
  "id": "123",
  "title": "New Title"
}
]]></sourcecode>
        </figure>
      </section>
      <section anchor="post-referencing-status">
        <name>POST Response Describes the Request Status</name>
        <t>The request <tt>Repr-Digest</tt> field-value is computed on the enclosed representation (see
<xref target="state-changing-requests"/>), which is the JSON object <tt>{"title": "New
Title"}</tt> followed by an LF.</t>
        <t>The representation enclosed in the response describes the status of the request,
so <tt>Repr-Digest</tt> is computed on that enclosed representation. It is a multiline
JSON object followed by an LF.</t>
        <t>Response <tt>Repr-Digest</tt> has no explicit relation with the resource referenced by
<tt>Location</tt>.</t>
        <figure>
          <name>POST Request with Digest</name> <tt>Digest</tt></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=:

{"title": "New Title"}
]]></sourcecode>
        </figure>
        <figure>
          <name>Response with Digest <tt>Digest</tt> of Representation</name>
          <sourcecode type="http-message"><![CDATA[
HTTP/1.1 201 Created
Content-Type: application/json
Repr-Digest: sha-256=:yXIGDTN5VrfoyisKlXgRKUHHMs35SNtyC3szSz1dbO8=:
Location: /books/123

{
  "status": "created",
  "id": "123",
  "ts": 1569327729,
  "instance": "/books/123"
}
]]></sourcecode>
        </figure>
      </section>
      <section anchor="digest-with-patch">
        <name>Digest
        <name><tt>Digest</tt> with PATCH</name>
        <t>This case is analogous to a POST request where the target resource reflects the
target URI.</t>
        <t>The PATCH request uses the <tt>application/merge-patch+json</tt> media type defined in
<xref target="RFC7396"/>. <tt>Repr-Digest</tt> is calculated on the content, which content that corresponds to the
patch document and is the JSON object <tt>{"title": "New Title"}</tt> followed by an
LF.</t>
        <t>The response <tt>Repr-Digest</tt> field-value is computed on the complete representation of the patched
resource. It is a multiline JSON object followed by an LF.</t>
        <figure anchor="fig-patch">
          <name>PATCH Request with Digest</name> <tt>Digest</tt></name>
          <sourcecode type="http-message"><![CDATA[
PATCH /books/123 HTTP/1.1
Host: foo.example
Content-Type: application/merge-patch+json
Accept: application/json
Accept-Encoding: identity
Repr-Digest: sha-256=:mEkdbO7Srd9LIOegftO0aBX+VPTVz7/CSHes2Z27gc4=:

{"title": "New Title"}
]]></sourcecode>
        </figure>
        <figure>
          <name>Response with Digest <tt>Digest</tt> of Representation</name>
          <sourcecode type="http-message"><![CDATA[
HTTP/1.1 200 OK
Content-Type: application/json
Repr-Digest: sha-256=:uVSlinTTdQUwm2On4k8TJUikGN1bf/Ds8WPX4oe0h9I=:

{
  "id": "123",
  "title": "New Title"
}
]]></sourcecode>
        </figure>
        <t>Note that a <tt>204 No Content</tt> response without content content, but with the same
<tt>Repr-Digest</tt> field-value field-value, would have been legitimate too.
In that case, <tt>Content-Digest</tt> would have been computed on an empty content.</t>
      </section>
      <section anchor="error-responses">
        <name>Error responses</name> Responses</name>
        <t>In error responses, the representation data does not necessarily refer to the
target resource. Instead, it refers to the representation of the error.</t>
        <t>In the following example, a client sends the same request from <xref target="fig-patch"/> to
patch the resource located at /books/123. However, the resource does not exist
and the server generates a 404 response with a body that describes the error in
accordance with <xref target="RFC7807"/>.</t> target="RFC9457"/>.</t>
        <t>The response <tt>Repr-Digest</tt> field-value is computed on this enclosed representation.
It is a multiline JSON object followed by an LF.</t>
        <figure>
          <name>Response with Digest <tt>Digest</tt> of Error Representation</name>
          <sourcecode type="http-message"><![CDATA[
HTTP/1.1 404 Not Found
Content-Type: application/problem+json
Repr-Digest: sha-256=:EXB0S2VF2H7ijkAVJkH1Sm0pBho0iDZcvVUHHXTTZSA=:

{
  "title": "Not Found",
  "detail": "Cannot PATCH a non-existent resource",
  "status": 404
}
]]></sourcecode>
        </figure>
      </section>
      <section anchor="use-with-trailer-fields-and-transfer-coding">
        <name>Use with Trailer Fields and Transfer Coding</name>
        <t>An origin server sends <tt>Repr-Digest</tt> as trailer field, so it can calculate digest-value
while streaming content and thus mitigate resource consumption.
The <tt>Repr-Digest</tt> field-value is the same as in <xref target="example-full-representation"/> because <tt>Repr-Digest</tt> is designed to
be independent of the use of one or more transfer codings (see <xref target="representation-digest"/>).</t>
        <t>In the response content below, the string "\r\n" represent represents the bytes CRLF.</t> CRLF bytes.</t>
        <figure>
          <name>GET Request</name>
          <sourcecode type="http-message"><![CDATA[
GET /items/123 HTTP/1.1
Host: foo.example
]]></sourcecode>
        </figure>
        <figure>
          <name>Chunked Response with Digest</name> <tt>Digest</tt></name>
          <sourcecode type="http-message"><![CDATA[
NOTE: '\' line wrapping per RFC 8792

HTTP/1.1 200 OK
Content-Type: application/json
Transfer-Encoding: chunked
Trailer: Digest Repr-Digest

8\r\n
{"hello"\r\n
8\r\n
: "world\r\n
3\r\n
"}\n\r\n
0\r\n
Repr-Digest: \
  sha-256=:RK/0qy18MlBSVnWgjwz6lZEWjP/lF5HF9bvEF8FabDg==:\r\n
]]></sourcecode>
        </figure>
      </section>
    </section>
    <section anchor="examples-solicited">
      <name>Examples of Want-Repr-Digest <tt>Want-Repr-Digest</tt> Solicited Digest</name> <tt>Digest</tt></name>
      <t>The following examples demonstrate interactions where a client solicits a
<tt>Repr-Digest</tt> using <tt>Want-Repr-Digest</tt>.
The behavior of <tt>Content-Digest</tt> and <tt>Want-Content-Digest</tt> is identical.</t>
      <t>Some examples include JSON objects in the content.
For presentation purposes, objects that fit completely within the line-length limits
are presented on a single line using compact notation with no leading space.
Objects that would exceed line-length limits are presented across multiple lines
(one line per key-value pair) with 2 two spaces of leading indentation.</t>
      <t>Checksum mechanisms described in this document are media-type agnostic
and do not provide canonicalization algorithms for specific formats.
Examples are calculated inclusive of any space.</t>
      <section anchor="server-selects-clients-least-preferred-algorithm">
        <name>Server Selects Client's Least Preferred Algorithm</name>
        <t>The client requests a digest, preferring digest and prefers "sha". The server is free to reply with
"sha-256" anyway.</t>
        <figure>
          <name>GET Request with Want-Repr-Digest</name> <tt>Want-Repr-Digest</tt></name>
          <sourcecode type="http-message"><![CDATA[
GET /items/123 HTTP/1.1
Host: foo.example
Want-Repr-Digest: sha-256=3, sha=10
]]></sourcecode>
        </figure>
        <figure>
          <name>Response with Different Algorithm</name>
          <sourcecode type="http-message"><![CDATA[
NOTE: '\' line wrapping per RFC 8792

HTTP/1.1 200 OK
Content-Type: application/json
Repr-Digest: \
  sha-256=:RK/0qy18MlBSVnWgjwz6lZEWjP/lF5HF9bvEF8FabDg==:

{"hello": "world"}
]]></sourcecode>
        </figure>
      </section>
      <section anchor="ex-server-selects-unsupported-algorithm">
        <name>Server Selects Algorithm Unsupported by Client</name>
        <t>The client requests a "sha" digest because that is the only algorithm it
supports. The server is not obliged to produce a response containing a "sha"
digest,
digest; it instead uses a different algorithm.</t>
        <figure>
          <name>GET Request with Want-Repr-Digest</name> <tt>Want-Repr-Digest</tt></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 with Unsupported Algorithm</name>
          <sourcecode type="http-message"><![CDATA[
NOTE: '\' line wrapping per RFC 8792

HTTP/1.1 200 OK
Content-Type: application/json
Repr-Digest: \
  sha-512=:YMAam51Jz/jOATT6/zvHrLVgOYTGFy1d6GJiOHTohq4yP+pgk4vf2aCs\
  yRZOtw8MjkM7iw7yZ/WkppmM44T3qg==:

{"hello": "world"}
]]></sourcecode>
        </figure>
      </section>
      <section anchor="server-does-not-support-client-algorithm-and-returns-an-error">
        <name>Server Does Not Support Client Algorithm and Returns an Error</name>
        <t><xref target="ex-server-selects-unsupported-algorithm"/> is an example where a server ignores
the client's preferred digest algorithm.
Alternatively
Alternatively, a server can also reject
the request and return a response with
an error status code such as 4xx or 5xx.
This specification does not prescribe
any requirement on status code selection;
the follow following example illustrates one possible
option.</t>
        <t>In this example, the client requests a "sha" <tt>Repr-Digest</tt>, and the server returns an
error with problem details <xref target="RFC7807"/> target="RFC9457"/> contained in the content. The problem
details contain a list of the hashing algorithms that the server supports. This
is purely an example, example; this specification does not define any format or
requirements for such content.</t>
        <figure>
          <name>GET Request with Want-Repr-Digest</name> <tt>Want-Repr-Digest</tt></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 advertising Advertising the supported algorithms</name> Supported Algorithms</name>
          <sourcecode type="http-message"><![CDATA[
HTTP/1.1 400 Bad Request
Content-Type: application/problem+json

{
  "title": "Bad Request",
  "detail": "Supported hashing algorithms: sha-256, sha-512",
  "status": 400
}
]]></sourcecode>
        </figure>
      </section>
    </section>
    <section anchor="sample-digest-values">
      <name>Sample Digest <tt>Digest</tt> Values</name>
      <t>This section shows examples of digest values for different hashing algorithms.
The input value is the JSON object <tt>{"hello": "world"}</tt>. The digest values are
each produced by running the relevant hashing algorithm over the input and
running the output bytes through <tt>Byte Sequence</tt> Byte Sequence serialization; see <xref section="4.1.8" sectionFormat="of" target="STRUCTURED-FIELDS"/>.</t>
      <artwork><![CDATA[ target="RFC8941"/>.</t>
      <sourcecode><![CDATA[
NOTE: '\' line wrapping per RFC 8792

sha-512 -   :WZDPaVn/7XgHaAy8pmojAkGWoRx2UFChF41A2svX+TaPm+\
            AbwAgBWnrIiYllu7BNNyealdVLvRwEmTHWXvJwew==:

sha-256 -   :X48E9qOokqqrvdts8nOJRJN3OWDUoyWxBf7kbu9DBPE=:

md5 -       :Sd/dVLAcvNLSq16eXua5uQ==:

sha -       :07CavjDP4u3/TungoUHJO/Wzr4c=:

unixsum -   :GQU=:

unixcksum - :7zsHAA==:

adler -     :OZkGFw==:

crc32c -    :Q3lHIA==:
]]></artwork>
]]></sourcecode>
    </section>
    <section anchor="migrating">
      <name>Migrating from RFC 3230</name>
      <t>HTTP digests are computed by applying a hashing algorithm to input data.
RFC 3230
<xref target="RFC3230"/> defined the input data as an "instance", a term it also defined.
The concept of an instance has since been superseded by the HTTP semantic term "representation".
It is understood that some implementations of RFC 3230 <xref target="RFC3230"/>
mistook "instance" to mean HTTP content.
Using content for the Digest <tt>Digest</tt> field is an error
that leads to interoperability problems between peers that implement RFC 3230.</t>
      <t>RFC 3230 <xref target="RFC3230"/>.</t>
      <t><xref target="RFC3230"/> was only ever intended
to use what HTTP now defines as selected representation data.
The semantic concept of digest and representation are explained
alongside the definition of <xref target="representation-digest">the Repr-Digest field</xref>.</t> the <tt>Repr-Digest</tt> field (<xref target="representation-digest"/>).</t>
      <t>While the syntax of Digest <tt>Digest</tt> and Repr-Digest <tt>Repr-Digest</tt> are different,
the considerations and examples this document gives for Repr-Digest <tt>Repr-Digest</tt>
apply equally to Digest <tt>Digest</tt> because they operate on the same input data;
see Sections <xref format="counter" target="state-changing-requests"/>, <xref format="counter" target="security"/> and <xref format="counter" target="usage-in-signatures"/>.</t>
      <t>RFC 3230
      <t><xref target="RFC3230"/> could never communicate
the digest of HTTP message content in the Digest <tt>Digest</tt> field;
Content-Digest
<tt>Content-Digest</tt> now provides that capability.</t>
      <t>RFC 3230
      <t><xref target="RFC3230"/> allowed algorithms to define their output encoding format for use with
the Digest <tt>Digest</tt> field. This resulted in a mix of formats such as base64, hex hex, or
decimal. By virtue of using Structured fields, Content-Digest Fields, <tt>Content-Digest</tt>, and Repr-Digest <tt>Repr-Digest</tt>
use only a single encoding format. Further explanation and examples are provided in <xref target="sample-digest-values"/>.</t>
    </section>
    <section numbered="false" anchor="acknowledgements">
      <name>Acknowledgements</name>
      <t>This document is based on ideas from <xref target="RFC3230"/>, so thanks
to Jeff Mogul <contact fullname="Jeff Mogul"/> and Arthur <contact fullname="Arthur Van Hoff Hoff"/> for their great work.
The original idea of refreshing RFC3230 <xref target="RFC3230"/> arose from an interesting
discussion with Mark Nottingham, Jeffrey Yasskin, <contact fullname="Mark Nottingham"/>, <contact fullname="Jeffrey Yasskin"/>, and Martin Thomson <contact fullname="Martin Thomson"/> when reviewing
the MICE content coding.</t>
      <t>Thanks to Julian Reschke <contact fullname="Julian Reschke"/> for his valuable contributions to this document,
and to the following contributors that have helped improve this specification by reporting bugs,
asking smart questions, drafting or reviewing text, and evaluating open issues:
Mike Bishop,
Brian Campbell,
Matthew Kerwin,
James Manger,
Tommy Pauly,
Sean Turner,
Justin Richer,
and Erik Wilde.</t>
    </section>
    <section numbered="false" removeInRFC="true" anchor="code-samples">
      <name>Code Samples</name>
      <t>How can I generate and validate the digest values, computed over the JSON object
<tt>{"hello": "world"}</tt> followed by an LF, shown in the examples throughout this
document?</t>
      <t>The following python3 code can be used to generate digests for JSON objects
using SHA algorithms for a range of encodings. Note that these are formatted as
base64. This function could be adapted to other algorithms and should take into
account their specific formatting rules.</t>
      <artwork><![CDATA[
import base64, json, hashlib, brotli, logging
log = logging.getLogger()

def digest_bytes(bytes_, algorithm=hashlib.sha256):
    checksum_bytes = algorithm(bytes_).digest()
    log.warning("Log bytes: \n[%r]", bytes_)
    return base64.encodebytes(checksum_bytes).strip()

def digest(bytes_, encoding=lambda x: x, algorithm=hashlib.sha256):
    content_encoded = encoding(bytes_)
    return digest_bytes(content_encoded, algorithm)

bytes_ = b'{"hello": "world"}\n'

print("Encoding | hashing algorithm | digest-value")
print("Identity | sha256 |", digest(bytes_))
# Encoding | hashing algorithm | digest-value
# Identity | sha256 | RK/0qy18MlBSVnWgjwz6lZEWjP/lF5HF9bvEF8FabDg=

print("Encoding | hashing algorithm | digest-value")
print("Brotli | sha256 |", digest(bytes_, encoding=brotli.compress))
# Encoding | hashing algorithm | digest-value
# Brotli | sha256 | d435Qo+nKZ+gLcUHn7GQtQ72hiBVAgqoLsZnZPiTGPk=

print("Encoding | hashing algorithm | digest-value")
print("Identity | sha512 |", digest(bytes_, algorithm=hashlib.sha512))
print("Brotli | sha512 |", digest(bytes_, algorithm=hashlib.sha512,
                                    encoding=brotli.compress))
# Encoding | hashing algorithm | digest-value
# Identity | sha512 |b'YMAam51Jz/jOATT6/zvHrLVgOYTGFy1d6GJiOHTohq4yP'
#                     '+pgk4vf2aCsyRZOtw8MjkM7iw7yZ/WkppmM44T3qg=='

# Brotli | sha512 | b'db7fdBbgZMgX1Wb2MjA8zZj+rSNgfmDCEEXM8qLWfpfoNY'
#                    '0sCpHAzZbj09X1/7HAb7Od5Qfto4QpuBsFbUO3dQ=='

]]></artwork>
    </section>
    <section numbered="false" removeInRFC="true" anchor="changes">
      <name>Changes</name>
      <section numbered="false" anchor="since-draft-ietf-httpbis-digest-headers-12">
        <name>Since draft-ietf-httpbis-digest-headers-12</name>
        <ul spacing="normal">
          <li>Be clearer that applications can enforce additional requirements wrt digest</li>
          <li>Change algorithm status names: s/standard/active, s/insecure/deprecated</li>
          <li>Remove "reserved" algorithm status</li>
          <li>Provide clear guidance about the use of standard or deprecated algorithms</li>
          <li>Editorial or minor changes</li>
        </ul>
      </section>
      <section numbered="false" anchor="since-draft-ietf-httpbis-digest-headers-11">
        <name>Since draft-ietf-httpbis-digest-headers-11</name>
        <ul spacing="normal">
          <li>Editorial or minor changes</li>
        </ul>
      </section>
      <section numbered="false" anchor="since-draft-ietf-httpbis-digest-headers-10">
        <name>Since draft-ietf-httpbis-digest-headers-10</name>
        <ul spacing="normal">
          <li>Editorial or minor changes</li>
        </ul>
      </section>
      <section numbered="false" anchor="since-draft-ietf-httpbis-digest-headers-09">
        <name>Since draft-ietf-httpbis-digest-headers-09</name>
        <ul spacing="normal">
          <li>Editorial or minor changes</li>
        </ul>
      </section>
      <section numbered="false" anchor="since-draft-ietf-httpbis-digest-headers-08">
        <name>Since draft-ietf-httpbis-digest-headers-08</name>
        <ul spacing="normal">
          <li>Add note about migrating from RFC 3230. #1968, #1971</li>
          <li>Clarify what Want-* means in responses. #2097</li>
          <li>Editorial changes to structure and to align to HTTP style guide.</li>
        </ul>
      </section>
      <section numbered="false" anchor="since-draft-ietf-httpbis-digest-headers-07">
        <name>Since draft-ietf-httpbis-digest-headers-07</name>
        <ul spacing="normal">
          <li>Introduced Repr-Digest and Want-Repr-Digest, and deprecated
Digest and Want-Digest. Use of Structured Fields. #1993, #1919</li>
          <li>IANA refactoring. #1983</li>
          <li>No normative text in security considerations. #1972</li>
        </ul>
      </section>
      <section numbered="false" anchor="since-draft-ietf-httpbis-digest-headers-06">
        <name>Since draft-ietf-httpbis-digest-headers-06</name>
        <ul spacing="normal">
          <li>Remove id-sha-256 and id-sha-512 from the list of supported algorithms #855</li>
        </ul>
      </section>
      <section numbered="false" anchor="since-draft-ietf-httpbis-digest-headers-05">
        <name>Since draft-ietf-httpbis-digest-headers-05</name>
        <ul spacing="normal">
          <li>Reboot digest-algorithm values registry #1567</li>
          <li>Add Content-Digest #1542</li>
          <li>Remove SRI section #1478</li>
        </ul>
      </section>
      <section numbered="false" anchor="since-draft-ietf-httpbis-digest-headers-04">
        <name>Since draft-ietf-httpbis-digest-headers-04</name>
        <ul spacing="normal">
          <li>Improve SRI section #1354</li>
          <li>About duplicate digest-algorithms #1221</li>
          <li>Improve security considerations #852</li>
          <li>md5 and sha deprecation references #1392</li>
          <li>Obsolete 3230 #1395</li>
          <li>Editorial #1362</li>
        </ul>
      </section>
      <section numbered="false" anchor="since-draft-ietf-httpbis-digest-headers-03">
        <name>Since draft-ietf-httpbis-digest-headers-03</name>
        <ul spacing="normal">
          <li>Reference semantics-12</li>
          <li>Detail encryption quirks</li>
          <li>Details on Algorithm agility #1250</li>
          <li>Obsolete parameters #850</li>
        </ul>
      </section>
      <section numbered="false" anchor="since-draft-ietf-httpbis-digest-headers-02">
        <name>Since draft-ietf-httpbis-digest-headers-02</name>
        <ul spacing="normal">
          <li>Deprecate SHA-1 #1154</li>
          <li>Avoid id-* with encrypted content</li>
          <li>Digest is independent of MESSAGING and HTTP/1.1 is not normative #1215</li>
          <li>Identity is not a valid field value for content-encoding #1223</li>
          <li>Mention trailers #1157</li>
          <li>Reference httpbis-semantics #1156</li>
          <li>Add contentMD5 as an obsoleted digest-algorithm #1249</li>
          <li>Use lowercase digest-algorithms names in the doc and in the digest-algorithm IANA table.</li>
        </ul>
      </section>
      <section numbered="false" anchor="since-draft-ietf-httpbis-digest-headers-01">
        <name>Since draft-ietf-httpbis-digest-headers-01</name>
        <ul spacing="normal">
          <li>Digest of error responses is computed on the error representation-data #1004</li>
          <li>Effect of HTTP semantics on payload and message body moved to appendix #1122</li>
          <li>Editorial refactoring, moving headers sections up. #1109-#1112, #1116,
#1117, #1122-#1124</li>
        </ul>
      </section>
      <section numbered="false" anchor="since-draft-ietf-httpbis-digest-headers-00">
        <name>Since draft-ietf-httpbis-digest-headers-00</name>
        <ul spacing="normal">
          <li>Align title with document name</li>
          <li>Add id-sha-* algorithm examples #880</li>
          <li>Reference <xref target="RFC6234"/>
<contact fullname="Mike Bishop"/>,
<contact fullname="Brian Campbell"/>,
<contact fullname="Matthew Kerwin"/>,
<contact fullname="James Manger"/>,
<contact fullname="Tommy Pauly"/>,
<contact fullname="Sean Turner"/>,
<contact fullname="Justin Richer"/>,
and <xref target="RFC3174"/> instead of FIPS-1</li>
          <li>Deprecate MD5</li>
          <li>Obsolete ADLER-32 but don't forbid it #828</li>
          <li>Update CRC32C value in IANA table #828</li>
          <li>Use when acting on resources (POST, PATCH) #853</li>
          <li>Added Relationship with SRI, draft Use Cases #868, #971</li>
          <li>Warn about the implications of <tt>Content-Location</tt></li>
        </ul>
      </section> <contact fullname="Erik Wilde"/>.</t>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA+19aXfbRpbo9/oVNfJ5x3ZCUqJ2Ke3uoTZLjrZosR0nOW2Q
AClYJMAAoGTa8fyW+S3vl727VaGwUJYcO9PzTufkJBQJ1HLr1t2XZrOpsjAb
Bpt6JxwEaab3wmDop8qPe5E3gq/9xOtnzTDI+s2rLBt3w7Tp05PNq8DzgyRt
tpdUz8uCQZxMN3Wa+SrupvEwyIJ0Uy8tLi0oFY6TTZ0lkzRbXFjYWFhUXhJ4
m7ozHg9DeDWMo1R7ka/PAm/YvAhHgbqNk+tBEk/Gm3r/4uJUXQdT+Mo3q1Qq
zeCFf3rDOII1ToNUpSMvyf75+ySmeaNYjcNN/UsW9xoa/hNGfhBlDZ3GSZYE
/RQ+TUfyIUvCHvzUi0djTz6M4GH4KYyGYRQ0NABj5I3HYTT4TambIJoEm0pr
d31aZ9MxrOQVrBse08/xN/j2KkYYIuDSzfl5/P/toBUng3n4beSFw01tIdu8
Hfzn7RL+CL95Se8qf28Yplna4h/nO/BTeBOk86eTLoBv3h0Ah02CcZy/Ogiz
q0m3BXuS2el/zeB9FkQpAn5+6HWDYTpfPFTF7zXDNJ0ETXoEUKH4iPIm2VWc
ACiaMK0GaAHgz1r6NB4OQ/qGMegs7gZJFjvfwzY29UXgjfA4w8wbAowP4H+h
F+nn8U2QRHgA9GjAUEribjjG9/9zgF/gfujnXjyJMsQ7fH1aWMkhrMRL/Eng
LOVw0vNS92tayfYwnvj9ISClO+UQnx3To63F5daaM7OK4mQEeHtDeHC2t91e
WmzLx6X22rL5dmNlQT4ury6vy8eVxSXzwGr+cW15YQU/7p0c7hwcP9/E79bX
Nhb51412m0bScAbpeOhNBe1UGPVLS8Ebt2nfWqx5a77dasO3p52L7X2aZ2Vt
fQO+OD5pHu2s0Der7ZU2f3O+35FvNpbhm/OD58edi8uz3XMAeXOnVaALoyBN
vUHQTMNB5GWTBG6l1pfHB695EUJnLq4CfQ53ZBjQb/p8HPTCvtCBhn4JqAUf
9KJu6lX9Mh7q8yDTsEt+emOdxrKop3N8gnFPxkFk7x5sG8jSpm5vbKw1FxCS
xwfnF+sLC82lxcKKDgCFYn/SwwVoRFS6WPrHYApI2ruK4mE8mBKBymCOvQCw
3xvq0x8P4M1+4gEBgXcngj01KzumrcErB1EKU06yQMd9fY4UDNCLSV8+UUNf
ts5beicA3MvwHuDD20iTkl7gbAtIaZu3BRvxkkGQ5bc+uhmOJ920FQHhaA3i
m3n8gN/MHwYDrzedPz+lr1KEvYfPGkLM4GmN/T4MvH102VxfWl1YXS/AC7BE
v5wMIwBDF04RINbDq0nH5mWZ17tOZ4Fi20uiYBAG+igYAu3WlxFgLhx4Bts+
j/vZLVxCvRsNgOwGCRJSC7Lizteb7cXmUrt287e3t61rIHlAdIhg3kyAvIX+
PO8ESeRBZ/usubiwuNBcaC8Xtgbo3mzrEM5En195I9he3Vaa8n9Dap639GEA
CCA0K9/uQZSEXkPvJV4kZ1d9+QLoVDCFzZbePfaiqQcQsJgBJzQsAgwA5I3j
JPgBHhp5aXCtD71unHhZnIRB6jxQAB5tu7mwUgu8YAwryVqh10sIePj4PECJ
MEI1m03tdQHhgVEqdXEFgALeOCEs9YM+nFpKJEb3SYqA++JlOp2MYQ0Z7BaE
hARWLowkbeGdVdsxfB9lTZE/6E3dA07QDfQkDXy6+3jx8vfhQtAsQnAA/WgI
Hu8MtvAlgwHfBIoFw7BA0lKvPFhVaXV4Vel7dxZ3fLgMIGvgZQoAh2A4IBaP
U4XTJWYAmKcPfwFKpLSeJOgF4Q1iO64MHoNbiRQdCZMskuHZKsPcSlpIoknY
smSqvGD5m9iGHY0OdBT6/jBQ6lGBECpFUPFjGDyKzfHS0KPAA4ENdjpOQNrq
ZfQlYJdXhKqcCmCzKsNWv7oCQu2eIdw4uPmAWFEKsEkAkt0guw3gKQDhOA5J
HhvGt0GigZEFieoHzGJgeFzHGG474DwgW+9KA4+/2D7VvasASNFkRM9cHJ4j
oGMkuB8//gP+fIYsdnl59dMnOkEY5Cb0A5WCyOZsRPYIy27pfZgfbl+D14lI
3cSbBs/6xTdwINiRGoajEH+cZOEQf+oGPQ/QRIcZ0ph47P0+IfqJAPRyaZi3
SGcXR8MpQBLvvMKnSHAjlgDYxVwU4BzZFRZACgQVAAiLvQmGGseAl3pXXhjB
LypFBoNomr8PB3MQWcA73+MC4XiILo7jNA27vB/AXkUHD3BNJmNeQ0dONofI
CEiYB/xmVAB0jkp4CZxjhr88VzWY4EZpTJTlARMJ6UrzKoTWyLsOaI9x2IMP
3XiSgQh+i28BxQJgAuRpgcF7bzQe0p2FNaW0NXwo9FXfmwwzmYQ4Gozrh94g
ilPcfy+B/YP2kGbBSMMEyMMB8SpX05DD7DYWelcHEN47bq2l9sIkJfWDr419
uqFvr0LE6l6W4hbggZtgClhlnnzy8eO5LHa1tYxnKyLjp09PWwp+iiO/UaJv
pftanqPuYWeadZAgAQWdaTTtXkg9gMm/QZbnWwDnN/MG5HwYT8idKpAMD6lf
PAFBh1nHLTyPlzZiGQvpdxKPNEpG+ANobnAffUYQNYJzC/FQkwCuVZrRtXeR
W92ffAKFjpPgnoT0B6DzARAVM1wTR/r0Ced79EjvmNnOrZxYWgYCzvzmI4j6
IE7Ft+km0Gd9HNyaDdEakD3AZgLNahgvOAHNBD4zuyPMC2XLIG/AygRTRHMH
gvekyNeeNuTB4rk7zzv87mkDJ5UXbhEkDAZ87L48E/CyCUItqKAoTPM1T0UR
wIt4J7KaXaXwa9DEmwTy4qBpjh3XcV74yWKE3aeosrC0poHNMGZ640LnUL5z
4MPo2SwuEFkIvAKUNdVouoBjFAqDRFifVXcjeqoVYYL3tFiU2nLgmjGakwgw
K+whL4GpEKDOj+5PsoryImA8WcadgoxIbXXLwvP6+NEbDoDhZVcjBLLsKdVX
Xgo32/yEa3CPlegnE0OyTgxClB8JEMAJgEYQF0cy2J/gDQBOkAlFhdsDJ9EL
xpk+Ae51Ewa3eHeCgozJYyMDhuvqXquy2FdkSi3QKyOyYwC3iFNkG7gPxJZ8
K7h2kLp7kyHLc0LIiQjB6GE0BgaTBPirL3xcuSyYJFJnvBCtUIDjcm9lOCv5
gLDAogQOnhOYFpwcSoiwWNqUUFAmT2ZJsEFHBJkkwKYBhnqf96Tyk6Pp+BiC
xMAt0HP4pO7kj1mQFQyDc+YEp/oJUD0FeAjXENTH9KqJ8GvaiZrmQeJCwIaG
SIdFyKULDRjAXEf0AVqZBTdiDajzPvEjfMfyakDlMqBTYUD28K0Q5od9ErYt
dtt9Fa8wyzF4KvSjUSkI32BZuLScl93ydyCBkRQhZ8DrKryvu1NkL2GqkASF
AG9GibdFGvn2gSQexjNoD1hnFCwDRkf2rogGDs8mtqWqzAH2vAcwGiEDrPLx
Bu3xrUM27ly8qi7+yUw28xRZoWwMRNEsJ6r26gHuTwKFttoJokh3SqLilK5t
zQVG6BDiBX4dT1FFmUaXZJotjyTP4mYFG82wJd2GRNAUBXykcuHgKgN8u/US
OihaKv4Gn8vIhBhd0me14AywRtRJ0HaNKxyB5DjGKyLmqm5gSS6JD+UVCVpa
yYqlIpqARUmS6kGkCr1hGUgFmayhjAx3hjwBqJLIWU9Y/jGQbJcQDRCqgu+I
FkW4GiyuocID0jZaRPrf1ogYMlyZn701V95DcUpZDQOBFrzHfabaKuZABj+/
SJUr58Npgy9mPla+YlfDh4GDEEXK+4GBaCDIf2YWDesbAZpVbQEPggQat2uG
dUwM+Zpza0N5UmZVoWV2Och2o17sw7G9pQtvv76YjoO3ho7JsPrCyNcAQT2A
5UQ5co68KWDADXwQaV7lBNwlAXRtooLB4BagLKpUzcLp6sGq6wxHup4l8FKn
wFQUWkBqhyAlw2wstw/gayJ/AK3qEqWm9cWICcrR/0jPMYaUUZB5SJcaVlvy
2UGic5s6uqVgUgRoFivXBDO+InqCd1ZUcCO+4Su3V6CcaBIT6La3NFJ5kRAb
LG4cCVzO7Wx4ra3NnwTMydB3rV24sIqhCiEwSRUzYbzMZMHAkS33dUBfQ5iN
Op26zoGKMSq3HqB9FkUr40Vge234Qf4kG1F44/WmLFWesKaGK7Oa38dHRf1N
qV/EnfKblTEJ5as3zXzjiqU1EqcCjuYNUzSX29HwGuo5YHEZ8tk5GtT+WSD1
c4VzB5ozREG/x/Kx4BFezyi+Zd49YVMxEL+p2QCTLBJaRmS2aiCO0dGnAUwG
AMwV9bsYp76TcSq1+34coGUM9nCFQ13FtxEv0U4u6gG8mcOZbj6RZJgxYxAp
PGU8KXjSAVQYEdNLEYmQFg+BxpB0GfMAaBH0xExFXkwxN49itNjGoxEag/B7
kd9TQ9JGMCaakVCKElnUSq1MgNge9eQWtqNuGeDw5PBpmaw0NOg5V3hecAnd
t7T7Vpldsxyaku0DUBj0VzpB3BToKygXCctC6x9sPAtHDGRELeVA2nPk0jLB
E9rUDSJADHQBEb6SmGEFE9CQYsWWSqTBYQ/tYrn9LezDHiJUn8kFiUcNP+Zn
GTJzjcT3FScKEDL/goi0xWcQNH3ioeOYnoAXnAPuoWUXMdcDUjqY4JGyHU7V
YNPs+9koKYjW/JPfdJbOK9zjybkxhH78+LeKMQUVdvh+plCLC7mDz+JdKphR
nqqZOi1e8G4AWiKQvCFQXsNWepOEWCRRnPwq48roTqH7W2gE0YYeXJcEsAql
PtFujVcEkQyQgJQqtmAdx5nxYG6jwEgnmJI0dg187pZs6nNHl+cXcw3+vz4+
oc9nuz9dHpzt7uDn8/3O4aH9oOSJ8/2Ty8Od/FP+5vbJ0dHu8Q6/DN/qwldq
7qjz8xzTs7mT04uDk+PO4Vw9wFhGdsmKh/pT2kvCLgN5a/v0//43iK0fP/4H
YMJiu70Bx8p/rLfXluEPlDYauUWe/0Q2r0AsAFiS0j4cws0ZI79OibDyZURp
ByD53S8Imd829d+6vXF7+e/yBW648KWBWeFLgln1m8rLDMSar2qmsdAsfF+C
dHG9nZ8Lfxu4O1/+7R8YMqOb7fV//L1ib52khISB7kwGzH/01vGea8H5RQIk
fiNQT8a+x1oe3VCMkfhNFH2gDsOJL8MlkyEG/Wyf6Sc9L0lCwF2gqiC/RE8b
+nBPP6E19YPAZ9slPInfwvOHe08rlnu7SjbDEvEHLh1KHAAZf3Lut4T29v84
vzi73EYZaae5d7B7uMPOpY3lNqAOCkkkxkx1OgXq8J6dgF6CDGFTbcVAhDzA
pq0p3MJz1KmANjT0TkgTeAnQeKIeKFjim4fo1Gc7mGPq1XNF+oO3ZgYHx59q
jB/Vr608ij8BWIDoDOA3c+2EEN5161Tx1unCrfv40coMsw+Bjy4eEnMnyyHG
D5Tu7y8SNvMbjLNf0R+Z+InqRoP2WLEnGZbtX2HiADNfxpOgNWg1OCygAWgD
XKKHGFNUAazHt6K7GucVsFtrWqPAEqD5BWsqSk2vjCEgn594BbumyiOEZD9N
AVOYR1Pom29WPJde0an1kh4see6pIAyLm8YxOmfPg2EdTzI0aIrBwHVIsk5h
F6xwQcBnGFfxV7JzNRTZMuCc55j7zZGbEwmmATUJW2K4wElImTN2ntwaOVMD
3XSUY94NCi730NzVHRx4xqA1WrQVKUoTIqMk0aHk+yCjKagWJZmBD6Oy6lx/
KBivCWxianFNbIgXaAobgWBF6GcMgFYXcIypgod15hU8Z1LmyCXr9bIJcPqy
xFiy8VSsiWSvQwepeptTrrfl15ZaixT7VCaXKPSwHSzwelebwC1JtDD2KVxX
deEytnuNniptNVMxEjqS+w8wLCMcebLfFijuW1enWWottVZmrbRBAFY6N59h
lEIvRsHpRsLX5A7htTDXakyxFWy0zNeEwxg1I47E9ipaOcDhv/7rvyg2xwTX
ody0u6kf//qYKeNtwoGpGtQd0mUpaLAUVLOpf4VpgCI0V9qLzzZ/Pup4o5X2
iw/z7046Fxer8x9u9pPDl4OTny+e703b/urzF+HJ/kV89fvy9PT78eB6+aa/
6G2nOMj07M1Jdrt+9O76aC28XZu+mX91PR6PjpaXL5Z+Hzx7tokrFvR28QDD
Y12kbrDT31gfkJ5g5NiVtfsYZFYVHM4NQjXk1tGRrUURYxaMFo1u69wQSLJz
Ph6u6CYeUigOCHKsPoakCZFOHOFdSWJcJtlBlJmBzFDCh71bT4SE2wD0yMRd
nWBsGvSaYtRkdfkrn/LiyuqzTX95aeWn+PvoxzffDw57l/vR2vOfsp/WFq/C
rZedwe/xYfomenMaXjw/vX622firEaSDfv1wjMEzGsRKDboM+RuiKYV/gCRt
g8ScMPGm9RF3A9BrQngU9Er03A7hjOGpKQ2WBhkqlKEoLRw/4NGJi/WePI+p
sGbfxiQAfowxti3ssR2NZAUTbmEWRMgNRzghZlLydnKoDmvSMgBbHxw3oaLN
MioPXAN6ES+UuzJ4uHwz3LeC91feJGVXNCJUR0LPBByoOhtrAOI8UCR1HbFs
C2RXjBSBcyZ5JIdYaCt3rcHXBX6SkRSxneIwtyGcpJxtmNVZwIUmpBzyAtMZ
Z1EqMU1oJiDpEo0SjeoAuMMu2gKTAYdhsWAhNmcZxYRo5OxrpWS1alkW7nrE
Df+u1+2FzhVEhH8JHo4qehJ8xoJXhEidFa8YtwBrQrsYQdjrUeQ9QToA8tkr
ej9zCwTcqNxFWzA4y91yzVEejcQcsuRiQock4Gnsp9YJtb/b2aG4pSHzeKS7
7qAY0uW4B+bk6t8CZObYg4ruZaL7Edvl5XmOqMcNizBthtHs48iNuxhKr5vi
R81xy4HkIgdHxYCPw7GG2zBhHabO32CNuQ2Voh8BSJeNIkFMEJ+26E4zQ1Hg
4Ci80rMyHFoHoxlBNRJ+hPeUI/s4ottLQd3LGAujuNZGeUs2YvJxi6xVspNS
8JwORuNsqjDLBs2fjHRkXmqGkZMqIH7Cwl1iKe2z4qSqE9L0/7Q4yVLiPWVE
DNC5S0r8FjKiA+p/C4j/fwqItUf8b+nw39Lh56RDXSMdqj8lHeqqdKiq0mGB
/D9YNCy8/fXkwkeP9CUhgysZwoI4yHTbBJlaWeXjo1mRqcKZGQoFjgq8YRiL
oOjptDZ8VTn+bzbbsQuZUnicKJ2a4eV0yeHAMQkcP8UIX8feW2yQDcUyiDY8
Kx9IfL3JZqifywYv4WToZqtESolx2WDqLP8ZewqtwNzAqOiwXwfEojUTgThJ
8/AngiEG8pbwpB4m+YmUTOVamwUDPLKmsSXiOfOMGFqXr9GkTVibo29P6t5L
mSXH263VDc23jxbhWSeuREIi86lBHQysBhUInYQYuUZCN31AnIOH0AFMMQdG
2KuNjJsBOLFAA5lD76VJuvDjKCBtIjHe+zolgvdJpEaxGlAQD4TvFwKSTOh2
MfqoqvWslfMlDkgOzzCvU2IdZwxlbyOrLSVgyOUQBzoDsBb9i+IcRfe8pdxc
G1cpMZe114xpaA3OjL0MI2vFkaDMXa0ZyN7D3NlQHYAYIexCya8lzCnDlay8
tAsD0/z+YtpjBoC8Y1d61q5mRV0KhtCanWvAxLsc915GEQT5mdXHPz66KznA
6lYlEs1YqdnrmN4HFWn7asZlKZ2FBbMNICf9IMxSUUDQ0V/RnSzw7P0aTlvK
yX6CZ5h9k0JJ5AyO2LCrJogwxi5yV/gCQMwNX8BQbwqsJ/5tXWPsY3PDLasx
enA2FUFCubGU9p7PCH6s99o4cYdpULbKdEHzV/WmGRRIaqcxm0pzoUYEqlsK
jxuG1wFnsVDYPmakiU1CLm0cOXmPaRr3QhL+SNtwmJW+PDuQJdXe2IZkPhWw
rbBru4Uibjx4/fW051tso3pyyP/7M+J+Z7jpkvx8PXue6ChVtVtPbkpbR8F+
SJIuZ7mi2cVcRIn/LXsmkUJJAovBptadTkdaJclVnr4KJXvZgDwxFM1aEpWV
kwmULLVXLpF1N08dwwbqQaMwy8dTbB/E6DGXizIJD943GSJNJraUfcTyfuDn
6R1AGcTjh1zBoxDWuBcPdZAkGGTaLwRB4155A36rWPeFjgE5k92JcshBHfyY
sEgIaPAez8NEfyUFbY68dBQHmFEErFH6mKqWo0thO7zAysIB+F6dlknmuiSa
SSZmh2LT6aLBwzWBfB0HaNEoBbKExI5U3JvtmY5YXbFceWkP8A0mb4gD/wZu
022AsmEBXihAAlKMQNnkkCu+NGTKXUCwtxc4cieFEfDhtlEwhgHIWzJSgtYf
fJJ/oojN/BesjkMaK+8SNrEggcBzJIz10ISKhSnmKA6V7ad1VrLyyWxa60h7
xm9o/lhq5I8tNDDI9n06GT1bqCsXUBmx7uc7ByVrCPDfYnJWOXOSayc5iXUf
Hzk44aYweUCcfYy6SMKAU25rTGR8+jVFE0xaGdrInEQ6pFuiEmKciF2lk79l
7Nl9r5fFSR5jnBUygE3oaaMUJayjIPDL17ucJ47aH5AYsotg+mMfU2jR2IFC
SEghpWj5cVeYWjnTyYcj7nXQOe4UMuPUAzLjTGLVPTLjgBjmlihnXQL9fFkK
6ReJcRRpa1ks2bWo8AHubZLZWCxrI1G7aI7MT4VChY1yLJIop+GZiF2fDd6G
7+H9D9kyVTwV5g88SceFKazNzmBv6VyH+OYc4WE6CemOEixHyK4MbpEoy0qT
E4Yo7rBiVQBiyamTXzlDxlOeT4HwCeFAmE1kBKa3lL3an0QS4CsKb1CEAfD9
UGLyyV8n5W6Af2LSfhOoUzhCTwuzZky4d77jkjjs/nKWovKlNAwsyeKGZyHs
PwdaMX8zp3KEwuLLMlrSMKCCD32neAXLNGEC2hzvA2PxAPAgXR1RQHCJopC7
iWQ1428qmB/vd+I7KO+htOXPSQ6UBWiEej9vEpTkvIAH32qYHc2GJr0N7eSG
2XGVKpsFzSWqpAIBDuUASiyAxoFD+0lu3OIe3gCzCzOnjERDdydiJ8NI2G6g
ckHSxqajzOaiVJDhyf1Q9FhQfhJSJC5jVBRuHpsspkLyClHTU4w1zawvbZLm
cCpTCPQpcr0S92aUPSdXcSrlFAACN2E8SU08ng17b1B+GKB+IskOdQISChD2
EQqDYoXtBqWwkPIRAAVQgrKZZhKSbxXRYgaXdxMDXZlEPqLLWHDP40olqClr
MllQ+C8WgcAxeCEs5LLLFsPZm2RvLxICdsgUKgxSckymgvfoksyNYGKopJp/
FfKp9yYJzjPidDV3PBNIQbxsSHW1EHnhbQACfJwgIQFIchgxW7AmIdNvPCER
1YvXSDmWS75IhgTAldsJ094kNb7DSoIk0szPXNqClGC1XsPfH5wDroxJqVDE
jSzhIUnS7HVxJM/l1iqunSPrF1fp4hrDOSavTIa+oeyF+GvAZSxfpZRuFuNg
N3n+vH4Gr5GkZwag4QJaV5TkRlHfbNRrmY16NZNKOLDWlUvxIIqOuoCWMH2K
az2no9ysMUjb42MBKh5bLJUyY82c+jeZThRRxbhpKA4YOMEobdgXT5HMpnSd
zNuTCGlv4ETxOs+7lJof9+03nDNYuWIN3N4OWdxp6ZvIAa4oDz3/srJZfOnM
qAtP0qebmjytQQKfreUxAcaZTK3tEX/i4GyhiZ18NE2x0JSIi3XSqEaaH2Re
OKwCWmx3SASDW/ar1NwGNkuyMEnbRxUzoUUIfo69qUIrduQGMsvr8DwfM59q
4SbL66DJIHHkEqZe4kuWonnWFPDqJjGQwHgM22Y4guYV3HhSGYiMaFSB1ArT
RDoOdi/28MCMB7JpHIvnOyeyJotVMqGYpwsiGaq8eRK9OBDKLLmBa7wOOL+S
oBSScDgEVZrzxnPwKlsjIMPLzEnYRryVHUQuSUvtOssHoioHkk4GYtyFEWC8
iDRU574V8BsWW7gfrT+NF8CLEYJItzx1z1lxh3h+kW+KwL2zwrT1JGKdAMqB
Id2HU3mtFSeVQiGW+RaWjQx9zKIE2lxKoVdkHUbQUWq8ZQB5mEIl4t8oDMg1
LQbB+gqb9MTzZtzfQXQTJjFVc+XACckp0+fmiZIm+/GRefcTme6J+RwZG2MH
CNAxAPqUxVpKXwcGDSocvdekcms80qdyQomIMgHVkijWqsvLk7nJ2JIXWxf5
lFdQYHERD59WOqtgB8pkADiFNSkxa/c6JL2479ZNm5Ftj2O7WhmGyelBEJE6
7cj3RpQdeagQgpCnMzhtLqJJgkWxXAq7zrFGWmpSOJyYCHuAeaJ6AxRr0C+a
Yy+7ajizkEJP0iiIUMBfOKHbKZqDGtGkawqfmkADRSRRnMysIRmtDc4wHEje
l2TPs4fF5swXcn8QmZU95jzJ3obiSO0x5aVO3T6usGf3iQyvkmmvnxQEaRcX
1cwM+afsc9oFDTCLm7uuDbPmhI0Ub5Jq78Y2EHZ9JxueaweWlHIyv8JpAWEB
UkWBjzaqkQKEkvg93IK5ssdujTyhTvynQrMxA1IkebndtKgxBgjacng2+OQq
HpOdpqY+3u4N+824ZE5+56T4H0IrqPoISlc1ZF6KfMq6ND2dp6aV6yN5jotS
6sXhEU9AfQ58KjJJdd5gKT6nmPc51wpuy9Eh5ehh1h1qrKA/Es40dJD1WrRq
SeGDAweiFBhLtggpaeBiLBUqzz3GRgt29j2zumlK+pAqgLiBtR+xPoBx3dqy
DLZiALr9MnIEAOXGSlRHHD7r1O1U9nUkND4rF0ZzqA3RNMEwHpeUcC/Bo7oX
UGWp3CqcDK2QRgvN4gHHGHEmsy3aWXS9WNppXKB5ZhoFqFCmPNerMWGvv+T1
nn8ThdApTS2lKOnakTFCSh65RRxsNUA2uhSDxhy2hbp+PfmWPFXfUSyLRaUo
Lpdr0NNQgGW93N9NTgKsMEIxybi9CpliN0ctZTHGDwRsS59EQR7CY+MUufCl
FCnBOUcOu/hsPRBSSjneDCtSoAljOC1Zo2YmldrwapMHyPn7hdoxTsC/LTFD
NxD0xk4JCDnnrkDDcGkuvzJ7RT2Sp8axaKB5YL6R9A1PJYlKWd6AohIzQrqI
+S0sRgJwORxaU9M67rWQMZVbRyTcUPdBhiCtqxQ51yBTDt4D0YhcOzhJGmgg
TG1UTCkSJ49WFcYLiDcZmWRqoZd0GOQdt+GwWDMv4BImnymhiAXfijceHatc
PqeLUnSAxYdwBVU7GlvOTFmvCmabkD3X69UqRyL1KXqC4g9ssQzlVq6lOYql
eXLaQGVwSZDtBaDUh3Feo4vDuSK0ATNLpgpjkQSz5AU3TOC7lsB3uY5FchAY
UoVOiwb6TFOq6dDI5YLCsTulN8z0GIQPdAnVETaw4t9KYrVwHb1e6EvospjY
+5NhobCMsT/Ab2Hm7Dk0JUWM8/cHWb4kNJddz31XLCaxT4yfYeZsyFOV7Vjg
FnbF4qRPHpwpLngwlCow1WpD+bok+vUxjN30J/ZSKFqbESVLNQEN8SlJRCuc
q+pIROwbkHCvnPbkF7bEHy9EB5CeKmqLpY2UfalVKlUX5NpwwjOMgcxwH9HM
I67lFZKgRZctp8Ws4LHq4CfxmCQCmUJVcnorWza6cS1vyy3jtWt2yJwpOkmx
DXDv+5kknNkyi7sAssQNvHaKGHbzYryliQwZTHWFdjYMr5s6pYFUcYIwoudN
xakT65KQwjhcS5FFunsdFrus8UwyRYBPrX/V5MiLFD1lNxjuPS8bxm4vJw1H
sbmhvrQhC7cSZFsPOVgjm1YwOYrz8zjMJQoGwpzSfLMlK8FRkFwP3WI4wsW0
YcTq48d/YBMQkCtHKaiG7F0Pe8GnT270r6WTXRtZbxLikPYHnI8hqqDUlmfe
S2HDrAKwB1j03xsAOqoAxnFpXyLqrGBzQ5CSEIQOWMyl79HVNHewho7RwYom
Dzy+EnSOV/wlciwW2F7BacArFeCY7FxJGnO1ASSGedFOQ4sCeRP1Cg9EEoBN
Q5viV3m0kkfl6TFVyM2ek7QhN1eF8onKh/r8zcFpHr5vlQoENtZfQhwm76Hx
oNQsijBXLBBwu1CschIYqczHrFBXWoup4dVwFludXxAVcz2MP4C2PlcWBzf1
4EM4npNYMX1CXNDmzQnDNdlgZjdJMERaiaEFMTlD0QAWjtBjPyL1Ko9P0F6Q
thfXB72RUzaTeU1etwZuAnk01tdF9iE0K15nMbLZgkQ3BodI/OBabs7wkiEp
6lCeaCJ5YWGNwI9HUXB4igMfPwFVcKM29ByrxtmcmkRDrLyFg3KNQCeBcoyp
amjVZrTPPS8dcTmx4c24mFQx+8Xpy1AfaWIMXP3wPU5RHV44FAJ3bXVjVUrE
gt7Chd+7ptsCiRmlWmAk1PWHwXuR+TB0WWo91yzFugMp9ON+jrAvivgAGOVW
VpsGVkhRs4X0A1/BFoGexVlo1d0qK2AO9ZAISYFrqewYPAvTGdJYySjixRLF
zdxQRQZq2uK0Lf6O6JUTAJTXznacEzb85sZ2E1Im0e/aZmNRlhxa9/My2oSb
+LI4qzkcAqQIm7jH+vpNSFeButCUdyWCidV9rN6DVWyIq3hT8nR45NWxGSey
QY5mTFlj/nwGyytKU666bEVKIF2AfeusaAKyxNGgkByIUTGOBYkEHzdEoJJN
2KpaBfy4YH9CYVDMrXRlyPEX30awEJ/sDtZyizK0ORfarS32i1PzDV1dbLfx
hooMVcFTYPF5zxhjr2ZKyyM3nMzLnvjK2DQi4eMSwGVvhwsdF2hxJAUD3fKo
AgLWu7tTuTXYFwaenK+1AJv8AbEg5nl0QvecxLoa466jyFssc8IYqNqy4Fyr
WAyRAiOS6rTlwLhUDO8MJOVMWPZ9kiUJABxNyD0NP+cPc9ANcdjwQ+DIj8ZL
kNf+Tq9DzjN1pjLBxOQnNrmLNUYMts1huIYN5nT8SyCk34gFwtXT6aUcJcVg
MStN9hFT76JTKXckcTWHYxQj3EAIODoK90PZ/JpZp3jd0O44tz9FJha8z/SF
qQNwaoKdn+C4T2sGnjpBEk+cQmdPq8lO7HXtBkAINpX6o1n3zx8zPt/nnz/U
H+4C7T9/SHACf677xzrqK7/88Y3WWSqfJetEP6YXIbn7o66ZCeG66+srrLOQ
/pPvvTjmrL4ndUPjmHV9TspjFluj3LFId8zSYv/smKVty95N4VMfPjsxYJUO
NtUJ7Dor8PxTY34DXGIvnJHH6KLdU6gzNxho/OfluZx25AEgKGcmgTH+RsHt
vQOrlG2uARLL39yGhqEXedSQz0uRPVGwGrdyFTusWeD83ymCVgoakBJig4UD
7qzCCguOWN4WkSI0p16YLHjszkJtviLqQ5QTzZSjzdyKJAWLLFAyXTwTnX+h
y7/V/lN5itCvWAXRpWJ/uOFItQSNUdWNP5J78hVXSuNJYH8+J0dMwAeELJaT
xF+dELDSEn+R7rBwg36R9rG/lcoXt+xEiyurd0yEv36FiUb+SvHNPO5DJsO2
oM5EnBx0c3efUGPML0T1/pL3Hf1NlogNdu8Di88skdt7/olFUqwxL7LQRNSs
E7v/FtdpAVy3Ykn0uGPFrpKXK//UCneOKnii6QXDuGUB5VnhIz5cDzCcnq0L
XzK9lBD9MwvwfLSs3XVinZ3D3bOl2Velis3Ydbl+Nq6FetdsXOD1XpMRO0at
Z2NxFdkaloEGDfO97tTO/Q1I4cdN/WgmEeeGts/mDiT1pcSA5ji8ygKA+ePn
BV1hVzkNfslatOGZM9ihX5jnPhI1T6TKEzntp7xM3Z9DEmd0/2i9v8pGw7+b
tFR0ujO3xkiOWHz1di7LQd2Q5PcZiOvq73ruovAstTCyeJUaSyD1cC/qZNVM
K2UnctLVXXmr0vMsL11fD4y/Gxs5pv10sa1nLqh1p+rXX5J+D0NQukETt9w0
WPvrb9ikNRwGBaZvYkU5Z72hK0KB8sTKOsFuH75pdIQ7+vWXzwhBioWgX2fs
5B6Cj9W4pMKA6XDbBSqOyqFV5EsN+Th/rvDVDjodsO5ffZE1055EjCA5WljD
M9Z+p96jM5OeRY9RpaJz7DuVegKg7puWnI67mKMGnKbHaeBUiqNmNcZmgGmW
6pItvBT8cBti4Q3Jgha3daHKXNdL8/iTF+cnx4Ax76i+xce5K+zaPbep5m7j
ZOjPfXorO2fWAHh8uCe9fV1vru3ihf0iqL+0x1VkPKymhC34JBCEnPJs3JNa
aU9NgTqqpM+Za07V6avgfdNUVSPvWovcLuwc9WwON/m9QIoPJKJ2iJHVXmFz
eQWR08sLgT6KB4rtUL4kxOSPOREX8+/SOLfeU8iOic9HA5s5Zzbr1xXzwinn
RTifbwPXtMUF1X6MeaL9OG7JIdmirxhLsllZhv35MIgG2dWmbm8oZQ9Om4Oj
xFJgIMIlJODYnBRXmXTBU7MfcVMgJ3H7HhlrZMlXQgXKwyyQ1iuSNMrnYyKR
U3M2ynp7uNAgp5ehm8cMV2g/s9xqt5bK1ajzkDwgknmRqGI8DgPprdtnboiF
TRKxEvp5e2bx6pncpPSvOseim6tyvEtwvO09vb6lF9b1woJeX9fLbb20pleX
8c+9PdXZ0qABbHf08rre3tHbG/jvypreWtQri2plQS929PaeXtyjZ+Cntu50
9O6KXlhUMMLOht5d1kttvbum20s4Jv17HwTCBdvr6WDTnH4E93Y8yZqDD1Iu
xNwqc8aBnx89Z7USweJoEn0TejWdx9gNnFehddxYI2+IBJa75+gSNkj9B7ak
YosvxjcJpf3W5/y/6EQtFOkw8eJXIGOLoi7DmFueb3K7VGn0jkDXFufgrBNn
CtNc4hOWq6NisE2zJA7ASfOMBTEml0rW52ft1pxVQnTIjViMkRPhANDnbeF0
3zoJ0iWmqN5WaWstUyyQSFkCimSWEwPfzs3iJeLJ9Q7y6oZYZ5SKKtQh5/Pd
ByBnhxxnZSJD4N5kjvqs3Vwrn545CAmCJgXDOa+L/FKlgOkpZV04+zapQAAd
Pn7fJCnkjSjLeRdPMJ4EiLKEkrA/J4FB2gvG1+HyKz9MKVzbt53vFJmocrpT
X1bT4u/iwqo+la3JDf0cSf4MIXeBqheaG/Pli95Z0VvLemtHry7CTcWLXoT6
qW3Raa4MtSEuktlSpxe8PSgN8bMltMLrRylFxRQnET17lP4DPFni3fDu3Hnb
KtWd7UKpWwiWa7ZHj35MklOxX08uUnSdAgamKg1ViiO/p4nl8HSRZhrvey4R
rJZLOFYPGlfzwGtSc7j196d0cO7O76aai4AGJz9+RdGgfG/zAykcxxOOVZVj
eIqL3OO+c4ZFOqX48opKUizBD0CCGw8L1Sgvzw6UDamYVRHQhNmaoyYfWIFE
SnVUT5+enF/YHEI/TDj9C/bxdp57Pabzbwl9Cohnu0R5NdXYVKGan4iKeXWo
mcsu1mZTOd8wYWnMQcyyALfeuuJoRfg0+ZdIYkrIXyt8ACS0Hf2LsPZzIsnH
OR4emdq2NwqHwyAJK0oDLeSeaN3W2+QR8e+tvsgpbWoXkGrG17Di0MfVwh/Y
9eg+y7eXgRhPpSYgIwfZybSpIoTYfxmlVHIF0U+MMh8fGQUaS2WZX4UR1pgG
/GDEZWwy6UpnEqxsW3FmnsIcTX2NausDjO2p63dMlT9RcB5cuZfJD33GNF4i
Zb1w5bUHhA5hdBtWnKhE2DnsNzXh7TaOYI86sDp3yJR7adhX6HL0w8wGfook
LkNhmevmkK6MpjxPtjXl9Q5izi6LBkNpGsa6Oo4G8MWN58F2mHVjooJT+Bku
2om7DI49DN5jlljNzKXyKOUkOHwhVU8QvLSQMdcDkIyPsRcmT3kVizw54ZVZ
TkgtCUw0+bYJ/ytkP97RHJLiwJtkg/AGEZCEsEcVkUqBP8DcY0qWN8nnXtEs
Z2VNtkth+p5rI3JKrttyXpz1MDXwZOOhxRKuBcmYgkklJnT/Pi2xbTEkrK1J
U9rWDUNp6HvON+ZMym9STnC9RU9W1OzDI1WrXp3GUG2eKoXRbITy7PLJJjLZ
y2wxNFuN8B5Ny8geh9DK66DeSOR8vWXuLiVE+pVfTVIu2mKNLJKKO0OVAFo2
Iip7F6sp0VZ8MXGUBDx8GKaWS9yvkv0XikiOFezOZklnP84v/D5trx8Nt85f
Rq8G724/rA7f7L56dzo/3FvZ39vo3uzure953Z3Bs807yuo/bJz7GOZcJsWp
j1jiYlZJW/5KvDulS3Ec112JGpwvyepk9mRhS1Jog0JosjIyoSm5e+GKYPV1
SZu2RKFb4bcghbZqCtrmZKfuHtxTGXe0eeKGZFp26iObFK98ITP1hy+5GwXY
/o9ejloMXl7b2f1p/G59f+vc+37+4mD06vuVF9vB5Kfg7Hq0cnw0fvHqzfOl
q/PJ3uXXvAl3oT1RwFKwFSI9f/yhiDb1uG905/tdAEdmGmHsMaK3qyjbGi11
gpoqWUT+HGEtmmIWmu31Bxpj/jxKzTaEPMTiQWuf/xwdfveuN9jaeXXcybo/
X74+WFrbfvl8aXA2eX7Seed5O2fPxweXe6k/DcY/fU3sm0F9KxaXO9HRWc2c
ESUcQmh9d90Yq6dGViFEJbJI6kgQKM6QvpUkfcmYadW0HitT1pxaioQqMWDY
GuxLyKbBekmTSr9BW5qHnRtVR7WWVXa11wlsYZoXDpUqKjlONu4on10LTMN6
lPVE6rd3wo1ELk7JZQn/2zR8fNjdIdgBodxmOodnKzTzVHSEWUK0YfAF/wCZ
WGZiowu9YpMIVTEJZWx1zE03kX5bMbN1k1IzBq4PisnkWSito42l32a7bSVx
NgxtElhZUqkzFhVnrLERzWpIEJrpjGWWPZ53XliSPTDVVRUT47yEkTbLwS5N
I2ao1AW60419DkqxJvGyG11V3OhWHArv4b3/8vZU5Ee7Fxv8DMepwY+/UEjH
bRguTBwiZwJ/sbaTW8csVGusxQCcsn4Ez32lXmFKsUNjfUGvbenFRb26rldX
9Oo2/bun4JulDuwLf1pbg2/02iL9tAzfqLUdvdDRC0t3yoM7tspC7vXg3xHk
DlETSjbbHtAo0bzZSpJL8u7Ldcv9cGxxBNI/VNWbeE9FvqxhzVqOcvLvskoV
kLx4kEtI3WIK1dIrTAbJvHibN7KSddjcNKEYd+pPfzGBqLEHfDua8WeIxmfs
6MuIoA8Uw2fv8EtveHEnu6R+JTVXVHSxLxcxZEjLgrLbuFRDuNzx0c1+/DeL
/EtY5P8uHlnPBusY5zdpnul31/r+Vnfw5mjwuv2qu3j0rrP+4c2775Pz40F/
tLO9u/v6aP33w1f9cT8+/nkh3R7vdz686b7DQRY2Xrfn1/Y73bUTf+WnfhYv
/zSebKV73cuTJf+nZ38x792V27BdsLuQU/CswhLyTEK8eAYRsC/Qx0e1face
wnHv2bjPJI3O6M2IBc1nhfkgYyZwIIIfB7fqgv6oDfUxK5/Z3rHooUZCQ54j
wnV3zpqhD7J7NQZTVWd3ubjRamu5XOvnB8X9a20hMfS7kO46qUgZWCNFGj5Z
n5q7HuX0JITlV9cz27PdjePr9E8TuvtQQIZZNp3BFEe71373ZO088TcOD06C
QT87WfC2Xn//8vTi5Ye1+e3z/SBdfLO4NugtMwl0MUQLhtT5zO9LB7+S/5wA
Wvae51/Wb37y8hwQ8uLC/+nydrR4Ei1fr1+8uAyvnx+3u/35nXT91enr5ThY
uNo4oM0DeXJd8PhnDTjU3f6NnLiYSP1aqrJTaPNpoClpgEJPatpyfn2SQpdK
/auRlHt1QU3j8o0u79rL7ojbyUqES32GcKmzem1FOtObemXSXaqOougCRVFv
/01JvjElqd/K9PXB852L45WXST+ehumPw9eDsx8v9/eP0qWV8+Nsur2Ufjj/
0IbtrsNWagkOEwvGS9wj50r7TDTKNASfaK+sbiwtrq0tbvAjUj8KH8yHfQht
KYdIUiqcaTwKz1LjUknxMY1qvcgbxgOqqx1LPJqlJXkBw3JbVKn1z/bIPDRO
bjTNY0eZiN1Sv3XPgvpXN6mx6fd4Lm85xIPTTJw8MCmStIRFksrlMGvNEkVr
BFUiN24siWyr6QD7eTqmZ9Ax5dCxzxku6kjwrGCLYudXG41XQ6M+J1zVkBE6
nxzHvoyWlE/wX5SuPOqHA16lJTG0/S+gMffRx/5FxY4yacjjNj39tmh/eVu0
ecRORT4MRLUcDGNs1Gxc51gzisih/MxhMAizcETJsoBf7EekNNHaoKHy6+69
8SohFVQUo5B4kZKnspiMMaPhNNoKrUYXBZg84SXhcMqs2VCNck9xfWDaPYdV
7aXuKpu0G3GgVgIoG3lmX0rmTRvIZKMqMPD440eL0J8+Ue1Pxm1XpqCCxVwp
Pb/lpWQN+7DdOjXcUKUYAC6ISAU+9TLgSdEe5rGNSaqiufKZtEuNVLm7nxD0
9YU1Lhr3hZSTcynrG7J/BRLpJPwsU2+OPSz5f8fll15F399BBHZfby2cL77c
W9xfC99dd16+uN5vn48WxltX8UK486Z38xIEjtcXF2/OO5YI5LferIGpAfcC
4khgqo/IRM0jUx0dZBDlyMrvWNEE9nRv0sG3qkpAqB6wPF2sB0wM1SbAb0vV
0E5katmbFBrC8VKAQFrsL9LQ6DHlVPK89YYkSLMv4JbiMdMMhK0Rx8UyqbIx
gabtRo7wXLRMupPcx3vJt9CTAjN3RVp+subTiqTCJW/J46moYrYN9jQEQjJM
3aL9JjFFUlvSe1TkK8dnWNqdJyFI7e65X5Nfo7n89tBvbATePqu/Fn8qcvLs
jpj6b2IbNUjoSB69q0l0DfKUoOymydFX6wgMa++lP/grY/qlP5bov3Offo3o
wwL992uZm2mwEty2eb267nqyiF+I4q/U2jq/I6j/a4T0G4bFQ2GWfhHx3RKe
xXB7nLEbAIMP46TQH6EQLVTfpz7NQ0b/Hbf/Px+3X+pa9C8aue+ET55zB3jx
4D1O9SG16T61iap5Jz7lJPTbxpKm6mvD9O8mcgrXfk7a4/E0IdaWDQKOMDYZ
2GpOyMMcLu7Wm/45Oju72zc3337WXriDFvO5l8f46yj0X+ipK1NQ41m1Ry1S
TRlH8lI9l1FeoBVkR3H/IkFt8oE3OWqK0qXMk3kBo0+zcIkQx/h/84Btbk6I
tCaOqOFBXibY9K5Iy+hGvWC6w3BgK2VT9XSvKA7YSgY0szK4jCVJWKdhm41X
53/+Btj6vxBFyef581HHG620X3yYf3fSubhYnf9ws58cvhyc/HzxfG/a9lef
vwhP9i/iq9+Xp6ffjwfXyzf9RW87xUGmZ29Ostv1o3fXR2vh7dr0zfyr6/F4
dLS8fLH0+xdhtIudZZwWlN6JKRIIpAIp0i8onKM4x/tybDnI3CT8K0X55fdC
8U9sUrSZr6XMPykurfJA9MepIaGBbaPs4Fonb3uJV8CtaUHRlNxdUjkuAKl8
hVtw0Z4oL+uk4jlAL6+th7/8/j3K3Cvv30uCU7FDtFuempmdQsbidFjWeaNT
Htj0kP9B5cq+BUs4BA6VsVodO+2rVJz3TJwdu18hHaVmv5UofnOeAgBCF9FX
bVNZVy03RCJ3wrhFmcyryrxq4qI8KgY2s0x2qvNmD6ICOlQsTDFwDMQwOujI
3fjs42A7MTF500ksUYW+1yQ6TMgO/BWyFr4t+ZpZZOSeVoeSxcAZoWwzOLeU
onpKVoBoGEpXsR4szLYemFBlU32krqQ5Jx+f81UQtYTL4JXKj2EKU5pL9twl
zgmSorLulkVVt8JKBjcVKejzn4tNZDwvToaNZwPsLCdMlWSAZBLZ7s22j3G1
kYHN6uK1YCFb901uaSKqd3aVUILz2y0sh3IusVpv8c6EVjo2pTsl7EFhqah1
BND5xdnlNjax22nuHewe7pybMhH3ZI6mwGtTa7356s3Oqfcyml97Pdj3OtP1
8Sh+17l+/io+e794ubd9tbfc7iymN6+/v/BOR9//qtwykp3ubWew9SpKDsKf
gdqtbR0fTwNv6L88vDm73R1d7L96ffPiNrglVmeqvdKsr5fXdzd+P4mvf/89
ufGzdD06eXH24njp5NXOZTx99X6rv3bdnWzsbJ3u4rtYwLUpk26e+/MwQ6d3
c3x4/nt7NXg98VYmP5k58ucW1ra9m3c7p8uTpfmLSTSIL/dfnMy/+pAs9/BZ
U7+U1vP8p0vzHes+Tb259iHd73RoXK71ySNvnry5fr7He5KqnPTD5k9Lw/0D
ep7yEwD9j7grAhwAWXXxBLDcIYiTI/PLJ5ZVbJ8K0nOMERSNl9JKrr6NUizI
xlm7dnzjWsuxkTtlEtvOfZBojMb2WygUEqeV9/hK9bC5zDjjziv8Brm8OVWF
7PVw8bEJkp9XV6W9mIobPHipYeGcMd1ik9ckzeLYNLlADb/cIoCDfGhXahTi
09fOBhAAmKXM01rqf5m6RkLTH9qtQmkkGBJ9aHZUhVMGKKwaW794UsXfNKiH
LWe3uOtxQG4Akt3Ncu0qMVzAHAN2giOxPiC5CJcDoFJSV/IWB6CFRyA1MOip
w5ZJy5iVmp2XNHHPyMhV1Ta0pqkaMXuF3VwHqTQmldb0xoPxC8ek5JYlAtZv
Tx7VmiLz1iDEBKbw63scpT6trJgCxolLvWInUnzDMoKikWEQ3ggvcIZUdDk0
UE9q5gRw3SnrV8FU01mawqiFHlQI0B+U0xAEJaS/zQyIadCvpsU3V1KGb2Y1
m7Vo0JOuZSTU5s2mCAK+tcG7bXPdHmhl1P2hlEhF2DM2KQDibRsL8rrLMM30
XFnNXHmcJUwMj7KdpkTeQrBPjHxdXg/LdZIiZnrqjULCBDHjWAkcy3OuLjew
9CUKcT7IeyNv2NJbU30TJtkkyFvWnWfJpIfA9G1s/91pi4os6xFrEGyRK+2j
pfcmScYdtuA2RHn91EIN0WJd+JT9AK47QnoJ607vGmA/DPwBy6EgKnGHksB/
NtcHgooO6mIj9zDNS5TCHJ70JXJ6DqToXfSia+oJ8yLo9/VRPJgMaZkdWP0k
ATEKCB52exbKBgc3wDAUDZLNNRMI9sJ4Q5oEgQrqF5wQsQ+ZC/Ya2zpcxV6j
0k3ZGi6PvOQaVUr88cobNWhdCVytn700vQ4j1kaOMOE0AmyghnqcY5EEN2GA
1mZCm6OD7d1SHS9yDuJ2ERdfTIYhLAXkzN7VNVfVu3KaZtOroJdN+KpmcZFG
NNirGZccr/al2BBt8jdjP8+AatQmMdUEqCggVOEN5VocpTsZYBd53O1ApyPY
qiaywEVv/cTrZ6YqmdkyVVlm0AS0BX5ijGViqTLUpjoKYZtbIYjA44baSnDz
24BvXRBVG+rIy2Ant/pHrHsbNdQLD3vwHGFectJQF0BIpvrUmwynDXWOPPAC
C4zALy+wdC5AMexd4Z84/24SXutX4dBHCylg7jZqryyb12Gt5valYZT0e8/m
4CIGUiiVdPID6y6mvTkNy0vSdOPuyh/3Tt3lIgdhodyWFaFjKpsFiqVBg3+U
/RzjaXYVR0ussrudpQFV7E6M+IU45zoVlFCj/U7ZVm3S6k0mF3ru3FJZGVU2
9rgDBVAf7i6omAQK0exPIlaCbAt0z/fGUhxM+tc7DeewLS03Uc28a/LVxOR5
n0S2x1TRgE4Yl0yGgSRxKEB3NAkZOowaZYPkymHYbeguJX029DAeIOtT8H/9
zPzVGgTZIXwMkidPFZBuI3H8kzSaJ/Tffzby9T6TYVsgk4PY/3STNAdTd4Pf
gtHt8zLC0xYPC5Pg8zB569ZLUIt6MgfTs/60qX+Nfvk/yW8gwcpb9LBYhATE
nPHCqytO+7SFztFxcR92B+Y0nw29Udf39PtN/f7z+2Kq9k+TZvPMDvOkZoUF
yJVedaaC9Sl+G8brPq5el1+jx0pRzs6TOeP+1H/UKAp/FPzpc0/NSwcSo6Wp
AQVqZ3/MNYoAefoU3Y/3Hxz7WFVH1Q8x9f+5PUmm9OwdOUfMGN8yHTy/YK+V
2fRDEmy+5umhRl+z11rEhWef1gLsgYM0CuaAWf98RXDXbLn7+EE2+scwSt0/
jx3j/ecM949V6eRpIXBFH5YhNWMpj/PMqc9lTT1WUgtBb6O+8gBujg4DUuRJ
dmmGQdanHshd7KPAMOfU2rTZXqyVbNV3egvN1QHwOOmZ6VgtuWpaEAEjQt+U
75OSSfVIHMvtLTURJvH9O9mCc/pia49Q8NnU6Txq/b6X+PMe9QkCyWA+jEgh
C+bzthUw0hntGC0PZIT25yqDwkMmj5N2oAeTkOPXvG48KbSmNLOicOc0x3C6
N36nd2F7MZruKKgnjLBjuxzIgyDdngXprzXBwjeeYGHjW0+wPmuCju9zYRo+
wVG97a2lH7U3Vtcb+L+1NmLd0EvC/pTNMWTC/04q31GXbwkqhdcWFzbWCvuQ
5UvHU9ZWteggIBQPqBcqG8SyKagviGImROG+u12btdsD0GrERF2up1b2Q7AO
4lwQPaNDS4ui/dDAnCvfHO5HUNtYIqi1N3B67JQDSiXcROqZSQ+sL8Evxxjy
Qf1AUK3CPjkUDihNc4sWH3prbfFhIFmdBRK59aHfNKZmivrnP5FC25q+xoVV
57jQj9ZXVh62opXZK+rGsaFwuQfVeBts251H7ZXVNUHhkpUDflpezDd3fnZg
PSeP2str6w9b6fJMdBI9uDj+0soyrorukz9h2h5UtgMgay8utp1RZhw3ghb3
gtZ8VmY8i5a2NnFALc1h7g189EQa/rAJC79dKdxB+Gb1gfizNPu0TJ6vLRmN
vO87vUM+NRRjkin350MWdp3an6hKheNgl/7IAJaVBXcTTh96AMXCw9Y9kwvn
jbC4RdyjdpvPjTrxAv5/x2YcWX9ezAPfZSwL03Ks6tHu+Xnn+cHxczop67WU
8JP8hsMe23gkVjCTJzw2DIi5nR1zqDbL1E1rm0PcQbpxhO+jjZaDNlPaxlrh
WAxk8ore+MyqXBwZmTr5kXU/bxZVuYAw6TKSMaR3aG5IuFB7BbFJ9DCmBz/u
MUWJHFuHMyjRRKqe8EAiP5PrO8ViijkOtXme8kjRUo9+n0fthQVEiF0uhm+M
zU5h9AhQc8qdhaK8Oj6F/SPZYZZmmsQB0BcXC7fQYQQNfAHPVXZnqEmqJ2Mk
9+2FjSb8F1QH/KO9ihoEflhr8Lj44+Lyw+A3U6jpMBdG9zVfAWuIxYMVvBEG
8Z0jI1oj06P19YUCCuYdEamPoumaaGOqALZ7B6fnzXbhXgJOumSA+gI2lxYp
1caPo8dkYu/iZQWCv764jpjJTZypqd+2cWxHDo7ZB8mVFEQahWI0MEY2CD7V
TzDVr8F5A0+R5izxpklq4GxVULnGDByg/WLKpEG3sWs2vEPCEstKrzwMuLEC
Mnq/rLjvRvfmZer/H/C73Dak7QAA

-->
</rfc>