<?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.10 --> encoding="utf-8"?>

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

<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc strict="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc rfcedstyle="yes"?>
<?rfc tocdepth="1"?> "rfc2629-xhtml.ent">

<rfc number="8674" xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902"
     docName="draft-nottingham-safe-hint-11" category="info"> category="info" obsoletes=""
     updates="" submissionType="independent" xml:lang="en" tocInclude="true"
     symRefs="true" sortRefs="true" version="3">

  <!-- xml2rfc v2v3 conversion 2.30.0 -->

  <front>
    <title abbrev="Preference for Safe Browsing">The abbrev='The "safe" HTTP Preference'>The "safe" HTTP Preference</title>

    <seriesInfo name="RFC" value="8674" />

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

    <date month="December" year="2019"/>

    <area>General</area>

    <keyword>safe</keyword>
    <keyword>preference</keyword>
    <keyword>child-protection</keyword>

    <abstract>
      <t>This specification defines a “safe” preference for HTTP requests that
      expresses a desire to avoid objectionable content, according to the
      definition of that term by the origin server.</t>
      <t>This specification does not define a precise semantic for “safe”.
      "safe". Rather, the term is interpreted by the server and within the
      scope of each Web web site that chooses to act upon this information.</t>
      <t>Support for this preference by clients and servers is optional.</t>
    </abstract>
  </front>
  <middle>
    <section anchor="introduction" title="Introduction"> numbered="true" toc="default">
      <name>Introduction</name>
      <t>Many Web web sites have a “safe” mode, "safe" mode to assist those who don’t don't want to be exposed (or have their
children exposed) to content to which they might object.</t>
      <t>However, that goal is often difficult to achieve, achieve because of the need to go to every Web web site that
might be used, used and navigate to the appropriate page (possibly creating an account along the way) to get
a cookie <xref target="RFC6265"/> target="RFC6265" format="default"/> set in the browser, for each browser on every device used.</t>
      <t>A more manageable approach is for the browser to proactively indicate
      a preference for safe content. A user agent that supports doing so
      (whether it be an individual browser, browser or through an
Operating System operating system HTTP
      library) need only be configured once to assure ensure that the preference is
      advertised to a set of sites, or even all sites.</t>
      <t>This specification defines how to declare this desire in requests as a an HTTP Preference <xref target="RFC7240"/>.</t> target="RFC7240" format="default"/>.</t>
      <t>Note that this specification does not define what content might be
      considered objectionable, and so the concept of “safe” "safe" is also not
      precisely defined. Rather, the term is interpreted by the server and
      within the scope of each Web web site that chooses to act upon this
      information.</t>
      <t>That said, the intent of “safe” is to allow end users (or those
      acting on their behalf) to express a desire to avoid content that is
      considered objectionable within the cultural context of that site;
      usually (but not always) always), the objectionable content that is content
      unsuitable for minors. The “safe”
      safe preference is not intended to be used for other purposes.</t>
      <t>Furthermore, sending “safe” the preference does not guarantee that the Web web site will
      use it, nor it or that it will apply a concept of “objectionable” "objectionable" that is
      consistent with the requester’s requester's views. As such, its effect can be
      described as “best effort,” "best effort" and not to be relied upon. In other words,
      sending the preference is no more reliable than going to each Web web site
      and manually selecting a “safe” safe mode, but it is considerably easier.</t>
      <t>It is also important to note that the “safe” safe preference is not a reliable indicator that the end
user is a child; other users might have a desire for unobjectionable content, and some children
might browse without the preference being set.</t>

<t>Note also that the cultural context applies to the hosting location of a site, the content
provider, and the source of the content. It cannot be guaranteed that a user-agent user agent and origin
server will have the same view of the concept of what is objectionable.</t>

      <t>Simply put, it is a statement by (or on behalf of) the end user to the effect “If
      indicating that "if your site has a
