<?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-rfc2629 version 1.5.24 -->
<?rfc tocindent="yes"?>
<?rfc strict="yes"?>
<?rfc compact="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-httpbis-targeted-cache-control-04" number="9213" submissionType="IETF" category="std" consensus="true" tocInclude="true" sortRefs="true" symRefs="true" obsoletes="" updates="" submissionType="IETF" xml:lang="en" version="3">
  <!-- xml2rfc v2v3 conversion 3.12.0 -->
  <front>
    <title>Targeted
    <title abbrev="Targeted HTTP Cache Control">Targeted HTTP Cache Control</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-targeted-cache-control-04"/> name="RFC" value="9213"/>
    <author initials="S." surname="Ludin" fullname="Stephen Ludin">
      <organization>Akamai</organization>
      <address>
        <email>sludin@ludin.org</email>
      </address>
    </author>
    <author initials="M." surname="Nottingham" fullname="Mark Nottingham">
      <organization>Fastly</organization>
      <address>
        <postal>
          <postalLine>Prahran</postalLine>
          <postalLine>Australia</postalLine>
        </postal>
        <email>mnot@mnot.net</email>
        <uri>https://www.mnot.net/</uri>
      </address>
    </author>
    <author initials="Y." surname="Wu" fullname="Yuchen Wu">
      <organization>Cloudflare</organization>
      <address>
        <email>me@yuchenwu.net</email>
      </address>
    </author>
    <date/>
    <date year="2022" month="June" />
    <area>Applications and Real-Time</area>
    <workgroup>HTTP</workgroup>
    <keyword>CDN</keyword>
    <keyword>Content Delivery Network</keyword>
    <keyword>Caching</keyword>
    <abstract>
      <t>This

<t>
This specification defines a convention for HTTP response header fields that allow cache directives to be targeted at specific caches or classes of caches. It also defines one such header field, targeted at Content Delivery Network (CDN) caches.</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-targeted-cache-control/"/>.
      </t>
      <t>
        Discussion of this document takes place on the
        HTTP Working Group mailing list (<eref target="mailto:ietf-http-wg@w3.org"/>), CDN-Cache-Control response header field, which is archived at <eref target="https://lists.w3.org/Archives/Public/ietf-http-wg/"/>.
        Working Group information can be found targeted at <eref target="https://httpwg.org/"/>. content delivery network (CDN) caches.

    </t>
      <t>Source for this draft and an issue tracker can be found at
        <eref target="https://github.com/httpwg/http-extensions/labels/targeted-cc"/>.</t>
    </note>
    </abstract>
  </front>
  <middle>
    <section anchor="introduction" numbered="true" toc="default">
      <name>Introduction</name>
      <t>Modern deployments of HTTP often use multiple layers of caching. For example, a website might use a cache on the origin server itself; it might deploy a caching layer in the same network as the origin server, it might use one or more Content Delivery Networks (CDNs) CDNs that are distributed throughout the Internet, and it might benefit from browser caching as well.</t>

      <t>Because it is often desirable to control these different classes of caches separately, some means of targeting cache directives at them is necessary. For example, if a publisher has a mechanism to invalidate the contents of a cache that it has a relationship with (such as a CDN cache), they might be more comfortable assigning a more generous caching policy to it, it while still wanting to restrict the behavior of other caches.</t>
      <t>The HTTP Cache-Control response header field (defined in <xref section="5.2" sectionFormat="of" target="HTTP-CACHING" format="default"/>) is widely used to direct caching behavior. However, it is relatively undifferentiated; while some cache directives (e.g., s-maxage) are targeted at a specific class of caches (for s-maxage, shared caches), targeting is not consistently available across all existing cache directives (e.g., stale-while-revalidate). This is problematic, problematic especially as the number of caching extensions grows, grows along with the number of potential targets.</t>
      <t>Some implementations have defined ad hoc control mechanisms to overcome this issue, but their interoperability is low. <xref target="targeted" format="default"/> defines a standard framework for targeted cache control using HTTP response headers, and <xref target="cdn-cache-control" format="default"/> defines one such header: the CDN-Cache-Control response header field.</t>
      <section anchor="notational-conventions" numbered="true" toc="default">
        <name>Notational Conventions</name>
        <t>The
         <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT",
