<?xml version="1.0" encoding="UTF-8"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
  <!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.2.12 -->

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>

<?rfc toc="yes"?>
<?rfc tocindent="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<?rfc strict="yes"?>
<?rfc compact="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>

<rfc ipr="trust200902" docName="draft-ietf-httpbis-variants-06" category="std" updates="7234">

  <front>
    <title>HTTP Representation Variants</title>

    <author initials="M." surname="Nottingham" fullname="Mark Nottingham">
      <organization>Fastly</organization>
      <address>
        <email>mnot@mnot.net</email>
        <uri>https://www.mnot.net/</uri>
      </address>
    </author>

    <date />

    <area>Applications and Real-Time</area>
    <workgroup>HTTP</workgroup>
    <keyword>content negotiation</keyword>

    <abstract>


<t>This specification introduces an alternative way to select a HTTP response from a cache based upon its request headers, using the HTTP “Variants” and “Variant-Key” response header fields. Its aim is to make HTTP proactive content negotiation more cache-friendly.</t>



    </abstract>


    <note title="Note to Readers">


<t><spanx style="emph">RFC EDITOR: please remove this section before publication</spanx></t>

<t>Discussion of this draft takes place on the HTTP working group mailing list
(ietf-http-wg@w3.org), which is archived at <eref target="https://lists.w3.org/Archives/Public/ietf-http-wg/">https://lists.w3.org/Archives/Public/ietf-http-wg/</eref>.</t>

<t>Working Group information can be found at <eref target="https://httpwg.github.io/">https://httpwg.github.io/</eref>; source code and issues list
for this draft can be found at <eref target="https://github.com/httpwg/http-extensions/labels/variants">https://github.com/httpwg/http-extensions/labels/variants</eref>.</t>

<t>There is a prototype implementation of the algorithms herein at <eref target="https://github.com/mnot/variants-toy">https://github.com/mnot/variants-toy</eref>.</t>


    </note>


  </front>

  <middle>


<section anchor="introduction" title="Introduction">

<t>HTTP proactive content negotiation (<xref target="RFC7231"/>, Section 3.4.1) is seeing renewed interest, both for existing request headers like Accept-Language and for newer ones (for example, see <xref target="I-D.ietf-httpbis-client-hints"/>).</t>

<t>Successfully reusing negotiated responses that have been stored in a HTTP cache requires establishment of a secondary cache key (<xref target="RFC7234"/>, Section 4.1). Currently, the Vary header (<xref target="RFC7231"/>, Section 7.1.4) does this by nominating a set of request headers. Their values collectively form the secondary cache key for a given response.</t>

<t>HTTP’s caching model allows a certain amount of latitude in normalising those request header field values, so as to increase the chances of a cache hit while still respecting the semantics of that header. However, normalisation is not formally defined, leading to infrequent implementation in cache, and divergence of behaviours when it is.</t>

<t>Even when the headers’ semantics are understood, a cache does not know enough about the possible alternative representations available on the origin server to make an appropriate decision.</t>

<t>For example, if a cache has stored the following request/response pair:</t>

<figure><artwork type="example"><![CDATA[
GET /foo HTTP/1.1
Host: www.example.com
Accept-Language: en;q=0.5, fr;q=1.0

]]></artwork></figure>
<figure><artwork type="example"><![CDATA[
HTTP/1.1 200 OK
Content-Type: text/html
Content-Language: en
Vary: Accept-Language
Transfer-Encoding: chunked

[English content]
]]></artwork></figure>

<t>Provided that the cache has full knowledge of the semantics of Accept-Language and Content-Language, it will know that an English representation is available and might be able to infer that a French representation is not available. But, it does not know (for example) whether a Japanese representation is available without making another request, incurring possibly unnecessary latency.</t>

<t>This specification introduces the HTTP Variants response header field (<xref target="variants"/>) to enumerate the available variant representations on the origin server, to provide clients and caches with enough information to properly satisfy requests – either by selecting a response from cache or by forwarding the request towards the origin – by following the algorithm defined in <xref target="cache"/>.</t>

<t>Its companion Variant-Key response header field (<xref target="variant-key"/>) indicates the applicable key(s) that the response is associated with, so that it can be reliably reused in the future. Effectively, it allows the specification of a request header field to define how it affects the secondary cache key.</t>

<t>When this specification is in use, the example above might become:</t>

<figure><artwork type="example"><![CDATA[
GET /foo HTTP/1.1
Host: www.example.com
Accept-Language: en;q=0.5, fr;q=1.0

]]></artwork></figure>
<figure><artwork type="example"><![CDATA[
HTTP/1.1 200 OK
Content-Type: text/html
Content-Language: en
Vary: Accept-Language
Variants: Accept-Language;de;en;jp
Variant-Key: en
Transfer-Encoding: chunked

[English content]
]]></artwork></figure>

<t>Proactive content negotiation mechanisms that wish to be used with Variants need to define how to do so explicitly; see <xref target="define"/>. As a result, it is best suited for negotiation over request headers that are well-understood.</t>

<t>Variants also works best when content negotiation takes place over a constrained set of representations; since each variant needs to be listed in the header field, it is ill-suited for open-ended sets of representations.</t>

<t>Variants can be seen as a simpler version of the Alternates header field introduced by <xref target="RFC2295"/>; unlike that mechanism, Variants does not require specification of each combination of attributes, and does not assume that each combination has a unique URL.</t>

<section anchor="notational-conventions" title="Notational Conventions">

<t>The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”,
“RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” 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>

<t>This specification uses the Augmented Backus-Naur Form (ABNF) notation of <xref target="RFC5234"/> but relies on Structured Headers from <xref target="I-D.ietf-httpbis-header-structure"/> for parsing.</t>

<t>Additionally, it uses the “field-name” rule from <xref target="RFC7230"/>, “type”, “subtype”, “content-coding” and “language-range” from <xref target="RFC7231"/>, and “cookie-name” from <xref target="RFC6265"/>.</t>

</section>
</section>
<section anchor="variants" title="The “Variants” HTTP Header Field">

<t>The Variants HTTP response header field indicates what representations are available for a given resource at the time that the response is produced, by enumerating the request header fields that it varies on, along with a representation of the values that are available for each.</t>

<t>Variants is a Structured Header Dictionary (Section 3.2 of <xref target="I-D.ietf-httpbis-header-structure"/>). Its ABNF is:</t>

<figure><artwork type="abnf"><![CDATA[
Variants        = sh-dict
]]></artwork></figure>

<t>Each member-name represents the field-name of a request header that is part of the secondary cache key; each member-value is an inner-list of strings or tokens that convey representations of potential values for that header field, hereafter referred to as “available-values”.</t>

<t>If Structured Header parsing fails or a member’s value does have the structure outlined above, the client MUST treat the representation as having no Variants header field.</t>

<t>Note that an available-value that is a token is interpreted as a string containing the same characters, and vice versa.</t>

<t>So, given this example header field:</t>

<figure><artwork type="example"><![CDATA[
Variants: Accept-Encoding=(gzip)
]]></artwork></figure>

<t>a recipient can infer that the only content-coding available for that resource is “gzip” (along with the “identity” non-encoding; see <xref target="content-encoding"/>).</t>

<t>Given:</t>

<figure><artwork type="example"><![CDATA[
Variants: accept-encoding=()
]]></artwork></figure>

<t>a recipient can infer that no content-codings (beyond identity) are supported. Note that as always, field-name is case-insensitive.</t>

<t>A more complex example:</t>

<figure><artwork type="example"><![CDATA[
Variants: Accept-Encoding=(gzip br), Accept-Language=(en fr)
]]></artwork></figure>

<t>Here, recipients can infer that two content-codings in addition to “identity” are available, as well as two content languages. Note that, as with all Structured Header dictionaries, they might occur in the same header field or separately, like this:</t>

<figure><artwork type="example"><![CDATA[
Variants: Accept-Encoding=(gzip brotli)
Variants: Accept-Language=(en fr)
]]></artwork></figure>

<t>The ordering of available-values is significant, as it might be used by the header’s algorithm for selecting a response (in this example, the first language is the default; see <xref target="content-language"/>).</t>

<t>The ordering of the request header fields themselves indicates descending application of preferences; in the example above, a cache that has all of the possible permutations stored will honour the client’s preferences for Accept-Encoding before honouring Accept-Language.</t>

<t>Origin servers SHOULD consistently send Variant header fields on all cacheable (as per <xref target="RFC7234"/>, Section 3) responses for a resource, since its absence will trigger caches to fall back to Vary processing.</t>

<t>Likewise, servers MUST send the Variant-Key response header field when sending Variants, since its absence means that the stored response will not be reused when this specification is implemented.</t>

<t><spanx style="emph">RFC EDITOR: Please remove the next paragraph before publication.</spanx></t>

<t>Implementations of drafts of this specification MUST implement an HTTP header field named “Variants-##” instead of the “Variants” header field specified by the final RFC, with “##” replaced by the draft number being implemented. For example, implementations of draft-ietf-httpbis-variants-05 would implement “Variants-05”.</t>

<section anchor="vary" title="Relationship to Vary">