‘safe’ safe setting, this user is hereby
      opting into that, according to your definition of the term.”</t> term."</t>

      <t>The mechanism described in this document does not have IETF consensus
      and is not a standard. It is a widely deployed approach that has turned
      out to be useful, useful and is presented here so that server and browser
      implementations can have a common understanding of how it operates.</t>
      <t>This mechanism was presented for publication as an IETF Proposed Standard,
      Standard but was not approved for publication by the IESG because of
      concerns that included the vagueness of the meaning of “safe”, "safe", the
      ability of a proxy to insert the hint outside of a user’s user's control, the
      fact that there was no way to know whether the hint was or was not
      applied to the response returned by the server, and how the possibility that
      the use of this preference may incentivize increased censorship and/or
      targeting of minors.</t>
      <t>The specification has been was updated to address those concerns, but the IESG has
      did not approved approve progressing this document as an IETF Proposed
      Standard. As a result, it is has been published in the Independent Stream.</t>

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

<t>The numbered="true" toc="default">
        <name>Notational Conventions</name>

        <t>
    The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”,
“RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
    "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
    NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
    "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and “OPTIONAL” "<bcp14>OPTIONAL</bcp14>" in this document are
    to be interpreted as described in BCP 14 BCP&nbsp;14 <xref target="RFC2119"/>
    <xref target="RFC8174"/> when, and only when, they appear in all capitals,
    as shown here.</t> here.
        </t>

      </section>
    </section>
    <section anchor="safe" title="The “safe” Preference"> numbered="true" toc="default">
      <name>The "safe" Preference</name>
      <t>When present in a request, the “safe” safe preference indicates that the user prefers that the origin
server to not respond with content which that is designated as objectionable, according to the origin
server’s
server's definition of the concept.</t>
      <t>For example, this is a request that includes the “safe” safe preference:</t>

<figure><artwork><![CDATA[

      <artwork name="" type="" align="left" alt=""><![CDATA[
GET /foo.html HTTP/1.1
Host: www.example.org
User-Agent: ExampleBrowser/1.0
Prefer: safe
]]></artwork></figure>
]]></artwork>

      <t>Typically, user agents that emit the “safe” safe preference will include it in all requests with the
“https”
"https" URI scheme, although some might expose finer-grained controls over when it is sent; this
ensures that the preference is available to the applicable resources. User agents MUST NOT <bcp14>MUST NOT</bcp14> emit the
“safe”
safe preference on requests with the “http” "http" URI scheme (see <xref target="security"/>). target="security" format="default"/>). See <xref target="browsers"/> target="browsers" format="default"/> for
more information about configuring the set of resources “safe” the safe preference is sent to.</t>

<t>Safe MAY
      <t>The safe preference <bcp14>MAY</bcp14> be implemented in common HTTP libraries (e.g., an operating system might choose to insert
the preference in requests based upon system-wide configuration).</t>
      <t>Origin servers that utilize the “safe” safe preference ought to document that they do so, along with the
criteria that they use to denote objectionable content. If a server has more fine-grained degrees
of “safety”, safety, it SHOULD <bcp14>SHOULD</bcp14> select a reasonable default to use, use and document that; it MAY <bcp14>MAY</bcp14> use additional
mechanisms (e.g., cookies <xref target="RFC6265"/>) target="RFC6265" format="default"/>) to fine-tune.</t>
      <t>A response corresponding to the request above might have headers that look like this:</t>

<figure><artwork><![CDATA[

      <artwork name="" type="" align="left" alt=""><![CDATA[
HTTP/1.1 200 OK
Transfer-Encoding: chunked
Content-Type: text/html
Preference-Applied: safe
Server: ExampleServer/2.0
Vary: Prefer
]]></artwork></figure>
]]></artwork>

      <t>Here, the Preference-Applied response header (<xref target="RFC7240"/>) <xref target="RFC7240" format="default"/> indicates that the site has applied the
preference. Servers are not required to send Preference-Applied (even when they have applied the
preference),
preference) but are encouraged to where possible.</t>
      <t>Note that the Vary response header needs to be sent if the response is cacheable and might change
depending on the value of the “Prefer” Prefer header. This is not only true for those responses that are
“safe”,
safe but also the default “unsafe” unsafe response.</t>

      <t>See <xref target="RFC7234"/> Section 4.1 target="RFC7234" sectionFormat="of" section="4.1"/> for
      more information about the interaction between the Vary header field and Web
      web caching.</t>
      <t>See <xref target="servers"/> target="servers" format="default"/> for additional advice
      specific to Web web servers wishing to use “safe”.</t>

