<?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.20 (Ruby 3.3.3) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-httpapi-digest-fields-problem-types-00" category="info" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.24.0 -->
  <front>
    <title>HTTP Problem Types for Digest Fields</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-httpapi-digest-fields-problem-types-00"/>
    <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="2024" month="November" day="04"/>
    <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 50?>

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

<section anchor="introduction">
      <name>Introduction</name>
      <t><xref target="DIGEST"/> by design does not define, require or recommend any specific behavior for error handling relating to integrity. The responsibility is instead delegated to applications. This draft defines a set of problem types (<xref target="PROBLEM"/>) that can be used by server applications to indicate that a problem was encountered while dealing with a request carrying integrity fields and integrity preference fields.</t>
      <t>For example, a request message may include content alongside <tt>Content-Digest</tt> and <tt>Repr-Digest</tt> fields that use a digest algorithm the server does not support. An application could decide to reject this request because it cannot validate the integrity. Using a problem type, the server can provide machine-readable error details to aid debugging or error reporting, as shown in the following example.</t>
      <sourcecode type="http-message"><![CDATA[
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-algorithm",
  "title": "hashing algorithm is not supported",
  "unsupported-algorithm": "foo"
}
]]></sourcecode>
    </section>
    <section anchor="conventions-and-definitions">
      <name>Conventions and Definitions</name>
      <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they
appear in all capitals, as shown here.</t>
      <?line -18?>

<t>The terms "integrity fields" and "integrity preference fields" in this document are to be
interpreted as described in <xref target="DIGEST"/>.</t>
      <t>The term "problem type" in this document is to be
interpreted as described in <xref target="PROBLEM"/>.</t>
      <t>The term "request", "response", "intermediary", "sender", and "server" are from <xref target="HTTP"/>.</t>
    </section>
    <section anchor="problem-types">
      <name>Problem Types</name>
      <section anchor="unsupported-hashing-algorithm">
        <name>Unsupported Hashing Algorithm</name>
        <t>This section defines the "https://iana.org/assignments/http-problem-types#digest-unsupported-algorithm" problem type.
A server <bcp14>MAY</bcp14> use this problem type if it wants to communicate to the client that
one of the hashing algorithms referenced in the integrity or integrity preference fields present in the request
is not supported.</t>
        <t>For this problem type, <tt>unsupported-algorithm</tt> is defined as the only extension member.
It <bcp14>SHOULD</bcp14> be populated in a response using this problem type, with its value being the algorithm key of the unsupported algorithm from the request.
The response can include the corresponding integrity preference field to indicate the server's algorithm support and preference.</t>
        <t>Example:</t>
        <figure>
          <name>A request with a sha-256 integrity field, which is not supported by the server</name>
          <sourcecode type="http-message"><![CDATA[
POST /books HTTP/1.1
Host: foo.example
Content-Type: application/json
Accept: application/json
Accept-Encoding: identity
Repr-Digest: sha-256=:mEkdbO7Srd9LIOegftO0aBX+VPTVz7/CSHes2Z27gc4=:

{"title": "New Title"}
]]></sourcecode>
        </figure>
        <figure>
          <name>Response Advertising the Supported Algorithms</name>
          <sourcecode type="http-message"><![CDATA[
HTTP/1.1 400 Bad Request
Content-Type: application/problem+json
Want-Repr-Digest: sha-512=10, sha-256=0

{
  "type": "https://iana.org/assignments/http-problem-types#digest-unsupported-algorithm",
  "title": "Unsupported hashing algorithm",
  "unsupported-algorithm": "sha-256"
}
]]></sourcecode>
        </figure>
        <t>This problem type is a hint to the client about algorithm support, which the client could use to retry the request with a different, supported, algorithm.