<t>This specification updates <xref target="RFC7234"/> to allow caches that implement it to ignore request header fields in the Vary header for the purposes of secondary cache key calculation (<xref target="RFC7234"/>, Section 4.1) when their semantics are implemented as per this specification and their corresponding response header field is listed in Variants.</t>

<t>If any member of the Vary header does not have a corresponding variant that is understood by the implementation, it is still subject to the requirements there.</t>

<t>See <xref target="partial"/> for an example.</t>

<t>In practice, implementation of Vary varies considerably. As a result, cache efficiency might drop considerably when Variants does not contain all of the headers referenced by Vary, because some implementations might choose to disable Variants processing when this is the case.</t>

</section>
</section>
<section anchor="variant-key" title="The “Variant-Key” HTTP Header Field">

<t>The Variant-Key HTTP response header field identifies one or more sets of available-values that identify the secondary cache key(s) that the response it occurs within are associated with.</t>

<t>Variant-Key is a Structured Header List (Section 3.1 of <xref target="I-D.ietf-httpbis-header-structure"/>) whose members are inner-lists of strings or tokens. Its ABNF is:</t>

<figure><artwork type="abnf"><![CDATA[
Variant-Key      = sh-list
]]></artwork></figure>

<t>Each member MUST be an inner-list, and MUST itself have the same number of members as there are members of the representation’s Variants header field. If not, the client MUST treat the representation as having no Variant-Key header field.</t>

<t>Each member identifies a list of available-values corresponding to the header field-names in the Variants header field, thereby identifying a secondary cache key that can be used with this response. These available-values do not need to explicitly appear in the Variants header field; they can be interpreted by the algorithm specific to processing that field. For example, Accept-Encoding defines an implicit “identity” available-value (<xref target="content-encoding"/>).</t>

<t>Each inner-list member is treated as identifying an available-value for the corresponding variant-axis’ field-name. Any list-member that is a token is interpreted as a string containing the same characters.</t>

<t>For example:</t>

<figure><artwork type="example"><![CDATA[
Variants: Accept-Encoding=(gzip br), Accept-Language=(en fr)
Variant-Key: (gzip fr)
]]></artwork></figure>

<t>This header pair indicates that the representation has a “gzip” content-coding and “fr” content-language.</t>

<t>If the response can be used to satisfy more than one request, they can be listed in additional members.  For example:</t>

<figure><artwork type="example"><![CDATA[
Variants: Accept-Encoding=(gzip br), Accept-Language=(en fr)
Variant-Key: (gzip fr), ("identity" fr)
]]></artwork></figure>

<t>indicates that this response can be used for requests whose Accept-Encoding algorithm selects “gzip” or “identity”, as long as the Accept-Language algorithm selects “fr” – perhaps because there is no gzip-compressed French representation.</t>

<t>When more than one Variant-Key value is in a response, the first one present MUST correspond to the request that caused that response to be generated. For example:</t>

<figure><artwork type="example"><![CDATA[
Variants: Accept-Encoding=(gzip br), Accept-Language=(en fr)
Variant-Key: (gzip fr), (identity fr), (br fr oops)
]]></artwork></figure>

<t>is treated as if the Variant-Key header were completely absent, which will tend to disable caching for the representation that contains it.</t>

<t>Note that in</t>

<figure><artwork type="example"><![CDATA[
Variant-Key: (gzip  fr)
Variant-Key: ("gzip " fr)
]]></artwork></figure>

<t>The whitespace after “gzip” in the first header field value is excluded by the parsing algorithm, but the whitespace in the second header field value is included by the string parsing algorithm. This will likely cause the second header field value to fail to match client requests.</t>

<t><spanx style="emph">RFC EDITOR: Please remove the next paragraph before publication.</spanx></t>

<t>Implementations of drafts of this specification MUST implement an HTTP header field named “Variant-Key-##” instead of the “Variant-Key” header field specified by the final RFC, with “##” replaced by the draft number being implemented. For example, implementations of draft-ietf-httpbis-variants-05 would implement “Variant-Key-05”.</t>

</section>
<section anchor="cache" title="Cache Behaviour">

<t>Caches that implement the Variants header field and the relevant semantics of the field-names it contains can use that knowledge to either select an appropriate stored representation, or forward the request if no appropriate representation is stored.</t>

<t>They do so by running this algorithm (or its functional equivalent) upon receiving a request:</t>

<t>Given incoming-request (a mapping of field-names to field-values, after being combined as allowed by Section 3.2.2 of <xref target="RFC7230"/>), and stored-responses (a list of stored responses suitable for reuse as defined in Section 4 of <xref target="RFC7234"/>, excepting the requirement to calculate a secondary cache key):</t>

<t><list style="numbers">
  <t>If stored-responses is empty, return an empty list.</t>
  <t>Order stored-responses by the “Date” header field, most recent to least recent.</t>
  <t>Let sorted-variants be an empty list.</t>
  <t>If the freshest member of stored-responses (as per <xref target="RFC7234"/>, Section 4.2) has one or more “Variants” header field(s) that successfully parse according to <xref target="variants"/>:
  <list style="numbers">
      <t>Select one member of stored-responses with a “Variants” header field-value(s) that successfully parses according to <xref target="variants"/> and let variants-header be this parsed value. This SHOULD be the most recent response, but MAY be from an older one as long as it is still fresh.</t>
      <t>For each variant-axis in variants-header:
      <list style="numbers">
          <t>If variant-axis’ field-name corresponds to the request header field identified by a content negotiation mechanism that the implementation supports:
          <list style="numbers">
              <t>Let request-value be the field-value associated with field-name in incoming-request, or null if field-name is not in incoming-request.</t>
              <t>Let sorted-values be the result of running the algorithm defined by the content negotiation mechanism with request-value and variant-axis’ available-values.</t>
              <t>Append sorted-values to sorted-variants.</t>
            </list></t>
        </list>
At this point, sorted-variants will be a list of lists, each member of the top-level list corresponding to a variant-axis in the Variants header field-value, containing zero or more items indicating available-values that are acceptable to the client, in order of preference, greatest to least.</t>
    </list></t>
  <t>Return result of running Compute Possible Keys (<xref target="find"/>) on sorted-variants, an empty list and an empty list.</t>
</list></t>

<t>This returns a list of lists of strings suitable for comparing to the parsed Variant-Keys (<xref target="variant-key"/>) that represent possible responses on the server that can be used to satisfy the request, in preference order, provided that their secondary cache key (after removing the headers covered by Variants) matches. <xref target="check_vary"/> illustrates one way to do this.</t>

<section anchor="find" title="Compute Possible Keys">

<t>This algorithm computes the cross-product of the elements of key-facets.</t>

<t>Given key-facets (a list of lists of strings), and key-stub (a list of strings representing a partial key), and possible-keys (a list of lists of strings):</t>

<t><list style="numbers">
  <t>Let values be the first member of key-facets.</t>
  <t>Let remaining-facets be a copy of all of the members of key-facets except the first.</t>
  <t>For each value in values:
  <list style="numbers">
      <t>Let this-key be a copy of key-stub.</t>
      <t>Append value to this-key.</t>
      <t>If remaining-facets is empty, append this-key to possible-keys.</t>
      <t>Otherwise, run Compute Possible Keys on remaining-facets, this-key and possible-keys.</t>
    </list></t>
  <t>Return possible-keys.</t>
</list></t>

</section>
<section anchor="check_vary" title="Check Vary">

<t>This algorithm is an example of how an implementation can meet the requirement to apply the members of the Vary header field that are not covered by Variants.</t>

<t>Given incoming-request (a mapping of field-names to field-values, after being combined as allowed by Section 3.2.2 of <xref target="RFC7230"/>), and stored-response (a stored response):</t>

<t><list style="numbers">
  <t>Let filtered-vary be the field-value(s) of stored-response’s “Vary” header field.</t>
  <t>Let processed-variants be a list containing the request header fields that identify the content negotiation mechanisms supported by the implementation.</t>
  <t>Remove any member of filtered-vary that is a case-insensitive match for a member of processed-variants.</t>
  <t>If the secondary cache key (as calculated in <xref target="RFC7234"/>, Section 4.1) for stored_response matches incoming-request, using filtered-vary for the value of the “Vary” response header, return True.</t>
  <t>Return False.</t>
</list></t>

<t>This returns a Boolean that indicates whether stored-response can be used to satisfy the request.</t>

<t>Note that implementation of the Vary header field varies in practice, and the algorithm above illustrates only one way to apply it. It is equally viable to forward the request if there is a request header listed in Vary but not Variants.</t>

</section>
<section anchor="example-of-cache-behaviour" title="Example of Cache Behaviour">

<t>For example, if the selected variants-header was:</t>

<figure><artwork type="example"><![CDATA[
Variants: Accept-Language=(en fr de), Accept-Encoding=(gzip br)
]]></artwork></figure>

<t>and the request contained the headers:</t>

<figure><artwork type="example"><![CDATA[
Accept-Language: fr;q=1.0, en;q=0.1
Accept-Encoding: gzip
]]></artwork></figure>

<t>Then the sorted-variants would be:</t>

<figure><artwork type="example"><![CDATA[
[
  ["fr", "en"]         // prefers French, will accept English
  ["gzip", "identity"] // prefers gzip encoding, will accept identity
]
]]></artwork></figure>

