<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.19 (Ruby 3.3.3) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-pauly-httpbis-geoip-hint-01" category="exp" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.23.2 -->
  <front>
    <title abbrev="IP-Geo Client Hint">The IP Geolocation HTTP Client Hint</title>
    <seriesInfo name="Internet-Draft" value="draft-pauly-httpbis-geoip-hint-01"/>
    <author initials="T." surname="Pauly" fullname="Tommy Pauly">
      <organization>Apple Inc.</organization>
      <address>
        <postal>
          <street>One Apple Park Way</street>
          <city>Cupertino, California 95014</city>
          <country>United States of America</country>
        </postal>
        <email>tpauly@apple.com</email>
      </address>
    </author>
    <author initials="D." surname="Schinazi" fullname="David Schinazi">
      <organization>Google LLC</organization>
      <address>
        <email>dschinazi.ietf@gmail.com</email>
      </address>
    </author>
    <author initials="C." surname="McMullin" fullname="Ciara McMullin">
      <organization>Google LLC</organization>
      <address>
        <email>ciaramcmullin@google.com</email>
      </address>
    </author>
    <author initials="D." surname="Mitchell" fullname="Dustin Mitchell">
      <organization>Google LLC</organization>
      <address>
        <email>djmitche@gmail.com</email>
      </address>
    </author>
    <date year="2024" month="October" day="19"/>
    <keyword>Internet-Draft</keyword>
    <abstract>
      <?line 37?>

<t>Techniques that improve user privacy by hiding original client IP addresses,
such as VPNs and proxies, have faced challenges with server that rely on
IP addresses to determine client location. Maintaining a geographically
relevant user experience requires large pools of IP addresses, which can
be costly. Additionally, users often receive inaccurate geolocation
results because servers rely on geo-IP feeds that can be outdated. To
address these challenges, we can allow clients to actively send their
network geolocation directly to the origin server via an HTTP Client
Hint. This approach will not only enhance geolocation accuracy and reduce IP
costs, but it also gives clients more transparency regarding their perceived
geolocation.</t>
    </abstract>
    <note removeInRFC="true">
      <name>Discussion Venues</name>
      <t>Source for this draft and an issue tracker can be found at
  <eref target="https://github.com/tfpauly/privacy-proxy"/>.</t>
    </note>
  </front>
  <middle>
    <?line 51?>

<section anchor="introduction">
      <name>Introduction</name>
      <t>HTTP Client Hints <xref target="RFC8942"/> defines a convention for HTTP headers to
communicate optional information from clients to servers as hints. This
can be done conditionally based on whether a server claims to support a
particular hint. A server can request hints by listing them in the
Accept-CH response header.</t>
      <t>This document defines a client hint that can be used to send a
geolocation entry based on the client's determined location. This
location can be used to influence server behavior, such as by causing
the server to return responses relevant to the client's location. The
format of the geolocation hint is the same as that defined for IP
geolocation feeds in <xref target="GEOFEED"/>. It only allows for
coarse-level location specification.</t>
      <t>This header aims to provide rough geolocation hints to servers based on
the client’s network location, shifting geolocation from a passive
IP-based approach to an active client-controlled one. This not only
allows the client to influence how their location is interpreted, but
it also reduces the need for extensive IP address pools when clients
mask their IP addresses through VPNs or proxies. Typically, VPN or proxy
providers need to manage egress IPs for each region to maintain
accurate geolocation. With a client-provided location hint, the hint can
minimize the number of IP addresses needed while still supporting
location-specific content such as weather, local news, and search
results. In addition, the hint reduces most servers' reliance on geo-IP
feeds that often come with limitations such as outdated
IP-to-location mappings and ongoing maintenance costs.</t>
      <t>The client determines geolocation via a cooperating server
that performs a geo-IP database lookup of the client's IP address.</t>
      <section anchor="requirements">
        <name>Requirements</name>
        <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.
<?line -6?>
        </t>
      </section>
    </section>
    <section anchor="ip-geo-header">
      <name>IP Geo Header</name>
      <t>The "Sec-CH-IP-Geo" is an Item Structured Field <xref target="STRUCTURED-FIELDS"/>.