Note that a request may contain more than one integrity field.</t>
        <t>This problem type can also be used when a request contains an integrity preference field. For example:</t>
        <figure>
          <name>GET Request with Want-Repr-Digest</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 the Supported Algorithms</name>
          <sourcecode type="http-message"><![CDATA[
HTTP/1.1 400 Bad Request
Content-Type: application/problem+json

{
  "type": "https://iana.org/assignments/http-problem-types#digest-unsupported-algorithm",
  "title": "Unsupported hashing algorithm",
  "unsupported-algorithm": "sha"
}
]]></sourcecode>
        </figure>
      </section>
      <section anchor="invalid-digest-value">
        <name>Invalid Digest Value</name>
        <t>This section defines the "https://iana.org/assignments/http-problem-types#digest-invalid-value" problem type. A server <bcp14>MAY</bcp14> 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 digest value and the server can skip computing the digest value. This problem type <bcp14>MUST NOT</bcp14> be used if the server is not able to parse the integrity fields according to <xref section="4.5" sectionFormat="of" target="STRUCTURED-FIELDS"/>, for example because of a syntax error in the field value.</t>
        <t>The server <bcp14>SHOULD</bcp14> include a human-readable description why the value is considered invalid in the <tt>title</tt> member.</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</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[
HTTP/1.1 400 Bad Request
Content-Type: application/problem+json

{
  "type": "https://iana.org/assignments/http-problem-types#digest-invalid-value",
  "title": "digest value for sha-512 is not 64 bytes long"
}
]]></sourcecode>
        </figure>
        <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>
      </section>
      <section anchor="mismatching-digest-value">
        <name>Mismatching Digest Value</name>
        <t>This section defines the "https://iana.org/assignments/http-problem-types#digest-mismatching-value" problem type. A server <bcp14>MAY</bcp14> 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>Three problem type extension members are defined: the <tt>algorithm</tt>, <tt>provided-digest</tt>, and <tt>calculated-digest</tt> members. A response using this problem type <bcp14>SHOULD</bcp14> populate all members, with the value of <tt>algorithm</tt> being the algorithm key of the used hashing algorithm, with the value of <tt>provided-digest</tt> being the digest value taken from the request's integrity fields, and the value of <tt>calculated-digest</tt> being the calculated digest. The digest values <bcp14>MUST</bcp14> BE serialized as byte sequences as described in <xref section="4.1.8" sectionFormat="of" target="STRUCTURED-FIELDS"/>.</t>
        <t>The following example shows a request with the content <tt>{"hello": "woXYZ"}</tt> (plus LF), but the representation digest for <tt>{"hello": "world"}</tt> (plus LF). The subsequent response indicates the mismatching SHA-256 digest values.</t>
        <figure>
          <name>A request with a sha-256 integrity field, which does not match the representation</name>
          <sourcecode type="http-message"><![CDATA[
PUT /items/123 HTTP/1.1
Host: foo.example
Content-Type: application/json
Repr-Digest: sha-256=:RK/0qy18MlBSVnWgjwz6lZEWjP/lF5HF9bvEF8FabDg=:

{"hello": "woXYZ"}
]]></sourcecode>
        </figure>
        <figure>
          <name>Response indicating the mismatching digests</name>
          <sourcecode type="http-message"><![CDATA[
HTTP/1.1 400 Bad Request
Content-Type: application/problem+json

{
  "type": "https://iana.org/assignments/http-problem-types#digest-mismatching-value",
  "title": "digest value fromr request does not match expected value",
  "algorithm": "sha-256",
  "provided-digest": ":RK/0qy18MlBSVnWgjwz6lZEWjP/lF5HF9bvEF8FabDg=:",
  "calculated-digest": ":8vXo+0QVwf2woEblm4hTAftp0/K5fWSMZG4CKtplwjc=:"
}
]]></sourcecode>
        </figure>
        <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>
      </section>
    </section>
    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t>Disclosing error details could leak information
such as the presence of intermediaries or the server's implementation details.
Moreover, they can be used to fingerprint the server.</t>
      <t>To mitigate these risks, a server could assess the risk of disclosing error details