"RECOMMENDED", "NOT RECOMMENDED", "MAY", "<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 "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are
    to be interpreted as described in BCP 14 BCP&nbsp;14 <xref target="RFC2119" format="default"/> target="RFC2119"/>
    <xref target="RFC8174" format="default"/> target="RFC8174"/> when, and only when, they appear in all capitals,
    as shown here.</t> here.
        </t>
      </section>
    </section>
    <section anchor="targeted" numbered="true" toc="default">
      <name>Targeted Cache-Control Header Fields</name>
      <t>A Targeted Cache-Control Header Field (hereafter, (hereafter "targeted field") is an HTTP response header field that has the same semantics as the Cache-Control response header field (<xref section="5.2" sectionFormat="comma" target="HTTP-CACHING" format="default"/>). However, it has a distinct field name that indicates the target for its cache directives.</t>
      <t>For example:</t>
      <sourcecode type="http-message"><![CDATA[
CDN-Cache-Control: max-age=60
]]></sourcecode>
      <t>is a targeted field that applies to Content Delivery Networks (CDNs), CDNs, as defined in <xref target="cdn-cache-control" format="default"/>.</t>
      <section anchor="syntax" numbered="true" toc="default">
        <name>Syntax</name>
        <t>Targeted fields are Dictionary Structured Fields (<xref section="3.2" sectionFormat="of" target="STRUCTURED-FIELDS" target="RFC8941" format="default"/>). Each member of the dictionary Dictionary is an HTTP cache response directive (<xref section="5.2.2" sectionFormat="of" target="HTTP-CACHING" format="default"/>) including extension response directives (as per <xref section="5.2.3" sectionFormat="of" target="HTTP-CACHING" format="default"/>). Note that while targeted fields often have the same syntax as Cache-Control fields, differences in error handling mean that using a Cache-Control parser rather than a Structured Fields parser can introduce interoperability issues.</t>
        <t>Because cache directives are not defined in terms of structured data types, it is necessary to map their values into the appropriate types. <xref section="5.2" sectionFormat="of" target="HTTP-CACHING" format="default"/> defines cache directive values to be either absent, a quoted-string, or a token.</t>
        <t>This means that cache directives that have no value will be mapped to a Boolean (<xref section="3.3.6" sectionFormat="of" target="STRUCTURED-FIELDS" target="RFC8941" format="default"/>). When the value is a quoted-string, it will be mapped to a String (<xref section="3.3.3" sectionFormat="of" target="STRUCTURED-FIELDS" target="RFC8941" format="default"/>), and when it is a token, it will map to a Token (<xref section="3.3.4" sectionFormat="of" target="STRUCTURED-FIELDS" target="RFC8941" format="default"/>), an Integer (<xref section="3.3.1" sectionFormat="of" target="STRUCTURED-FIELDS" format="default"/>) target="RFC8941" format="default"/>), or a Decimal (<xref section="3.3.2" sectionFormat="of" target="STRUCTURED-FIELDS" target="RFC8941" format="default"/>), depending on the content of the value.</t>
        <t>For example, the max-age directive (<xref section="5.2.2.1" sectionFormat="of" target="HTTP-CACHING" format="default"/>) has an integer value; no-store (<xref section="5.2.2.5" sectionFormat="of" target="HTTP-CACHING" format="default"/>) always has a boolean Boolean true value, and no-cache (<xref section="5.2.2.4" sectionFormat="of" target="HTTP-CACHING" format="default"/>) has a value that can either be boolean either Boolean true or a string containing a comma-delimited list of field names.</t>
        <t>Implementations MUST NOT <bcp14>MUST NOT</bcp14> generate values that violate these inferred constraints on the cache directive's value. In particular, string values whose first character is not alphabetic or "*" MUST <bcp14>MUST</bcp14> be generated as structured Strings, Strings so that they are not mistaken for other types.</t>
        <t>Implementations SHOULD NOT <bcp14>SHOULD NOT</bcp14> consume values that violate these inferred constraints. For example, a consuming implementation that coerces a max-age with a decimal value into an integer would behave differently than other implementations, potentially causing interoperability issues.</t>
        <t>Parameters received on cache directives are to be ignored, unless other handling is explicitly specified.</t>

	<t>If a targeted field in a given response is empty, or a parsing error is encountered, that field MUST <bcp14>MUST</bcp14> be ignored by the cache (i.e., it behaves as if the field were not present, likely falling back to other cache-control mechanisms present).</t>

      </section>
      <section anchor="cache-behavior" numbered="true" toc="default">
        <name>Cache Behavior</name>

	<t>A cache that implements this specification maintains a <em>target list</em> - target list. A target list is an ordered list of the targeted field names that it uses for caching policy, with the order reflecting priority from most applicable to least. The target list might be fixed, user-configurable, user configurable, or generated per request, depending upon the implementation.</t>
        <t>For example, a CDN cache might support both CDN-Cache-Control and a header specific to that CDN, ExampleCDN-Cache-Control, with the latter overriding the former. Its target list would be:</t>

	<artwork name="" type=""  align="left" alt=""><![CDATA[ ><![CDATA[
  [ExampleCDN-Cache-Control, CDN-Cache-Control]
  ]]></artwork>
        <t>When a cache that implements this specification receives a response with one or more of the header field names on its target list, the cache MUST <bcp14>MUST</bcp14> select the first (in target list target-list order) field with a valid, non-empty value and use its value to determine the caching policy for the response, and MUST it <bcp14>MUST</bcp14> ignore the Cache-Control and Expires header fields in that response, unless no valid, non-empty value is available from the listed header fields.</t>
        <t>Note that this occurs on a response-by-response basis; if no member of the cache's target list is present, valid valid, and non-empty, a cache falls back to other cache control mechanisms as required by HTTP <xref target="HTTP-CACHING" format="default"/>.</t>
        <t>Targeted fields that are not on a cache's target list MUST NOT <bcp14>MUST NOT</bcp14> change that cache's behaviour, behavior and MUST <bcp14>MUST</bcp14> be passed through.</t>
        <t>Caches that use a targeted field MUST <bcp14>MUST</bcp14> implement the semantics of the following cache directives:</t>
        <ul spacing="normal">
          <li>max-age</li>
          <li>must-revalidate</li>
          <li>no-store</li>
          <li>no-cache</li>
          <li>private</li>
        </ul>
        <t>Furthermore, they SHOULD <bcp14>SHOULD</bcp14> implement other cache directives (including extension cache directives) that they support in the Cache-Control response header field.</t>
        <t>The semantics and precedence of cache directives in a targeted field are the same as those in Cache-Control. In particular, no-store and no-cache make max-age inoperative, and unrecognised unrecognized extension directives are ignored.</t>
      </section>
      <section anchor="interaction-with-http-freshness" numbered="true" toc="default">
        <name>Interaction with HTTP Freshness</name>
        <t>HTTP caching has a single, end-to-end freshness model defined in <xref section="4.2" sectionFormat="of" target="HTTP-CACHING" format="default"/>. When additional freshness mechanisms are only available to some caches along a request path (for example, using targeted fields), their interactions need to be carefully considered. In particular, a targeted cache might have longer freshness lifetimes available to it than other caches, causing it to serve responses that appear to be prematurely (or even immediately) stale to those other caches, negatively impacting cache efficiency.</t>
        <t>For example, a response stored by a CDN cache might be served with the following headers:</t>
        <sourcecode type="http-message"><![CDATA[
Age: 1800
Cache-Control: max-age=600
CDN-Cache-Control: max-age=3600
]]></sourcecode>
        <t>From the CDN's perspective, this response is still fresh after being cached for 30 minutes, while from the standpoint of other caches' standpoint, caches, this response is already stale. See <xref target="AGE-PENALTY" format="default"/> for more discussion.</t>
        <t>When the targeted cache has a strong coherence mechanism (e.g., the origin server has the ability to proactively invalidate cached responses), it is often desirable to mitigate these effects. Some techniques seen in deployments include:</t>
        <ul spacing="normal">
          <li>Removing the Age header field</li>
          <li>Updating the Date header field value to the current time</li>
          <li>Updating the Expires header field value to the current time, plus any Cache-Control: max-age value</li>
        </ul>
        <t>This specification does not place any specific requirements on implementations to mitigate these effects, but definitions of targeted fields can do so.</t>
      </section>
      <section anchor="defining-targeted-fields" numbered="true" toc="default">
        <name>Defining Targeted Fields</name>
        <t>A targeted field for a particular class of cache can be defined by requesting registration in the Hypertext "Hypertext Transfer Protocol (HTTP) Field Name Registry Registry" (<eref target="https://www.iana.org/assignments/http-fields/"/>).</t> target="https://www.iana.org/assignments/http-fields/" brackets="angle"/>).</t>
        <t>Registration requests can use this document as the specification document, document; in which case case, the Comments field should clearly define the class of caches that the targeted field applies to. Alternatively, if other documentation for the field has been created, it can be used as the specification document.</t>
        <t>By convention, targeted fields have the suffix "-Cache-Control": "-Cache-Control", e.g., "ExampleCDN-Cache-Control". However, this suffix MUST NOT <bcp14>MUST NOT</bcp14> be used on its own to identify targeted fields; it is only a convention.</t>
      </section>
    </section>
    <section anchor="cdn-cache-control" numbered="true" toc="default">
      <name>The CDN-Cache-Control Targeted Field</name>
      <t>The CDN-Cache-Control response header field is a targeted field (<xref target="targeted" format="default"/>) that allows origin servers to control the behaviour behavior of CDN caches interposed between them and clients, clients separately from other caches that might handle the response.</t>
      <t>It applies to caches that are part of a distributed network that operate on behalf of an origin server (commonly called a Content Delivery Network or CDN).</t>
      <t>CDN caches that use CDN-Cache-Control will typically forward this header so that downstream CDN caches can use it as well. However, they MAY <bcp14>MAY</bcp14> remove it when this is undesirable (for example, when configured to do so because it is known not to be used downstream).</t>
      <section anchor="examples" numbered="true" toc="default">
        <name>Examples</name>
        <t>For example, the following header fields would instruct a CDN cache (i.e., a cache with a target list of <tt>[CDN-Cache-Control]</tt>) to consider the response fresh for 600 seconds, other shared caches to consider the response fresh for 120 seconds, and any remaining caches to consider the response fresh for 60 seconds:</t>
        <sourcecode type="http-message"><![CDATA[
Cache-Control: max-age=60, s-maxage=120
CDN-Cache-Control: max-age=600
]]></sourcecode>
        <t>These header fields would instruct a CDN cache to consider the response fresh for 600 seconds, while all other caches would be prevented from storing it:</t>
        <sourcecode type="http-message"><![CDATA[
CDN-Cache-Control: max-age=600
Cache-Control: no-store
]]></sourcecode>
        <t>Because CDN-Cache-Control is not present, this header field would prevent all caches from storing the response:</t>
        <sourcecode type="http-message"><![CDATA[
Cache-Control: no-store
]]></sourcecode>
        <t>Whereas these would prevent all caches except for CDN caches from storing the response:</t>
        <sourcecode type="http-message"><![CDATA[
Cache-Control: no-store
CDN-Cache-Control: none
]]></sourcecode>
        <t>(note
        <t>(Note that 'none' is not a registered cache directive; it is here to avoid sending a header field with an empty value, which would be ignored)</t> ignored.)</t>
      </section>
    </section>
    <section anchor="iana-considerations" numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>Please register
      <t>IANA has registered the following entry in the Hypertext "Hypertext Transfer Protocol (HTTP) Field Name Registry Registry" defined by <xref target="HTTP" format="default"/>:</t>
      <ul spacing="normal">
        <li>Field Name: CDN-Cache-Control</li>
        <li>Status: permanent</li>
        <li>Specification Document: [this document]</li>
        <li>Comments: Cache
      <dl spacing="compact">
        <dt>Field Name:</dt>
        <dd>CDN-Cache-Control</dd>
        <dt>Status:</dt>
        <dd>permanent</dd>
        <dt>Specification Document:</dt>
        <dd>RFC 9213</dd>
        <dt>Comments:</dt>

        <dd>Cache directives targeted at Content Delivery Networks</li>
      </ul> content delivery networks</dd>
       </dl>
    </section>
    <section anchor="security-considerations" numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>The security considerations of HTTP caching <xref target="HTTP-CACHING" format="default"/> apply.</t>
      <t>The ability to carry multiple caching policies on a response can result in confusion about how a response will be cached in different systems, potentially resulting in unintentional reuse of responses with sensitive information. For this reason, care must be exercised.</t>
    </section>
  </middle>
  <back>

    <displayreference target="RFC8941" to="STRUCTURED-FIELDS"/>
    <references>

      <name>References</name>
      <references>
        <name>Normative References</name>

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

<reference anchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner">
              <organization/>
            </author>
            <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="HTTP"> anchor='HTTP' target="https://www.rfc-editor.org/info/rfc9110">
<front>
<title>HTTP Semantics</title>
<author fullname="Roy T. Fielding">
              <organization>Adobe</organization> initials='R' surname='Fielding' fullname='Roy Fielding' role="editor">
<organization />
</author>
<author fullname="Mark Nottingham">
              <organization>Fastly</organization> initials='M' surname='Nottingham' fullname='Mark Nottingham' role="editor">
<organization />
</author>
<author fullname="Julian Reschke">
              <organization>greenbytes GmbH</organization> initials='J' surname='Reschke' fullname='Julian Reschke' role="editor">
<organization />
</author>
<date day="12" month="September" year="2021"/>
            <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.

   This document updates RFC 3864 and obsoletes RFC 2818, RFC 7231, RFC
   7232, RFC 7233, RFC 7235, RFC 7538, RFC 7615, RFC 7694, and portions
   of RFC 7230.

              </t>
            </abstract> year='2022' month='June' />
</front>
 <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-semantics-19"/> name='STD' value='97'/>
 <seriesInfo name='RFC' value='9110'/>
  <seriesInfo name='DOI' value='10.17487/RFC9110'/>
</reference>

<reference anchor="HTTP-CACHING"> anchor='HTTP-CACHING' target="https://www.rfc-editor.org/info/rfc9111">
<front>
<title>HTTP Caching</title>
<author fullname="Roy initials='R' surname='Fielding' fullname='Roy T. Fielding">
              <organization>Adobe</organization>
            </author>
            <author fullname="Mark Nottingham">
              <organization>Fastly</organization>
            </author>
            <author fullname="Julian Reschke">
              <organization>greenbytes GmbH</organization>
            </author>
            <date day="12" month="September" year="2021"/>
            <abstract>
              <t>   The Hypertext Transfer Protocol (HTTP) is a stateless application-
   level protocol for distributed, collaborative, hypertext information
   systems.  This document defines HTTP caches and the associated header
   fields that control cache behavior or indicate cacheable response
   messages.

   This document obsoletes RFC 7234.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-cache-19"/>
        </reference>
        <reference anchor="STRUCTURED-FIELDS">
          <front>
            <title>Structured Field Values for HTTP</title>
            <author fullname="M. Nottingham" initials="M." surname="Nottingham">
              <organization/> Fielding' role="editor">
<organization />
</author>
<author fullname="P-H. Kamp" initials="P-H." surname="Kamp">
              <organization/> initials='M' surname='Nottingham' fullname='Mark Nottingham' role="editor">
<organization />
</author>
            <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="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
<author fullname="B. Leiba" initials="B." surname="Leiba">
              <organization/> initials='J' surname='Reschke' fullname='Julian Reschke' role="editor">
<organization />
</author>
<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> year='2022' month='June' />
</front>
 <seriesInfo name="BCP" value="14"/> name='STD' value='98'/>
 <seriesInfo name="RFC" value="8174"/> name='RFC' value='9111'/>
  <seriesInfo name="DOI" value="10.17487/RFC8174"/> name='DOI' value='10.17487/RFC9111'/>
</reference>

<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8941.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>

</references>
      <references>
        <name>Informative References</name>

        <reference anchor="AGE-PENALTY" target="https://dl.acm.org/doi/10.5555/1251440.1251447">
          <front>
            <title>The age penalty and its effect on cache performance</title>
            <author initials="E." surname="Cohen" fullname="Edith Cohen">
              <organization>AT&amp;T Labs - Research</organization>
            </author>
            <author initials="H." surname="Kaplan" fullname="Haim Kaplan">
              <organization>School of Computer Science, Tel-Aviv University</organization>
            </author>
            <date year="2001" month="March"/>
          </front>
        </reference>
      </references>
    </references>

  </back>
  <!-- ##markdown-source:
H4sIADD17WEAA61ba28bx5L9Pr+iVwbWUsChJNvJTWhcwIokx8LasteSYRi+
QW5zpkk2PK87PSOKKyi/fU9V9TxJ+SrYDRKT5kx3V9fj1KnqThiGQWWrxMzU
tS6XpjKxenN9/UGd6mhl1GmeVWWeBHEeZTrFS3GpF1VoTbUIV1VVzK0LKz8u
jGhIGMmQ8OhFEOsKQ+4u33++DyJ8X+blZqZcFQeBLcqZqsraVc+Ojn45ehbo
0uiZOimKxOJVm2dO6SxWH41OwmubmmCdl9+WZV4XMxYw+GY2+CmeBSpUp2eX
/IGlTVapM5PYG1Nu1KWpaBg/g3A2WwaBqzDvHzrJM8i2MS4o7Ex9rfJoovCH
zWLMMFEuL6vSLBy+bVL/pSpthEdRnhbaf0nxMh7ZLLGZ+T24MVltIJHqC6pU
tSmw1mdIAgnUb/QMv65yUihp0c0OD+lzvZzm5fIQz1Jtk5lq1Ryul6/Wz+kh
nukyWnXjEusqN5WHhyd4hJ27ww/1HHo87E9A05amyLuhS1ut6vkU2/Cr80do
bqFERxY4TPTcJO6ws3AUyKDQOlebkJ/Djr3nga6rVV6SWbCggmrcTF1N1ds6
thn/Io50VZliZbLe79iAzuz/sPHhCd80lMAPjGjDJfTqK/5TVNFb4d1UXeZV
Bf2udNpb5p0uv42fDBd6rV2VbPhBkcM5khl/V/CZD6VelVqki/Iafg33PYHP
ljqxui9bmuXVK/pjmpmKH9Sl7TS9Xq+nzdPDgdxfpupz3ZP3Sx2RVvxvQ0lP
k7yOFwkiZbC0ebXhQeuaFw+yvEwx4oYd8ePr02fHx7/QV3LGmboIz6aD8HWY
J6ts5Pwr4enJ6ZuLy992vMoBjteurj9+Or3+9PH8LHx9cf727GpG6/z8y4tj
BHa26K9/8tt5+OH88uTt9RfRq/hKp5o4meooZe+Nc3t4fDT9Ef8cHj/78fjF
i6OpfP5NhnqcAi7ppVGFyXRSbRgmbOWUWSxMVKk8UywnnpcsShaJvgSN3lH4
KIDOMf/Yeitb3Fve2+Z8CkSBYttfxUTnMUJg9GRoqL2T6/+8Vm/13MGJPhpn
aM299mVvOEPzvCr946muKgrFnZK8mar/0kWix6K80TYdPxmKchWt8jxR+QIC
p0VdmRI/WQOdTNS1ScKTG3ujPmUEl85Wm7GMKyzw7RXMuZpWuoalpjYJgiAM
Q4XdIQ4iONz1yjrlChPZhcduFZsFABEQjrjJgIr8I6whuQV7LgAvRq2MjiHR
wpokdqpa6UrpJMnX3oKxLWFRAjRAs5qbFmgUXmwWlHcd9q2iRDtHXxf+x6m6
oBld3goE1FcO4TJYejKY+KEsovaRZg6amUUJqY3jxATBE3VBWS+uI9opNPQu
x+ykhyLJN5wlSCrefb7A9KrG9tM6qWyRGJXoDfTfyA2omqrX2I+51SkeT6DG
tZnDPhhil6uKB2uvJCi2oo/SLm2mnCkhM8WDSRYv8elHiCB+EGUhXhLexYMd
vEllfpvabU846WaitUmLkC/NS/Oguhzryx14s5ZkTkqh85r0XK2QBZervK54
MWgP6jJIqhLNfq25yWC3Si3KPFXzMl9DmnYHkHNtkgSW+NVEmsTCm9Z5/cbG
2VLPoVy4jucktJQjOYAUJcm85TDYbqFLAEWyIQ4AraRGZ/yCuAgtvOWcmjeR
0uKZiYxzutyMLGgX0H1BWdmtsIeVpthITbRCrLqUZLTZDbIKgRRrJBK18tKN
qVmT2KSMLk0iRGllC7UmTNpnz+aHUL0MOpjQdJtWoWI0AA2isWL9QAV2mbFG
5eESWod1XKvpIgeZ2LCQsNB6ZTHKVTZJ1JpSB97AIwQ1EySWfm5W+sZCAZA+
r1beahw2BN8dwww9w9yNCWpf4jYmR727uzIcXurH6bMmmppsdX9/QOpf2xim
Ix+NSSaxUbuPRqqpepOvTePWGCaqvOGhWeseFraIXzb7JWfYsvy+mS6n8JQw
1bfISQfs530w0T2cImfrudo+4WEzEnOsMDb2Dw8mPX8jt8or8giHCIJgEFPf
AJ/FfFGZY17gJrwNz3d6aCMn6I0JeUNhaRp/O5gqhnD8W5Q55qT0DTpsWHRM
vGkwIavTuSl7OKU6skicdw0uTMx6Kf44HFLkFSs18VsjZ7girVoKEcJIz/th
JKMaw+sYRDlqI7gNGU4JOWwY0RSVyA9OOlFzwRRL6AZUycED9NwmyG60Q2SX
KVypsdH9fS9XcWmgyxh4A0BkMCQbtfYUtTai1I4UsCuhOYGxu7sozoZVUW+5
USaasbYQtuEj4gKaC548IV7LKoNKT9s06yTEUB4pqo+c2nv36ep6byKf6vI9
f/94/t+fLkDg6PvVm5O3b9svzRtXb95/envWfZPfA4w8ff/u3fnlmQzGr2r0
07uTL3uigb33H64v3oP97Ummgf5RSdZka4kUzupspqKUkHEBkDtCmpCg//X0
gzp+AVX+h2ey0KD85efjv73AX9agYbJYnsFR5a+MeLoowKxoEoqNSBcW3k+m
cYFb5esMGi0Na7IrfYe6fyMqfy305O5J6zRBcPKYMWqflkDBTEiz17oRm3CP
8Upn32FEgvcrH3uco1uy3kTko0D07q4PlRPVw1Hg5hANJbfEDCSATpmB2KbP
PoBHKuVlddkSBwkx8DHsQLm9JDgLgj///JOJf5hSklyaYMvfUc/o2xCP/v7T
Eb2OgoLkGerOUwrqFQg1/HcchIyuBqlkR2T6oLraAIhuEUSDJR3765llxSG9
o34tQfZqgmzvH/tdgnouCWqrTmJtn2NZ4FgDixWrrJ235xSiztamrV77K8GE
DyTDLOJKuQfRO6aC1NAMEHKYXafPd0zJFbZ3A8mJ1UhFwrwYvjuPZXWS/oeu
KkMmLRkDbSLLmLLMiR5lcUKyE/uSFQVt9WgWkDWihGBsxDHwIoJ9h2n8axEe
W8/Tza7sgPzhenxym+jBBygV91wJc6Sc1V23KpKq5qaPawhGSwvJW1Nd+ASF
DFzzvvEraQwuDYlKyySQxk//Hetp08lI1mZqQVhjWT8o2bi5pdW/6pz6NcTY
suWEuDwEzr+ZbOrLOaG9rPntWkxg6YZ0Iesg3QNiiVwS6DL10upXFJ5kvkFc
PJ/+9HBkfKbWB+lBJuXIH0kKde5a64ofj5d6/tBSkjAoV3j7+N1387ONaOZr
+n088YvvTczFzBLqHg06fmiQqP8MXCtFJh+NehBIJlTTmYxD3NeAvmZoUIW1
OMRgTo0NxH4HUUTYMaZwbuAQ4v3x/C/hBLAO1Q1bk/y4axKdrPXG+Twz9z6C
2PHyimkwp7jd1pwvHhTMe4332axxenjKYBVWtrgTK0xbX/tQO1eHqB9sagnU
qLNKi3UpkLDhYkRWG1IlVRMFbhN5JAeqjcRXdFSfZoA6JvkYWZVYmeo7b7th
lD113nzwJoIv5Pw60eWkkdwvsl7lmHdhS4gKYkz9GKrqpWDQSbHSc9QQEW16
74c9EXZuWlmJb/WBS8KIet2551Ae8FLoQlMgUKqXgk7waVshHVvkbYLs/UWN
bPU+ZBquhAZreVPnqAGYvjduzbUHOIwPKA8mhLE9513nNazKFWGvIwAGyUlE
tjgqTCZdCYP3KEWwTA+mkQ+ayoiKOjuwqoFV4647OcoqngkvMwRSPEEVmhgq
FitpFvhsCLuaWzogsSSoLywNVQMXi22SRMRXLbFCL/HTDGlRbTzkU15kisBZ
lx5m3Oc2LASrV+ZqHMcLqOabntPu26mZMnSKOpmcWsEgGb423o8KandSCkrs
N6q2F1AlV+Y6+sYFXdcrCHeUfH74gadqckb1q6/qiZT3+ySN8ZwUHsMGZUqu
hv/Ib/7wNJYC/g8VkpegcCIdtBjQkd1WvQwIbUumpjYSBcewZzLpCmGeEpZY
JGR3eqOE0OQw3N1Kc+cpbdR0rYBZrppyv7snYdfJWdhb9hVQG1LWwi5r7nix
cbsQL3jZf8Enq37OqAuPPEMvH+eLXivJr+zqoshLSJBTG3yrYCX41k0B0jY/
mOBQc/XscqLOZfKtsT1tASMIyajALy3Ly96Ul6kpqavrBippgllKjECprw8v
sfXT71JnMPnQj/cgH9LSifPhxeL3m6PedQblmDhOnnHJ1NvFpBdSHG/OkKv4
MCKE3ye+2ds2u9RBE2OCetzUmSDYspAj3cMfWUVapK7Jk9QUJ/YK+tiu3Ov2
ceejV39IYmbBBAV21J/0xvltAWhzo96+9WjdzeYhTijkLpGJlrVdLo4Rdgxq
gcXD2eGzXWnCpsqjqC5ZyZ11wvkmbC011866l4RSEGBYjLEFng4dzLoOulhc
z1K8xJPWcQjQ3C4429XB0o4D03pE5aJvWKtzVTquRNuGOiFq3jrtSOSWmNBy
y5YXyYu+E1qXPasCUQpqh7fNeSx9Kq1KX4GZ7SQj/tAEipR9bY/CK3SR05nO
rr4k4vWHJm3Tt9pVvb4kfmm4pXyV88cfCDlv6Hnwui5JwxRqvunj2UcnUd8E
/bJ3V308fuug8ShM3KCePzF5XJPueqAO0nRBsBFTudt2gvticc4eqViXvXKa
2z45M6ehDFtEsaXlAz6dgsW1RMlmzFtoafGDOoMk+RLeidU7vYy4iicBlIQp
C/PZjRaOziDEfvwaOlmhMHVB0DYzSNtC1Yl1UHZBLgqrPMQHItwPAHKChKud
nf8Xu2pgXzjqOLa+G9qbqxdthMfZoHeOEO36+s63rnWTLaFOOlRZ9NOhcL5R
40POWJqGs6iCan6pTuc0P/J+zayRmvjMLbYMpseNZkm3TFBJMPKrdl+JXYDY
UyIZ7MZWff4q25p0VLXiHdOJXuuyDZxIs1TEhZOmmioCCLxPuycOadPUxJaP
xg7kIEGSOjnjcLnMLJvTFMtXZbrQNwvkTzp+3mzzjDaI2G0ZEbfJx9yI/HFH
FTp48d33XY3Gk6WZqeOfj46CB9uNR9/rRj6n58wTXjeZCG8/5d4Z8QKJIc49
fbItp2RsNsV9YGyg1UbMOfb5EbaW1RVpTtpqnOv6Kn0qJxNFbrNqxyI6KbHx
jRhlqq6MQcT0Ll7c3/NCTEhi66LaOSF6bb9l5Hg+RqEBrpFX0p/rHVf646Tt
c+emWd3UQvCQosx11LhDd8bpNdC64cHk4eNb1ON22RWNctEDdSKfHlWQKrMU
sBCC/HR46i44bzjTfDRpftNwSXjEAK7x/FMB0ZrnZ7TggLi1vIlZQl3yETIF
4XjoLgr08GiUlUlN2WGjdjufDN19zyI3UusXiY4Mz9FSbk8t/OWDbOuY7UHF
yhEa46+VV9vj746EUIclJvj0tdgZvw4FtGxFeq9UlY0S2qKpPT30jU5Geep5
dwIIHPCATNOXZknXCGT7Phm/2SAKK+QrdV3qzKGUVx/KvMojpOZ9yhUH/jzm
klLoR5kB0Pb19/3+DS2rM80XkeREnBUnV+Jkz4cHVHh+7AvgBRN1EEEanXH5
o5uRzeQpXRukiI9WGO08nfZXCr2m3IoLmwiVYInwEY2IA40OkxuiskUe2kOS
qTpJ6JKFh2a+kiAg0wik21s6XeVOAT2nsIqAMRWVm7ZqDMSn7N/dIvXSN70r
QJMtN+oOC2qkhlu1NwTgvZkSqNl7qKDb6x1fSZUmE7X0txHUF1x08EeJkq55
2sVmLNDLBoWYKPRE9weFO89ohy6v7p5sny4JF3zk8a7adea13z+0bm7VUOZz
Qwx2owsvHdfnW2BNPnX+2DUn3cxNtTaSC1ImghGchm+2dvdhttOSyNCwlCxO
zKBgpLbU4JSuP4rIGCGAXG/p3wxqriHxa8JP+ZITbSNZ8PvZKOvsU+uWLRZB
I+SUD1/ignfTNS6qbTpVtPXNtoH4NKDaFDbirh+iY003BNjVmiaH723E8C3s
w+i0r+YGGWzV3ljqeyxKi3cnX6A0pCZ+aS1JWe5j1FmXCIdElF9ruj7+tgvB
MfTUvwz1LSOHpwwh1I5DoRO06aT56HI7DgvG9KqJXOm52EzaxwOq5huCTU3s
OxODzsVC/fPrdifmnwfeeZkjD7zJkyjSAagYLI+36PxQHHJweeYxcxw/683B
LauM0kzqTwMeP9FP7Tw7z7cfIpvdnaG/Q5Tvn4N74nnNOfrRRvirihTuSVcl
BjHetNaoKCAoJDwiICCSLjXFXz7X3+LgbZXP+2xOX7dj0Z9rtJ2YfhD6JhhL
60X19z54GwOZ++p4hNWG4n3mOx3OU6YHFzS3kSnkakQPDP5fxNih3CzPvHj7
WdsJe0q/Pm1Pgzx1Mm2gdHV9k/Voa3zseZNbsA/fKdYjHXM4Z6rXq5t4HtM6
i28RHHDSvDi5PCFAZl/U/o7SB+pum1amEdQYumv/f6N3QY8/SlPt/p6rgO7d
2baP4fkViFDtZlTZpTqDJPTbgN6ceXozU//4OiB8//gd7zYcbubPJ/on54+4
ZuxYZ1cGJQJVUGO9SUvJP4wGD9sbxk2vZdxL5GS88X2pXokW6RLrt7eRB41g
a0ZtVE5o+AveJgNRCqq5S6TndJt3la+HHXE5rPflHhVn7e1bt4Hl09Gxmsws
B2tIf5aVJF2d0vDd40Wvd8G+6KhNxcfY7f98AL7Gp4i+VtaOuCd1YbjHyFci
bk0ZUZ9r6u+zU882CP4Xm4ttLhA1AAA=

-->
</rfc>