<?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.0.39 -->

<!DOCTYPE rfc SYSTEM "../Tools/rfc2629xslt/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-nottingham-site-wide-headers-01" category="std">

  <front>
    <title>Site-Wide HTTP Headers</title>

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

    <date year="2016"/>

    <area>General</area>
    
    <keyword>Internet-Draft</keyword>

    <abstract>


<t>This document specifies an alternative way for Web sites to send HTTP response header fields that
apply to an entire origin, to improve efficiency.</t>



    </abstract>


  </front>

  <middle>


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

<t>HTTP response headers are being used for an increasing amount of metadata that applies to an entire
Web site (i.e., the entire origin, as per <xref target="RFC6454"/>).</t>

<t>For example, <spanx style="verb">Strict-Transport-Security</spanx> <xref target="RFC6797"/> and <spanx style="verb">Public-Key-Pins</spanx> <xref target="RFC7469"/> both
define headers that are explicitly scoped to an entire origin, and number of similar
headers are under consideration.</t>

<t>Likewise, some HTTP header fields only sensibly have a single value per origin; for example,
<spanx style="verb">Server</spanx>.</t>

<t>Furthermore, some headers are used uniformly across an origin. For example, a site might have a
homogenous <spanx style="verb">Content-Security-Policy</spanx> <xref target="W3C.CR-CSP2-20150721"/> header.</t>

<t>HTTP/2’s HPACK <xref target="RFC7541"/> header compression mechanism was designed to reduce bandwidth usage for
often-repeated headers, both in responses and requests. However, it limits the amount of
compression contents usable for a connection (by default, 4K), and some sites are beginning to
exceed this limit, thereby reducing the efficiency of HPACK itself.</t>

<t>For example, it is not uncommon for a CSP response header field to exceed 1K (and has been observed
to be greater than 3K on popular sites). This forces site administrators to make an awkward choice;
put the large header in the HPACK table, thereby crowding out other headers, or omit it, requiring
its full content to be sent on every applicable response.</t>

<t>This document defines a way to specify one or more sets of HTTP response header fields in a
well-known resource <xref target="RFC5785"/> that, when their use is negotiated, are appended to the header
blocks of all HTTP responses on that site by the user agent. This allows common response headers to
be omitted both from on-the-wire responses and the HPACK compression table, making both more
efficient.</t>

<t>This approach is preferable to increasing the HTTP/2 SETTINGS_HEADER_TABLE_SIZE (<xref target="RFC7540"/>,
Section 6.5.2), because increasing that setting incurs a per-connection overhead on the server,
whereas using the technique documented here does not.</t>

<section anchor="selecting" title="Selecting Site-Wide Headers">

<t>Only certain header fields are suitable for being set for an entire origin. Therefore, a header
field MUST be listed below, or its field name MUST start with the characters “site-“ (case
insensitive) to be usable as a site-wide header.</t>

<t>The whitelisted field names are:</t>

<t><list style="symbols">
  <t>Access-Control-Allow-Origin</t>
  <t>Alt-Svc</t>
  <t>Content-Security-Policy</t>
  <t>P3P</t>
  <t>Public-Key-Pins</t>
  <t>Public-Key-Pins-Report-Only</t>
  <t>Server</t>
  <t>Strict-Transport-Security</t>
</list></t>

<t>Note that inclusion in this list does not imply that a header field is always site-wide.</t>

<t>Future specifications SHOULD NOT update this whitelist; instead, they SHOULD use the “site-“ prefix.</t>

</section>
<section anchor="example" title="Example">

<t>If a user agent has a fresh copy of the well-known resource for an origin (see <xref target="well-known"/>)
(e.g., because it performed a GET, or HTTP/2 Server Push was used):</t>

<figure><artwork><![CDATA[
HTTP/1.1 200 OK
Content-Type: text/site-headers
Cache-Control: max-age=3600
ETag: "abc123"
Content-Length: 284

Strict-Transport-Security: max-age=15768000 ; includeSubDomains
Server: Apache/2.4.7 (Ubuntu)
Public-Key-Pins: max-age=604800;
  pin-sha256="ZitlqPmA9wodcxkwOW/c7ehlNFk8qJ9FsocodG6GzdjNM=";
  pin-sha256="XRXP987nz4rd1/gS2fJSNVfyrZbqa00T7PeRXUPd15w=";
  report-uri="/lib/key-pin.cgi"
Site-Foo: bar
]]></artwork></figure>