<t>Which means that the result of the <xref target="cache" format="title"/> algorithm would be:</t>

<figure><artwork type="example"><![CDATA[
[
  ["fr", "gzip"],
  ["fr", "identity"],
  ["en", "gzip"],
  ["en", "identity"]
]
]]></artwork></figure>

<t>Representing a first preference of a French, gzip’d response. Thus, if a cache has a response with:</t>

<figure><artwork type="example"><![CDATA[
Variant-Key: (fr gzip)
]]></artwork></figure>

<t>it could be used to satisfy the first preference. If not, responses corresponding to the other keys could be returned, or the request could be forwarded towards the origin.</t>

<section anchor="a-variant-missing-from-the-cache" title="A Variant Missing From the Cache">

<t>If the selected variants-header was:</t>

<figure><artwork type="example"><![CDATA[
Variants: Accept-Language=(en fr de)
]]></artwork></figure>

<t>And a request comes in with the following headers:</t>

<figure><artwork type="example"><![CDATA[
Accept-Language: de;q=1.0, es;q=0.8
]]></artwork></figure>

<t>Then sorted-variants in <xref target="cache" format="title"/> is:</t>

<figure><artwork type="example"><![CDATA[
[
  ["de"]         // prefers German; will not accept English
]
]]></artwork></figure>

<t>If the cache contains responses with the following Variant-Keys:</t>

<figure><artwork type="example"><![CDATA[
Variant-Key: (fr)
Variant-Key: (en)
]]></artwork></figure>

<t>Then the cache needs to forward the request to the origin server, since Variants indicates that “de” is available, and that is acceptable to the client.</t>

</section>
<section anchor="variants-that-dont-overlap-the-clients-request" title="Variants That Don’t Overlap the Client’s Request">

<t>If the selected variants-header was:</t>

<figure><artwork type="example"><![CDATA[
Variants: Accept-Language=(en fr de)
]]></artwork></figure>

<t>And a request comes in with the following headers:</t>

<figure><artwork type="example"><![CDATA[
Accept-Language: es;q=1.0, ja;q=0.8
]]></artwork></figure>

<t>Then sorted-variants in <xref target="cache" format="title"/> are:</t>

<figure><artwork type="example"><![CDATA[
[
  ["en"]
]
]]></artwork></figure>

<t>This allows the cache to return a “Variant-Key: en” response even though it’s not in the set the client prefers.</t>

</section>
</section>
</section>
<section anchor="origin" title="Origin Server Behaviour">

<t>Origin servers that wish to take advantage of Variants will need to generate both the Variants (<xref target="variants"/>) and Variant-Key (<xref target="variant-key"/>) header fields in all cacheable responses for a given resource. If either is omitted and the response is stored, it will have the effect of disabling caching for that resource until it is no longer stored (e.g., it expires, or is evicted).</t>

<t>Likewise, origin servers will need to assure that the members of both header field values are in the same order and have the same length, since discrepancies will cause caches to avoid using the responses they occur in.</t>

<t>The value of the Variants header should be relatively stable for a given resource over time; when it changes, it can have the effect of invalidating previously stored responses.</t>

<t>As per <xref target="vary"/>, the Vary header is required to be set appropriately when Variants is in use, so that caches that do not implement this specification still operate correctly.</t>

<t>Origin servers are advised to carefully consider which content negotiation mechanisms to enumerate in Variants; if a mechanism is not supported by a receiving cache, it will “downgrade” to Vary handling, which can negatively impact cache efficiency.</t>

<section anchor="examples" title="Examples">

<t>The operation of Variants is illustrated by the examples below.</t>

<section anchor="single-variant" title="Single Variant">

<t>Given a request/response pair:</t>

<figure><artwork type="example"><![CDATA[
GET /clancy HTTP/1.1
Host: www.example.com
Accept-Language: en;q=1.0, fr;q=0.5

]]></artwork></figure>
<figure><artwork type="example"><![CDATA[
HTTP/1.1 200 OK
Content-Type: image/gif
Content-Language: en
Cache-Control: max-age=3600
Variants: Accept-Language=(en de)
Variant-Key: (en)
Vary: Accept-Language
Transfer-Encoding: chunked
]]></artwork></figure>

<t>Upon receipt of this response, the cache knows that two representations of this resource are available, one with a language of “en”, and another whose language is “de”.</t>

<t>Subsequent requests (while this response is fresh) will cause the cache to either reuse this response or forward the request, depending on what the selection algorithm determines.</t>

<t>So, if a request with “en” in Accept-Language is received and its q-value indicates that it is acceptable, the stored response is used. A request that indicates that “de” is acceptable will be forwarded to the origin, thereby populating the cache. A cache receiving a request that indicates both languages are acceptable will use the q-value to make a determination of what response to return.</t>

<t>A cache receiving a request that does not list either language as acceptable (or does not contain an Accept-Language at all) will return the “en” representation (possibly fetching it from the origin), since it is listed first in the Variants list.</t>

<t>Note that Accept-Language is listed in Vary, to assure backwards-compatibility with caches that do not support Variants.</t>

</section>
<section anchor="multiple-variants" title="Multiple Variants">

<t>A more complicated request/response pair:</t>

<figure><artwork type="example"><![CDATA[
GET /murray HTTP/1.1
Host: www.example.net
Accept-Language: en;q=1.0, fr;q=0.5
Accept-Encoding: gzip, br

]]></artwork></figure>
<figure><artwork type="example"><![CDATA[
HTTP/1.1 200 OK
Content-Type: image/gif
Content-Language: en
Content-Encoding: br
Variants: Accept-Language=(en jp de)
Variants: Accept-Encoding=(br gzip)
Variant-Key: (en br)
Vary: Accept-Language, Accept-Encoding
Transfer-Encoding: chunked
]]></artwork></figure>

<t>Here, the cache knows that there are two axes that the response varies upon; language and encoding. Thus, there are a total of nine possible representations for the resource (including the identity encoding), and the cache needs to consider the selection algorithms for both axes.</t>

<t>Upon a subsequent request, if both selection algorithms return a stored representation, it can be served from cache; otherwise, the request will need to be forwarded to origin.</t>

</section>
<section anchor="partial" title="Partial Coverage">

<t>Now, consider the previous example, but where only one of the Vary’d axes (encoding) is
listed in Variants:</t>

<figure><artwork type="example"><![CDATA[
GET /bar HTTP/1.1
Host: www.example.net
Accept-Language: en;q=1.0, fr;q=0.5
Accept-Encoding: gzip, br

]]></artwork></figure>
<figure><artwork type="example"><![CDATA[
HTTP/1.1 200 OK
Content-Type: image/gif
Content-Language: en
Content-Encoding: br
Variants: Accept-Encoding=(br gzip)
Variant-Key: (br)
Vary: Accept-Language, Accept-Encoding
Transfer-Encoding: chunked
]]></artwork></figure>

<t>Here, the cache will need to calculate a secondary cache key as per <xref target="RFC7234"/>, Section 4.1 – but considering only Accept-Language to be in its field-value – and then continue processing Variants for the set of stored responses that the algorithm described there selects.</t>

</section>
</section>
</section>
<section anchor="define" title="Defining Content Negotiation Using Variants">

<t>To be usable with Variants, proactive content negotiation mechanisms need to be specified to take advantage of it. Specifically, they:</t>

<t><list style="symbols">
  <t>MUST define a request header field that advertises the clients preferences or capabilities, whose field-name SHOULD begin with “Accept-“.</t>
  <t>MUST define the syntax of an available-value that will occur in Variants and Variant-Key.</t>
  <t>MUST define an algorithm for selecting a result. It MUST return a list of available-values that are suitable for the request, in order of preference, given the value of the request header nominated above (or null if the request header is absent) and an available-values list from the Variants header. If the result is an empty list, it implies that the cache cannot satisfy the request.</t>
</list></t>

<t><xref target="backports"/> fulfils these requirements for some existing proactive content negotiation mechanisms in HTTP.</t>

</section>
<section anchor="iana-considerations" title="IANA Considerations">

<t>This specification registers the following entry in the Permanent Message Header Field Names registry established by <xref target="RFC3864"/>:</t>

<t><list style="symbols">
  <t>Header field name: Variants</t>
  <t>Applicable protocol: http</t>
  <t>Status: standard</t>
  <t>Author/Change Controller: IETF</t>
  <t>Specification document(s): [this document]</t>
  <t>Related information:</t>
</list></t>

<t>This specification registers the following entry in the Permanent Message Header Field Names registry established by <xref target="RFC3864"/>:</t>

<t><list style="symbols">
  <t>Header field name: Variant-Key</t>
  <t>Applicable protocol: http</t>
  <t>Status: standard</t>
  <t>Author/Change Controller: IETF</t>
  <t>Specification document(s): [this document]</t>
  <t>Related information:</t>
</list></t>

</section>
<section anchor="security-considerations" title="Security Considerations">

<t>If the number or advertised characteristics of the representations available for a resource are considered sensitive, the Variants header by its nature will leak them.</t>

<t>Note that the Variants header is not a commitment to make representations of a certain nature available; the runtime behaviour of the server always overrides hints like Variants.</t>

</section>


  </middle>

  <back>

    <references title='Normative References'>





