<?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-04" 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-04"/>
    <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="February" day="09"/>
    <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="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="12" month="December" year="2025"/>
          <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-03"/>
      </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:
H4sIAAAAAAAAA91bW1MbxxJ+318xJR6c1EGSsQ2xVcenDAZsHGMoEHaSk1Nh
tDuSxqx25JldZJkiv/1098zuzl4AOXGclPNAYOfSPX39umfc7XaDVKaxGLDO
y+HwmB1rNYrFjA2Xc2HYWGm2KyfCpGxfijgynSDkqZgovRwwk0ZBEKkw4TNY
Hmk+TrtSpOPuNE3nfC67Ea3sjmlld2537qa4c/f+o8Bko5k0RqoEPw3Ywd5w
n7E1xmOjgB2ZRGIu4EeSdtZZR0QyVVryGP842N6B/wFznYOT4X4nSLLZSOhB
EAFzgyBUiRGJycyApToTweWAPQy4Fhx2fSdGjCcRO0hSoRORsqHmiZkrnXaC
hdIXE62yOczbyWQcyWTCdmIVXlhJkIC2jw9AChdiCbOjQcC6LBEfUzYRidA8
hcPgpyyRodL0q5lzfRHjTpE0qZajLBURi0U0ETq4FEkGDDO2IlnGrKg674BV
nPYC1+H3GZcxfHeif4Z66Ck9wSGuw6kbMoN+H2fiJ3kpevm0Pn7oj7RaGNF3
e/Rx7USm02yE2kDFLia5bvu36BbXxaAIk3pUa+t7duOeVLft1P88o+pN01nc
CQKepVOlUTfACWPjLI6tjXYOuZaZYT/GQkZxh0bh9DyRn0h1A2sNseJgbDQq
nFxntPBZWg73QjXrtJB4nYXcsGOuo0y0UXgeqywagwZEhUCMy57Rzzmtrewv
E7Dlkx47VnEs6xRPFNh+quxgG0lgpjsUYYUeyE3OccGzCX5x1OC/UGVJiu59
kPJ4GQSJ0jPY55LMdPfgxd7pEFjZf/5k8+F9+HL2Zu/N827+/aC726vpbCRN
N0tEEqpIRE57sO745Gjn9d6h3erR5g/w6XR4cvZ8eHayt9vdP9h7vXtqB7c2
N2AQncD+vbGBdOG3xz88eYBMvTo9ekNDjx9sPgkCmYxLloOg2+0yPgLP42Ea
BMOpNAxiVjaDsAK+KUIJlmSsjzljIh8zLJ1ymCH0pdCGhTxhmRGgCKYFhAsI
MDBD5UsMwwNmGFPAuRdTGQsWCU5uvwBLZxyWfcgwjoZc6yV+lzB7omW6ZNaW
KSyVH+dajGG3JBRuvMfODK4DThrcrgO3wjFLvMLgpYwEhAVw9ER0IfhFHKYz
oTWElEikoHQ6AZcR/DnKJhPcHMbsDC0wJsKnnhXhTEZRLIJgDSOnVlEWUqwL
rq6s7q+vif+rK98g4GMkxkDfcuzOiTFNfAynPJlU5WCNwwqiPL5ZZxAzQWks
UbnKluskT6kFZQEtwHxBoxEsXeZaDdlITPmlhPFxcSwgGpFWtIAQhb+ACEoO
RsCEMHKS9NgQBOpULUcyxlEwHXDEFEQJs2Ix4RjJUYTzeSxDcjaDC30Ts+eH
M4F2UqbGbZb23dWVc4fr6++t3aEORwJNLkKmnGZ9QpbxCP8Udg0vtl3wr2KQ
QbBPquSzeQyKKLecCWP4BK0PhJaEcQaWCEk5RYHwWCUTg7Z5/tx+6lqEcU70
zk/EXBdfHCN0PHQ/7mwEdgEMAueY+YYfKRAmGUk2R+vtse3ElxnGthh1FyJ5
kJ8W70WYwhagsZz3kQg5eTopAXe7BLFFVsqilMff5I4gZsPMVC0SjEVIZgxR
XC1wttME6OX3339nGHy7ThPgtm+OhnsDdu/XeyxGh1xoEAwumgOLEDsZRtMg
wKP0N3ob7NH9+2wHDP3EiiXIdTUk/OEJte8O/q/3BuLBOw5zqnoFoDjl3c2N
B08frtOvDza3nkIMD64gdndQXB0fJ/CEW0Ri0A/RhwwhkmqqX/uVkpUDA1ni
NA4ZprAM01knAohukcJZOQnCgJmS8mqTvY1+88YG7L9E7op+wrxiDDceK0Wr
aWQKmhUaP7eIwmbYa/j5v+AalYTxFKYADLQ+jR6wixFD0t9BcKpmItersRr3
ows6FYev6FOkV+cr6HgjMg1IumQyENZCAJ8CPRqitEuf19c9zIlg2kJDEuvU
Q0CHOOrcEgQ6TaYA2qAlj0SA6zQsQZE3eagkjmweUTilkWoO8VhkHd/NWmhL
sxLpItxWj+9iAFYYeZbH32mvGRQgXC/xb4NVicbfwlja8oTEZB2+QwIYazUD
QuhPBZVq1G+Vm00XIA6KLYhsYBP8H2yCKWmZZwagBbWQ/EQnwriRMEyIEKtw
q58OXzOLgvDwKktj2pXOvj3Hqkp+ZDuYjnxJrFWrP8t0GV6MoJxfpLR0qkX9
UMCJ+AhiNwCZICWrpERIZJgqDDMN+UgkZSourQsC3S2mxlTixVUSh6nTx8iN
c85dZDinbeCwNlhKTfPY2clBjx3BB90G+nxFgOwoWVVUtc6WIi1xBhzapSVC
FSIqDr1OnqiFZQt2sNyArF1ctcgyz5GzLE4lePrKIumxSgZO0UCQYiGGlVOs
kUicJ0JlJiayuR49JEZAqkjksBWkJZgDf9n8WgC41CoK6hOWypkgXcE2CvEa
UMICtDQMlAAkFAHfCgHgKktOJSLPzRaUVRWW66npTWi2+SHQzIq9LS1uoaWF
RgLyMtFkEvsNADAJGk4RtmgbCqgqt9HdQTQbexECllyBHEIEDBlm4bU15ied
ly7pbBeJxdUjTccSn58Qb0+FFan1gm0fnHjGWc5Bo0YPxk4GYR9lxUEBjwQQ
oGZAQTPQKkYSHG7mVVZYT5QDlpX93dlWvs5ZAXZyfJQnIgdEG2ewMOy8Pamf
g22AHWP7CfAqto8weThzQrtQIBbSJH7n1VgMIUKDm8GpgT+NBaRvN2RNHtVS
HL1gD8dw0TI/lt2qpKFGBEoJpVfxnWXTQFXbJU84L/Y9947gtsFeE6xxVpqb
c4mbL8Qy19oNrDoi1uZXpoBNiXzjFTVt/ckzlFuYCry6TFSCZ9Nbb6NYKZ7y
nHLPeAJy5GvVaM/5bMVXSCZg+GnNTfgI0kdzS4o64dSfaSsT8kQsS9A8PJO3
xhDJMTEB61tEY3r1fO3SAlULxqvOCsvKI/n5VYmS34gFG9If1+fsu3mcGfZ6
/3sbeV2Sc96Z55jD3c2Si/xo0lRdFItYrybipmaN5HogZVRI1FbAHB+dDll/
pNSFbdZgkRK8VFheAP7uubPeUqZQebIdhmKetgx4KXHAZtHm08HZ4sOTjzuP
Dl+lu8OL5O3R6d7exrvtp08HQb28uWP6WdH8WnFB0K4OqheuBozGnna2q/qE
PRsFfK6MRsCsagO2/psLxor082px4/46Ser+7UVlbVpT2s2J30zlCcdpqzw9
cbqKc/3zN2mtXP/APnWFNGvg0qZP8rjuYnOeU/Jgi6GYR2CyqTT5WFsoRItu
RmnCmbFRRWONyhCvEWYTGVbht6UO2z5LbkhQPiAftPjViz0IYzIF3NvfePDw
tlDW9Ay0Xmyc3BoIeC0U1PlfLUL/rTHhW/fPumb/hEugntawJ09Nyvyu9i3C
1r+iupCWTpdwcb2qYCtUFeRyHkTDzkVuvznobvShc4RXdH8tLM8b5WjG4NLu
Bra05FrpVldsrXaWFrJWKDgYe+5SyHlzk9yNth4B1RSki524da95PEK2rXJO
X27jLlUSGNJqzWJzIedYe82zQtv+EnfDUA9tjhgFNncWt6djkfrNeGXFtan1
sv2GvxpRR5Hn/IUgxlxVV1enzpge9TZROo0ru+vrdXe/Y7Fn3k2HuZyZJQTY
j7ajfUfN5gztN9dR+KuLNUfOyfmfVaV92ULMK7iqDYyqCPIehiOtBYfAvBJp
KISyGU/KKw7bep2T2Sym1jULVeFTDdCGpu4AMdBeYLlaDemOeRYXPQHbir2H
TaQ4zGLbhkL7Q8xBNyhNt8ZAZUssN0h9Kj+JYtU2g/Xj/OJoIeMYUt6FiJfk
S0uSIlh0BgWFMeMsLmrSP1WGTQWswhSxUDqOKiWYvQX1zgKxCNwLwmmqs8TW
TaQsk40MkkjSsk4u5eeruhqQWquus1XRyh2FVyvCH/x8uM1nmxuvPvXfH20P
h1v9T5cv9eu3k6Ofhy/2lxvR1otX8ujlUE0/PKKyqC6eu5CQI1Q3/zxg3ChI
jHUPH9iI/q0goVrqriKggxbnd3NqkfgOxOMkfldVUgzbwILDlazYllU/HyW5
NrS7fC1OR3dECv1Rpw4/HUoz42k4FX89hJoVpP5BKKq4OSfWmkCokGXBmo22
IK8xZXFRqaIw9thLa+924I6MX8rlayX9kuI/Mu/f2FMvsnJu2E5gK5OpqpZf
gDHRdaWnxnumYUCVHmAhdu8ekiNZ9Fdm8w9UnM2b1xJAbvQe3wAhvxLiaei/
uLipXzPRbnRFz2NAAIW3+K3nimA8/6g2PtFTLxVEWp6mPLzAp2V8lLlmBr0v
co/XQER0+6V5iFdWNBtbvAdjD/fgwychLykitXpV8SBHTqZUHlhUgxfMSfVM
wKZre+Q33Q5NWEJef7rO5o0N6waKwsNHEV0qAqSAYprjKnxS6d4Bg4YNLP9S
EOqnn3+5AUK13luSwG8HYasiLM+0EGQ92Nyqm9hXhFr43mZw8mP//oflxuPD
eOf0bfJu8n7xaSv+Ze/d++N+vL/5cv/J6HJv//E+H+1OntaxFslxFayF52zB
WthuKnxmJOixirsoqSriW8FazRxfhVuH7ZHHTWtmwhVAF4i+RFW1xABzfnVD
MPh5prBaf/mzWleNuEsYe41BasjIcJ67opC7R1DbUHyZfDCsDObvbPK0soXx
v/YiNR/7Acdqz1PRGpaYphZg7uCWu9KEsaJ4XH2aZwNgLPiFH/wCKACn+W2W
teSQUpAXSBF7OIxU3DJKdORZGX8skV5wqLRQMMU95fBfgYLDAPCZ4KMmumgs
H8JAtFQg1FRO3G0miFxLc2HW86yj5igvpfNjgC1TEJ7aichwdMPBg/L6E5zc
9tjianJUdKNn3wEUb2JU4hKpdmgekjikhKh4sDGuyKT+3KANpMo0aMGd80zP
le0wuYeaiDXZaUZtnTJNOVlitrWrg0ZuXWMH22+2G+ZHHxF7mAurBy0m0qRC
159f5kDTIseWf0/TcUsh7cF5/p3HmMVi0VsxzvzHPis5sdu4dsc4r55ufP3h
cwFacU+gBsGAfdFnJrA1/Vsi2Peuhy8n+ZNtHEdBGfCFDA00ovUQxHGSu7rA
L1dXPlGHij3i4M2E/bxHQLfKqt7L/uIyqhLwZHNDt/6PiCSn4UhaUp8riZaS
9IsLo0HDk8fN1fcfEYlH6W6p4D9tGIH7B/8HSVXPfgk3AAA=

-->

</rfc>