and prefer a general problem type over a more specific one.</t>
    </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-algorithm-problem-type">
        <name>Registration of "digest-unsupported-algorithm" Problem Type</name>
        <dl>
          <dt>Type URI:</dt>
          <dd>
            <t>https://iana.org/assignments/http-problem-types#digest-unsupported-algorithm</t>
          </dd>
          <dt>Title:</dt>
          <dd>
            <t>Unsupported Hashing Algorithm</t>
          </dd>
          <dt>Recommended HTTP status code:</dt>
          <dd>
            <t>400</t>
          </dd>
          <dt>Reference:</dt>
          <dd>
            <t><xref target="unsupported-hashing-algorithm"/> of this document</t>
          </dd>
        </dl>
      </section>
      <section anchor="registration-of-digest-invalid-value-problem-type">
        <name>Registration of "digest-invalid-value" Problem Type</name>
        <dl>
          <dt>Type URI:</dt>
          <dd>
            <t>https://iana.org/assignments/http-problem-types#digest-invalid-value</t>
          </dd>
          <dt>Title:</dt>
          <dd>
            <t>Invalid Digest Value</t>
          </dd>
          <dt>Recommended HTTP status code:</dt>
          <dd>
            <t>400</t>
          </dd>
          <dt>Reference:</dt>
          <dd>
            <t><xref target="invalid-digest-value"/> of this document</t>
          </dd>
        </dl>
      </section>
      <section anchor="registration-of-digest-mismatching-value-problem-type">
        <name>Registration of "digest-mismatching-value" Problem Type</name>
        <dl>
          <dt>Type URI:</dt>
          <dd>
            <t>https://iana.org/assignments/http-problem-types#digest-mismatching-value</t>
          </dd>
          <dt>Title:</dt>
          <dd>
            <t>Mismatching Digest Value</t>
          </dd>
          <dt>Recommended HTTP status code:</dt>
          <dd>
            <t>400</t>
          </dd>
          <dt>Reference:</dt>
          <dd>
            <t><xref target="mismatching-digest-value"/> of this document</t>
          </dd>
        </dl>
      </section>
    </section>
  </middle>
  <back>
    <references anchor="sec-normative-references">
      <name>Normative References</name>
      <reference anchor="DIGEST">
        <front>
          <title>Digest Fields</title>
          <author fullname="R. Polli" initials="R." surname="Polli"/>
          <author fullname="L. Pardue" initials="L." surname="Pardue"/>
          <date month="February" year="2024"/>
          <abstract>
            <t>This document defines HTTP fields that support integrity digests. The Content-Digest field can be used for the integrity of HTTP message content. The Repr-Digest field can be used for the integrity of HTTP representations. Want-Content-Digest and Want-Repr-Digest can be used to indicate a sender's interest and preferences for receiving the respective Integrity fields.</t>
            <t>This document obsoletes RFC 3230 and the Digest and Want-Digest HTTP fields.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="9530"/>
        <seriesInfo name="DOI" value="10.17487/RFC9530"/>
      </reference>
      <reference anchor="PROBLEM">
        <front>
          <title>Problem Details for HTTP APIs</title>
          <author fullname="M. Nottingham" initials="M." surname="Nottingham"/>
          <author fullname="E. Wilde" initials="E." surname="Wilde"/>
          <author fullname="S. Dalal" initials="S." surname="Dalal"/>
          <date month="July" year="2023"/>
          <abstract>
            <t>This document defines a "problem detail" to carry machine-readable details of errors in HTTP response content to avoid the need to define new error response formats for HTTP APIs.</t>
            <t>This document obsoletes RFC 7807.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="9457"/>
        <seriesInfo name="DOI" value="10.17487/RFC9457"/>
      </reference>
      <reference anchor="STRUCTURED-FIELDS">
        <front>
          <title>Structured Field Values for HTTP</title>
          <author fullname="M. Nottingham" initials="M." surname="Nottingham"/>
          <author fullname="P-H. Kamp" surname="P-H. Kamp"/>
          <date month="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="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="RFC2119">
        <front>
          <title>Key words for use in RFCs to Indicate Requirement Levels</title>
          <author fullname="S. Bradner" initials="S." surname="Bradner"/>
          <date month="March" year="1997"/>
          <abstract>
            <t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
          </abstract>
        </front>
        <seriesInfo name="BCP" value="14"/>
        <seriesInfo name="RFC" value="2119"/>
        <seriesInfo name="DOI" value="10.17487/RFC2119"/>
      </reference>
      <reference anchor="RFC8174">
        <front>
          <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
          <author fullname="B. Leiba" initials="B." surname="Leiba"/>
          <date month="May" year="2017"/>
          <abstract>
            <t>RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
          </abstract>
        </front>
        <seriesInfo name="BCP" value="14"/>
        <seriesInfo name="RFC" value="8174"/>
        <seriesInfo name="DOI" value="10.17487/RFC8174"/>
      </reference>
    </references>
  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA9Va6XIbNxL+P0+BpX5ks+EhypIPVpyYkiiLsWQpFGXH3toq