<reference  anchor="RFC2119" target='https://www.rfc-editor.org/info/rfc2119'>
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials='S.' surname='Bradner' fullname='S. Bradner'><organization /></author>
<date year='1997' month='March' />
<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="RFC7231" target='https://www.rfc-editor.org/info/rfc7231'>
<front>
<title>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</title>
<author initials='R.' surname='Fielding' fullname='R. Fielding' role='editor'><organization /></author>
<author initials='J.' surname='Reschke' fullname='J. Reschke' role='editor'><organization /></author>
<date year='2014' month='June' />
<abstract><t>The Hypertext Transfer Protocol (HTTP) is a stateless \%application- level protocol for distributed, collaborative, hypertext information systems.  This document defines the semantics of HTTP/1.1 messages, as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.</t></abstract>
</front>
<seriesInfo name='RFC' value='7231'/>
<seriesInfo name='DOI' value='10.17487/RFC7231'/>
</reference>



<reference  anchor="RFC7234" target='https://www.rfc-editor.org/info/rfc7234'>
<front>
<title>Hypertext Transfer Protocol (HTTP/1.1): Caching</title>
<author initials='R.' surname='Fielding' fullname='R. Fielding' role='editor'><organization /></author>
<author initials='M.' surname='Nottingham' fullname='M. Nottingham' role='editor'><organization /></author>
<author initials='J.' surname='Reschke' fullname='J. Reschke' role='editor'><organization /></author>
<date year='2014' month='June' />
<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.</t></abstract>
</front>
<seriesInfo name='RFC' value='7234'/>
<seriesInfo name='DOI' value='10.17487/RFC7234'/>
</reference>



<reference  anchor="RFC8174" target='https://www.rfc-editor.org/info/rfc8174'>
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
<author initials='B.' surname='Leiba' fullname='B. Leiba'><organization /></author>
<date year='2017' month='May' />
<abstract><t>RFC 2119 specifies common key words that may be used in protocol  specifications.  This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the  defined special meanings.</t></abstract>
</front>
<seriesInfo name='BCP' value='14'/>
<seriesInfo name='RFC' value='8174'/>
<seriesInfo name='DOI' value='10.17487/RFC8174'/>
</reference>



<reference  anchor="RFC5234" target='https://www.rfc-editor.org/info/rfc5234'>
<front>
<title>Augmented BNF for Syntax Specifications: ABNF</title>
<author initials='D.' surname='Crocker' fullname='D. Crocker' role='editor'><organization /></author>
<author initials='P.' surname='Overell' fullname='P. Overell'><organization /></author>
<date year='2008' month='January' />
<abstract><t>Internet technical specifications often need to define a formal syntax.  Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications.  The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power.  The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges.  This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='STD' value='68'/>
<seriesInfo name='RFC' value='5234'/>
<seriesInfo name='DOI' value='10.17487/RFC5234'/>
</reference>



<reference anchor="I-D.ietf-httpbis-header-structure">
<front>
<title>Structured Headers for HTTP</title>

<author initials='M' surname='Nottingham' fullname='Mark Nottingham'>
    <organization />
</author>

<author initials='P' surname='Kamp' fullname='Poul-Henning Kamp'>
    <organization />
</author>

<date month='August' day='25' year='2019' />

<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 fields.  It is intended for use by specifications of new HTTP header fields that wish to use a common syntax that is more restrictive than traditional HTTP field values.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-httpbis-header-structure-13' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-httpbis-header-structure-13.txt' />
</reference>



<reference  anchor="RFC7230" target='https://www.rfc-editor.org/info/rfc7230'>
<front>
<title>Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing</title>
<author initials='R.' surname='Fielding' fullname='R. Fielding' role='editor'><organization /></author>
<author initials='J.' surname='Reschke' fullname='J. Reschke' role='editor'><organization /></author>
<date year='2014' month='June' />
<abstract><t>The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems.  This document provides an overview of HTTP architecture and its associated terminology, defines the &quot;http&quot; and &quot;https&quot; Uniform Resource Identifier (URI) schemes, defines the HTTP/1.1 message syntax and parsing requirements, and describes related security concerns for implementations.</t></abstract>
</front>
<seriesInfo name='RFC' value='7230'/>
<seriesInfo name='DOI' value='10.17487/RFC7230'/>
</reference>



<reference  anchor="RFC6265" target='https://www.rfc-editor.org/info/rfc6265'>
<front>
<title>HTTP State Management Mechanism</title>
<author initials='A.' surname='Barth' fullname='A. Barth'><organization /></author>
<date year='2011' month='April' />
<abstract><t>This document defines the HTTP Cookie and Set-Cookie header fields. These header fields can be used by HTTP servers to store state (called cookies) at HTTP user agents, letting the servers maintain a stateful session over the mostly stateless HTTP protocol.  Although cookies have many historical infelicities that degrade their security and privacy, the Cookie and Set-Cookie header fields are widely used on the Internet.  This document obsoletes RFC 2965.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='6265'/>
<seriesInfo name='DOI' value='10.17487/RFC6265'/>
</reference>



<reference  anchor="RFC4647" target='https://www.rfc-editor.org/info/rfc4647'>
<front>
<title>Matching of Language Tags</title>
<author initials='A.' surname='Phillips' fullname='A. Phillips'><organization /></author>
<author initials='M.' surname='Davis' fullname='M. Davis'><organization /></author>
<date year='2006' month='September' />
<abstract><t>This document describes a syntax, called a &quot;language-range&quot;, for specifying items in a user's list of language preferences.  It also describes different mechanisms for comparing and matching these to language tags.  Two kinds of matching mechanisms, filtering and lookup, are defined.  Filtering produces a (potentially empty) set of language tags, whereas lookup produces a single language tag. Possible applications include language negotiation or content selection.  This document, in combination with RFC 4646, replaces RFC 3066, which replaced RFC 1766.  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='47'/>
<seriesInfo name='RFC' value='4647'/>
<seriesInfo name='DOI' value='10.17487/RFC4647'/>
</reference>




    </references>

    <references title='Informative References'>





<reference anchor="I-D.ietf-httpbis-client-hints">
<front>
<title>HTTP Client Hints</title>

<author initials='I' surname='Grigorik' fullname='Ilya Grigorik'>
    <organization />
</author>

<date month='March' day='11' year='2019' />

<abstract><t>HTTP defines proactive content negotiation to allow servers to select the appropriate response for a given request, based upon the user agent's characteristics, as expressed in request headers.  In practice, clients are often unwilling to send those request headers, because it is not clear whether they will be used, and sending them impacts both performance and privacy.  This document defines two response headers, Accept-CH and Accept-CH- Lifetime, that servers can use to advertise their use of request headers for proactive content negotiation, along with a set of guidelines for the creation of such headers, colloquially known as "Client Hints."  It also defines an initial set of Client Hints.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-httpbis-client-hints-07' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-httpbis-client-hints-07.txt' />
</reference>



<reference  anchor="RFC2295" target='https://www.rfc-editor.org/info/rfc2295'>
<front>
<title>Transparent Content Negotiation in HTTP</title>
<author initials='K.' surname='Holtman' fullname='K. Holtman'><organization /></author>
<author initials='A.' surname='Mutz' fullname='A. Mutz'><organization /></author>
<date year='1998' month='March' />
<abstract><t>HTTP allows web site authors to put multiple versions of the same information under a single URL.  Transparent content negotiation is an extensible negotiation mechanism, layered on top of HTTP, for automatically selecting the best version when the URL is accessed.  This enables the smooth deployment of new web data formats and markup tags. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind.  Discussion and suggestions for improvement are requested.</t></abstract>
</front>
<seriesInfo name='RFC' value='2295'/>
<seriesInfo name='DOI' value='10.17487/RFC2295'/>
</reference>



<reference  anchor="RFC3864" target='https://www.rfc-editor.org/info/rfc3864'>
<front>
<title>Registration Procedures for Message Header Fields</title>
<author initials='G.' surname='Klyne' fullname='G. Klyne'><organization /></author>
<author initials='M.' surname='Nottingham' fullname='M. Nottingham'><organization /></author>
<author initials='J.' surname='Mogul' fullname='J. Mogul'><organization /></author>
<date year='2004' month='September' />
<abstract><t>This specification defines registration procedures for the message header fields used by Internet mail, HTTP, Netnews and other applications.  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='90'/>
<seriesInfo name='RFC' value='3864'/>
<seriesInfo name='DOI' value='10.17487/RFC3864'/>
</reference>




    </references>


<section anchor="backports" title="Variants for Existing Content Negotiation Mechanisms">

<t>This appendix defines the required information to use existing proactive content negotiation mechanisms (as defined in <xref target="RFC7231"/>, Section 5.3) with the Variants header field.</t>

<section anchor="content-type" title="Accept">

<t>This section defines variant handling for the Accept request header (section 5.3.2 of <xref target="RFC7231"/>).</t>

<t>The syntax of an available-value for Accept is:</t>

<figure><artwork type="abnf"><![CDATA[
accept-available-value = type "/" subtype
]]></artwork></figure>

<t>To perform content negotiation for Accept given a request-value and available-values:</t>