The field's value is a String. The string uses the format defined in
<xref section="2.1.1" sectionFormat="of" target="GEOFEED"/>, with the IP Prefix element removed. Thus, this
contains a comma-separated list of Alpha2code, Region, and City. The
value SHOULD NOT contain a Postal Code.</t>
      <t>For example, the header for an entry "192.0.2.5,US,US-AL,Alabaster" would be:</t>
      <artwork><![CDATA[
    Sec-CH-IP-Geo = "US,US-AL,Alabaster"
]]></artwork>
      <t>Given that the Sec-CH-IP-Geo is a high-entropy client hint (i.e.,
a client hint that is not in the low-entropy hint table), the server
needs to explicitly opt-in in order to receive the Geo Client Hint as defined in
<xref target="RFC8942"/>. It will not be sent by default and the server MAY
indicate support for this hint via the Accept-CH header in the
initial response:</t>
      <artwork><![CDATA[
    Accept-CH: Sec-CH-IP-Geo
]]></artwork>
      <t>Servers SHOULD indicate for any cacheable content if the geo hints
will influence the cached content, using the 'Vary' header. This will
indicate that the server may have used this header as a determining
factor when choosing a response:</t>
      <artwork><![CDATA[
    Vary: Sec-CH-IP-Geo
]]></artwork>
    </section>
    <section anchor="client-behavior">
      <name>Client Behavior</name>
      <t>The client MUST determine geolocation using a cooperating server
that looks up the client's IP address in a geo-IP database. The client
MUST NOT use GPS. The client hint value MUST NOT be more precise
or detailed than what can be inferred from the user’s IP address.
When the client is routing traffic through a proxy or a VPN, the
IP address used to generate this geolocation hint MUST be an
address that is presented upstream beyond the proxy or VPN
(in other words, the "egress IP address"). The proxy or VPN's
selection of this egress IP address MAY have been based on
the client's original un-proxied IP address, but any hints that
the client presents to servers beyond a proxy or VPN MUST NOT
reveal more geolocation information that would be possible to
determine from looking up information about the egress IP address
itself.</t>
      <t>The client MAY include the client hint header in requests to the
server after the server has explicitly opted in to receiving the
hint, or if the client knows of specific server configurations,
such as proxy settings, that support including the hint.</t>
    </section>
    <section anchor="server-behavior">
      <name>Server Behavior</name>
      <t>Upon receiving a Geolocation Client Hint, a server can use the
information to influence its behavior in various ways, such as
determining the content of HTTP responses.</t>
      <t>Servers can choose to use the hint value in one of several ways,
including:</t>
      <ul spacing="normal">
        <li>
          <t>Using the client hint information instead of consulting IP-based
geolocation feeds.</t>
        </li>
        <li>
          <t>Recognizing a mismatch between the client hint information and the server's
current result from its IP-based geolocation feed as a reason to schedule an
automatic refresh of its geolocation feed information. This can help ensure that
changes to feeds are adopted quickly, improving results for clients that don't
send the client hint.</t>
        </li>
        <li>
          <t>Serving content that corresponds to the client’s indicated location,
including delivering region-specific news, weather forecasts, and
relevant advertisements.</t>
        </li>
      </ul>
      <t>The server MUST be able to handle situations where geolocation is
not provided in a request. Since not all web clients will send a
Geolocation Client Hint, the server MAY defer to alternative methods
such as IP-based geolocation feeds to provide said value.</t>
    </section>
    <section anchor="sec-considerations">
      <name>Security Considerations</name>
      <t>Servers MUST NOT use Geolocation Client Hints for security or
access-control decisions, as the value is provided by the client
without additional authentication or verification. Servers that
offer services restricted to clients in a specific country or
administrative region might already rely on geoIP databases to
determine the client's location for access control purposes.
However, the Geolocation Client Hint can be used to customize
responses based on where the client claims to be within that
restricted region.</t>
    </section>
    <section anchor="privacy">
      <name>Privacy Considerations</name>
      <t>Any value provided in this hint MUST NOT be more specific than the
information that could be obtained from the client's IP address and
a well-maintained map of IP ranges to locations. In particular,
when a privacy technology such as a VPN is in use, the value MUST
NOT reveal information about the user's location that would
otherwise be hidden.</t>
      <t>To prevent disclosing private information, this value cannot be