<t>and the user agent makes a subsequent request:</t>

<figure><artwork><![CDATA[
GET /images/foo.jpg HTTP/1.1
Host: www.example.com
SH: "abc123"
]]></artwork></figure>

<t>That indicates that the user agent has processed the well-known resource (because the <spanx style="verb">SH</spanx> header
field is present, and its value matches the current value of the <spanx style="verb">ETag</spanx> of the well-known
resource). Therefore, the server can omit the nominated response header fields on the wire,
replacing them with the <spanx style="verb">HS</spanx> response header field, whose value is the same as that of the <spanx style="verb">SH</spanx>
field:</t>

<figure><artwork><![CDATA[
HTTP/1.1 200 OK
Content-Type: image/jpeg
Vary: SH, Accept-Encoding
Cache-Control: max-age=3600
Transfer-Encoding: chunked
HS: "abc123"
]]></artwork></figure>

<t>Upon receipt of that response, the user agent will consider it equivalent to:</t>

<figure><artwork><![CDATA[
HTTP/1.1 200 OK
Content-Type: image/jpeg
Vary: SH, Accept-Encoding
Cache-Control: max-age=3600
Connection: close
Strict-Transport-Security: max-age=15768000 ; includeSubDomains
Server: Apache/2.4.7 (Ubuntu)
Public-Key-Pins: max-age=604800;
  pin-sha256="ZitlqPmA9wodcxkwOW/c7ehlNFk8qJ9FsocodG6GzdjNM=";
  pin-sha256="XRXP987nz4rd1/gS2fJSNVfyrZbqa00T7PeRXUPd15w=";
  report-uri="/lib/key-pin.cgi"
Site-Foo: bar
]]></artwork></figure>

<t>If a request omits the <spanx style="verb">SH</spanx> header field, or its field-value does not match the current <spanx style="verb">ETag</spanx> of
the well-known resource, all of the header fields above will be sent by the server in the response,
and <spanx style="verb">HS</spanx> will not be sent.</t>

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

<t>The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”,
“RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in
<xref target="RFC2119"/>.</t>

<t>This document uses the following ABNF rules from <xref target="RFC7230"/>: <spanx style="verb">OWS</spanx>, <spanx style="verb">CRLF</spanx>, <spanx style="verb">header-field</spanx>. From
<xref target="RFC7232"/>: <spanx style="verb">entity-tag</spanx>.</t>

</section>
</section>
<section anchor="server" title="Server Operation">

<t>When a server wishes to use site-wide HTTP headers, it places a file in the format specified in
<xref target="type"/> at the well-known URI specified in <xref target="well-known"/>. That file SHOULD NOT contain header
fields not allowed by <xref target="selecting"/>.</t>

<t>Then, when a request has a <spanx style="verb">SH</spanx> request header field (as per <xref target="sm"/>) whose value matches the
current ETag of the well-known resource, the set of response header fields in the payload of the
well-known resource are omitted from the corresponding response, and the <spanx style="verb">HS</spanx> response header field
is sent with the same value as the <spanx style="verb">SH</spanx> request header field.</t>

<t>Servers MUST include <spanx style="verb">SH</spanx> in the field-value of the <spanx style="verb">Vary</spanx> response header field for all
cacheable (as per <xref target="RFC7234"/>) responses of resources that behave in this manner, whether or not
headers have been actually appended. This assures correct cache operation, and also advertises
support for this specification.</t>

<t>Servers MAY use HTTP/2 Server Push (<xref target="RFC7540"/>, Section 8.2) to proactively send the well-known
resource to user agents (e.g., if they emit <spanx style="verb">SH: *</spanx>, indicating that they do not have a fresh copy
of the well-known resource).</t>

</section>
<section anchor="client" title="User Agent Operation">

<t>User agents that support this specification SHOULD always emit a <spanx style="verb">SH</spanx> header field in requests.</t>

<t>When a valid representation of the well-known resource is held (as defined in <xref target="well-known"/>), its
value will be its <spanx style="verb">ETag</spanx>. When one is not (e.g., because it has not been requested, the one held is
syntactically invalid, or it is stale, as per <xref target="RFC7234"/>), its value is “*” (unquoted).</t>