<t><list style="numbers">
  <t>Let preferred-available be an empty list.</t>
  <t>Let preferred-types be a list of the types in the request-value (or the empty list if request-value is null), ordered by their weight, highest to lowest, as per Section 5.3.2 of <xref target="RFC7231"/> (omitting any coding with a weight of 0). If a type lacks an explicit weight, an implementation MAY assign one.</t>
  <t>For each preferred-type in preferred-types:
  <list style="numbers">
      <t>If any member of available-values matches preferred-type, using the media-range matching mechanism specified in Section 5.3.2 of <xref target="RFC7231"/> (which is case-insensitive), append those members of available-values to preferred-available (preserving the precedence order implied by the media ranges’ specificity).</t>
    </list></t>
  <t>If preferred-available is empty, append the first member of available-values to preferred-available. This makes the first available-value the default when none of the client’s preferences are available.</t>
  <t>Return preferred-available.</t>
</list></t>

<t>Note that this algorithm explicitly ignores extension parameters on media types (e.g., “charset”).</t>

</section>
<section anchor="content-encoding" title="Accept-Encoding">

<t>This section defines variant handling for the Accept-Encoding request header (section 5.3.4 of <xref target="RFC7231"/>).</t>

<t>The syntax of an available-value for Accept-Encoding is:</t>

<figure><artwork type="abnf"><![CDATA[
accept-encoding-available-value = content-coding / "identity"
]]></artwork></figure>

<t>To perform content negotiation for Accept-Encoding given a request-value and available-values:</t>

<t><list style="numbers">
  <t>Let preferred-available be an empty list.</t>
  <t>Let preferred-codings be a list of the codings in the request-value (or the empty list if request-value is null), ordered by their weight, highest to lowest, as per Section 5.3.1 of <xref target="RFC7231"/> (omitting any coding with a weight of 0). If a coding lacks an explicit weight, an implementation MAY assign one.</t>
  <t>If “identity” is not a member of preferred-codings, append “identity”.</t>
  <t>Append “identity” to available-values.</t>
  <t>For each preferred-coding in preferred-codings:
  <list style="numbers">
      <t>If there is a case-insensitive, character-for-character match for preferred-coding in available-values, append that member of available-values to preferred-available.</t>
    </list></t>
  <t>Return preferred-available.</t>
</list></t>

<t>Note that the unencoded variant needs to have a Variant-Key header field with a value of “identity” (as defined in Section 5.3.4 of <xref target="RFC7231"/>).</t>

</section>
<section anchor="content-language" title="Accept-Language">

<t>This section defines variant handling for the Accept-Language request header (section 5.3.5 of <xref target="RFC7231"/>).</t>

<t>The syntax of an available-value for Accept-Language is:</t>

<figure><artwork type="abnf"><![CDATA[
accept-encoding-available-value = language-range
]]></artwork></figure>

<t>To perform content negotiation for Accept-Language given a request-value and available-values:</t>

<t><list style="numbers">
  <t>Let preferred-available be an empty list.</t>
  <t>Let preferred-langs be a list of the language-ranges in the request-value (or the empty list if request-value is null), ordered by their weight, highest to lowest, as per Section 5.3.1 of <xref target="RFC7231"/> (omitting any language-range with a weight of 0). If a language-range lacks a weight, an implementation MAY assign one.</t>
  <t>For each preferred-lang in preferred-langs:
  <list style="numbers">
      <t>If any member of available-values matches preferred-lang, using either the Basic or Extended Filtering scheme defined in Section 3.3 of <xref target="RFC4647"/>, append those members of available-values to preferred-available (preserving their order).</t>
    </list></t>
  <t>If preferred-available is empty, append the first member of available-values to preferred-available. This makes the first available-value the default when none of the client’s preferences are available.</t>
  <t>Return preferred-available.</t>
</list></t>

</section>
<section anchor="cookie" title="Cookie">

<t>This section defines variant handling for the Cookie request header (<xref target="RFC6265"/>).</t>

<t>This syntax of an available-value for Cookie is:</t>

<figure><artwork type="abnf"><![CDATA[
cookie-available-value = cookie-name
]]></artwork></figure>

<t>To perform content negotiation for Cookie given a request-value and available-values:</t>

<t><list style="numbers">
  <t>Let cookies-available be an empty list.</t>
  <t>For each available-value of available-values:
  <list style="numbers">
      <t>Parse request-value as a Cookie header field <xref target="RFC6265"/> and let request-cookie-value be the cookie-value corresponding to a cookie with a cookie-name that matches available-value.
If no match is found, continue to the next available-value.</t>
      <t>append request-cookie-value to cookies-available.</t>
    </list></t>
  <t>Return cookies-available.</t>
</list></t>

<t>A simple example is allowing a page designed for users that aren’t logged in (denoted by the <spanx style="verb">logged_in</spanx> cookie-name) to be cached:</t>

<figure><artwork type="example"><![CDATA[
Variants: Cookie=(logged_in)
Variant-Key: (0)
Vary: Cookie
]]></artwork></figure>

<t>Here, a cache that implements Variants will only use this response to satisfy requests with <spanx style="verb">Cookie: logged_in=0</spanx>. Caches that don’t implement Variants will vary the response on all Cookie headers.</t>

<t>Or, consider this example:</t>

<figure><artwork type="example"><![CDATA[
Variants: Cookie=(user_priority)
Variant-Key: (silver), ("bronze")
Vary: Cookie
]]></artwork></figure>

<t>Here, the <spanx style="verb">user_priority</spanx> cookie-name allows requests from “gold” users to be separated from “silver” and “bronze” ones; this response is only served to the latter two.</t>

<t>It is possible to target a response to a single user; for example:</t>

<figure><artwork type="example"><![CDATA[
Variants: Cookie=(user_id)
Variant-Key: (some_person)
Vary: Cookie
]]></artwork></figure>

<t>Here, only the “some_person” <spanx style="verb">user_id</spanx> will have this response served to them again.</t>

<t>Note that if more than one cookie-name serves as a cache key, they’ll need to be listed in separate Variants members, like this:</t>

<figure><artwork type="example"><![CDATA[
Variants: Cookie=(user_priority), Cookie=(user_region)
Variant-Key: (gold europe)
Vary: Cookie
]]></artwork></figure>

</section>
</section>
<section numbered="false" anchor="acknowledgements" title="Acknowledgements">
<t>This protocol is conceptually similar to, but simpler than, Transparent Content Negotiation <xref target="RFC2295"/>. Thanks to its authors for their inspiration.</t>

<t>It is also a generalisation of a Fastly VCL feature designed by Rogier ‘DocWilco’ Mulhuijzen.</t>

<t>Thanks to Hooman Beheshti, Ilya Grigorik, Leif Hedstrom, and Jeffrey Yasskin for their review and input.</t>

</section>


  </back>