based on other sources of geolocation data, such as GPS or physical
latitude and longitude coordinates. Providing overly precise location
information could expose sensitive user information especially when
combined with other identifiable signals. Furthermore, when a client
designates a location different from that derived from their IP
address, the combination of designated location and IP can create a
unique identifier, increasing the risk of cross-site tracking.</t>
      <t>The hint MUST NOT be sent by default or in an always-on manner. It
should only be included in response to explicit server requests (e.g.,
via the Accept-CH header) and in contexts where sharing location
data serves a clear purpose, such as for location-based services.</t>
    </section>
    <section anchor="iana">
      <name>IANA Considerations</name>
      <section anchor="iana-header">
        <name>HTTP Headers</name>
        <t>This document registers the "Sec-CH-IP-Geo" header in the
"Permanent Message Header Field Names" registry
&lt;<eref target="https://www.iana.org/assignments/message-headers"/>&gt;.</t>
        <artwork><![CDATA[
  +----------------------+----------+--------+---------------+
  | Header Field Name    | Protocol | Status |   Reference   |
  +----------------------+----------+--------+---------------+
  | Sec-CH-IP-Geo        |   http   |  exp   | This document |
  +----------------------+----------+--------+---------------+
]]></artwork>
      </section>
    </section>
  </middle>
  <back>
    <references anchor="sec-normative-references">
      <name>Normative References</name>
      <reference anchor="RFC8942">
        <front>
          <title>HTTP Client Hints</title>
          <author fullname="I. Grigorik" initials="I." surname="Grigorik"/>
          <author fullname="Y. Weiss" initials="Y." surname="Weiss"/>
          <date month="February" year="2021"/>
          <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, user agents 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.</t>
            <t>This document defines an Accept-CH response header 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."</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="8942"/>
        <seriesInfo name="DOI" value="10.17487/RFC8942"/>
      </reference>
      <reference anchor="GEOFEED">
        <front>
          <title>A Format for Self-Published IP Geolocation Feeds</title>
          <author fullname="E. Kline" initials="E." surname="Kline"/>
          <author fullname="K. Duleba" initials="K." surname="Duleba"/>
          <author fullname="Z. Szamonek" initials="Z." surname="Szamonek"/>
          <author fullname="S. Moser" initials="S." surname="Moser"/>
          <author fullname="W. Kumari" initials="W." surname="Kumari"/>
          <date month="August" year="2020"/>
          <abstract>
            <t>This document records a format whereby a network operator can publish a mapping of IP address prefixes to simplified geolocation information, colloquially termed a "geolocation feed". Interested parties can poll and parse these feeds to update or merge with other geolocation data sources and procedures. This format intentionally only allows specifying coarse-level location.</t>
            <t>Some technical organizations operating networks that move from one conference location to the next have already experimentally published small geolocation feeds.</t>
            <t>This document describes a currently deployed format. At least one consumer (Google) has incorporated these feeds into a geolocation data pipeline, and a significant number of ISPs are using it to inform them where their prefixes should be geolocated.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="8805"/>
        <seriesInfo name="DOI" value="10.17487/RFC8805"/>
      </reference>
      <reference anchor="RFC2119">
        <front>
          <title>Key words for use in RFCs to Indicate Requirement Levels</title>
          <author fullname="S. Bradner" initials="S." surname="Bradner"/>
          <date month="March" year="1997"/>
          <abstract>
            <t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
          </abstract>
        </front>
        <seriesInfo name="BCP" value="14"/>
        <seriesInfo name="RFC" value="2119"/>
        <seriesInfo name="DOI" value="10.17487/RFC2119"/>
      </reference>
      <reference anchor="RFC8174">
        <front>
          <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
          <author fullname="B. Leiba" initials="B." surname="Leiba"/>
          <date month="May" year="2017"/>
          <abstract>
            <t>RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
          </abstract>
        </front>
        <seriesInfo name="BCP" value="14"/>
        <seriesInfo name="RFC" value="8174"/>
        <seriesInfo name="DOI" value="10.17487/RFC8174"/>
      </reference>
      <reference anchor="STRUCTURED-FIELDS">
        <front>
          <title>Structured Field Values for HTTP</title>
          <author fullname="M. Nottingham" initials="M." surname="Nottingham"/>
          <author fullname="P-H. Kamp" surname="P-H. Kamp"/>
          <date month="February" year="2021"/>
          <abstract>
            <t>This document describes a set of data types and associated algorithms that are intended to make it easier and safer to define and handle HTTP header and trailer fields, known as "Structured Fields", "Structured Headers", or "Structured Trailers". It is intended for use by specifications of new HTTP fields that wish to use a common syntax that is more restrictive than traditional HTTP field values.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="8941"/>
        <seriesInfo name="DOI" value="10.17487/RFC8941"/>
      </reference>
    </references>
  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA61a627cRpb+X09RI/9wgjQ7lpHMxMJkJhr5JsAXrSUlWAwG