</section>
<section anchor="implementation-status" title="Implementation Status">

<t><spanx style="emph">Note to RFC Editor: Please remove this section before publication.</spanx></t>

<t>This section records the status of known implementations of the protocol defined by this
specification at the time of posting of this Internet-Draft. Please note that the listing of any
individual implementation here does not imply endorsement by the IETF. Furthermore, no effort has
been spent to verify the information presented here that was supplied by IETF contributors. This is
not intended as, and must not be construed to be, a catalog of available implementations or their
features. Readers are advised to note that other implementations may exist.</t>

<t><list style="symbols">
  <t>Microsoft Internet Explorer - see https://support.microsoft.com/en-hk/help/2980016/</t>
  <t>Microsoft Bing - see https://developer.microsoft.com/en-us/microsoft-edge/testdrive/demos/familysearch/</t>
  <t>Mozilla Firefox - see https://support.mozilla.org/en-US/kb/block-and-unblock-websites-parental-controls-firef</t>
  <t>Cisco - see http://blogs.cisco.com/security/filtering-explicit-content</t>
</list></t> safe preference.</t>
    </section>
    <section anchor="security" title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>The “safe” safe preference is not a secure mechanism; it can be inserted or removed by intermediaries
with access to the request stream (e.g. (e.g., for “http” "http" URLs). Therefore, it is prohibited from being
included in requests with the “http” "http" scheme.</t>
      <t>Its presence reveals information about the user, which may be of
      assistance in “fingerprinting” fingerprinting the user by sites and other entities in
      the network.  This information which provides insight into the preferences of
      the user, user and might be used to make assumptions about the user and so user; thus, it
      could be used to
target identify categories of user users for purposes such as
      targeting (including advertising and identification of minors).
      Therefore, user agents SHOULD NOT <bcp14>SHOULD NOT</bcp14> include it in requests
      when the user has expressed a desire to avoid such attacks (e.g., some
      forms of “private mode” private mode browsing).</t>

      <t>By its nature, including “safe” the safe preference in requests does not assure ensure that all
      content will actually be safe;
it content is safe only when servers
      elect to honor it that content might be “safe”.</t> it.</t>
      <t>Even then, a malicious server might adapt content so that it is even
      less “safe” safe (by some definition of the word). As such, this mechanism on
      its own is not enough to assure ensure that only
“safe” safe content is seen; those
      who wish to ensure that will need to combine its use with other
      techniques (e.g., content filtering).</t>
      <t>Furthermore, the server and user may have differing ideas regarding
      the semantics of “safe.” "safe". As such, the “safety” safety of the user’s user's experience
      when browsing from site to site site, as well as over time time, might (and
      probably will) change.</t>
    </section>
    <section anchor="iana-considerations" title="IANA Considerations">

<t>This specification registers numbered="true" toc="default">

      <name>IANA Considerations</name>
      <t>Per this specification, IANA has registered the following entry in
      the “HTTP Preferences” "HTTP Preferences" registry <xref target="RFC7240"/>:</t>

<t><list style="symbols">
  <t>Preference: safe</t>
  <t>Value: (no value)</t>
  <t>Description: target="RFC7240"
      format="default"/>:</t>
      <ul spacing="normal">
        <li>Preference: safe</li>
        <li>Description: Indicates that “safe” / “unobjectionable” safe (i.e., unobjectionable) content is preferred.</t>
  <t>Reference: (this document)</t>
  <t>Notes:</t>
</list></t> preferred.</li>
        <li>Reference: RFC 8674</li>
      </ul>
    </section>
  </middle>
  <back>

    <references title='Normative References'>

<reference  anchor="RFC7240" target='https://www.rfc-editor.org/info/rfc7240'>
<front>
<title>Prefer Header for HTTP</title>
<author initials='J.' surname='Snell' fullname='J. Snell'><organization /></author>
<date year='2014' month='June' />
<abstract><t>This specification defines an HTTP header field that can be used by a client to request that certain behaviors be employed by a server while processing a request.</t></abstract>
</front>
<seriesInfo name='RFC' value='7240'/>
<seriesInfo name='DOI' value='10.17487/RFC7240'/>
</reference>

<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="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="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>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>

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

      </references>

      <references>
        <name>Informative References</name>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6265.xml"/>
      </references>

    <references title='Informative References'>

<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>

    </references>

<section anchor="acknowledgements" title="Acknowledgements">

<t>Thanks to Alissa Cooper, Ilya Grigorik, Emma Llanso, Jeff Hughes, Lorrie Cranor, Doug Turner and
Dave Crocker for their comments.</t>

</section>

    <section anchor="browsers" title="Sending “safe” numbered="true" toc="default">
      <name>Sending the "safe" Preference from Web Browsers"> Browsers</name>
      <t>As discussed in <xref target="safe"/>, target="safe" format="default"/>, there are many possible ways for the “safe” safe preference to be generated.
One possibility is for a Web web browser to allow its users to configure the preference to be sent.</t>
      <t>When doing so, it is important not to misrepresent the preference as binding to Web web sites. For
example, an appropriate setting might be a checkbox with wording such as:</t>

<figure><artwork><![CDATA[
  []

<ul empty="true">
<li>[] Request "safe" safe content from Web sites
]]></artwork></figure>

<t>… along web sites</li>
</ul>
      <t>along with further information available upon request.</t>

<t>Browsers

      <t>
   Browsers might also allow the “safe” safe preference to be “locked” – that is, locked to
   prevent modification without administrative access, access or a passcode.</t>
   passcode.
</t>
      <t>Note that this specification does not require browsers to send “safe” the
      safe preference
      on all requests, although that is one possible implementation; e.g.,
      alternate implementation strategies include blacklists and
      whitelists.</t>
    </section>
    <section anchor="servers" title="Supporting “safe” numbered="true" toc="default">
      <name>Supporting the "safe" Preference on Web Sites"> Sites</name>
      <t>Web sites that allow configuration of a “safe” safe mode (for example, using a cookie) can add support
for the “safe” safe preference incrementally; since the preference will not be supported by all clients
immediately, it is necessary to have another way to configure it.</t>
      <t>When honoring the safe preference, it is important that it not be
      possible to disable it through the Web site’s web site's interface, since “safe” the safe
      preference may be configured and locked down by the browser or
computer’s
      computer's administrator (e.g., a parent). If the site has such a means
      of configuration (e.g., stored user preferences) and the safe preference
      is received in a request, the “safer” "safer" interpretation ought to be
      used.</t>

      <t>The appropriate level of “safety” safety is a site-specific decision. When
      selecting it, sites ought to bear in mind that disabling the preference
      might be considerably more onerous than through using other means, especially
      if the preference is generated based upon Operating System the
      operating system configuration.</t>
      <t>Sites might offer different levels of “safeness” safety through Web configuration, web configuration; they will need to
either inform their users of what level the “safe” safe hint corresponds to, to  or provide them with some
means of adjusting it.</t>
      <t>If the user expresses users express a wish to disable “safe” safe mode, the site can remind
      them that the safe preference is being sent, sent and ask them to consult
      their administrator (since “safe” the safe preference might be set by a locked-down Operating System
      operating system configuration).</t>
      <t>As explained in <xref target="safe"/>, target="safe" format="default"/>, responses that change based upon the presence of the “safe” safe preference
need to either carry the “Vary: Prefer” "Vary: Prefer" response header field, field or be uncacheable by shared caches
(e.g., with a “Cache-Control: private” "Cache-Control: private" response header field). This is to avoid an unsafe cached
response being served to a client that prefers safe content (or vice versa).</t>
    </section>
    <section anchor="acknowledgements" numbered="false" toc="default">
      <name>Acknowledgements</name>
      <t>Thanks to Alissa Cooper, Ilya Grigorik, Emma Llanso, Jeff Hughes, Lorrie Cranor, Doug Turner, and
Dave Crocker for their comments.</t>
    </section>

  </back>

<!-- ##markdown-source:
H4sIAPt0RF0AA61aW3MbuXJ+x69AuA+WXCRlOZs9Z+mHRGvLayW+xZKzlUql
UuAMSOJoOOABZkhzT3l/e77uBuZCyT55yIstzgwuffv66wZms5lqXFPZhb7b
WD2JZmUn+s3d3Uf9MdiVDbYurDLLZbD7xeCRXvmgb/Gx/iX4Q3T1WpW+qM0W
E5XBrJpZ7ZsGjzdmO6NJZxtXN7PLS1WaBt88f3b5syrw59qH40K7euWVcruw
0E1oY/P82bOfnz1XJliz0L/a2gZTqYMP9+vg291C3dsjfpULpWeaZqf/d/1+
8avYuKqc7YJvbNE4XysVG1OX/2MqX2P9o41q5zBeN76Qn1pHHxpMErvfTXBF
k38Vfru1ddO9dXXl8lRah1Vhy9gcq+4JJi7trtks9KVSpm02PvB+MRBzvJvr
952G8LXWorx3JtyfvvFhbWr3uyE5FvzEbo2rFnoLJf8L/TOvbcMv2uAWetM0
u7i4uDgcDvP89kKp2oct5tjbBVQNhfe/1Gw202YJeU3RKHW3cVHHnS3cyhW8
qi7tCsJGbbKL7MauwB4T7F9bG5uom41ptP2Cb2LkQaWNLlioRJu9d6Xyy7+I
WcyystBs3UCzU22KAlaF5PRlA3/kZR3vwK9k2saGrV4e+bUPbu1qHW3Y2zB/
fOMeG4AOkgTYC3ZVuGgxamvqxhW8f5Fqrj8ZzBumPDuvhAnhuDZgVGNLlRaW
FTUcSh9cA9eWp4XfWdqoNcVG/2aXOrrGyraLjfekC1JB0eh252kMz54s4WtI
cNvudvBC3hO/HugZaxeVIxfkhWUPkXbod6zLap5MuXVlWVmlftA3dRN82aYQ
eGfqY7evqDdmb3uLbn1pp7y/GF2EojfYsD5sPHRYP2n0Adqi10tLpsW7Up9h
lzwJpHdBccxhr/n9OX2ejEt/HjYOesG3R+xwvWm0uAF2/cYf7F70Dl2tvalY
rBVG6tKtYM22akR3G4cvp9hFYdpoxS2sri22g/drT//SXMexAZSsiM1jVDlF
tO3d2jQ2e5rZASt2wdGjnVlbfQYRoltWUDpQiMIRWmcPbSENwciaBx7MkeVc
IwINpPX3zuq//e2fP71++dPzn/7p61cYqtHJQ5YEliQn2Ze9JD3RcAfZdWn3
rpBdQjFXMAsCB56KPXGw8EZpJBQkXtJNS9vglxTW2LirSwqD5PTDcGXMTJaZ
6ytaDd68ZjuRBaK4YYTpSfDo9dlhYyk0tGMlQhU0+96VLWzVicX7AUSvN/hC
fdgBt1lzt8fY2K2gROWWwQQojW3ma2x0yRiwcus28KPCJj9sQwofknIgg4vK
lFBX46LY3bCW4Qzs2bwRqBP2qip59A10SLC28QeapbRFZXhJfJkwC5brcM0Q
lp0kR9j6H2DrPz3/8dnXr1gF2N3t+e+i0YGhIUVI56F4EF1pWRdDoJxK3HtF
2ihITTuWOQUwVjMVTEXzJ5Crjmml8u9Cmx5Bm/r/h7Y7dizjStmCE6FH26cZ
qgq2sFidfDIyxAgSkVvDlXhyoA0UtTHVimMvpRr1INH06EOLY4VvqXYoK2FN
C8Ihg780OfUoEvkF9gWXh2LPlm3DujYVMCCeP1irrWPrGp6dYm7rkIDjfMiz
Rh5NcynWSik+nbCKB3uOvV0bCFjJmV+3gR4ROkxhs5qzZpq287J1awJQ2w6C
qDPdwSE0CEEdEm/NWqZtN/xCAWUgohl52Uhhk7FKI0tOSuRVUsTY8CTqvbMH
iH2FWGiLzRRLRGVXK0ylC8DIkrJ8LIJbQlQE2GSJgRofAH+mE/Z4EkX0ESwS
YMkuNkduS2ohKhh7LeCZOtWswCgNZ3tg7zVyRWIaY5+mFYG3YmSEkBW/G+dJ
RcZ3I5cylCusiY6pyE3TxaPbEpam7FkP4OHbfoDVur0mFM8WomEQVDFk0xJC
dV8kXUjUCJSk/J5igtyorb/FvBhYtlbnHJ7zJSM7G9a3D2B4aTk72CbjHsvb
bfNBIJFXOUEKeo+wZtVWPsEjvMywEQQi0u5gTL8nDcs2GY58G4ou+XeJ7IZd
ivQHX+mcv5QdGdbNTLIcTSTsUSUux/GQyQxwCrogzx2skQPhkBx/pEribjA0
XGDXNtPkGhCmQf6lsoHglbDM1wm4MNN5Nqbk36SVFBuTm5U+Qkxxyg2lHvWE
3OUJKZz0NhWUzY4A61ssQlwQOgWQiCVOWDVPeUqrJSHMJwTSIBu2QHi4uB0E
pkuQjiKvZXE6jGGV3VzfveZAsMA8oaedI3PdZULJ5qHEDVWXkpl2lT9S1GdK
w3YiUeE2NUF02/RAuGqraZ6Z4B67wCcktc5ON8hdmRKRTdgA7GGRISfFBRV0
0EALvA28SU4vKyYDsJ9n9tIzh14tBzPcAcXVrl1WOceTpWrRyEdQSibKt0kH
4K1tw+NZNyT3XqZQwylSKr65vv11SHTZB0Od6itXF1XLqQKf7s26RZkcYzbo
1mKvIo+AzJRZg1m6yjVHiTSs/uVICkZFCi4lMekoKbcNQZp8Rf71hGEOpUQl
kbmiRJ/jPNgkkUIepOnua2gw88VuUvoGqhoIz1ievB7q3JH/4I9k/BEfEcvD
MixFR/zHBdLWEOctYBYQ098JOYm6k/7xDMV93LgdzXNBWGoCGHvSUErN4v5j
xkbeuLRgku2OOhdCNsuS6EbiJdkqYtvObpsTIxOKrWmYpKhhLH3PYzhxUjaI
ANOMK+wrcZPj0qob+PCOiANmu20g9JZKwR9+oE6CkdpQv/T1nlQDLYug96jD
OHXqybvPt3eTqfyv33/gvz9d//vnm0/Xr+jv2zdXb992f+Qvbt98+Pz2Vf+X
PFcY+fLDu3fX71/JYDzVJ4/eXf3nREw6+fDx7ubD+6u3k4cYY4TJLe2Ip5qo
Rrj0y8uP+vLHRMOfX17+jJJLfvz58k8/4gc8sZbFuNiQn1yFwjbWBJqE6oTC
7EDXKhgSS0T4Ws3owpocsrYh9/+BHn1V6jdMmjGB58sUaPqtPJ9qs9inSwZy
+WTwdJylhEGkaBGG3vFOKa9T5bKujSjrQQlx2mMZLfAkPpIcUu4j1kl11RdD
mDrtZRzhUXxc4IVSf/zxh/r1+k5frLyfb5ptxaXUxeX8EvV/bBaa+lVp9rkP
a/WZ8vUV5euFvpbnvwisY9AzJXZYSDFLk6u74w5KBW+bDira3I7aum9xLk79
afscYeIPXdmXaa2acGdtoj9/ukFFtEFegRYqokYoeJk+CWuS/oemwivM1sFQ
AZYBFAZhukEOI9FMPvOCXV9R+gxDnxgzQ7M3rhIC23UtKGnQEwxjUgSq/Xkg
e47oTn71UH5fP5RVs6xDUfVZtFTtRlu0ATnk69fzub7lRynZRgQbpTLm2oPi
D1mHMnku8RNHzxV7t/FBIRilY0SkinrMgAtGgZzLJfBT/h40FYhbntn5ek7h
nhI4M1RpP4hxpFzt05461fNAG0vOHlzRyhwz4i6dJCzdOXb5YdiITOZrG6Ta
3+03fI5chslNh3bZ5iBGHs40TT2mzvmAeABBZwYftiIHYJ/I96PUHqyLSbXA
ByUltg65ZueZpUVislFlrtAcJ5xpEqpLDcThbmKaHSBhUksOmxB0HUnygiYg
u9EekTCdZCHVsajOUtIyi6OeGVf1vMemrS33wTqCAPhK8DcAsYxE8LS9HZY/
G2vKziQVloKr3EuHJ0FSBiH9/Nkz/eHf1B2qhggzza7rwtMaC7hMW98jhb8U
nc6AM3ahqaS5IBxTfUaYXQmtSah0y2rv0Et+XjwHeP2HoXMPGSjg9caGVPc8
nK6XXuTRZ8Ou0/lj2aQvGzLRGpXFFLrirJRlJaf8tXVBGA6V0o9t44ybaoxd
7IDCpB9d4Fz4EM2On4hwAFIpXWBijKm7ak86ZlaTYh6IS63CmLiApNjVmDVS
HY4KIrVIqYJPsW7qtVVCjvruEehy1Xbl40QEnaTFqEPjYq5fmDI0obWp2epj
v2rSNkRMoJpEliK4D5JJW0v854GEa7bvHP4jsZRbiV39IzyR20WnIJqbZnRG
w0WCbQ5ETFlhJDJ1MEgJkLNbICGSAPMgDvEnt5kz2SXdcgckOcUB9DKFFwVw
Oh5hJnQzqqiIqDYtGOVTMaPXEElfYx0Pv/9YEf+G3Fu/T23VaPP2VyThoOyZ
P8092vRJsAXTU3ZnXoZMRtVF/aCuS7akAz9f+Cq3PaWKQGYds/rka43bshfs
UiMi1xQ3pObaNrNXdJQ5z2KMezdg4HmQqY9q0A4f701K1K5eliYB3BEVR9cZ
kKrh7vVcj/p6tU+NMApkxWUI5JBGEszkVsfkFb2XnFTGvFsquaijz1GK1XK1
3oBDt01qSrLLK95h7kGaKMC+baN0OlNvmsIhdSiJBUKnSFWiiI6gPLBPkLat
WlkYMhBN+ZSgmSCC3DG18nstS0frdCaq8uwXKB/u+FS/c0Xw0a+azmgA210F
9QU6G0YQ5NPQdKYx3+YRcxCIC1vPNvcXG1vtLp7//Odnzy5/uhjN+guZeDxR
CRCsiFw8nKqNF92zmS3X9gKY3JTB7S2GbX28WJmtq44RZUex4ZX872CfRr8G
9K78l2/tWb4iVkzLfL69uF9eLCtf3M9goFlby98Hu+TDjtkOOoXCqlkmnbMV
zY/1XrpY+MEqWARj13Fe0AuWIxO8i5WriHHU6xkILaLUNbPckiMguE3fUWUp
HVAxEIqiTBGl0PxOl5O/HLScmDaktrDQM2oDhYQg7L2MgVtbOuZ7ivkRihou
yMdkIHIlLDxDTnkzp30bz7kRHxiEurI6+I1bOm7qBL+V9qbq+izuOzRZKDL3
fXNvqKCN7C2ywSNcONd701S1kVMvpeHCp68mMdEJUGxNpS+kxl8TTrJc20AT
corLhS1HClX3DVGpdJCBYKA7Ezm6B5uQRVNflV5FTpepaThM4x2yym5Hp6ik
760Bm6KTuu1OrD+WLzWWARttVQ7GKem/6HQFxMk6PEL6aXLQwUcGVMT27Zoz
sQe35NMRoJzNwkDU/+hAXnWNnbGth5Vh37c4qf96QyeuI8OIT+V7DcBHdXrc
JNttGlPcd/yW60JSPYs4gSn3dCZLxwgTaVNi/1RE/HKksxFdMz5OdS9nrosG
2+rSyfCQlJsYuRlANS2YghxjEG3CHC+UOHrXB+nyvVB8yLHxdBbkUjny4Giy
IwLXe9ELdVbgBIQOvo25zpDvTWl2/Ry5SStbYCJZUdAm6c7IoaEq9bD/QE2q
88EJUjNux/qa9casQJSCeogq8pMzZJI6V795U8w2bP1C97cdiPrwqVDdD2Vt
5jsGwMglHd7Som06HJEIVA02VTuyUV/dyEIdlp6fHt6d3CdhPyM4YG5Nlx94
GDk3nC/YtQllX0HLFZbYtXnnE6hJZTXZrp4bRvET9mHMKs0PcoPshoJ7crTr
03EYYsCSL6XGBXGmdDh0RvsFiCz56It0dJ4YNzFFoopX769OssOjx/CQik4Q
g1C9laczYNoNFBeOGc0mJwfvcZLG4ZNhNbQgWtB/liqxp+DJ4PwLfQZSxfT/
HM9ecSORkWsBAjEqopKnXBB9Pzn6HHiPIGWgyxpPwWi6Rc9GrUxai/hxzJet
lkAI0tBVQXS2IqrAl8v4mLy+51R2BYYZDfRHXGOqb6qj0b8GR3B5P9XX263R
byvUqn6q/xU0Ub+Bz9Pdh7cokJ3VL1HHeox7hVjQd9RTZwdTr8ivXgbwhQS2
cpyer7fNU24fnSizW1B9kPpvlOS7pg+qc0gK+tAyKsJcqDuoLfp1mo4HjFxh
OXZVH92a6a+vPOQHUumt+eJfQ7r9UOeSUc4v0uUXw5saXH+R6wMpMkNMF5Dk
ZslpQ60vJ+epgZtvu2RC0J/cpiPorYvB5jbvyXR0UOC6pkR3ywqU3gfVN03r
0VWjdJTXAywd59rifgkqyLhySM3alAhTz0Lr//pveJvQnBNI62zFy0tvYT6f
D9tJK8GfMS/pqDu3u1KmobSUTZ5AnapbUfP3bDchQmrLiYazp5sCU/pqz+nE
l32azmfLpkS2pnDmW4mJ0vFNHqN3wPECCfP/fL8mNTOya8SuqZH268ct3r6N
q/K1Bl/3TYqTGuSFTj1GgnTqs59WfCwEsImpldCKZYWIp5IxytWaDYzDP1O8
CdEfhBymISPeMscjSi2FPDy1u7+Xkz5MMepIyrnd4LqCPlsNG/etMKbUeTtn
vm3KMt/6Ut+OSz5RYznBKl5gG2zwcRxIrpRqMc0oxJ3piVxgVG7LDB46OOZg
qy0ZnJoZREO4sVSn+x1yrNgHsusilulKlw6pV9zv5GEUZ/6RdteZl3qoLkrd
Sl+F5An9dZkn6a7UytC8IndWsDm9wEYGFveHQx6649zuql9QANtdK9djBm4P
tefutZYK7pzbt6N2ngABn+/GdCg8sLyMVxFz2XJ4osQZ87y/QDFWFakpQP9u
LwD+2PFVmKjuGC65We5hL7v7incnVykrqpX1oLGcrkVAmlnXeyrprho1gPRv
wknznRu6miSunpdSy3RgB6Wlex1iuewDw+Pg0/t0TFO4r4bgDkRX+R5QvrEo
FI4VO9WWd8fk2a1OZ4YMXW4anhE8uPA4Mg5fESFh0uVXYnaJ4BEosqp6JkeH
+ZNub9zbG06WTjCHxFRZN0D1lNYlDeZbK2KOQWzzyXzfUSecZMhNpSF9upWc
wdy88zpT/qWNyUZU9fbscnTvO3PpHF3jq8bZrQl/ACtiUbsd9LCJuY31nq8c
5UtLJt6nQQwQkQ8lWPKTwBrHbHYNOoNaHpVJ8TrjeP2+GYnAXzGFruT4ZER4
TnrDQoeHPpJcSRoEuQN9CrQq1xrJpIUJQUBkMjw4mDxolK+crUq2IMVk3ffE
qbraGAIFfhZVQhppn+jJS3o6eyntooVOVeo3Fjjve+Rd6WvoJg3DCi9Qqm5k
NlnY57u6kgVEQ/nAW4YmDkM3pbg/TTnPQOP/C9QriFqoMgAA

-->

</rfc>