gTMgCWtmwAAzommW8iz7LPtk293AXCQlK1k7lfUPmQQG3Y0+vj6GjUbDS2QS
ig6rHQ+H5+xcq1EoIjZczIRhY6XZoZwIk7AjKcLA1DyfJ2Ki9KLDZDxWnhco
P+YRnA80HycNKZJxY5okMz6TjYCONsZ0tDGzpBsJkm5sb3smHUXSGKliXOqw
fm94xNgW46FRII+MAzET8CdOanVWE4FMlJY8xC/97j78B9LV+oPhUc2L02gk
dMcLQLqO56vYiNikpsMSnQrvpsMeeVwLDlTfihHjccD6cSJ0LBI21Dw2M6WT
mjdX+nqiVTqD5/ZTGQYynrD9UPnXVhWkoe55H9RwLRbwdNDxWIPF4mPCJiIW
midwGVxKY+krTR/NjOvrECkF0iRajtJEBCwUwURo70bEKQjM2APZMmZVVXsL
ouJjL/EcrkdchrDuVP8C7dBUeoJbXPtTt2U6rRY+iUvyRjSzx1q40BppNTei
5Wi08OxEJtN0hNZAw84nmW1b99gWz4VgCJOUuK6cb1rCTanuo9T6fU7VnCZR
WPM8niZTpdE2IAlj4zQMrY/WTrmWqWGvQiGDsEa7cHsey09kuo71hlBxcDba
FU6vER18kRTbTV9FtQ0sTlKfG3bOdZCKTRwOQpUGY7CAqDAI8dgL+jujsxX6
MgZfHjTZuQpDucpxoMD3E2U3N7EEYRpD4Vf4gd7kDA+8mOCK4wb/fJXGCcZ3
P+HhwvNipSOgc0Nueth/2bsYgihHB8/2Hm3DyvngbP+kd2qXdveewNLFcHB5
MLwc9A4bR/3eyeEFbT59ttuGTXRm+3C7ve15CCI5fc9rNBqMjyBMuJ943nAq
DQOASSPAAAgk4Uswu2HO6BQLhiVTDptC3whtmM9jlhoBCmNaQFgDEMATKjti
mIjpgkJDEM6nMhQsEJzCcw4eyTgc+zVFwPO51gtcl/D0RMtkwazPEXwUizMt
xkAt9oXbb9prRDIIQuF5Wwg1WgWpT+DgLZdWibe3bLQA5kZOYrgkiBmrBL6P
ZSzqJIXUAiFOC7ANaCAAxotMCz4biSm/kbCPECG0hr9TkIyuogXEH36Am+eS
NtlwKjKtyJEMUXpQMPhWIngArEMx4QhOcIrPZqH0yX8MHkRDYCw6AUEJoPKE
qfGKMf6+XDqPuL391poGTTISaJUAb2wtVWFgxQzwq7BneE52zv8kmx2hGj/y
aBaC+guSkTCGTwTgKygr9sM0EBAiQAk8kocqnhgJK1cHdqlhs+UV8bsaiJnO
V5wgdD30UM4skgEVyKdwD1Ah2MepJ3cIk84wOTVZNy7rDMM0RJv5yB70p8UH
4SdAAiyVyT4SPqdgICMgtRtQW2C1LMqecWlQa7xizHpZHjQibN4gt4hD8ohF
AxJqwOFx532BSABIyJhcomijdDJBsrl/aoFXgSVQsGFmquYxBiqyGQMUqTk+
7WwAFvntt98Yon7D2cBD7Gi1m222u73N9sFlB/aiXqb9ISXHkppa7kLffTAQ
e285PFO1VAfE4I299s7zR3X6uLP3+DkC0xKwqoZqqJWTGI+5TZcGwxZhyVC6
rOahLZej0thZTwSN3Mq1OlHGootIczMl3edeICuGF4E9sJkWEBgrVfNuUVmI
NXA7qClsVKEPHmK4SvqOeCoYFC4MKxcDyfDyYojFFP7PXp/R50Hv58s+IDd+
vjjunpzkHzz3xMXx2eXJYfGpOHlwdnrae31oD8Mqqyx5tdPuO9hBqWpn58P+
2evuSc3avwzzkBjRhUbWPzWEKkISNx5ApQ/lk8BAZvsH5//5d3uXLZd/g1yy
024/Azy1X562n+zCl/lUxJabisOF+wqutvDAPwTXSIWHIXj2TEKmMyWfnAI2
gP/945+omX912Pcjf9be/cEt4IUri5nOKouks/WVtcNWiRuWNrDJtVlZX9F0
Vd7uu8r3TO+lxe9/BCQVrNF++uMPnvURUDtkytoqiNas7e6B0fvM6VXNySrm
LJJisxCB1cpwtIG2NA8inSekCm0HkuirWaWAn4lUBM0G1wv8brAD0ZnfWjSs
0a3GWkVAHUGJSG9VmydY2GKXRdSyYxfp3Sx6XYFjBFUGeWZFOPyyiFOB9abX
zUAdvINSEWm1/AyTY0wac8BLUjEWINjSUOZQJKEfSjQBpjNPgf9AJYDLa3CG
2cg5SZCBfeFBSt+XlXHFkKHtOWcybxUhXfZeu0adXW1UyBV6jlU3+QvSJpCA
Rg76RjRGJLChbHr9hLlwBECaqVkaUoWE2JEXmKBDqrXW2VN5IkGHkHdTASTs
c6KE9ojHTnclWUsPkJuVbt/0SmWcoMSc1SVkF6XtXlCtg1aVu1JzZYn+G1Ni
7cQh1y/Og7Z7Nkd3NuTo8zNAyNZIKWhes3ztHSvMtJCpmi6735OxKVN3fV/M
kjs3Gj2oCPGCHSZxPgAX9ErFVifP5J2odx2Mzp5c6ODZSf9MTMbJ2Tbf/+W7
N+fDN5+etA4ujoXZeb/zZOLvPofrLIvE/FrM2ZC+2OS67DDae17r5gWWKz8d
t9Wqs47Fqj9dS+hYBRcaB/JfqdJZ0wiWOe3tos75E8ucMhCuYcRnKhwnblbl
FIYYZEHQDUCRiTRZeF3kvHKwNahnC7hVpMNWBsRJVoCNj1SarMdCZtPSk7YS
JxzFMhx653K4Zj4SyDHFD1DIr1kv6De916pofvLmA5oObDY44E2kNO3HDOF2
xdWam66G0ICztLz7whqo3C1Zylgo3gMUTVbqjDZF/MseBLxMoLlutXce3Rf0
G72Squ2qXZHioKy+1YNfJWb+X2LhC8TBFg4lqBfMxrtvMEF9hYJEWjYNSoAr
hQh7QCFCLltKaNhcZg6MsajMWiyYPB/mLTZxr+fjCERjiAk3si0AuZo710xT
iYQ61kh4qMwiy+RXDm2v1olk2eDxLnBNQLs4Q6iXWvQRym1tUyGNSXilITfX
coa12SxNMouXj7i5TUWfWQOTY4K7haPqhKOuHqdmXJuVWUE+UPFBW5lJlssL
5zO7zT1UwtoI8Pa2bgdVVnv5aAKehfy5ACD66IYE2UCAihR7D1u2OxFdOVbY
eJpGPC6GEbb4n5E086k1rNUgXA7fDEDFoKmEs0p2/K4olq7ywo9Yrk0lqEE0
JQwleLK+Y2dCV8vaVMApDFbos8OgdnvF/j4LU8NOjr6ts1GalA0F/gG6AB9P
dBpjLRbYMZ1JRwZZAMW81MvKNeMsYuWHthJdzRHcNDY5v3woQH+mKttYUHTe
nXZ5tNf+6VPrw1l3OHzc+nRzrE/eTM7eDV8eLdrB45c/ybPjoZr+uksV1qp6
HlJd4QU3VFcY/Xcq8q+bJKqgWE0OlZjHiMmvvwE37kkFzlksLnDrc26AlwML
9c8KfVpTSt1QHeUux9mYp2Heitm2+BscuIc+NkUYbhjfrjDPkLCKR11XH7lN
w6NqnYQlVwTnx9mUcy7DkIXyWkBzhrdfECqAT6TQBxgzTsM8PJqU1k6liXji
E+Z+5dQWFaz+CunNmjmfG5No6wkq94U8jVjzgVOMqYUWlfIQ8ccObm0nTlYh
cNRCVK+y2jsbGpK4LrtjMbbowKE1z7zRvdG7siOWq0KibCMjaP3n/p47Sw9Z
q04jPne+XqB1nq1LIn22PTeb6rWNRFevViJdtQa/BvuvdvjfmDWb1/P0XzDZ
oKiCTcmuLjFQWilzN7YY2O+hL0gApE92GoLwwmzy8THw1+ZpRa5vN5/eke2/
VAL95d37OxJo1Sezm6ET35+CH5pfS+FNORYb/Ir6/txUS9OMwavW9q+L9tPT
cP/iTfx28mH+6XH4vvf2w3krPNo7Pno2uukdPT3io8PJ89VcS5r8HycZG9Cl
aoa/bs5dR+v78i5EpM51s3Jr8XEGASBccWrJbJxX0M4KFOD+7zOjJbMW7ETo
6c0v6rvtn9/Mxztz1RuF0e502B0ns+3Wq73x24vT9y93D14ls3D+wQdCDywW
qq5vuVHX2B+XUj++lhbyhoJlbe5ZTiORnEypq7GJHfSWxpLsDoYGdF5g9+Um
ENng3cWoZVSar0zpdbX7xQAE/Z0Dl7VCAhNrEICngrwigqaY4yn8NYf7CRIU
Q8YG9RYDgEvJ+Q9cu8DdC7RDafxQUeapvvO0MoaCX5fl86BMmWYDZhsmPmF3
6a74ewaXePMJrESEiApos0ya3qnSQsEj9j1W5cU63A8S7QTfgtAsKyeHQKzA
CImcuEkvKFJLc405Ja8CSHwIJNLP1D6AggZ3XNgrRsJAxTbSYTURK3rLb8dW
+Y8WVEx1Gut3X3fXtEuLOI8z1/ZGWkykAU2tviGOE1KbK0U3/HCt5o6CjaHc
+T6DjPl83nwgbPxgy8mBJePK23EGE3e9ZykLAXpHNVwO+h2vw77kOAko00/2
gOxn3i8Nsp+O4DZqyYBLpeiuAR0HQMaH3LwPV5bLMktX7RSsb29tNVR6C3ev
nlbGP19cPxX6Jb1snm79EXVkHBxDYvR7tbChU/jimljjUdLG3U3RH9FImdNn
tYK/hBpx/9r7L4HyfmhqKgAA

-->

</rfc>