g2qyulljksWwSMltW8G8xv7bZ9lH2SfZ75xTJIuSDAywYziw1F2Xc/nOdy6V
LMtU7/rKHumL0urTM/3C+srnpne+0S8vLs70SeVs0+uXrumV2Ww6e3WEdRnW
Lb4qfN6YGucUndn2WWuGap+Vfd9uXMh21rs2K7Eue3SocLrd+W5/pO2HVinX
dke674bQP3706Mmjx+q93V/7rsA1TW+7xvbZUzpTqdCbpvi7qXyDe/Y2qNYd
6b/2Pl/p4Lu+s9uAn/Y1/fA3pczQl747UjpTGn9cE6DlWp+RaPyJCHzh63qf
fOq73ZE+btsK9mjyNX8WcLjtj/Tbxsavzkz3Xv9iZEvuemhzMrS2613jV/rE
VG7ru8YZ/eT7R4ffySo/ND2pfdm43hb6vIchgvZbfVzbzuWGV9nauAoGYQv+
ZOiyde7rhRZP1/o8hznNR5co8tRcuWL5BXQxjfvI7jzSL7zfQfRXr07Sm4oQ
d6yd7bc/7ejTOzeerPXr/PVQVa5JbjxxpjPLL/6VG3PaVuc17/ppx2vu0/G1
6/PSVlWqI2DimuU3/5KS/6h5S6JelmXabOBZkwNbFzYvG/frAIf0pem1q9vO
X1k9BNvptnNXJt/rzV6XrnDNDne6HYxW6VxiAJFjiqKzIdiwUmHIS22C/vns
TdDALA7wHxy+0aXBmVuTw/15aarKNjvceO36UuOiK9zFt3e22mvfqPRY3Xtd
WERE7YDCeO8YqzCWQXjhP5LOaETcrjNtCVRVwDXOs1cG61kdhB3wZpvc4qJf
B4fzdWW6ndWt9xUjcqGPvsY5pc5Noza42Ye+2q/1cVE4upouWPHBtLO3DQ7N
rYOeMFCeDx1QTvKMokKYMFR90BubG2yLiodRaVqb4f6ttUV0Bm7Gau2HvsBh
xRoxq6J4WGBxxmxMSGt5Az7w19FObDz4GVLhjmDhEuxznQK7gGvep/LpAgbJ
oSLtwaro69E/V4hps+BGRQQImUoHZ7dwtYGxrl1V6cb3UAgn2aY0ZO70GrEN
UEUA6Wwx5ETAiswLJTYDMNhDieD1DmKHSZPadxZ8aZrQmg5O3GPzznQMS1ZK
w7vsgEIl960VI752RVFZpR4Qu3Yet7Iwnx645NcbpW5zf9CfPv3u3fOTH558
9/jmBkDcAoXQF3BorrCIDgHjiV1KawryaO+hTl0PjSPO174VvAAYWFqLGbad
r1MvjWhA+FDCCGJYFSFQeMK+b2bo6Y0JiCacdF1a6N9BpuiqvDKulkOHtkWG
0EbBZr3LB8CdjweMp9Wm4XCwoZebKdwrR3zDhq0hNv2rjvPctn128hLLQ+sb
wE8UhokZBMiFQ02GS6wklqRzF5AeSHbWGiAwqb+AGSSLWTtCopzyMMw8UCQM
wHaatt+6ACavBg75qO7Ggouc75AxI1tBXQpIqKvospGPPNTsh66ZtOVIFTqJ
ETLJlQpjlTiZ6IQWpbqxHRwHrw4gdrqezSIWKxhKCIZ0j/ABfAAgvnj29vmz
Z09/JED+8Oj7m5u1Po2hxmEf6ABgz3TBZpDVVpNoOrQ2d1s3RQW7TByoR7wQ
97sC9OiHXXlH8gVORwep2RD/+8//CnpklnEn7Fy6LYNpoRXB3+jWhICIBeFn
cuBEJERcTeSueH6GAECwgvDoYhupZyQbFS0wy7P0fwlWFJ6YhHBkVyCqhadt
weSjRvIRZpLjGhtdYz+A50ngJFHE5IEobMZ4VrUJ7+Nly1RWimU5QfpuzI/Q
ZN9KylrRd+NXexUd0gWRAQrVpjHIWHbHd5+eBRGMTAY+JK14kSRFdV8iWutf
KO+OwZnFO+aQYmevWHMGLCVABJ2r3Ucr9hjqDVBzK1+yiDgGWROFCPgDmSAS
EMXWeHo2ApH4rCc3jYF4bQ0R2YoFQRax10gIlCWCNV1ejgkUmG/oVifwmsQc
PVYjk4wwfUgx6zgHTRlWJRlWEjfI2koxUkHJnsUMk1hj+iWQ9j6brFQDq1BM
Kh3f7DxhnC1vG76RUxpH2oTIicDCIho4uWK9RwozHCsiv2Ih8SFRSpD6hmoE
yGMoXmAp/35oR6qZ+Gh2C65/8EC/k3KnZnCyPGg2NHUbQR+8vjy/OFjJv/rN
W/753bP/uDx99+wp/Xz+8vjVq+kHFVecv3x7+erp/NO88+Tt69fP3jyVzfhU
Lz5SB6+P//NA/Hrw9uzi9O2b41cHkmPSHGIo23ui8iRE4Q5V2JB3boNfsOcv
J2f/89+H38Uk/fjw8AmSdMzYh3/4Dr9QXK6ii0CT8iuMBb5oW+CKTkHgAeQt
PF8R4uB6kAXCwHZ2rf7454oKz+z3f/6T4vqBm0X9kplTjHlwbnPkxUz6wwPi
FXDXaY/ceY4OL0cagbjPna0KEu784t3lycUlzJs9P3326un5j1JgHILP+bwt
rYQbrwy4i0+jcwALzi/UlRFEhhDpKeabMYcg7D99gkSMrMfrw/Uh4SOmjpub
lSC9l773DE2j+6CR2NjqwAiqf6o0yyGs2CWKwhSolqKnrk0WLKoJigguE7iR
q9rSPM59YVfA2o7jkkx+ggZRcqKoMkNFx1Nx6BnCBOF+gt1A63OmWVOj/4ux
LSmKWM6M1cHB4ZPH60frx+vvV5fn+Jsdv1odVxQSgMoBgD3A0ht7pNRvv/3G
/dDCQ/pHfXDPPl6sXoDeG2EHun65kX1Rul2ZkSC+3S8qnK/c2q5X6p6yJ+Yp
qaQQtdfTflljNpX9WvSNkd8ISXnqWiqHTpuaBJRfOAJ/EbljjSI9B+28NZsg
IC8wMZWxXDVMlfqG7sRy1EFYjva7Z98ltRAiVjnUnlzNjjUlOYRDljUgBqMd
c5EY/RaLR6SP3sHLYzGVuGbacrQ0trjjPNYbETqTGIIHKt3Q3pL5pnTiprpL
qhbFms6FADMl7SrGLdTGxWpXP/zZdPuHY2UrJQYdMBtggka0Tm320t9KzZmW
VYSWkfIpB6ID7iG31Aql90G61nuMQlLca48Ho4v/EgvZRX5hDp+75TTHDPGy
L2UZSiVBI5l8IZMwUd5OQEJIslqNCYQMoV+cnadfRpQwC0zrgDzu6kDuuQtW
wTSQ3biK7WiotZlbBjjQdsSjXDqSkNR7c82ZprtfSps2DRR5qLmkmenMluqO
sQozUmRRtWWo7OL4S2YPUxOxs43txPUu3C3oWR9IiDJp7s4l6KEZxRaOGVoa
ppkaC/c+htd0PS5XX1FYcyPHeVnI4GCq80ahDr4Ws6Z7HwYVwODC+FwL4Oo7
OymMBagbCxvdU8A/DPOAZ2gyqU6L5AjpzynsYj8ANZP9o7rLRkH0NQuJJwyg
qLuyuI5xkFo27ZXZmiOpo95Gz0ABjzZ7hjqjgjDMqbFd7DcbIIDteccoqPdh
uu2ySiNDuSavhsKmUGJnz7QWm+YQu0EV6cCgpOxSfihBA0sSl9plYu9IPUrK
bhjIpeWcft9QWwO3ToXz2Ln7Zut2VN9TvTqP38TQwfaEegaS6SfaFr1GtuNZ
AJGK0GxCKpdgpEQ+s5iQJ1lmlcwdTMOhL3yfuC9twxxPwOQWssKV6ZwfwLFm
H6aeXCWkKaaI3A4r8KRl6snXc4ag65lUuXCMgqS8QwEGpJAlAboOqONL1WQS
8G+mL6dUkLo91Qe1UA8U0EGQi3oS2jG2sHeb9zVOfWdzv2vcR7Fl7QLOgqob
dMt2SVh3rlsmY8Q6WrpOijW6W5BPZp2a6NsSSCIC+wTxRqDkN1TCWEPv6aIc
329xYklq0Wl3DklkinmRLF7aqkVVFoZOMqPKQdw7GdtKo0WVvCkE9mhD8vfU
5cqcmawxjkUpoU/zMJ6J+OZhr8ahZWoeMih5nbaPyJDpku8EGUVYzmg4TYwZ
fO50E98j81QopDoRabdoVKUTje0pCWpzw9NKuGaeMZviit5BgrRZkVHGCmpM
EcJb4ISmoCbZ9UPsNq+p21gyYFBUnk3tOeffSDprfe4ommgBdS/XdjMZj8ud
OFj7YtAuqzsq/KSeNBW9PRmeutS2L30RJl75Ir4Ws6NgXCEBF4kFcEUbgPq+
CTTKiPp+ehBQ3OSLD2/mYF7WEvdrIZgJ4wVgLYNSMoRxTgStUFYwN8qgzc4d
1WRVVL0zTBS1RpQrzDTk1/ScRoPeeD9uJJRMgzQ9Sszg91uyIxnW5TwwpF4t
76WMGB3EjkymIPw8xuIXRHn0NMP2j/OcGu0GeRnxW+zT14KkDgvLZHjvcFJK
ZraQHi3UDh3SKdHoS39NpLgaO4n7DH57uJoPAeThPlo1z0jTsXS3SJ/zWHoj
0xYnmV0lVhKVGThn8fHpDm7iqxTAcoxCRDyaBsnclNwpNCejc3V5J08JhcQy
w2+oP03rzfuKYmIAg/CrqmwcumFLbdo4HesmMhwNKvOreR6/UtwOmOm1racn
Odh/t59GUFyeyriSjL9KsEw60kxGx0Lq/rqHSuUUCnNFpbjmvAZtkdKlKwrL
02EKaHvFMysX8kpaFRaxt+klMiSIwgAf0lGqCQZS0gY/dLk8+i6enADfeRCP
loEnn+U+0DBUVVjUUw1GGbDyzU5+QwNDrz70iLwGSsjx/DQJ9CI0Yi8xqbrw
sDgXxZjn9zcAiwONXwfTdZaBws8s5Bx6zdmwY3l0IioBbmCFrWNKD24HroA8
z4eOviW0rXR0bOSWwvKqnh9Gklc3ogyyc8QZT3I6esaakMdjZDXV4FIQkURm
rPins5MpLlkNCOSyCNwBtxk18FvvJDvFO/IIVQZj0dO58J4rmw5ldgYD8aNb
TmV1TGl3Quv29EAKO36KpAIr41lp01A7fYqEXrITeBrHbR3X2YVU1PFdKRl7
jFlqqra/suvdeqW+NHD4mvV2jRQGH/oxs4bScG6fcEHYk8PloYpmgZEOZ0gS
ZU6Da8H0SO5MUqfHb47vMpQzjbnhwSsXqy/js6B8kYmcN7cfzYj6aAwlier2
SHE5TTk4A8RMw70KIEEPAnJJHDK+MbUNB/HIbq/++Ne/fUX/U0o4+vbb6+vr
Ncmx9t3uW3p+2TVcsHxby0lRvvD1n9bjOOKb7N4/39zz4+2l32D757vC0Yjj
MwVv73Okoc/8P4WgC/iMz99ZDoicFn3+d9y+HOHFP3QTmUR+BNr4h6VL/t+3
k/n+D/1qV5VsJAAA

-->

</rfc>