<t>When an <spanx style="verb">ETag</spanx> is sent and the response contains the <spanx style="verb">HS</spanx> response header field (see <xref target="hs"/>), user
agents MUST confirm that the value of the “HS” response header is character-for-character identical
(after removing leading and trailing whitespace) to that of the <spanx style="verb">SH</spanx> request header field it sent.
If it is not, the response MUST be considered invalid and MUST NOT be used; the user agent MAY
retry the request without the <spanx style="verb">SH</spanx> request header field if its method was safe, MAY attempt to
re-fetch the well-known location beforehand, and MAY take alternative recovery strategies.</t>

<t>If the values match, the user agent MUST append the contents of the well-known resource that are
currently held to be appended to the response headers received, but MUST NOT include any headers
not allowed by <xref target="selecting"/>.</t>

<section anchor="sm" title="The “SH” HTTP Request Header Field">

<t>The <spanx style="verb">SH</spanx> HTTP request header field indicates that the user agent has a fresh (as per <xref target="RFC7234"/>)
copy of the well-known resource (see <xref target="well-known"/>) for the request’s origin (<xref target="RFC6454"/>).</t>

<figure><artwork><![CDATA[
SH = "*" / entity-tag
]]></artwork></figure>

<t>Its value is the <spanx style="verb">entity-tag</spanx> <xref target="RFC7232"/> of the freshest valid well-known location response held
by the user agent. If none is held, it should be <spanx style="verb">*</spanx> (without quotes).</t>

<t>For example:</t>

<figure><artwork><![CDATA[
SH: "abc123"
SH: *
]]></artwork></figure>

</section>
<section anchor="hs" title="The “HS” HTTP Response Header Field">

<t>The <spanx style="verb">HS</spanx> HTTP response header field indicates that the server has chosen to omit the headers in the
well-known resource’s response that shares its <spanx style="verb">ETag</spanx> with the field value.</t>

<figure><artwork><![CDATA[
HS = entity-tag
]]></artwork></figure>

<t>Its value is the <spanx style="verb">entity-tag</spanx> <xref target="RFC7232"/> of the well-known response whose headers are being used,
and MUST match that received in the <spanx style="verb">SH</spanx> header field of the request.</t>

<t>For example:</t>

<figure><artwork><![CDATA[
HS: "abc123"
]]></artwork></figure>

</section>
</section>
<section anchor="well-known" title="The “site-headers” well-known URI">

<t>The well-known URI <xref target="RFC5785"/> “site-headers” is a resource that, when fetched, returns a
representation in the “text/site-headers” format (see <xref target="type"/>).</t>

<t>Its media type SHOULD be generated as <spanx style="verb">text/site-headers</spanx>, although user agents SHOULD NOT reject
responses with other types (particularly, <spanx style="verb">application/octet-stream</spanx> and <spanx style="verb">text/plain</spanx>).</t>

<t>Its representation MUST contain an <spanx style="verb">ETag</spanx> response header <xref target="RFC7232"/>.</t>

<t>User agents SHOULD NOT consider it valid if it fails to parse, but MAY attempt to recover from
errors in a manner similar to how headers are normally handled.</t>

<t>User agents SHOULD consider it to be valid for its freshness lifetime (as per <xref target="RFC7234"/>). If it
does not have an explicit freshness lifetime, they SHOULD consider it to have a heuristic freshness
lifetime of 120 seconds.</t>

<section anchor="type" title="The “text/site-headers” Media Type">

<t>The <spanx style="verb">text/site-headers</spanx> media type is used to indicate that a file contains a set of HTTP header
fields, as defined in <xref target="RFC7230"/>, Section 3.</t>

<figure><artwork><![CDATA[
site-headers = OWS *( header-field CRLF ) OWS
]]></artwork></figure>

<t>As in HTTP itself, implementations need to be forgiving about line endings; specifically, bare CR
MUST be considered to be a line ending.</t>

<t>For example:</t>

<figure><artwork><![CDATA[
Strict-Transport-Security: max-age=15768000 ; includeSubDomains
Server: Apache/2.4.7 (Ubuntu)
Public-Key-Pins: max-age=604800;
  pin-sha256="ZitlqPmA9wodcxkwOW/c7ehlNFk8qJ9FsocodG6GzdjNM=";
  pin-sha256="XRXP987nz4rd1/gS2fJSNVfyrZbqa00T7PeRXUPd15w=";
  report-uri="/lib/key-pin.cgi"
Content-Security-Policy: default-src 'self'; img-src 'self'
  *.staticflickr.com; frame-ancestors 'none';
  report-uri https://mnot.report-uri.io/r/default/csp/enforce
]]></artwork></figure>