<!-- ##markdown-source:
H4sIAOLCv10AA+VdWZMbN5J+56/AUg9qOki2TnumtZrdtg5LM7pWkj0x4XDY
IAmSsIpVdKHYLbpD89s3L1xVxW7J9nrHu/MwVpNVQCKR+eUJcDKZDBrbFOZE
PXn79pV6bba1caZsdGOrUn2ja6vLxg30bFabs5PBopqXegNPL2q9bCbWNMvJ
umm2M+smZ/Lw5Mbng4Vu4KGLh6dvH30YzOGPVVXvT5RrFoPdFr90J+qLW7fv
DAZ2W5+opt655taNG3++cWuga6NP1Ol2W9g5UeGULhdAmS4mb+3GDM6r+t2q
rnZbpnnwzuzho8WJelo2pi5NM3mIxMXPYRX7+Ne8Kkuzyv5uYMEKPqwaSzMO
Bq6BOb/XRVXCMvbGDbb2RH3bVPOxgv+z5QLeGCtX1U1tlg7+td/IP5razuGr
ebXZavnHBh6Gr2xZ2NJ8NxjoXbOu6pOBmgwU/M+WwIznU/WiahpbrtZ6Qx8z
n5/r+l37m6pe6dL+TKSeqMfaNcWevjAbbYsTtSmr5j/x/6bADPpiVwP5uE/u
5Pj4/Px86r89HgzKqt7AUGcGCFKvHz+4dfPmn09gX8pl/GIwmEwmSs9gdbCo
weDt2jrltmZul7JJsIqmrha7ucHtUrrAraC31bneA9OUM4WZN0qzoIGUbWFr
jVrW1QY+nOv52qiZdmahdlscr3Hw0E874xq1NnphamDhzgEbVANP0iBDL59D
EhH/5+RvZj+MM/DbamlNsXBT9RQG1najYAVA1Ua/k8G2dQVrQ4J7JEJtqtow
kZNlbU25KPZT5gpw0nz/Av+vqb5/zZQOBp8BJ9Wjh0/fvnx9oraFgYUBRZsK
hm+IecALHHdmljjydjfz4v7ZYPDQuvnOOfy+WvLzpG+qAWodDKfnRsGXgRGo
EsgZUguFUoB/FdY1g6Ogo5Pz1X+e356C9IzG6nxt52vkga7na1j0QulG/bsX
EXzTTfnh41N+wh2/IiKP0wGP/wJc+LvM/hXNHgQHCJxrXKFaVrsynwD/e76a
rmyz3s2mtjr+yz3Qpl09R+4vDG2ndQ52n1cBQ6Z8ODiuDAhKJ1PQfybmPWwo
8tMdF3pmCnfswQrpf7s2sAXICxSCpmr2W/hzA7u2CUhI+wB0FQBkMMfGKXzJ
lodmRwULk0yaav8XEZeNXSwKMxhcQ7gijWHE+QgZPLq4+DcQK8DNmx8+jNUb
EaHb0zvTmyNFQmVwH2pTmnPYUYt4CPozVrOqWSvkoXkP3ORnMtUCLoMenM7n
ZttMnulytdMr3gV8C4erQeBgN454FI3cGeOE6uLiP55OHk4zUzAvQEWayRoo
cB8+jGDpb3YwtnPLXVHsYXJWZL84oNVrKyjlGli61sCDmTElACroB67FIwcj
BdJv4SUFi9Aglm6Ne4XbpFG3qnIBoC/PAtQnvLuT8g45N1UPdjXwDFB0TJuM
9sKjxgGefzG9Ob0zUouKCAbWz/YABBuLkAcLQxqImBabpwpkzdbqTBco2vOq
QEyE/QamoNbQ9H3kI9e1WsGTZWDVlIXmuqPncNoNqE4BMlpU5yjMc1M3Ghm3
AT0hcgogr9mBfsGnhPvAOEbUypkWsQyYQiraOqUJMW05rwnOkNb5WpcI+cR3
JndtG0SXAhbS2KIgcnGRAtwOjFTZ2LljldJ+uql6Up2bM1OPA2ViWBxCLLFH
o/AszBLM6GKsAFQXNCrStCTiYZUtvbUlkzUmYV4AA+uVKRE+lyBfIGYWUMcB
wQZNDkwGXH2EXKZPkGDZuusJ5eCiKEAe+LSpKqDEL53EAYl9V1bnypTVbrUG
q1ntGhppWwGmzwqTWcc687hg7DNAb41PCcAD3qxgFc7UQHswWWhjtwAX2xr1
B5gyt4hvQP3jVEFtsi+wfaJMOOyyQjFJoOA4GMyttuCdDP75z3/6gQZfPXqr
jpdVRSp4fHN6c/Ckcs2JQl9CnkHYG7QQ5ASYcO+n+zemd8dg6OFfN6c3aOBs
cD+mAg9Qvfzb4AFj3+Qt4DD4hgDegOKbInyejj5AZT1pI9fgba1LtzT15FEJ
9gRWCX7eele+M4vB4NtH5QoBw2Psd0TQ4FVdndkFcUfzfkW+IWzRphZmsTLe
GGSi3IedbYLHKGLnVsbiiWAjPT25KJBBCsKAw23sat2g3aNPWOxRJGgY9Rgg
bN43CApkGGiqvtw1REcurCmuj1D4YYEIOX/VWw2435bTnLhzsHso5CCZhH4w
Kr4tgoWe7xwQFr8SFdiD+pQGDQLCHKASkL6fXuVXBnfHu339Ph5itre8YHyQ
UabcbUyNikJGPBAuj3WUsE/10PNHA41CotjAcWRCYuKICV7nUx+I39qaGlaN
kOaWe88Zp8AhMJaYBQaEPWS2H7l/zJJY0VMw8rmuFx5PPWg3FX7qUrphcHre
K3rmwHgcRYS8uKAJPnyALUD3mIKXMgkA0aO+ktkTMFTIb4iOcPNkwzQHcsht
+P7IjaJ+hQFRmJyDuIpcAWQk2Rt60AZvrzaF1TNxH5hwArJds6tBrh8tl96W
knyLGSRFzSSKbFWvrYOtYq6oNagEjkFjukNmGX1fNhNdsXVIH9DJLoVoFhoD
wHyvyMBn8wcHWq+KnW/uLcw9oOnH7SCRIRrol2HzZbGZQTfEuo04j+c4AOwl
yAwJCmlmwIzSmPZO418VSpx5j8JqwRO8J74tPwWaoU4dq+WuYPxEpw8lyO0s
Si37yZGo6iwiYPCyGarBezg3RTGJLgQIUqBPF0AIBnQyPjkifcvOgsEzQmt4
DEN00uvggWbQBuuy6P4YkOEAf8gSJxzDcCsqV6oeftVgvybJogHaygkExDyl
65kzXZ3oskPXXiNHHTls4BIDK5JA61RcJONyFQ3mYIHYBrEHZixu/fnuhw/3
wKZQFENMDjIxjjsfLJ4ED11cIK6Aes3IkResaJraznYNOsHkQ/pRALLAqvB0
nRfXtLhdaUEA1NevnwEPBteuYSaHvtcFOgfgZxKDKAQlPx9TUk4Nn3/95u1w
zP9VL17Sv18/+q+vn75+9BD//ebJ6bNn4R/+iTdPXn797GH8F38+gDcfvHz+
/NGLh/wyfKpaHz0//ceQVzd8+ert05cvTp8NWQQw5K7mOwquUHBZSCiyhD1G
GdBusDBuDjxisfnywSt1847iuAmTSR8+yB9/uvkFBF8k0DxZVQKa85+w53u0
FUbXFOuBjzTXW9uANoxxCgd6WlLM3e8m7JzYm9PdCokFWr7U83c7N3mhd7V6
jMHV0emXLx6PcO/C5jJhdykqVLDJZGQMOQBvmhpi8x36y09EfckWwyudeJdF
dOL8KzAYqsZW1xheAcWni4XlfRfrFOgdklxPMNs3VPWuMGEWDjtvYNg5xJQE
bpTbzfw/BRImjKGSASsEfSeAsSsYMB+LQlh6bl5V76yRWZOHPr/1+V1yAwbX
MFRNM2zkeTEn1GPSxYtrwc1iCQ6alqf4WgrsvYNzVJxO+FOn/lkr7OUEkXgP
jfXK1/YltoIQY4QI7/q1/aUsKxhcDVwQbT/wqajgFbIduu39CkhJGB9QPScc
MSGFPkowdaRKPbSUUkDH4iimdG6JdH6EqI04p4nCDXOIP6Fn5TJOLf+7r9x6
Auxv2Ko+QtDamM0MxkNJiKtk0YyS2eszMc8cSnkTQ6KOk3SPwVHmIZYRK9C1
L+ETNDj4OmbOy5VDL7ep3plS+DpHmNx3PfQlxBIo/xagVPaBk4S6aVktBA29
bMgcg9tRs/kHfB6G/WKy3BD932XPHokiqyU8TxRqWc91x5OzVaCsFbHBj6Ag
LCrIHJPnx84gBw+KwL0B2rwEZyKmaTjKklVRsdKVAbGYdg5hZGs1YX8085Nd
0hS30foS08m9AK8h5Ghwy8F+YrKf8u6IGWcWdA+ttMZ0XjUWtSQT4d3blLyW
Y9txFL33d/9o9bPdjlgkUcjmdkv8mZOIhAiXAhs0GDnwtZSuYVARqADShjj6
UB0l6kywa7GEY5v9EPiL/guP5t0+P4f/nJOYX+GKD65L87pMWNfVa4KtzVfj
1NHM7CvMfgt9I0IWt9tuqxq2jcpEfs/RWTzXe9igRFUtOlnOTCygYekses1o
gKSCUSHR7z31n7ZHalaPxm0///4RCMGylrU+AV0bx/W6ziaed1eM5l7MIypm
sjMZpqIbQH4z5SHjOMrbPJfwhh8m7IYXugq98KBr0a0j54ODsmo+39Xe+yU9
yKwXSJgzgAZgwNCQi78ZUPfjGVkBLIwOR085V99STA9UoLwjFLdwi3L/dlWS
O1Ty4sGYhXwRRUFgC6NHf90lmYAlraon93Bkc/0ei1mAoCVwnepomPs0Sw2h
UVuB/GOsQO2FXGaQzQZoOsPFBY8B/UyINIjKWB8mW0DQjoldiHBk97KYOyZp
pb7gSDKEhpCZ3Zp6s/M2RrKllLBbVyVASgLf1106KfGwtde+tsev4getTQaG
vEwzTE6J345hHIZhWJKA7wANRFBaTKq8owzrIgQ8gmXBElR/seP2KCmzsGvl
kXIsYSFWXfXMUYac1g32YbWCESXJBfq5xCln4FvjH1QqAX8LU3ns6T4DlYAA
nIpDvCiyc7SKJvqIl2SUKOB1ss9eQ/oI3BjtvQQ2urRdYVCiHwM1yh1xJuCS
bI2vGxg0rFn59lWrfGsgYH7foFOgV7XernuKuNPPwJPIKhHkslD10oWibk4E
8SmQgRad3OiMN4jwsdDtJteuYZwGoqIXXpYTlz17VSaLSLC0GIbCQseMlEMc
DLwQTCiEh7jeCj70DHOUVF5MOaXyasOBFR/qE7kL8e4OY4Kw6LiyG3eHEjO/
NgWPtwbk9DJHscf+Q38syB0mmRaQy4cZwSDJ5B2FiW1DCfVViRvZD0kCK2l1
kD0O3PkaIITrYH3lu7ku5ruiXcXtVCJD0cnWrWpTwnMlOt4jQZp1DN6eVzXr
wYIrPL2RmEuSPZ7v7AHrci8OrpeqdNUhA0L+rm5N5pNK3v2MWS4vU7mY+LQS
VwshwP0R20SaKhgHW9PDZBMo/H9DFgbDDnD+JdQGbfHpUVhBCZiECcN5Ryhx
PbQWifQIaoFATCy3cny8fWYJ7LVYnxB7uqirbfYa71o3yyROdWpnfB4wGA7i
CdIzxnSwBpBSrtq0WeRk6vm6wjotpiutI8APs0YMTkBOTDO6g92QnrtkLonq
KZ+fBfYE2pfF9uS5LTmCpnoFOZ0+LdhxW1hE+KX9ofjxQMlAXDX28pDL6Cvm
RYQYfBPhB+LvZxh/JpH3zU+IvIHXuCGsKqKpIah1vVHtVcE6kRqjdep+aUfr
bCpmJg+iOUxjK9KA77RM4lF0ZAXEgahAr+gUEe4/DG5ZGo6Ct9MfgypACxD2
XxnY0qJbsW263kSwtPIJg4445TgkCJKOSgFSCuTdBY2ZI6CVXi59P0cX1Tk/
wQntWGggzQs9GqhyznRpXVSEEb4YEQsPSRL0IJH3OGKRqdOgXhA2+vbeQEgZ
0mMEkS47mJnwtg/L9Q9O12yYxixCa+Ucjg6FzrSbScLHb6xjQWGzlrG8m9Dw
1rbX3kz0e+uuJ/sMaA5WDCebyGS/WUIk77L4LYPorFbGzydRoA1igC0aWaG1
X9e4CiEpkHbeBPPAyzp+XsSw5OkyR9tUyLGVU8rYhO4wd0lwH8r9qXBGD0OH
FLiHmqlSvysbx+ooEd3A1w4bE/3NVo7yFyr3jPxtdUkUjwLqkH+CV+PcFKBT
PkpL0aLdPNIdBndqMkHPb623LngLje9dBDDFmSaY4QHqkd7ejhBfs873LsXh
kKKlnjvPiTT2xzdkTAb7qJGp40ZtCYyRLDmSm2POciVpZUpqzMhx6HeRBb8d
8ucMwBWsY7V1Xi5ybFqmeJwarHMTEmuYFeLwtPEtthxFG+aMd9t8w55HtJba
+sQ3QhBmcrJMry17mZOur2fdJIZqmOeUgEIQ+y0WkDlBLsLqOytos7vdgIoy
QvNit4gWx2fIg+SOqZzW5LP4vBoZ0wMjQ5ifjSyI3JkATat1zF/Mw2Fm2KvE
JTNQBsMW3EjXYNWWnRav2H+Y4B839rL4n/37P24KgNbnswDqAXldX/qOTYhS
uGVpMHjQG88f9J18kIyVXnOGgWqrI9XkvmKiiGgLWMB0k3QDovvGPVz+iEPe
mxnyUqmOj9EiSCtXBpgW/ens/W7nHY/I+dS9tK7AZtW7UjwWm6Z3j2AmTJst
d+VcDDBG1aAOMOaIT1vUZm7smU//EiUnUu9AhcTO5tXEk3ikQXW2W8nhptxC
5aI/fdcwwwoLDbdHiKOFqRgWsaTmGaqeofQ94qCGFzyJ2cujGAa00n6OGnJC
PYgSfzhj0u4WUi7ZbJSNAVgDI5LWiiX7gEvzWRzTHw+MgGM3KSDqkIuAudk2
eyyNQOhYUroCP6BVTAe3puolpsW7b4oODh/CtMNWpLKpXEM7x+QhUPm/p4Pb
U/XMNHREySyCwknQmM59h0gmuYdp1yY651XPSi7PMN+Z3hqR05mG/wcSkiGu
d+nRAIR5g6W0qvZRXNrNiWeUFDD5DWsaTnMJsVK8P0AAC+klZLjDdJBUgr1X
Aclk5Jmc76EBxOaIpZLk/oytSLp50cdCm/n89B90uIUORoF7Viz48EXqNKYp
M9q2KTLmloBx0ttFYREKfYtQYiTzEnb/UAyVOHau7dn1Z35IpfXlbXoxXGnl
5qTK6TxxTB+KsUwqgaCwMNnFduonK4h2IYzQt8SmbrvMHuXMXc8b00hSW7Mo
nheSOHdIPXABjPuabkWtL2cTLSRfORXis81qZxYSQkGzT7dbdD1zWjGCy2EB
TAm/cirxz7ay/oBjih7kbCGEBPSlRNc4bfHwVrSpthOwsKbgZzvJGd0R0YM2
mwkfp1H5z6auAsKAf7kJdcKsJ2DSadGhKME30MekFTapc2kyLyeO1YpiABch
Fph1d6peM5B3N/wBRAI7sBGvfE0R/BiHiRHY+QXmDFHQc76Oc0ymXW6hNEf/
bD1cm/9pojGzftTIXSfZMIGlxMVyPR3cTdaZFaujEVkr78jzoZR2IizJESSQ
QTyOrGV2j31PfTx4QdWPniNcvokHPHGvWT6hPscG2JBNJ6aO2L/HtoCLC/jv
/N33VDL6gA2sO2yTbSRPLQdUFxXJvlSd+rfx4hrtomxH1Os5Py359hremXAX
WuiMMoVUMeBvWM1kCS42KR47WfGj1Ldp7664Q/iwa3az3A3i/Q/bxs6cVEnI
P+GX/W7iZl8+Gfszz8jKpSDHcWHU9nQ5Aa83rKh+UTMuFG33lLmNFZEk65yw
gN2wOBl5SIlpo1CxFLK8T4Dz4gbiwvL5PL+8kRRUDAGhf4u+Z3+os4Dowml+
O0yFmdWUpzQKIMRLjAm4FA7YcECgyPfOpxrHoTv7RX6dQE/rC5ZalHNfIU2E
viOw3IHnWySAR9gHL0nexCKjUm+MaVSPO4wtGPv2JnYqpHywwsMv18U6ujr9
1401kIJWiJEoxtJinzpD+b7HL0HvsuuZXnfkk7bCcxJyHFTy9G233dvRLDN9
WTtrWli74txE6C/rr9GK2FEKJK8N5wyIGfZ2C5okW5ZJ7yQb2vZS04Ck3wq4
GIjJ6aWD9XTqbCLefx/2U6xCj0/Ih5LzFfkMHWNFkmLp3jAQgru3Nfj8iY/w
WBfOdE34l1UF/kTps3qxLZrP3rXl8Gr7mqcJe8+vd1VT6uA2LZn7FEmECz63
lBtOUP7EejIa2AbrmwSWP+3ouO6Z9c7WgWxHE0/ft4Q5607YU2yE+JGABkLe
o4hhrSRR9ywsCxWGjmbRCd3O9ZVtfK3kMrjzo07JLOakpf2zzJcsCizHcMWB
aU3cOd3lz3SN/Tmvm4PWtCeU/g+5XfHP2v475dpm7fz6t2CxvsUKw1gNTTn8
LkQQx8firzkpJow5BGAv2h9cpbcpczxOihzfpW8TS3xFMB/EvzCQs15/p7R5
q7crutn4VziveHHC5yzvD+kSm+GHRGQ/Yq1E83fj5JNIPX8K3Gg9x5/E5zzZ
r3O/i32k1NldhjO6Y2LH9WhQMEGwc53T2kknJoaC/cIp+X0QxqSNmrKWvPxe
wGhTF8v40cXvrabzwV7yHMMEjGh43CJUM7ykyxOi+URH+5TqFJX4mjoNLY7P
LZeoH2P+A58jrQ41yd9YfZlfpxhwJXRLl0DoFo9naD9SXxcm6Ksjff1Toplt
rUxP4HYlutNczBK8MP16+pWB18t7sfuxpasirsJNFraQ4W6lzvKlp0HjFbLY
rj6ZctRCJp44HDzssw1e5PJD2NwGGg/V5MVbZEt2Nt0bM/FLDkT/IoRh1Lf4
/MOqvN6olzBrobcsib7z9zWT+AcTShJFEsof9a8USvDle6USrYcXMYk4wils
ab+uQg48K/Xg0eDEpTJ8toRP0yPLJS/H3G6SvfOSj3uopJ/6Decl0nIRi9GH
Tst1dmK4oas1FlgW0nzPwzdZ6su36/iqNV+sk+WtWpcP6DLLtvQkWzpNpnlL
d7tjOz8MR8At1SfgNji0DdWrg88RT8WxPxmvoAjNYYYOuVOljsrTFD9lBer0
SM0OLFwh+eeyooR0cFZB0aerKU1h3m/xeh6yCegNnlnUj1HWIF7lO5FxGA/X
1sn5viTEJJ733FEj7XcqNOxwOg95kTfCFaZc0RUDBCWw6HlttrqcWyNEcB05
trzrs8ouksvH0suKYE/9mRE54JCFCu18pltHs1loufrHNYdPO9LJbjzreC9c
UoNR2wp5K3cj9OykLYEKu+BsKCgIaoGjmfJiGZ4M8gUdzo51r0Cyzkf+C2na
QAVMKpSdFtjk8gN/jUPadS29b2mxtlMP59IGXpuBaka+yLyhO9da+ktJ3cWZ
FS9nDn9zCce36EofxlUXB6SXhCT90PfYKYtJeSkRZAGzTuqnctuQ17Lhojov
V7VGu+R712GkRcF+MJMGewhkeWmwdHNgp/04D3cwFSnQ60/fMrNij3PcixC2
hfDevwq7Cfgs5u8N0BR7in1KJpigqy8Imhca+6R/0dUVZJcozLkxvfupV1fY
DQx0vLLL/qsryIOc4Fd1hfcj6vcTNLi3P79x4wp7jMa468p886l3DpE9/DoU
2rdN6ALJ26skzVGyyZTzcj1HX/2rciA6PyZHQTlXPsMhLXiHIxcuLbAbzy1s
6UEudJ/osraZk+u0Qr/bEd/plXfHWcfVx1GKm5mtF9vEZfj85f4GiDHwfCuH
f6qSD4lHF4saiJNqWgPeLvanypFUmx5T5o4W9CpAn9sddkQI6qxYS2yQ+Mmf
Ts59SttyHcfSlpSfNsKTDg7bYU7z3rdDDmr0RH1RLY2SEs83diRvqy0dIhEr
RDzG+fyNeJ0WjjYFZDnDccl2PYzo8BvoeRHuGwvMDhBz3m7nY7+ODpteQVI4
I0EpTZGRIIg6Yw+2r3TPVHR3VNOVPyKJ4mJSso79yqyH5ijcQ7U0DXs6sMtL
H3Ey40fxzFlyVoZD53a1Uop0Mf3WI295OmuceDl4mo7iYureBBJntsDGRJLg
HsspxqeVCbumnu+Kxm6TYyH5uV+SgsXHw/lmV9f6UjjH+2U/Bs57c1VjNat/
a6CXD+NEMMXlCP/jNgX5vhbTmU+ttA0B5fh6bUEnKXilceCD0/02IBzRQGug
3+f93rKHksbFZq57iSYBsvmsm08yxeGwD77RVIor8SqkpM6bW5zYpioW54ib
ND0ShU5aP9co5pBbgX7wyg5gOk9GQIUrnYrZ1HgwrGWTCO7pyd5xQpR5oP8u
XixGruQiuWntHue5OEpJUxJZiNKG7JDPIl18JYXXB+jA415cXPMn1hAnzsc5
K7yPHtPVmO4+p70KqfYkiX99wZJwFFgOEDPonufr0+uZrv/vKfWV+vo/qKyZ
WFzRJaiuaKC7Sdf27ZogHuwIgQS0TYq/iombO5NeKLyqm7WPLw6z5c6kh3+C
1fJ6LVeFdTopA8ykLpe/6olxRM4noNQPrqmH2N7ETTAcbb1Ioq2v88kvrsnd
ahC9yF1t4TLJ5Nj3FddyxwguUcvY59yb08Ei1RsfbRZy6+8eNOUzbsOWm+EO
XRJItewFaHVj/SVO/jrI9EYAbL/RW02mnG6ZYHc76TYLDYErn9Ybyh6DE57T
Qru0hxW8p0LCgcteSA7DDRaB060cVHtsXV5+FwQ4FVTUo3cCqh48hRdq/Vkn
UrsNqL/VSm6UaeVQWtsg9yz7O3XIQfS9fD2PW7kwoBn5vqoOybSW4P21Ujah
Gi01KOmcCL1ZfH4Z3atUYySxrkvy13prtRcX6PdRwyMeYt4VS7xcqFkb1zr3
THuCp4LD7d0frRSWzxFwD/3T0xenqJl8cjncPNfJvdQgkK7h5GiaZoZ5AMnE
9X1FdQY6AYTXuIJmZaeIX1CPBo8EL4VbutN7+27/6fM72NIL8vikfc7hJPqw
n/kfg6ALOvCC9jlG8XiWAL57A/Z85/CnJTQi7QIfp99XOH5AaTIlYX9h6hP1
9NHbx/hOtlx/v92RG+FvPKRX3n0HD9P1A2RUw52uJ//6bENF/9fk3DU0drsa
3cW2LIqi+YPKdYTZRTx9iSowP3BM2XXujsuSJN6k0lWV0pgy7tN5ZDZaVYAZ
jM/4jJHR7/DZTRbn9b3s71ym3/6wje+Xoji6J5kTL2qX6cIa7vESMeW+MfG6
8njZGlU5+A4oShTXsDogw3JI+s6kESL++AACDkFB5gI88rDSZ7WfRzC5uBYB
y5d3qBfOvg/nhJM+sWzjkQGYW/h0CDvKD2/038d/d3p7FCtj/UfVOX/KFha7
48StxPsUwz0iMpxfjb/LwmdsgymTUVqm5shFclr9ZTfjBUiX2vF4j1DregC5
Xaz9/H1Fv1YxPB4quRtSim8Vepn0mwJ9/E2mWeVZ3qTRvG0nY9vb1t+kF+np
OVlyq/0wkufy/nFkJn8sAJmTcST8Tpqj7bL1DKobmP/RmJ2KkOS2eDQT780Y
g0as1r6FuzonH0Tc8DeX7RhMjwU1Pi2NFQWKeCW3ymPjKzdG5CNo3ooCdESa
K+W8vKei216JRz20w6u7ML6jLrvQ5ZqzLbZOB0b6vtfOfS0d/8a3vOUDpD+n
szELq/nSUH4av4hFj+hQJ8enDrAs/LJMuwVwlLTOprdm9DqRVa+MHRF41qH9
e4sZxkVsJhc/LJQ5aFmKloU/4CDGC2/V822GfbP0tPp2m54/kmQ5+7Ohu5rj
OF33PdygxrW0Mon3ey8cy5L+abdhHxG5xcoagZObJ/j2I0xByK/l0CnXjSGf
hkAZucnaKpXeIZplCB+Howxe44H4iLPhPohfhrVxyMtA986vBN04Sy/6+jX0
wHDrdoXjpEfsExE50vA7QrO/jLEDzsktjf/L8Hzz18KzPPArARqGSm6RCL5e
2tPcYmrAkfgewc9p+1PuNWif57rbaxS8mJbd+RLDkDTXtuF4HF3qCQjfJPyV
tGr3TdcmMEFJ/UsAcvD5J0AX9p+QEsZeq5hbluvIDt0p5CUj5BYSxh/1nxA+
CCkR6UI6LiJduPPyFyJdGPIypLv7a5EuKU19GtLld4x/KriFaX9HcEOKe6At
X8gfAeJyii+ButaDAnm/2hPFYXPIIdb+Gk8UB/CeqBSCkd1famfnioLThn9c
4jGdy8DHHAyxMX36ent6O3Lwzud3vqAL739bp9PWvMv/71xIPhWJvxtAWIf/
+GSEk/fbwJb++MAo/MDDVUAmg+X4Jb9s0OeghZ88+GjMkhl+CVTxdO5SoEqV
rE1wj3x4NXtFdyS0iEH1FnIzo5eyNtxa4N8VnmSn6rPPek5t8/ceexKuigMg
Gt4i3h9Lp3MG4mFg9xD+guc4Vqmk84Wu2OkbAaBdFKp3CVRgbvE9PTLZ8yW2
SPBv0ITTkL5t2Z+gXaFiITTKHWA7l/6WDzaJF9VqxUh0BC5FlTTa/cBffW/L
H1JejaRSRWWCw1fl84bePwqDtIuaN3xNk59My5PZfdcB7ZN7HLlahJXFbm9W
cl4k3niGO/4DT3SiAkn3b/wwVQ+yJhVkSezuzCeUc4JJ64LcYp0Jr6NGz6xG
Hq8hv5JduEHfb2uLIe6+zTJnizPDl8HN6qr82QwP85B2MBst20Xf3R5YRDWk
4aoqFkMvJdIwy3fGS5PBkGmQ32wRKuj3Ve91G+xoh6RFQdSj0A366c15RT/Y
Rj/C4Xs3qOJZr7BDN9tO/KUlau9Euu6p5Of+Po6ddtFhZLUx3wOCuqo8zEGi
ntqwkseHwlS7+CHrRU9Xnq14o/RKU29FcsBx2brDLt0YetsxKobSO9d5r+ct
HLFlwm9SFFhxFj7mnv9+0Rvnn2Ndp+roMIqLMjv8jcA+PmK6/nQerpsiJR5c
nHCRxCzuD5d4vHT4gY2mr/JQAq4q0eXmc5iAcQB5eAstt5b4391C9o0VdTxs
Ec2a3ipA+kNb6I/o8h3/GCyWl6loFLoJ6GJKt7W1v26QBZR+1kzLyYnw4658
Ko5+wVx98+CZWhougQS8BRh9Xa0sEHr9YTX/uy3m1XXsc1vv7I8/G26598Q8
qaoNyMKXBqBo3dixelrstfqqtpjrejcGswwy8wSCxQaUkDuU/mqWyxrixH+A
7/vOlskasB/HnHNvaLndgbX+b0ukBvgsfwAA

-->

</rfc>

