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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

{
  "type": "https://iana.org/assignments/http-problem-types#\
    digest-mismatched-values",
  "title": "Mismatched digest values",
  "mismatched_digests": [
    {
      "algorithm": "sha-256",
      "provided_digest": \
        ":RK/0qy18MlBSVnWgjwz6lZEWjP/lF5HF9bvEF8FabDg=:",
      "header": "Repr-Digest"
    }
  ]
}
]]></sourcecode>
        </figure>
      </section>
    </section>
    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t>All security considerations from <xref section="5" sectionFormat="of" target="PROBLEM"/>, <xref section="6" sectionFormat="of" target="DIGEST"/>, and <xref section="7" sectionFormat="of" target="UNENC-DIGEST"/> apply as well.</t>
      <t>Disclosing error details could leak information
such as the presence of intermediaries or the server's implementation details.
Moreover, they can be used to fingerprint the server.</t>
      <t>To mitigate these risks, server operators could assess the risk of disclosing error details
and prefer a general problem type over a more specific one.</t>
      <t>There is no method defined for the server to communicate a digest value that it
calculated for the purpose of validation. Such information can be abused for
oracle attacks.</t>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <t>IANA is asked to register the following entries in the "HTTP Problem Types" registry at <eref target="https://www.iana.org/assignments/http-problem-types">https://www.iana.org/assignments/http-problem-types</eref>.</t>
      <section anchor="registration-of-digest-unsupported-algorithms-problem-type">
        <name>Registration of "digest-unsupported-algorithms" Problem Type</name>
        <dl>
          <dt>Type URI:</dt>
          <dd>
            <t>https://iana.org/assignments/http-problem-types#digest-unsupported-algorithms</t>
          </dd>
          <dt>Title:</dt>
          <dd>
            <t>Unsupported Hashing Algorithms</t>
          </dd>
          <dt>Recommended HTTP status code:</dt>
          <dd>
            <t>400</t>
          </dd>
          <dt>Reference:</dt>
          <dd>
            <t><xref target="unsupported-hashing-algorithms"/> of this document</t>
          </dd>
        </dl>
      </section>
      <section anchor="registration-of-digest-invalid-values-problem-type">
        <name>Registration of "digest-invalid-values" Problem Type</name>
        <dl>
          <dt>Type URI:</dt>
          <dd>
            <t>https://iana.org/assignments/http-problem-types#digest-invalid-values</t>
          </dd>
          <dt>Title:</dt>
          <dd>
            <t>Invalid Digest Values</t>
          </dd>
          <dt>Recommended HTTP status code:</dt>
          <dd>
            <t>400</t>
          </dd>
          <dt>Reference:</dt>
          <dd>
            <t><xref target="invalid-digest-values"/> of this document</t>
          </dd>
        </dl>
      </section>
      <section anchor="registration-of-digest-mismatched-values-problem-type">
        <name>Registration of "digest-mismatched-values" Problem Type</name>
        <dl>
          <dt>Type URI:</dt>
          <dd>
            <t>https://iana.org/assignments/http-problem-types#digest-mismatched-values</t>
          </dd>
          <dt>Title:</dt>
          <dd>
            <t>Mismatched Digest Values</t>
          </dd>
          <dt>Recommended HTTP status code:</dt>
          <dd>
            <t>400</t>
          </dd>
          <dt>Reference:</dt>
          <dd>
            <t><xref target="mismatched-digest-values"/> of this document</t>
          </dd>
        </dl>
      </section>
    </section>
  </middle>
  <back>
    <references anchor="sec-normative-references">
      <name>Normative References</name>
      <reference anchor="DIGEST">
        <front>
          <title>Digest Fields</title>
          <author fullname="R. Polli" initials="R." surname="Polli"/>
          <author fullname="L. Pardue" initials="L." surname="Pardue"/>
          <date month="February" year="2024"/>
          <abstract>
            <t>This document defines HTTP fields that support integrity digests. The Content-Digest field can be used for the integrity of HTTP message content. The Repr-Digest field can be used for the integrity of HTTP representations. Want-Content-Digest and Want-Repr-Digest can be used to indicate a sender's interest and preferences for receiving the respective Integrity fields.</t>
            <t>This document obsoletes RFC 3230 and the Digest and Want-Digest HTTP fields.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="9530"/>
        <seriesInfo name="DOI" value="10.17487/RFC9530"/>
      </reference>
      <reference anchor="UNENC-DIGEST">
        <front>
          <title>HTTP Unencoded Digest</title>
          <author fullname="Lucas Pardue" initials="L." surname="Pardue">
            <organization>Cloudflare</organization>
          </author>
          <author fullname="Mike West" initials="M." surname="West">
            <organization>Google</organization>
          </author>
          <date day="2" month="March" year="2026"/>
          <abstract>
            <t>   The Repr-Digest and Content-Digest integrity fields are subject to
   HTTP content coding considerations.  There are some use cases that
   benefit from the unambiguous exchange of integrity digests of
   unencoded representation.  The Unencoded-Digest and Want-Unencoded-
   Digest fields complement existing integrity fields for this purpose.

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

            </t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-unencoded-digest-04"/>
      </reference>
      <reference anchor="PROBLEM">
        <front>
          <title>Problem Details for HTTP APIs</title>
          <author fullname="M. Nottingham" initials="M." surname="Nottingham"/>
          <author fullname="E. Wilde" initials="E." surname="Wilde"/>
          <author fullname="S. Dalal" initials="S." surname="Dalal"/>
          <date month="July" year="2023"/>
          <abstract>
            <t>This document defines a "problem detail" to carry machine-readable details of errors in HTTP response content to avoid the need to define new error response formats for HTTP APIs.</t>
            <t>This document obsoletes RFC 7807.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="9457"/>
        <seriesInfo name="DOI" value="10.17487/RFC9457"/>
      </reference>
      <reference anchor="STRUCTURED-FIELDS">
        <front>
          <title>Structured Field Values for HTTP</title>
          <author fullname="M. Nottingham" initials="M." surname="Nottingham"/>
          <author fullname="P-H. Kamp" surname="P-H. Kamp"/>
          <date month="September" year="2024"/>
          <abstract>
            <t>This document describes a set of data types and associated algorithms that are intended to make it easier and safer to define and handle HTTP header and trailer fields, known as "Structured Fields", "Structured Headers", or "Structured Trailers". It is intended for use by specifications of new HTTP fields.</t>
            <t>This document obsoletes RFC 8941.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="9651"/>
        <seriesInfo name="DOI" value="10.17487/RFC9651"/>
      </reference>
      <reference anchor="HTTP">
        <front>
          <title>HTTP Semantics</title>
          <author fullname="R. Fielding" initials="R." role="editor" surname="Fielding"/>
          <author fullname="M. Nottingham" initials="M." role="editor" surname="Nottingham"/>
          <author fullname="J. Reschke" initials="J." role="editor" surname="Reschke"/>
          <date month="June" year="2022"/>
          <abstract>
            <t>The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes.</t>
            <t>This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230.</t>
          </abstract>
        </front>
        <seriesInfo name="STD" value="97"/>
        <seriesInfo name="RFC" value="9110"/>
        <seriesInfo name="DOI" value="10.17487/RFC9110"/>
      </reference>
      <reference anchor="RFC8792">
        <front>
          <title>Handling Long Lines in Content of Internet-Drafts and RFCs</title>
          <author fullname="K. Watsen" initials="K." surname="Watsen"/>
          <author fullname="E. Auerswald" initials="E." surname="Auerswald"/>
          <author fullname="A. Farrel" initials="A." surname="Farrel"/>
          <author fullname="Q. Wu" initials="Q." surname="Wu"/>
          <date month="June" year="2020"/>
          <abstract>
            <t>This document defines two strategies for handling long lines in width-bounded text content. One strategy, called the "single backslash" strategy, is based on the historical use of a single backslash ('\') character to indicate where line-folding has occurred, with the continuation occurring with the first character that is not a space character (' ') on the next line. The second strategy, called the "double backslash" strategy, extends the first strategy by adding a second backslash character to identify where the continuation begins and is thereby able to handle cases not supported by the first strategy. Both strategies use a self-describing header enabling automated reconstitution of the original content.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="8792"/>
        <seriesInfo name="DOI" value="10.17487/RFC8792"/>
      </reference>
      <reference anchor="JSON">
        <front>
          <title>The JavaScript Object Notation (JSON) Data Interchange Format</title>
          <author fullname="T. Bray" initials="T." role="editor" surname="Bray"/>
          <date month="December" year="2017"/>
          <abstract>
            <t>JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data.</t>
            <t>This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance.</t>
          </abstract>
        </front>
        <seriesInfo name="STD" value="90"/>
        <seriesInfo name="RFC" value="8259"/>
        <seriesInfo name="DOI" value="10.17487/RFC8259"/>
      </reference>
    </references>
  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA91bW3PbthJ+56/AyA9p5+gSJ7GbaE7ORI7txGkce2w5aXt6
poZISEJMEQpAWlE87m8/uwuQBEnZVto07aQPrk1cdrHXbxdIp9MJUpnGos9a
L4fDY3as1SgWMzZczoVhY6XZrpwIk7J9KeLItIKQp2Ki9LLPTBoFQaTChM9g
eaT5OO1IkY470zSd87nsRLSyM6aVnbnduZPizp37W4HJRjNpjFQJfuqzg73h
PmMbjMdGATsyicRcwI8kbbVZS0QyVVryGP84GOzA/4C51sHJcL8VJNlsJHQ/
iIC5fhCqxIjEZKbPUp2J4LLPHgZcCw67vhMjxpOIHSSp0IlI2VDzxMyVTlvB
QumLiVbZHObtZDKOZDJhO7EKL6wkSECD4wOQwoVYwuyoH7AOS8THlE1EIjRP
4TD4KUtkqDT9auZcX8S4UyRNquUoS0XEYhFNhA4uRZIBw4ytSZYxK6rWO2AV
p73Adfh9xmUM353on6EeukpPcIjrcOqGTL/Xw5n4SV6Kbj6thx96I60WRvTc
Hj1cO5HpNBuhNlCxi0mu294tusV1MSjCpB7V2vqu3bgr1W079T7PqLrTdBa3
goBn6VRp1A1wwtg4i2Nro61DrmVm2I+xkFHcolE4PU/kJ1Jd31pDrDgYG40K
J9cZLXyWlsPdUM1aK0i8zkJu2DHXUSZWUXgeqywagwZEhUCMy57Rzzmtrewv
E7Dlky47VnEs6xRPFNh+quzgKpLATGcowgo9kJuc44JnE/ziqMF/ocqSFN37
IOXxMggSpWewzyWZ6e7Bi73TIbCy//zJ1sP78OXszd6b5538+0Fnt1vT2Uia
TpaIJFSRiJz2YN3xydHO671Du9WjrR/g0+nw5Oz58Oxkb7ezf7D3evfUDm5v
bcIgOoH9e3MT6cJvj3948gCZenV69IaGHj/YehIEMhmXLAdBp9NhfASex8M0
CIZTaRjErGwGYQV8U4QSLMlYH3PGRD5mWDrlMEPoS6ENC3nCMiNAEUwLCBcQ
YGCGypcYhgfMMKaAcy+mMhYsEpzcfgGWzjgs+5BhHA251kv8LmH2RMt0yawt
U1gqP861GMNuSSjceJedGVwHnDS4bQO3wjFLvMLgpYwEhAVw9ER0IPhFHKYz
oTWElEikoHQ6AZcR/DnKJhPcHMbsDC0wJsKnrhXhTEZRLIJgAyOnVlEWUqwL
rq6s7q+vif+rK98g4GMkxkDfcuzOiTFNfAynPJlU5WCNwwqiPL5pM4iZoDSW
qFxlyzbJU2pBWUALMF/QaARLl7lWQzYSU34pYXxcHAuIRqQVLSBE4S8ggpKD
ETAhjJwkXTYEgTpVy5GMcRRMBxwxBVHCrFhMOEZyFOF8HsuQnM3gQt/E7Pnh
TKCdlKnxKkv77urKucP19ffW7lCHI4EmFyFTTrM+Ict4hH8Ku4YX2y74VzHI
INgnVfLZPAZFlFvOhDF8gtYHQkvCOANLhKScokB4rJKJQds8f24/dSzCOCd6
5ydirosvjhE6HrofdzYCuwAGgXPMfMOPFAiTjCSbo/V22SDxZYaxLUbdhUge
5KfFexGmsAVoLOd9JEJOnk5KwN0uQWyRlbIo5fE3uSOI2TAzVYsEYxGSGUMU
Vwuc7TQBevn9998ZBt+O0wS47Zuj4V6f3fv1HovRIRcaBIOL5sAixE6G0TQI
8Ci9ze4me3T/PtsBQz+xYglyXQ0Jf3hC7bmD/+u9gXjwjsOcql4BKE55Z2vz
wdOHbfr1wdb2U4jhwRXE7haKq+XjBJ5wi0gM+iH6kCFEUk31G79SsnJgIEuc
xiHDFJZhWm0igOgWKZyVkyAMmCkprzbZ2+g3b6zP/kvkrugnzCvGcOOxUrSa
RqagWaHx8wpR2Ax7DT//F1yjkjCewhSAgdan0QN2MWJI+jsITtVM5Ho1VuN+
dEGn4vAVfYr06nwFHW9EpgFJl0wGwloI4FOgR0OUdunz+rqLORFMW2hIYq16
CGgRR61bgkCryRRAG7TkkQhwnYYlKPImD5XEkc0jCqc0Us0hHous5bvZCtrS
rEW6CLfV47sYgBVGnuXxd9prBgUI10v822BVovG3MJa2PCExWYdvkQDGWs2A
EPpTQaUa9VfKzaYLEAfFFkQ2sAn+DzbBlLTMMwPQglpIfqITYdxIGCZEiFW4
1U+Hr5lFQXh4laUx7UpnH8yxqpIf2Q6mI18SG9XqzzJdhhcjKOcXKS2dalE/
FHAiPoLYDUAmSMkqKRESGaYKw0xDPhJJmYpL64JAd4upMZV4cZXEYer0MXLj
nHMXGc5pGzisDZZS0zx2dnLQZUfwQa8Cfb4iQHaUrCqqarOlSEucAYd2aYlQ
hYiKQ7fJE7WwbMEOlhuQtYurFlnmOXKWxakET19bJF1WycApGghSLMSwdoo1
EonzRKjMxEQ216OHxAhIFYkctoK0BHPgL5tfCwCXWkVBfcJSOROkK9hGIV4D
SliAloaBEoCEIuBbIQBcZcmpROS52YKyqsJyPTW9Cc02PwSaWbG3pcUttLTQ
SEBeJppMYr8BACZBwynCFm1DAVXlNro7iGZjL0LAkiuQQ4iAIcMsvLHB/KTz
0iWdQZFYXD3SdCzx+Qnx9lRYkVo3GPjgxDPOcg4aNXowdjII+ygrDgp4JIAA
NQMKmoFWMZLgcDOvssJ6ohywrO3vzrbydc4KsJPjozwROSDaOIOFYeerk/o5
2AbYMbafAK9i+wiThzMntAsFYiFN4ndejcUQIjS4GZwa+NNYQPp2Q9bkUS3F
0Q32cAwXLfNj2a1KGmpEoJRQehXfWTYNVLUd8oTzYt9z7whuG+w1wRpnpbk5
l7j5Qixzrd3AqiNibX5tCtiUyDdeU9PWnzxDuYWpwKvLRCV4Nr31NoqV4inP
KfeMJyBHvlaNdp3PVnyFZAKGn9bchI8gfTS3pKgTTv2ZtjIhT8SyBM3DM3lr
DJEcExOwfoVoTLeer11aoGrBeNVZYVl5JD+/KlHyG7FgQ/rj+px9N48zw17v
f28jr0tyzjvzHHO4u1VykR9NmqqLYhHr1UTc1KyRXA+kjAqJVhUwx0enQ9Yb
KXVhmzVYpAQvFZYXgL+77qy3lClUngzCUMzTFQNeSuyzWbT1tH+2+PDk486j
w1fp7vAieXt0ure3+W7w9Gk/qJc3d0w/K5pfay4IVquD6oWrPqOxp61BVZ+w
Z6OAz5XRCJhVbcDWf3PBWJF+Xi1u3m+TpO7fXlTWpjWl3Zz4zVSecJxVlacn
Tldxtj9/k5WV6x/Yp66QZg1c2vRJHtddbM5zSh5sMRTzCEw2lSYfWxUK0aKb
UZpwZmxU0VijMsRrhNlEhlX4banDts+SGxKUD8j7K/zqxR6EMZkC7u1tPnh4
WyhregZaLzZObg0EvBYK6vyvF6H/1pjwrftnXbN/wiVQTxvYk6cmZX5X+xZh
619RXUhLp0O4uF5VsDWqCnI5D6Jh5yK33xx0N/rQOcIrur8WlueNcjRjcGl3
A1tacq10qyu2VjtLC1krFByMPXcp5Ly5Se5G24+AagrSxU5c22sej5Btq5zT
lwPcpUoCQ1qtWWwu5Bxrr3lWaNtf4m4Y6qHNEaPA5s7i9nQsUr8Zr6y4NrVe
tt/wVyPqKPKcvxDEmKvq6urUGdOj7hZKp3Fld33ddvc7Fnvm3XSYy5lZQoD9
aDvad9RsztB+cx2Fv7pYc+ScnP9ZVdqXLcS8gqvawKiKIO9hONJacAjMa5GG
Qiib8aS84rCt1zmZzWJqXbNQFT7VAG1o6g4QA6sLLFerId0xz+KiJ2Bbsfew
iRSHWWzbUGh/iDnoBqXp1hiobInlBqlP5SdRrNpmsH6cXxwtZBxDyrsQ8ZJ8
aUlSBIvOoKAwZpzFRU36p8qwqYBVmCIWSsdRpQSzt6DeWSAWgXtBOE11lti6
iZRlspFBEkla1sml/HxVVwPSyqrrbF20ckfhtRLh938+HPDZ1uarT733R4Ph
cLv36fKlfv12cvTz8MX+cjPafvFKHr0cqumHR1QW1cVzFxJyhOrmnweMGwWJ
se7hAxvRvxUkVEvdVQR0sML53ZxaJL4D8TiJ31WVFMM2sOBwJSuuyqqfj5Jc
G9pdvhanozsihf6oU4efDqWZ8TScir8eQs0KUv8gFFXcnBNrTSBUyLJgzUZb
kNeYsrioVFEYe+yltXc7cEfGL+XytZJ+SfEfmfdv7KkXWTk3bCewtclUVcsv
wJjoutJT4z3TMKBKD7AQu3cPyZEs+iuz+QcqzubNawkgN7uPb4CQXwnxNPRf
XNzUr5loN7qi5zEggMJb/NZzRTCef1Qbn+iplwoiLU9THl7g0zI+ylwzg94X
ucdrICK6/dI8xCsrmo0t3oOxh3vw4ZOQlxSRVnpV8SBHTqZUHlhUgxfMSfVM
wKZre+Q33Q5NWEJef7rO5o0N6waKwsNHEV0qAqSAYprjKnxS6d4Bg4YNLP9S
EOqnn3+5AUKtvLckgd8OwtZFWJ5pIch6sLVdN7GvCLXwvU3/5Mfe/Q/LzceH
8c7p2+Td5P3i03b8y96798e9eH/r5f6T0eXe/uN9PtqdPK1jLZLjOlgLz7kC
a2G7qfCZkaDHKu6ipKqIbwVrNXN8FW4dro48blozE64BukD0JaqqJQaY86sb
gsHPM4X1+suf1bpqxF3C2BsMUkNGhvPcFYXcPYIaQPFl8sGwMpi/s8nTylbl
TUvbG9mGkSB/UtR2j1XzwR9wWe3lKhrKEjPYAjwBPHZXmjBWFKqrr/ZsbIwF
v/DjYgC14TS/6LJGHlJ28mIswhIHn4oLSIk+PitDkyXSDQ6VFgqmuFce/gNR
8CXARBN870R3kOUbGQikCuSdyom76ARtaGkuTDtPSGqOolQ6PwaYOcXnqZ2I
DEc3HDwob0bB/237La7mTUWXffaJQPFcRiUux2oH9CG/Q7aIircc44pM6i8R
VuFXmQYrIOk803Nlm0/uDSfCUHaaUcenzGBOlpiI7eqgkXY32MHgzaBhmfQR
YYm5sHrQYiJNKnT9ZWaOQS2oXPFPbVpuKWREOM+/8/CzWCy6a4ag/9gXJyd2
G9cJGeeF1Y0PQ3wuQCvudVQ/6LMv+gIFtqZ/ZgT73vUm5iR/zY3jKCgDvpCh
gUa0HuI7TnK3Gvjl6son6gCzRxy8mWCh9z7oVlnV29xfXEZVAp5sbmjk/xGR
5DQcSUvqcyWxolr94sJo0PDkcXNh/kdE4lG6Wyr4rx5G4P7B/wEYi7e1JDcA
AA==

-->

</rfc>