<t>Note that the <spanx style="verb">Public-Key-Pins</spanx> and <spanx style="verb">Content-Security-Policy</spanx> header fields are line-folded; as in
HTTP, this form of header is deprecated in this format, and SHOULD NOT be used (except in
documentation, as we see here).</t>

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

<t>TBD</t>

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

<section anchor="injecting-headers" title="Injecting Headers">

<t>Site-wide headers allow a single resource to inject HTTP response headers for an entire origin.
Accordingly, the ability to write to that resource needs to be carefully controlled by the origin
server.</t>

</section>
<section anchor="differing-views-of-headers" title="Differing Views of Headers">

<t>Because headers sent via this mechanism will not be seen by user agents and intermediaries that do
not implement this specification, they will potentially have a different view of the response
headers.</t>

</section>
</section>


  </middle>

  <back>

    <references title='Normative References'>





<reference  anchor='RFC2119' target='http://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='RFC6454' target='http://www.rfc-editor.org/info/rfc6454'>
<front>
<title>The Web Origin Concept</title>
<author initials='A.' surname='Barth' fullname='A. Barth'><organization /></author>
<date year='2011' month='December' />
<abstract><t>This document defines the concept of an &quot;origin&quot;, which is often used as the scope of authority or privilege by user agents.  Typically, user agents isolate content retrieved from different origins to prevent malicious web site operators from interfering with the operation of benign web sites.  In addition to outlining the principles that underlie the concept of origin, this document details how to determine the origin of a URI and how to serialize an origin into a string.  It also defines an HTTP header field, named &quot;Origin&quot;, that indicates which origins are associated with an HTTP request.   [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='6454'/>
<seriesInfo name='DOI' value='10.17487/RFC6454'/>
</reference>



<reference  anchor='RFC5785' target='http://www.rfc-editor.org/info/rfc5785'>
<front>
<title>Defining Well-Known Uniform Resource Identifiers (URIs)</title>
<author initials='M.' surname='Nottingham' fullname='M. Nottingham'><organization /></author>
<author initials='E.' surname='Hammer-Lahav' fullname='E. Hammer-Lahav'><organization /></author>
<date year='2010' month='April' />
<abstract><t>This memo defines a path prefix for &quot;well-known locations&quot;, &quot;/.well-known/&quot;, in selected Uniform Resource Identifier (URI) schemes.   [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='5785'/>
<seriesInfo name='DOI' value='10.17487/RFC5785'/>
</reference>



<reference  anchor='RFC7230' target='http://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='RFC7232' target='http://www.rfc-editor.org/info/rfc7232'>
<front>
<title>Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests</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 HTTP/1.1 conditional requests, including metadata header fields for indicating state changes, request header fields for making preconditions on such state, and rules for constructing the responses to a conditional request when one or more preconditions evaluate to false.</t></abstract>
</front>
<seriesInfo name='RFC' value='7232'/>
<seriesInfo name='DOI' value='10.17487/RFC7232'/>
</reference>



<reference  anchor='RFC7234' target='http://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>




    </references>

    <references title='Informative References'>





<reference  anchor='RFC6797' target='http://www.rfc-editor.org/info/rfc6797'>
<front>
<title>HTTP Strict Transport Security (HSTS)</title>
<author initials='J.' surname='Hodges' fullname='J. Hodges'><organization /></author>
<author initials='C.' surname='Jackson' fullname='C. Jackson'><organization /></author>
<author initials='A.' surname='Barth' fullname='A. Barth'><organization /></author>
<date year='2012' month='November' />
<abstract><t>This specification defines a mechanism enabling web sites to declare themselves accessible only via secure connections and/or for users to be able to direct their user agent(s) to interact with given sites only over secure connections.  This overall policy is referred to as HTTP Strict Transport Security (HSTS).  The policy is declared by web sites via the Strict-Transport-Security HTTP response header field and/or by other means, such as user agent configuration, for example. [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='6797'/>
<seriesInfo name='DOI' value='10.17487/RFC6797'/>
</reference>



<reference  anchor='RFC7469' target='http://www.rfc-editor.org/info/rfc7469'>
<front>
<title>Public Key Pinning Extension for HTTP</title>
<author initials='C.' surname='Evans' fullname='C. Evans'><organization /></author>
<author initials='C.' surname='Palmer' fullname='C. Palmer'><organization /></author>
<author initials='R.' surname='Sleevi' fullname='R. Sleevi'><organization /></author>
<date year='2015' month='April' />
<abstract><t>This document defines a new HTTP header that allows web host operators to instruct user agents to remember (&quot;pin&quot;) the hosts' cryptographic identities over a period of time.  During that time, user agents (UAs) will require that the host presents a certificate chain including at least one Subject Public Key Info structure whose fingerprint matches one of the pinned fingerprints for that host.  By effectively reducing the number of trusted authorities who can authenticate the domain during the lifetime of the pin, pinning may reduce the incidence of man-in-the-middle attacks due to compromised Certification Authorities.</t></abstract>
</front>
<seriesInfo name='RFC' value='7469'/>
<seriesInfo name='DOI' value='10.17487/RFC7469'/>
</reference>



<reference anchor='W3C.CR-CSP2-20150721'
           target='http://www.w3.org/TR/2015/CR-CSP2-20150721'>
<front>
<title>Content Security Policy Level 2</title>

<author initials='M.' surname='West' fullname='Mike West'>
    <organization />
</author>

<author initials='A.' surname='Barth' fullname='Adam Barth'>
    <organization />
</author>

<author initials='D.' surname='Veditz' fullname='Daniel Veditz'>
    <organization />
</author>

<date month='July' day='21' year='2015' />
</front>

<seriesInfo name='World Wide Web Consortium CR' value='CR-CSP2-20150721' />
<format type='HTML' target='http://www.w3.org/TR/2015/CR-CSP2-20150721' />
</reference>



<reference  anchor='RFC7541' target='http://www.rfc-editor.org/info/rfc7541'>
<front>
<title>HPACK: Header Compression for HTTP/2</title>
<author initials='R.' surname='Peon' fullname='R. Peon'><organization /></author>
<author initials='H.' surname='Ruellan' fullname='H. Ruellan'><organization /></author>
<date year='2015' month='May' />
<abstract><t>This specification defines HPACK, a compression format for efficiently representing HTTP header fields, to be used in HTTP/2.</t></abstract>
</front>
<seriesInfo name='RFC' value='7541'/>
<seriesInfo name='DOI' value='10.17487/RFC7541'/>
</reference>



<reference  anchor='RFC7540' target='http://www.rfc-editor.org/info/rfc7540'>
<front>
<title>Hypertext Transfer Protocol Version 2 (HTTP/2)</title>
<author initials='M.' surname='Belshe' fullname='M. Belshe'><organization /></author>
<author initials='R.' surname='Peon' fullname='R. Peon'><organization /></author>
<author initials='M.' surname='Thomson' fullname='M. Thomson' role='editor'><organization /></author>
<date year='2015' month='May' />
<abstract><t>This specification describes an optimized expression of the semantics of the Hypertext Transfer Protocol (HTTP), referred to as HTTP version 2 (HTTP/2).  HTTP/2 enables a more efficient use of network resources and a reduced perception of latency by introducing header field compression and allowing multiple concurrent exchanges on the same connection.  It also introduces unsolicited push of representations from servers to clients.</t><t>This specification is an alternative to, but does not obsolete, the HTTP/1.1 message syntax.  HTTP's existing semantics remain unchanged.</t></abstract>
</front>
<seriesInfo name='RFC' value='7540'/>
<seriesInfo name='DOI' value='10.17487/RFC7540'/>
</reference>




    </references>



  </back>

<!-- ##markdown-source:
H4sIAE9LNlgAA+1aW3PbuJJ+x6/AKg+xU6J8ycWJUlO7HseJfZLYXsuZzJmt
rRFEQhJiXhSCjKJJJb99v24AJCXLmdraqn0685CRSQJo9OXrrxuIokhUpkr1
UI5MpaOPJtHy7ObmSp5plejSCjWZlPrLUCRFnKsM3yWlmlZRXlSVyWdzlUWW
Bi4xMJq7MdH+gUhUhW8P9w+eiRg/Z0W5GkpbJUKYRTmUVVnb6nB//8X+oVCl
VkP5Rue6VKlYFuXtrCzqxVDc6hX+SobyPK90mesqekVrC2ErlSd/qrTIscZK
W7EwQ/lfVRH3Jf4xeaLzqi9tUValnlr8WmX+R1WaGK/iIlso/yPDx3hl8tTk
+r+FUHU1L8qhkJGQ+M/kdijfD+RFs2F+7HTxXpW3m2+KcqZy85eqTJEP+YnO
lEmHMoPO/oP+GWAr/KIuIfe8qhZ2uLe3XC4H4e2eEHlRZpjji6Y5rl+fHB4c
vBhCe/m0fSFEFEVSTbAt7EaIm7mxEoaqaU/SLnRspkZbqXKpUlIhj5NLtZKY
RX7UE0nGs9CatDpPnOVLbRdFbrV05pSYIk3wzVxVQi0W6Yo+x5RYw5Qa+zUz
k5PmpckWZYEF9HRqYqPzeDVwImYmSVItxAMyZVkkdUzaEWLbehAXs040VCpr
qxMWFcuZPIajWHqssqLGBoupzHSl4GqKpZMknXHbaeQTYZdyxwz0AHLO9abo
ysoFNvrt279D0c+ePH3y/fsuJH+NhfVXlS1S3ZfjEftOdFOqHPKWVTTSMQxY
rcZh4NGLo+/fsXIix1f1JDVx9Favoit4UPjk6MmzF/hkUlRzkegpHK7ZtNsA
hNJfsYkYMbmSNi4WUMBWddMyeZ1NIDf0YE1mUlWKrgrrnKwXQ7WIzZL9EZt6
Z2710lhN8ZH5WF83dJHT0hrDJvgxVzCokqT3VMsvKq01K8vJ8ZKtE5QkxiNd
ftHlmJRXl9B0mRVlWGpNNjJsnRtyZiyi4rKw7Kdu2oFc071yBszMbF55gcS8
yIqZzovayvFJAYDIW4tEVwVU6Azz8fHJ4OQ6OhldHUaAo6f7R4cHMIETZuBc
cO/woZVnV8cnb4Odnj5pP2K0gJNaKBAOF88R3jZDFCHWtDWz3Jmo1HBrOC4M
AzCs5tijmmnSjyimEC8q9UIDCpOgiD77Afy6iQDLVi3151rbyg7kWbHUUCfA
qZIpLFxZ9t7G/UVXstgpwdK6k1S7sKGnueZokzuTFQSeqjoF8D15u+t8iE3j
UMDFHdSfU5BVhdBfY02bI1jh9Tl6So2JeLf82bwb7+SLTpEQVqfTzSjCRjAX
UA7GJ+yFWE5O2Gc78JBqvRwHb+UOiTyH5idaw1kmlvwtEfhmouWsJP2WFEq5
fPwWjiwXxaJGXLgN7g4kIyRWjLFd9imVZAbmBIBWRcnIkalbzYi5vF2qMpHx
vDCxfikWdcWbxXSzRkQYj565LVek91ZF8OllQioqMLKgp63lseciI2VApWRv
U+JDQQae1mkabCndviz9xGbIF1YO5GI2cVDYYBP6HbbAooz1hO6cC2CenBBE
UlRiWixH9voJ6GN/Six1mka3ebFkTy1qaA9x8m+Ik6dHz58iTgi7+nI516wN
U1J4s52R9ytDPt9n54LoyDIuXEhtbi0xSYv4lkVR2PuaOIRGDhrZWtAqjcP0
8BlEf+UtinHF0krvUXcSClwZaiSFU/hx1E3LIsPcEaYDdyn1Rgy2Ru2GmDcw
PITMyvOQJkXw/yoYAhstCxXPSQkYPQX8kr0oRbZZjNdg9JGj05ub84s3oz/P
To9fnV7/eXP867vTP0fnf5zKnQaR9r9/74uRD+Zng6eDQ4TwRMeKtd2dl9Sl
mZTQ85owlzA76oAB0nRJ6nH6JWcg4O6LJTmvIhAJIlZAvNwAkhr3Yggr6W/N
sYxdiwcP5EinNDmGdaikt8C3Bza8/S7EJWWYWJeVgn+tOxy5ia1N1UCYIwLY
TuABa3mQ7A9RppxlVHAoBxzvP4xuKHxShDeZXcNHOPI4zPgTYnHuO1DKspJL
A5PSpgHyRKlI9B7z257ciZXV4F+cGYlH7frw9HirrM9TzIXbBAMBERp47uVo
V+bdgsU9kscxAMlGlMfKIo2OyZ2jS94hvU2R2r7E+HVPosObq8dX9O867bj7
JLrWzF3IAnjr0jX9uI/cCAF6q51PwZfSmgOBYY+Tgq0aNyD6R+SQicw6hnOI
AopsqyCmCFVN5nY8NWaGYuXo7PLDu1fy4vJG1gsqI9xSjQpfEiWvMDsj7Sp8
T0FAlgvmorAzX71rnrr8Azf0mQhOeA646SAJZxUFXNB2jqBfcCqjCbehn3dF
54Nyx2oCxPZD0EexowezQSc+K4pAojtwASXfnN6wK4b4ZzvAWFh7ydGnk114
xo8fPxxBORgcoJjal5dvRfCBm9UCFUilv1Z7vGUPduIEuKODK6HqUF8jbPCX
x8/298XpjZoNZU9N4oPDx71mqnc6n1VzlGvPnwhxryu0cx08PXr2fB/ivHQ+
kehRPXlVoMyBz7m9DOXxggTZOxw8GRzJnQ8TUJZ6V2z4Yzvns/0nmPIlip2F
ySM7V4dPn/3S+wM8+PNVdvxiWSTx19vl5ce9+EjP04vXt88//+PFa1vERfLm
2Zu/kk8X73/pbQ7//fr3qxfPj/K/npTJwd5sdDj9x+jit+mq/GPyWe3v3xxd
6evfP1wlB0+XbnDpwgP7/aW3l5rJHmrQCDMO4pnpCca110UxBMsr2TgiJIuO
IxGBYCyoQU+Am3jkKZ2z6A8B68s9k+FzuzctisGnxUwGM4uzAh9Kqga9rw6Q
gsTorGM3ngTAwjGZUORoX0BsiEI+jUxE4KKTe715JzgpfTAenY3XcdTlMMs1
NW2X4NPVAahDYWJHSuEjJS3p3vjYGZPDje9Gkghr764BeJuIZEzhRQyJnuX4
lTN1voem+CRGibyPuRepCtw0azF9fDYab5+AuEthQ3Vj3IYs5Qbl9Rr2A+U4
rQRT/jw62cZ7nxZ6Jn5T1AEZnfUZ7BdVdAoCTPTwpwHLUQj60Hw9RGqq81tw
3rPRHY/4sGD2E2uz8CKrqtlxf9M5lsYxTS4PCaCIh0IFjnj+P23wpKEk2FkK
I/wLf/4X+PPDpzGPLxwxdjOMg493mU/kXL1J3RzJa3HchK64Bzb6zNZ9YGyQ
uAl1gdi/QvnimbuPbl82Na7JMMrxyYNIIj/QJ3CQEKYHKiUO9IU4IAY6cgUV
SeoTgqoRlev13f+JQdDv69P//HB+ffqKfo/Ojt+9a36ELxyDaH+55wIjTy7f
vz+9eOUGvz/+Z88hYO/y6ub88uL4Xa9hQk3pRQTW8UJDXUsgJ+GW6xXEpZng
D5C6b998S+/79zvFW209pE4L4oEEZMe/XryWZZ3iBRcurvo6OnyMmmAox5cf
R+O+HJ9cv3tN/3fGiNgY44F8jRGiGXHII0iBoI8VTMwaDgzkcuE7RczY6RGY
0kcq7FSw3dLYueuxUcpoCW+nk2S50CcU5kQ4NakOJnfdy6Y36ZVRAUyodVZt
5qgP1+dr327QLMoeGMQLdHgjlc9taSG8V5JXcaFIxcAKM7UliTOCzn0R2waU
I4UcTM2jLrHdaVqHNgPrW8sjnewoQlRRUP2EWIYUyOh9f0lOHy3UKi2ofuPJ
ttbo5Iqh6GW34fguSjcxtyba5BCIzP1ZUsBJrUscPqNyinSbVR3Y2aYpKNi5
mHX1lsdtNyD4RgeZQsKlrHKPPI6Fp6mICei5BmvN4b2dOrndZsK00Y5P7BPN
/cQQxplCOirZDbhhgxXgNk1blb/l1hOKwxprr5qeRuhEWIuaxjo1x5Vk2WQR
wsrpWaW2kCqBNioDsYStFwT7vCEWY60k6qru+J8cdVvKhvU+gQx9gueDQ65T
uR9BVavr7W6SwYaQ+bj2HMFKX8aYqSu2NFGyMZHRR+N+IJ9N04E/SQqONN83
buspcb/b7zoM+kDrHjM36eJQnFJrBTj0oSOXa3J4vd3VWUADX3Wy2OpuUnTN
V99ubYAOHmiIanrW6yb8STWIxecBDFznbQtU7RImWuG8O6RGyscu0Q4kL079
Od8gvVtAEhi51KgbsbUrg3ng3LF1YVcQGsaO2UFNzvvx+Z9mt5XirnqIlTZU
+h1yjw97j3pyp84/1wXW2W0UlAdyEAAhYEcTph6A7d8gSqic55bXJr8T3r4M
EphmasqsLW3WsKF3NurdmRciNb2bCPEUNX9JQ8eCpBSxo6b0oNRZ8YWcN8VY
PleifZTKpPQHNxwsSKRr9GyWAdvzgak8awEta3rd/XXlhL5UoN7sLc7nSIDA
XVxrSScvN3k7QADhWpUrP60Tg0C58C3qn8g3ZQtnQLci4VaDVVP4AgGLQqLI
FsT9MX001YERdlw+LXx4Tbhim0Neh2g0vuLGeeecEQBYcMua2+t6ZjQF2fm0
NaV1SfJOacI6cMjqk5Y/2/hJFIYDtJBr6ezKnx9M7rae7/SIuWz6QuE0qavW
CCFPqXwVPhV/QySIrxIvBZvsOVZ07U3huqHyNZsCBCv77hgs28v3vbcZ7W9r
/ICzW/Of+Ltu1rb+lc9FjX89tE23y03eHpNSGTI6k78wXOzJllq6Dsl5F1HY
OzvkU3Z5aZCR90JacEGxzf865gMx2XIsAC/LPZjOufqhyESApNQIluNHY7kT
IobhzW4c+A7DvjpFNqc9t6lgYoIgb2Iv0IaNAW3exoSC9x+1bDOyJ9xk4Jh4
ZU7O2zRFguM68rSNAD607VouXwILsUCbdVoq54RgO3mTno1g0v+7MdflcsI4
lrz9uN/Vghx/oSjlJoaLzkAV72Zyv5x3163G3OyYMOm4aXrGXp7eZv3x7UEn
Mnw/f+OL7mHYxmTECddByhcZDLCEN8DyukSuVGKDcvi99u70eHuhjPKR68on
8uBzBvfEKEnPAguis1G+XuNL0fGdGcdUzVM4zOZr9K9TVJX6E0BOtGSafced
a9Ji4IoLBUIb04FrukId6k8qaS97BVJwFSERaJWN3R0JFgJFosnHQfQNBQQS
wMVcSzs2A6jrdoN1mrheFDadLgcsnAzlFPmey1lIT4UQw/9aOgyJjIsoocuy
cGGnfLkQbl/Qp/NiuebYfI0n5XsUeZLqZLt8XdlcvnISTkPPhhAx15ZOXOA3
Jrun1GHcM5Vo+jqOhefNpZItM60fo2xI4ln8XNelsbBtO140kiDyDg73gVYY
m9huAtziuO/ZOal5iLhiv/XweNclu45s3JmIO0F1QBkOmrj4bwinCtVzpx3h
GwB9ucnP2yZKWzA99vDXFQVAePlxJB/tyG5rRVK/Re7SK4cmx+wVvLC7/dDn
IzGdBYemE3EdGAlsOzNMP9WE0hBdPwPeEhG1L9tqJqVQmpArnVyLLdTR05vu
8G3g9+NffdX7+6r3HKsOw3WZyJaxfEgWfQjNZLPO35j70cCSeeMpxtyWdFrz
EmGiMh2pPEYuIrR4SGTk4bokzc0/vvXXPh+YYq/c80vvxXaxp3O+suI7vu2B
LGfCO1fNGFzvvRJ197idPAelUppQraHIh7np33dlNWUaiqe2vkoIpGPOJaFt
4tKRKwU6kOsrGJSyX+lEgGYOXc7QDUEaIaKj+UaB7wOcH18cU5u3vbdGnd5f
X7k+pdvPnfcP6G7hJ38BIVxedR3zznm8vyrSXmjr9j0Mj99K0uz22wfiOI6L
kmKOopTvZk1QPVZ852ZZ0pWVUDo2CxEEWB+2MfRPF35WDGBlkaaupOCK3h3/
OxLoUfWVmU41XRWSvxm9dLd3wlZ/9Y2CIDBX5l8IQLmx1d5bW+uwg4hgvW7K
5yM+al0z/JYmMNKkEOGQnxFtS9fFpxJeYVGQ/xmf+ziLJCy9E0svW8bmNB2a
bAN/rXWi4lvxP1JkXsmgLAAA

-->

</rfc>

