<?xml version="1.0" encoding="UTF-8"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> version='1.0' encoding='utf-8'?>
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.2.13 -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>

<?rfc toc="yes"?>
<?rfc tocindent="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<?rfc strict="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?> "rfc2629-xhtml.ent">

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-httpbis-client-hints-latest" category="exp">
     docName="draft-ietf-httpbis-client-hints-15" category="exp"
     obsoletes="" updates="" submissionType="IETF" xml:lang="en"
     tocInclude="true" sortRefs="true" symRefs="true" version="3"
     number="8942" consensus="true">
  <!-- xml2rfc v2v3 conversion 2.47.0 -->
  <front>
    <title>HTTP Client Hints</title>
    <seriesInfo name="RFC" value="8942"/>
    <author initials="I." surname="Grigorik" fullname="Ilya Grigorik">
      <organization>Google</organization>
      <address>
        <email>ilya@igvita.com</email>
        <uri>https://www.igvita.com/</uri>
      </address>
    </author>
    <author initials="Y." surname="Weiss" fullname="Yoav Weiss">
      <organization>Google</organization>
      <address>
        <email>yoav@yoav.ws</email>
        <uri>https://blog.yoav.ws/</uri>
      </address>
    </author>
    <date /> month="January" year="2021"/>
    <area>Applications and Real-Time</area>
    <workgroup>HTTP</workgroup>

    <keyword>Content Negotiation</keyword>
    <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
      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> "Client Hints."</t>
    </abstract>

    <note title="Note to Readers">

<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="http://httpwg.github.io/">http://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/client-hints">https://github.com/httpwg/http-extensions/labels/client-hints</eref>.</t>

    </note>
  </front>
  <middle>
    <section anchor="introduction" title="Introduction"> numbered="true" toc="default">
      <name>Introduction</name>
      <t>There are thousands of different devices accessing the web, each with
      different device capabilities and preference information. These device
      capabilities include hardware and software characteristics, as well as
      dynamic user and user agent preferences. Historically, applications that
      wanted the server to optimize content delivery and user experience based
      on such capabilities had to rely on passive identification (e.g., by
      matching the User-Agent header field (Section 5.5.3 of <xref target="RFC7231"/>) (<xref
      target="RFC7231" sectionFormat="of" section="5.5.3"/>) against an established database of
      user agent signatures), use HTTP cookies <xref target="RFC6265"/> target="RFC6265"
      format="default"/> and URL parameters, or use some combination of these
      and similar mechanisms to enable ad hoc content negotiation.</t>
      <t>Such techniques are expensive to set up and maintain, maintain and are not
      portable across both applications and servers. They also make it hard
      for both user agent and server to understand which data are required and is
      are in use during the negotiation:</t>

<t><list style="symbols">
  <t>User
      <ul spacing="compact">
        <li>User agent detection cannot reliably identify all static
	variables, cannot infer dynamic user agent preferences, requires an
	external device database, is not cache friendly, and is reliant on a
	passive fingerprinting surface.</t>
  <t>Cookie-based surface.</li>
        <li>Cookie-based approaches are not portable across applications and
	servers, impose additional client-side latency by requiring JavaScript
	execution, and are not cache friendly.</t>
  <t>URL friendly.</li>
        <li>URL parameters, similar to cookie-based approaches, suffer from
	lack of portability, portability and are hard to deploy due to a requirement to
	encode content negotiation data inside of the URL of each resource.</t>
</list></t>
	resource.</li>
      </ul>
      <t>Proactive content negotiation (Section 3.4.1 of <xref target="RFC7231"/>) (<xref target="RFC7231"
      sectionFormat="of" section="3.4.1"/>) offers an alternative approach;
      user agents use specified, well-defined request headers to advertise
      their capabilities and characteristics, so that servers can select (or
      formulate) an appropriate response based on those request headers (or on
      other, implicit characteristics).</t>

      <t>However, traditional proactive content negotiation techniques often
      mean that user agents send these request headers prolifically. This
      causes performance concerns (because it creates “bloat” "bloat" in requests), as
      well as privacy issues; passively providing such information allows
      servers to silently fingerprint the user.</t>

      <t>This document defines Client Hints, a framework that enables servers
      to opt-in to specific proactive content negotiation features, adapting
      their content accordingly, as well as guidelines for content negotiation
      mechanisms that use the framework. This document also defines a new
      response header, Accept-CH, that allows an origin server to explicitly
      ask that user agents send these headers in requests.</t>

      <t>Client Hints mitigate performance concerns by assuring that user
      agents will only send the request headers when they’re they're actually going to
      be used, and they mitigate privacy concerns of passive fingerprinting by requiring
      explicit opt-in and disclosure of required headers by the server through
      the use of the Accept-CH response header, turning passive fingerprinting
      vectors into active ones.</t>
      <t>The document does not define specific usages of Client Hints. Such
      usages need to be defined in their respective specifications.</t>
      <t>One example of such usage is the User Agent User-Agent Client Hints <xref target="UA-CH"/>.</t>
      target="UA-CH" format="default"/>.</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>
        <t>This document uses the Augmented Backus-Naur Form (ABNF) notation
	of <xref target="RFC5234"/>.</t> target="RFC5234" format="default"/>.</t>
      </section>
    </section>
    <section anchor="client-hint-request-header-fields" title="Client Hint numbered="true" toc="default">
      <name>Client Hints Request Header Fields"> Fields</name>
      <t>A Client Hint Hints request header field is a an HTTP header field that is
      used by HTTP user agents to indicate data that can be used by the server
      to select an appropriate response. Each one conveys user agent user-agent
      preferences that the server can use to adapt and optimize the
      response.</t>

      <section anchor="sending-client-hints" title="Sending numbered="true" toc="default">
        <name>Sending Client Hints"> Hints</name>
        <t>User agents choose what Client Hints to send in a request based on
	their default settings, user configuration, and server preferences
	expressed in <spanx style="verb">Accept-CH</spanx>. <tt>Accept-CH</tt>. The user agent and server can use an
	opt-in mechanism outlined below to negotiate which header fields need
	to be sent to allow for efficient content adaption, and they can optionally use
	additional mechanisms (e.g., as outlined in <xref target="CLIENT-HINTS-INFRASTRUCTURE"/>)
	target="CLIENT-HINTS-INFRASTRUCTURE" format="default"/>) to negotiate
	delegation policies that control access of third parties to those same
	header fields. User agents SHOULD <bcp14>SHOULD</bcp14> require an opt-in to send any hints
	that are not listed in considered low-entropy.  See the low-entropy hint table
	at <xref target="CLIENT-HINTS-INFRASTRUCTURE"/>.</t> target="CLIENT-HINTS-INFRASTRUCTURE" format="default"/> for
	examples of hints that expose low amounts of entropy.</t>
        <t>Implementers need to be aware of the fingerprinting implications
	when implementing support for Client Hints, Hints and follow the
	considerations outlined in the <xref target="security-considerations">Security Considerations</xref> Security Considerations section of this document.</t>
	document (see <xref target="security-considerations"
	format="default"/>).</t>
      </section>
      <section anchor="server-processing-of-client-hints" title="Server numbered="true" toc="default">
        <name>Server Processing of Client Hints"> Hints</name>
        <t>When presented with a request that contains one or more Client Hint Hints
	header fields, servers can optimize the response based upon the
	information in them. When doing so, and if the resource is cacheable,
	the server MUST <bcp14>MUST</bcp14> also generate a Vary response header field (Section 7.1.4 of <xref target="RFC7231"/>)
	(<xref target="RFC7231" sectionFormat="of" section="7.1.4"/>) to indicate which
	hints can affect the selected response and whether the selected
	response is appropriate for a later request.</t>
        <t>Servers MUST <bcp14>MUST</bcp14> ignore hints they do not understand nor support. There
	is no mechanism for servers to indicate to user agents that hints were
	ignored.</t>
        <t>Furthermore, the server can generate additional response header
	fields (as specified by the hint or hints in use) that convey related
	values to aid client processing.</t>
      </section>
    </section>
    <section anchor="advertising-server-support" title="Advertising numbered="true" toc="default">
      <name>Advertising Server Support"> Support</name>
      <t>Servers can advertise support for Client Hints using the mechanism described below.</t>
      <section anchor="accept-ch" title="The numbered="true" toc="default">
        <name>The Accept-CH Response Header Field"> Field</name>
        <t>The Accept-CH response header field indicates server support for
	the hints indicated in its value. Servers wishing to receive user agent
	information through Client Hints SHOULD <bcp14>SHOULD</bcp14> add the Accept-CH response
	header to their responses as early as possible.</t>
        <t>Accept-CH is a Structured Header <xref target="I-D.ietf-httpbis-header-structure"/>.
	target="RFC8941" format="default"/>. Its
	value MUST <bcp14>MUST</bcp14> be an sf-list (Section 3.1 of <xref target="I-D.ietf-httpbis-header-structure"/>) (<xref
	target="RFC8941" sectionFormat="of"
	section="3.1"/>) whose members are tokens (Section 3.3.4 of <xref target="I-D.ietf-httpbis-header-structure"/>). Tokens (<xref
	target="RFC8941" sectionFormat="of"
	section="3.3.4"/>). Its ABNF is:</t>

<figure><artwork

<sourcecode type="abnf"><![CDATA[
  Accept-CH = sf-list
]]></artwork></figure>
]]></sourcecode>
        <t>For example:</t>

<figure><artwork type="example"><![CDATA[
<sourcecode type="http-message"><![CDATA[
Accept-CH: Sec-CH-Example, Sec-CH-Example-2
]]></artwork></figure>
]]></sourcecode>
        <t>When a user agent receives an HTTP response containing <spanx style="verb">Accept-CH</spanx>, that
	<tt>Accept-CH</tt>, it indicates that the origin opts-in to receive
	the indicated request header fields for subsequent same-origin
	requests. The opt-in MUST <bcp14>MUST</bcp14> be ignored if delivered over non-secure
	transport (using a scheme different from HTTPS). It SHOULD <bcp14>SHOULD</bcp14> be
	persisted and bound to the origin to enable delivery of Client Hints
	on subsequent requests to the server’s server's origin, for the duration of the user’s
	user's session (as defined by the user agent). An opt-in overrides
	previous persisted opt-in values and SHOULD <bcp14>SHOULD</bcp14> be persisted in its
	stead.</t>
        <t>Based on the Accept-CH example above, which is received in response
	to a user agent navigating to “https://site.example”, "https://site.example", and delivered
	over a secure transport, persisted Accept-CH preferences will be bound
	to “https://site.example”. "https://site.example". It will then use it for navigations to e.g., “https://site.example/foobar.html”,
	for example, "https://site.example/foobar.html", but not to e.g., “https://foobar.site.example/”. to, for example,
	"https://foobar.site.example/". It will similarly use the preference
	for any same-origin resource requests (e.g., to “https://site.example/image.jpg”)
	"https://site.example/image.jpg") initiated by the page constructed
	from the navigation’s navigation's response, but not to cross-origin resource
	requests (e.g., “https://thirdparty.example/resource.js”). "https://thirdparty.example/resource.js"). This
	preference will not extend to resource requests initiated to “https://site.example”
	"https://site.example" from other origins (e.g., from navigations to “https://other.example/”).</t>
	"https://other.example/").</t>
      </section>
      <section anchor="interaction-with-caches" title="Interaction numbered="true" toc="default">
        <name>Interaction with Caches"> Caches</name>
        <t>When selecting a response based on one or more Client Hints, and if
	the resource is cacheable, the server needs to generate a Vary
	response header field (<xref target="RFC7234"/>) <xref target="RFC7234" format="default"/> to
	indicate which hints can affect the selected response and whether the
	selected response is appropriate for a later request.</t>

<figure><artwork type="example"><![CDATA[

<sourcecode type="http-message"><![CDATA[
Vary: Sec-CH-Example
]]></artwork></figure>
]]></sourcecode>
        <t>The above example indicates that the cache key needs to include the
	Sec-CH-Example header field.</t>

<figure><artwork type="example"><![CDATA[

<sourcecode type="http-message"><![CDATA[
Vary: Sec-CH-Example, Sec-CH-Example-2
]]></artwork></figure>
]]></sourcecode>
        <t>The above example indicates that the cache key needs to include the
	Sec-CH-Example and Sec-CH-Example-2 header fields.</t>
      </section>
    </section>
    <section anchor="security-considerations" title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <section anchor="information-exposure" title="Information Exposure"> numbered="true" toc="default">
        <name>Information Exposure</name>
        <t>Request header fields used in features relying on this document
	expose information about the user’s user's environment to enable
	privacy-preserving proactive content negotiation, negotiation and avoid exposing
	passive fingerprinting vectors. However, implementers need to bear in
	mind that in the worst case, uncontrolled and unmonitored active
	fingerprinting is not better than passive fingerprinting. In order to
	provide user privacy benefits, user agents need to apply further
	policies that prevent abuse of the information exposed by features
	using Client Hints.</t>

        <t>The information exposed by features might reveal new information
	about the user user, and implementers ought to consider the following
	considerations, recommendations, and best practices.</t>

        <t>The underlying assumption is that exposing information about the
	user as a request header is equivalent (from a security perspective)
	to exposing this information by other means. (For example, if the request’s
	request's origin can access that information using JavaScript APIs, APIs
	and transmit it to its servers).</t> servers.)</t>

        <t>Because Client Hints is an explicit opt-in mechanism, that it means
	that servers that want wanting access to information about the user’s user's
	environment need to actively ask for it, enabling clients and privacy
	researchers to keep track of which origins collect that data, and
	potentially act upon it.
    The header-based opt-in means that removal of passive fingerprinting vectors
    is possible, such as possible. As an example, the user agent can reduce the information
    exposed by the User-Agent string (enabling string, while enabling active access to that
    information through User-Agent Client Hints (<xref target="UA-CH"/>) or otherwise <xref target="UA-CH"
    format="default"/>.
    Otherwise, the user agent can expose information already available through
    script (e.g., the <eref target="https://wicg.github.io/savedata/#save-data-request-header-field">Save-Data Save-Data Client Hint</eref>), Hints <eref brackets="angle"
    target="https://wicg.github.io/savedata/#save-data-request-header-field"></eref>),
    without increasing the passive fingerprinting surface. User agents supporting
    Client Hints features which send certain information to opted-in servers SHOULD
    <bcp14>SHOULD</bcp14> avoid sending the equivalent information passively.</t>

        <t>Therefore, features relying on this document to define Client Hint
	headers MUST NOT <bcp14>MUST NOT</bcp14> provide new information that is otherwise not made
	available to the application by the user agent, such as existing
	request headers, HTML, CSS, or JavaScript.</t>

        <t>Such features need to take into account the following aspects of
	the information exposed:</t>

<t><list style="symbols">
  <t>Entropy - Exposing exposed information:</t>

        <dl newline="false" spacing="normal">
          <dt>Entropy:</dt>
	  <dd>Exposing highly granular data can be used to help
	  identify users across multiple requests to different
	  origins. Reducing the set of header field values that can be
	  expressed, or restricting them to an enumerated range where the
	  advertised value is close to but is not an exact representation of
	  the current value, can improve privacy and reduce risk of
	  linkability by ensuring that the same value is sent by multiple users.</t>
  <t>Sensitivity -  The
	  users.</dd>

          <dt>Sensitivity:</dt>
	  <dd>The feature SHOULD NOT <bcp14>SHOULD NOT</bcp14> expose user-sensitive
	  information. To that end, information available to the application,
	  but gated behind specific user actions (e.g., a permission prompt or
	  user activation) SHOULD NOT activation), <bcp14>SHOULD NOT</bcp14> be exposed as a Client Hint.</t>
  <t>Change Hint.</dd>

          <dt>Change over time - The time:</dt>
	  <dd>The feature SHOULD NOT <bcp14>SHOULD NOT</bcp14> expose user
	  information that changes over time, unless the state change itself
	  is also exposed (e.g., through JavaScript callbacks).</t>
</list></t> callbacks).</dd>
        </dl>
        <t>Different features will be positioned in different points in the
	space between low-entropy, non-sensitive non-sensitive, and static information (e.g.,
	user agent information), information) and high-entropy, sensitive sensitive, and dynamic
	information (e.g., geolocation). User agents need to consider the
	value provided by a particular feature vs vs. these considerations, considerations and
	may wish to have different policies regarding that tradeoff on a
	per-feature or other fine-grained basis.</t>

        <t>Implementers ought to consider both user- and server- controlled server-controlled
	mechanisms and policies to control which Client Hints header fields
	are advertised:</t>

<t><list style="symbols">
  <t>Implementers SHOULD

        <ul spacing="normal">
          <li>Implementers <bcp14>SHOULD</bcp14> restrict delivery of some or all Client
	  Hints header fields to the opt-in origin only, unless the opt-in
	  origin has explicitly delegated permission to another origin to
	  request Client Hints header fields.</t>
  <t>Implementers considering fields.</li>
          <li>Implementers that consider providing user choice user-choice mechanisms that
	  allow users to balance privacy concerns against bandwidth
	  limitations need to also consider that explaining to users the
	  privacy implications involved, involved to users, such as the risks of passive
	  fingerprinting, may be  challenging or even impractical.</t>
  <t>Implementations impractical.</li>
          <li>Implementations specific to certain use cases or threat models MAY
	  <bcp14>MAY</bcp14> avoid transmitting some or all of the Client Hints header
	  fields. For example, avoid transmission of header fields that can
	  carry higher risks of linkability.</t>
</list></t> linkability.</li>
        </ul>

      <t>User agents MUST <bcp14>MUST</bcp14> clear persisted opt-in preferences when any one of
	site data, browsing history, browsing cache, cookies, or similar, similar are cleared.</t>
      </section>
      <section anchor="deployment-and-security-risks" title="Deployment numbered="true" toc="default">
        <name>Deployment and Security Risks"> Risks</name>
        <t>Deployment of new request headers requires several considerations:</t>

<t><list style="symbols">
  <t>Potential
        <ul spacing="compact">
          <li>Potential conflicts due to existing use of a header field name</t>
  <t>Properties name</li>

          <li>Properties of the data communicated in a header field value</t>
</list></t> value</li>
        </ul>
        <t>Authors of new Client Hints are advised to carefully consider
	whether they need to be able to be added by client-side content (e.g., scripts),
	scripts) or whether they the Client Hints need to be exclusively set by the user
	agent. In the latter case, the Sec- prefix on the header field name
	has the effect of preventing scripts and other application content
	from setting them in user agents. Using the “Sec-“ "Sec-" prefix signals to
	servers that the user agent - -- and not application content - -- generated
	the values. See <xref target="FETCH"/> target="FETCH" format="default"/> for more
	information.</t>

        <t>By convention, request headers that are Client Hints are encouraged
	to use a CH- prefix, to make them easier to identify as using this
	framework; for example, CH-Foo or, with a “Sec-“ "Sec-" prefix,
	Sec-CH-Foo. Doing so makes them easier to identify programmatically
	(e.g., for stripping unrecognised unrecognized hints from requests by privacy
	filters).</t>
        <t>A Client Hints request header negotiated using the Accept-CH opt-in
	mechanism MUST <bcp14>MUST</bcp14> have a field name that matches sf-token (Section 3.3.4 of <xref target="I-D.ietf-httpbis-header-structure"/>).</t>
	(<xref target="RFC8941" sectionFormat="of"
	section="3.3.4"/>).</t>
      </section>
      <section anchor="abuse-detection" title="Abuse Detection"> numbered="true" toc="default">
        <name>Abuse Detection</name>
        <t>A user agent that tracks access to active fingerprinting
	information SHOULD <bcp14>SHOULD</bcp14> consider emission of Client Hints headers similarly similar
	to the way it would consider access to the equivalent API.</t>

        <t>Research into abuse of Client Hints might look at how HTTP
	responses to requests that contain Client Hints differ from those with
	different values, values and from those without. without values. This might be used to reveal
	which Client Hints are in use, allowing researchers to further analyze
	that use.</t>
      </section>
    </section>
    <section anchor="cost-of-sending-hints" title="Cost numbered="true" toc="default">
      <name>Cost of Sending Hints"> Hints</name>
      <t>Sending Client Hints to the server incurs an increase in request byte size. Some
      size. Some of this increase can be mitigated by HTTP header
      compression schemes, but each new hint sent will still lead to some
      increased bandwidth usage. Servers SHOULD <bcp14>SHOULD</bcp14> take that into account when
      opting in to receive Client Hints, Hints and SHOULD NOT <bcp14>SHOULD NOT</bcp14> opt-in to receive
      hints unless they are to be used for content adaptation purposes.</t>

      <t>Due to request byte size increase, features relying on this document
      to define Client Hints MAY <bcp14>MAY</bcp14> consider restricting sending those hints to
      certain request destinations <xref target="FETCH"/>, target="FETCH" format="default"/>,
      where they are more likely to be useful.</t>
    </section>
    <section anchor="iana-considerations" title="IANA Considerations"> numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>Features relying on this document are expected to register added
      request header fields in the Permanent "Permanent Message Header Fields Field Names" registry (<xref target="RFC3864"/>).</t>
      <xref target="RFC3864" format="default"/>.</t>

      <t>This document defines the “Accept-CH” "Accept-CH" HTTP response header field, and registers field;
      IANA has registered it in the same registry.</t>

      <section anchor="iana-accept-ch" title="Accept-CH">
<t><list style="symbols">
  <t>Header numbered="true" toc="default">
        <name>Accept-CH</name>
        <dl newline="false" spacing="normal">
          <dt>Header field name: Accept-CH</t>
  <t>Applicable protocol: HTTP</t>
  <t>Status: experimental</t>
  <t>Author/Change controller: IETF</t>
  <t>Specification document(s): <xref target="accept-ch"/> name:</dt>
	  <dd>Accept-CH</dd>
          <dt>Applicable protocol:</dt>
	  <dd>HTTP</dd>
          <dt>Status:</dt>
	  <dd>experimental</dd>
          <dt>Author/Change controller:</dt>
	  <dd>IETF</dd>
          <dt>Specification document(s):</dt>
	  <dd><xref target="accept-ch" format="default"/> of this document</t>
  <t>Related information: for
	  RFC</dd>
          <dt>Related information:</dt>
	  <dd>for Client Hints</t>
</list></t> Hints</dd>
        </dl>
      </section>
    </section>
  </middle>
  <back>

    <references title='Normative References'>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3864.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5234.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7231.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7234.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"/>

<!-- draft-ietf-httpbis-header-structure-19: RFC 8941 -->
<reference  anchor="RFC3864" target='https://www.rfc-editor.org/info/rfc3864'> anchor='RFC8941' target='https://www.rfc-editor.org/info/rfc8941'>
<front>
<title>Registration Procedures
<title>Structured Field Values for Message Header Fields</title>
<author initials='G.' surname='Klyne' fullname='G. Klyne'><organization /></author> HTTP</title>
<author initials='M.' initials='M' surname='Nottingham' fullname='M. Nottingham'><organization /></author> fullname='Mark Nottingham'>
    <organization />
</author>
<author initials='J.' surname='Mogul' fullname='J. Mogul'><organization /></author> initials='P-H.' surname='Kamp' fullname='Poul-Henning Kamp'>
    <organization />
</author>
<date year='2004' month='September' month='January' year='2021' />
<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'/> value='8941' />
<seriesInfo name='DOI' value='10.17487/RFC3864'/> value='10.17487/RFC8941' />
</reference>
      </references>

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

        <reference  anchor="RFC5234" target='https://www.rfc-editor.org/info/rfc5234'> anchor="UA-CH" target="https://wicg.github.io/ua-client-hints/">
          <front>
<title>Augmented BNF for Syntax Specifications: ABNF</title>
            <title>User-Agent Client Hints</title>
            <author initials='D.' surname='Crocker' fullname='D. Crocker' role='editor'><organization /></author> initials="M." surname="West" fullname="Mike West">
              <organization>Google</organization>
            </author>
            <author initials='P.' surname='Overell' fullname='P. Overell'><organization /></author> initials="Y." surname="Weiss" fullname="Yoav Weiss">
              <organization>Google</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> month="August" year="2020"/>
          </front>
<seriesInfo name='STD' value='68'/>
<seriesInfo name='RFC' value='5234'/>
<seriesInfo name='DOI' value='10.17487/RFC5234'/>
</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="CLIENT-HINTS-INFRASTRUCTURE" target="https://wicg.github.io/client-hints-infrastructure/">
          <front>
            <title>Client Hints Infrastructure</title>
            <author initials="Y." surname="Weiss" fullname="Yoav Weiss">
              <organization>Google</organization>
            </author>
            <date year="n.d."/>
  </front>
</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="I-D.ietf-httpbis-header-structure">
<front>
<title>Structured Field Values 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='June' day='3' year='2020' />

<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='Internet-Draft' value='draft-ietf-httpbis-header-structure-19' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-httpbis-header-structure-19.txt' />
</reference>

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

<reference anchor="UA-CH" target="https://wicg.github.io/ua-client-hints/">
  <front>
    <title>User Agent Client Hints</title>
    <author initials="M." surname="West" fullname="Mike West">
      <organization>Google</organization>
    </author>
    <author initials="Y." surname="Weiss" fullname="Yoav Weiss">
      <organization>Google</organization>
    </author>
    <date year="n.d."/> month='July' year='2020'/>
          </front>
        </reference>

        <reference anchor="FETCH" target="https://fetch.spec.whatwg.org/">
          <front>
    <title>Fetch</title>
    <author initials="A." surname="van Kesteren" fullname="Anne van Kesteren">
      <organization>Mozilla</organization>
            <title>Fetch - Living Standard</title>
            <author>
              <organization>WHATWG</organization>
            </author>
            <date year="n.d."/> month="September" year="2020"/>
          </front>
         <refcontent>Living Standard</refcontent>
        </reference>

      </references>

<section anchor="changes" title="Changes">

<section anchor="since-00" title="Since -00">
<t><list style="symbols">
  <t>Issue 168 (make Save-Data extensible) updated ABNF.</t>
  <t>Issue 163 (CH review feedback) editorial feedback from httpwg list.</t>
  <t>Issue 153 (NetInfo API citation) added normative reference.</t>
</list></t>

</section>
<section anchor="since-01" title="Since -01">
<t><list style="symbols">
  <t>Issue 200: Moved Key reference to informative.</t>
  <t>Issue 215: Extended passive fingerprinting and mitigation considerations.</t>
  <t>Changed document status to experimental.</t>
</list></t>

</section>
<section anchor="since-02" title="Since -02">
<t><list style="symbols">
  <t>Issue 239: Updated reference to CR-css-values-3</t>
  <t>Issue 240: Updated reference for Network Information API</t>
  <t>Issue 241: Consistency in IANA considerations</t>
  <t>Issue 250: Clarified Accept-CH</t>
</list></t>

</section>
<section anchor="since-03" title="Since -03">
<t><list style="symbols">
  <t>Issue 284: Extended guidance for Accept-CH</t>
  <t>Issue 308: Editorial cleanup</t>
  <t>Issue 306: Define Accept-CH-Lifetime</t>
</list></t>

</section>
<section anchor="since-04" title="Since -04">
<t><list style="symbols">
  <t>Issue 361: Removed Downlink</t>
  <t>Issue 361: Moved Key to appendix, plus other editorial feedback</t>
</list></t>

</section>
<section anchor="since-05" title="Since -05">
<t><list style="symbols">
  <t>Issue 372: Scoped CH opt-in and delivery to secure transports</t>
  <t>Issue 373: Bind CH opt-in to origin</t>
</list></t>

</section>
<section anchor="since-06" title="Since -06">
<t><list style="symbols">
  <t>Issue 524: Save-Data is now defined by NetInfo spec, dropping</t>
  <t>PR 775: Removed specific features to be defined in other specifications</t>
</list></t>

</section>
<section anchor="since-07" title="Since -07">
<t><list style="symbols">
  <t>Issue 761: Clarified that the defined headers are response headers.</t>
  <t>Issue 730: Replaced Key reference with Variants.</t>
  <t>Issue 700: Replaced ABNF with structured headers.</t>
  <t>PR 878: Removed Accept-CH-Lifetime based on feedback at IETF 105</t>
</list></t>

</section>
<section anchor="since-08" title="Since -08">
<t><list style="symbols">
  <t>PR 985: Describe the bytesize cost of hints.</t>
  <t>PR 776: Add Sec- and CH- prefix considerations.</t>
  <t>PR 1001: Clear CH persistence when cookies are cleared.</t>
</list></t>

</section>
<section anchor="since-09" title="Since -09">
<t><list style="symbols">
  <t>PR 1064: Fix merge issues with “cost of sending hints”.</t>
</list></t>

</section>
<section anchor="since-10" title="Since -10">
<t><list style="symbols">
  <t>PR 1072: LC feedback from Julian Reschke.</t>
  <t>PR 1080: Improve list style.</t>
  <t>PR 1082: Remove section mentioning Variants.</t>
  <t>PR 1097: Editorial feedback from mnot.</t>
  <t>PR 1131: Remove unused references.</t>
  <t>PR 1132: Remove nested list.</t>
</list></t>

</section>
<section anchor="since-11" title="Since -11">
<t><list style="symbols">
  <t>PR 1134: Re-insert back section.</t>
</list></t>

</section>
<section anchor="since-12" title="Since -12">
<t><list style="symbols">
  <t>PR 1160: AD review.</t>
</list></t>

</section>
<section anchor="since-13" title="Since -13">
<t><list style="symbols">
  <t>PR 1171: Genart review.</t>
</list></t>

</section>
<section anchor="since-14" title="Since -14">
<t><list style="symbols">
  <t>PR 1220: AD review.</t>
</list></t>

</section>
</section>
    </references>

    <section numbered="false" anchor="acknowledgements" title="Acknowledgements"> toc="default">
      <name>Acknowledgements</name>
      <t>Thanks to Mark Nottingham, Julian Reschke, Chris Bentzel, Ben Greenstein, Tarun Bansal, Roy Fielding, Vasiliy Faronov, Ted Hardie, Jonas Sicking, Martin Thomson, <contact fullname="Mark Nottingham"/>, <contact
      fullname="Julian Reschke"/>, <contact fullname="Chris Bentzel"/>,
      <contact fullname="Ben Greenstein"/>, <contact fullname="Tarun
      Bansal"/>, <contact fullname="Roy Fielding"/>, <contact
      fullname="Vasiliy Faronov"/>, <contact fullname="Ted Hardie"/>,
      <contact fullname="Jonas Sicking"/>, <contact fullname="Martin
      Thomson"/>, and numerous other members of the IETF
      HTTP Working Group for invaluable help and feedback.</t>
    </section>
  </back>

<!-- ##markdown-source:
H4sIAHrWEF8AA81c63LbyJX+z6folX+MlCKom2/DSaYiS/ZYie3xSnJSU6lU
FgSaZEcgwKAB0hyX8yz7LPtk+51zuhsNkrK9t6pNVcYU0ZfTp8/lOxcwSZJB
Y5pCj9Xru7v36rIwumzUa1M2dpBOJrVejQd5lZXpAkPyOp02idHNNJk3zXJi
bJLxhGROE5IibbRtBjn+GatPVxd3Lz8PMvwxq+rNWOmPy8HALOuxaurWNmcn
J9+fnA3SWqdjdbFcFgZDTVValZa5utFpkdyZhR6sq/p+VlftUkgc3OsNvsrH
6rpsdF3qJrkisrrvhSTFJEXfVmWpZ93flxWmY9g7UNcY3nkwsA32/ltaVCUO
sNF2sDRj9ZemyoYK/zFljhlDZau6qfXU4tNm4T40tcnwKKsWy5Q+2HYSPuPD
AhMxzJSFKfVfB4O0beZVPR6oZKDwP1NanGekfqoNeGXu+Uvh+XWxSfvfV/Us
Lc2vTPJY/VRVs0LzA71ITTFWBjN+b2Yr06QjbM2P2hoHoTuz4+Pj9Xo96p4f
94j4ZaT+rI21EQW/VOkq+vJr228w/Pf0n9Ha7u49KarZyD09HgzKql5gpZUG
K9TNq8vz508fu49Pzs79x2dn56fdR/728s31y3d3yevrd3e3yfW7VzcXt3c3
Hy7vPty8HPOuTVrPdBMd2mSz0cw083YyMtVxT25NOa1TXGGbNW2tj2W+aEWs
EJC4eBwPCxeJ/wkb9zHyAVY+wEyQs8WWp2dPn9DHDxfJ5etvOl+b9lSzd6YP
VtfqYkbn6un7F8/zls4D5Y6P89bc6/jbB0Xjf4szSr16efcQB6a6yeYju9TZ
aD1Pm/VshDV6B39FI758zIuRWqWl+iMOpWtd9mi8gAXZ97RP6tvqV1MU6WAw
SJJEpRPIC6zAYMD2NddTGACrlnWFL3HBZJfYDpWdHYKtUWlRVGuFi1rp2tIX
Vhc6a1Qz1ypdYvqyxmCtam2XsJlaQWRUqmZYssSX/2hB4lBNUqtz1S5pTUxs
6eJTuvjvrMrmKRGma2Mbk8E4pZZMNBakOSasouY6zUHECOIPuonsTA+jtWCw
a62qKY6h2nKNw5tyJiTDkIPPVm+vBcp0lmIJZRplrCqrBmZbp7VazzUorYnc
jaK1MJL2yofsFmhJXn2uF8qwfbVqUjVztdQ1a02ZaR4J/qzSbDMaDO7m2AE+
rCUjHG4A13iRZXrZQKM6Lgp9WD5tAvMzDCVS6VZyfNMY+mOuTc1fV9Pt0/Fd
fPGGcRj4mBkOCMpT7NTQMrPW5Lpg6mgFurEM3pFFAo9tm807BmYVJOQfrYGg
bNR9Wa1LusCDWKFHB04IwV79t3f0n6b6242sMBhcGZu11rrVG+YSeVIo1j2J
aJGClU5yWHjJExPz2Rsrsvb0VwH5GRwGUJCsZ79fn5PqHQ1xmwY0G5KQbA5e
5Ap8/a1XWJppRzL4+EJG2OP37QRQ4Dhe8PhHXOOf3e4/8e7BRoJAuqAJaUBb
dhtgffpnHRvFH3+A727rTA+yKhcxgcHB1fEhHNMDG/YuS3S7Bcl3yhb8T6I/
4pqJnfa4SCe6sD0nQ0fgy1iYPIcpGzwiAFNXOZwJY487iL1mVYLKtBbEWbqX
3EynZGtIclfQPPASYotrEy1Qaz0ZKp2CzSxM28NximU6wU01RlunGJpH4FnE
xJHC/pDmfbNMmRUt+AWDka+JQNZEKDz/sc+OrDUUF//mG1hOkzljgVmd1Yjo
gGl5jckAOBlJ85AMXIcGWRfXKXQo5wOLWpI2VsvGLMyvnYaR9uDZptsKBg2E
8WHFFkJcWI96B5ynOa1Xa6gSBixTsBeKawjumamjRB3q0WwEy7WB6MOP+Asg
b5qIN3XWY2p0kavDW803q56MnozO6So/fXJY5vPnIzAhhcNpyA7BdKSQeTsH
fcDOKVFK4yNmWTMrUwId9ohNryhkVlX3RD8vTBjh82c++oebNzhEDafVsK2o
xFLZakG8WkxMGYxKw7fOFwpeFrDAC40bLY1dsNvRJUjDgFzNq2yfKYNY3xJD
G0wrDdlBlmFifMlcZEfQwAnxLrAaZYP/izmnkWT7l0DUsk9WV9ZZ9HQ7JnAG
mUUVd1zYCsvdsw8h0WT95ZkR47p5RAg0GQsQyHemidjNVJAJNzUZKDYK5P+I
ZTnAq7vn6MzjATx/IjhKtsnB6cwbIzoRZMngRBsvRERvgTAB8zNgiJoeajLj
MhyaiLX66rKtJUNPJDsvsjZ1mRZeY73gDIM/hU2A9SLpz1mp5GBMGBYGqWmQ
dLjEma7hMkEqjmvbegrjP+JTXrKQJaI+DD1oYfvg3T10bUPy14QF0jw39BS0
OwNpwSRFwWOZbUi/5JxEyR/SVXqb1WbZ4MA6a53zjESnf0wheVv+vWhDArL9
p6GAjQwnFqoWICW7J+WQo5GV2HSbsqhhpVwvi2oDCRFk4C+HQQYrDvuYffCO
hQ7KT6cWFWSK8ZHtOC6YnRQ06/0XYWKwMOejx6PTHQtT0YFYVtKCZYUX8mf+
oYfg2DwAOcPaEdQi+50IUsp30M0eHLTjZHacAnR1B1Q5SHsItSU/1JIEHDG9
+wBusN97ESWvQiaN0COLGoQQhmGLkCMw9XW11isaBGAeJPErgLwzboJzFzot
5UAxFx3g1XvIw/oFuxI4ODJghliAubYHXLF3hpvCaSJ8zBgQAw8QO6fNQQTN
yRlE3tZBXodpfvDaDSOE3VcmF9UmQBaBJw40bC/SMAVOg1mRVQjhw4N4Ogae
oAqKBPUjxChsEj/S2wfuG5E37yiSl33lFqZaXCCWz9Nl4wwziZ8bDGRU1XRM
tncdY7aA9b61Y6/nrpXPHI4x2jo3u58QTGCt9XYUMewCjKEs6ngN0QHWmZky
8kzwlyywYHtq778oWl6kIjnArfQSFQuI9Yy0Z69wTWgP6z3b1kYcc1Ul6PBb
7sgyYjSOCjbfERbMmpZjkFnlwr5ewOZlMmxOZnW/1+kZfs8PLyW0Vo6ApahA
eAi62GN7sjA/xodzxAmzuRdcb2gfjPlwRW1d0tYPkLeCraqY7WQARUorXD5r
hI4UotLigEU4OuEGpp+xAenpykgxfHIPS61zx0Nvfk3ppJwI1rKvX1O8LCj4
uSTIlcLq6RAq8pLk8j1K3ZPzgcfgnNLnzxSePHqkECWmziReVuWKsAt2kCPe
U0gOBYMpevvh9u5gKP+qdz/z55uX//rh+ublFX2+fX3x5k344Efcvv75w5ur
7lM38/Lnt29fvruSyfhWbX319uKXAxGog5/f313//O7izYFwpqeTtXbMM5Qb
BnaioIHiEG0BIibCzReX79XpY5z8X+Asz05Pvwdqlj+enz57jD9IvmUz1gP5
kxMScEyUpDBsNsnrmQZ2gG2NnVMITjHcjolkM8/C187oC5DxAgijtcm7tK3V
KyioOrx48e7VEclNgObszCkLypfzKL43deNU8rVEHK8o4sAtXfQG9fXWhSUU
jEv00Pua7YBhIJCTJvGI2C6Ar6bMSeQEa8oMFyP7Wf34zPn3Bxz6SL0ktAMV
IuOw0hv7AO6VnaKlewkZOAK5Kh8MisVye7BM37qkUS/ZOfgQHS6bV4QpKG3Y
Vw+fxaIbD/yMkAjpJRQ1bQuCNg0ZCutyYzjU1MzaOu0wq6M/Plsv4/ZvwTr9
24g1bn8g489PfkSsY/Beqmqbgs3GRFMCEfR7L6ddyBNfe8/gWIdcJfVIjlJP
YWOYG8HDsuP156mWYiqgJG0f2Efu1IXNUJFAGyj+9OkLGXxCrz3K4b31TBRj
WZFf8FJBdAFZuZyIy2MBnwP9MxZtKgcXLdx4/+ijngQ4g+ScSsRaLwFpuZGS
knPlLvygxFEw0gqMSzRRtJTBykVGzdfOC0G9JuPN5qHuXUu6lvSqwJG+TxKY
62ItdsvGryJgb0khDN/lFj4rKVzmi+Y0Y8XRSO1Wii+KHv/2IyTW5dt/d2AR
h9UIiZL+rIMfb90D8hzRg98e0/QfwcasyzpE9tF5nlsRboQ8Pr215SkHgz/T
CUlfxIi67KlXyyAQlFhhu4JjLyowLzaKPRkY9uKRvSZkO4ceY2dhz2KkmLCc
AZCtXKg99ctwMKcY8CPUJIEYxtaMXSijSUgi8QxXrv6U1pudrPRWXunZ6HT0
eCfqi+20U3iWWjpgiogw86aUbDNHd24TSYqE7PueEcb2DLlUHChoq/0dUDLI
MZSPZWYl8d/rDTxoXrHaRIkYjPCCypmdWksGIzJqtFMUOITzUUYndlEkALLX
mpfh3fORGgxetTUdjKRhuO1KOrZ39msv62HLyNH7MNk7PFZ0UCg7S+LoKEgj
HBvlXFLi5CotWjFKqcl9nXoZBJ69/IULrUmWnErcCnc63vJdhhD8IS0HHT53
1bGyQ0LsIMRB3vWA8Y0/ewwu1KdHqYzI5p8FDj5cPnFIw12TD/p6hHrG2TCM
rY3BF8ylUTjs2ti5iyxqnWmCv5FbjNXRQ/4eE5xhx91+qd5TRRibHliuhqU1
h2PwObgf6C241a3BQOrWF4Nzzy0gyevkatRrkpBdklA5hr1X1/6koikT9jl2
mnAlIsrsuLzOtyx6BP0lX7fQiwlnfhgO32vKJ3QLnnuj8U1LCqEETnHgMSz1
P//5T5VOyulARfz8naecHkPbCDtINDKWGe6veNIY4p3h3+SlPBtu/Z2cyWJs
W9P4zp0YcCDNODVcp7P+JC4RlnLRdyePAVC6MByG3zpf70VMTL2XzH1IWnIJ
tp1Yekg5ekCMxK3YBeakKQ5K+It2dolchKtYEJwkDSmrMmH3qik5VVpWl0PR
41RZuA+gmK7Ew8lK4sDt0Whw3XhZn3DcbwWZkImdcAlLhNyfucvth6rJlr+V
Wkk4nj+SX0eU+jvrFhwGtc4d5vWYhW7uOzICUms85HhMYltnQbu7xTkuAvQi
ltTAEZTZ0itTtTY6lxvjTCqdct/pnUnB5zSH9r6IkHskvj5yTifYMqpaOmFw
1XAnY5zsjaSxTFeUa3Em6sAXCa1p9Mgt7ELXrcumum//qocR5R11cbjgK+Lh
Rvfvx9LAYxvSHpdIpAvy1HJlDSLA2HzvIsfTqpqk9WjeLAocYNI27Ll3J7lx
vbkRBS757mIEYnxUgWQMAWTd1x0HmYLEuRDioeMemwWuYvT35ezgCFdlOGYI
wrWkLAhBVbZq+J61his6gRff2XC/vZNyReOrdAWiOPag0GMTSAvJ/L/bgyOX
Q4zOzxyizbh47KqQ29t0R3rwwuVQnPx2+hio4ydb1x4W4RndrR0JHuDOulQc
BoPsSy6SOFsswFBM0m52/gHcbf+LqJgCICb1G0Gxx8CP/z9g4L7HI7K3nZ24
NvINbHOCBdrjo6TARbm3wBNfkKfH/XV7XPkmSh5yu/8HtLGR3tpsOyYnCPxA
HOlEs8N7Lz8uORs8GNzs9c+tS6v4ugEX+Dmw3E4c6o9cmezVRWBim9h/6XJl
6qrs6nvsPF1+O+GotF5x/vgrnT+UTFhVCAB4169nnEddxcrszxFISnJhSp/H
Ewe3xmRK0ZFRa0uXKikcJmjLRQW7wkDEkbudXJA09kQ3jbRElQ8Qyp1hVe2A
tNSanFP36f8JtHhqGtvvG/MnoJLxRk0lRtvK8JDr58zTJMrixxcld8fmPly0
IKZ+ml1E+mszF2Y2J6yz0ogCqajzsEyIQYtvhKIP8RtOcCVnw3kWIqifMKF6
vrQG5/4LBmskyL7PzlcXOF4W4aXSzWIp+QfHoyBIXyLWRqkSpyeYT/kuYCji
0yF7CodKSP0IjLiKw5GrUVUupOQOiW4vcFB8D9VFwevDKAIYdkafNw+IUcyx
JO6c2HYryg1G5f+L99eOQQyXFtQ4yLxmfCexIrmvF65w2kOyxrVM9GtKISp2
AQIT3y9Th+ajQGj17VYiiDez0FX2yGMYID22HywUTKjtVcvImFDLnEt43Gu9
pGNLV4J4NO/lqQ9QHBoopcS8q7tVZHmkOxD7S/7KNBKPuDjP+WzPjHD4Wi8q
yMQXSnWhFtbFxkMpOqVduck1RVFrPKYchgM7a9MxdOfyfSAfrdK7zsNQtToi
rMGit6ZUyD47XtQ4LZiwSgFDyWT71a0IlgeXoPovt+lKJ1dU3Yj2++vhAz3W
FqOJ48eP6FNCHxMn5D6UZk90RJ2Qhrr66JhUzg+Jma804Kg4Re3SJ9uWrbNd
Ihicrc50TYFwn6tcctd5EgrPXXaE/VHUXBvbhXiN0FIwcg2LU86ofd3DNr5Y
vicZ65KFVPbzzmPb8vryVHfV5JoWKXVxdhcrgWnUgLQbYHZiqj9SSwho3elN
fn339s1QXd7ecudcZ4N8q1s4rVfwhrvQpC6cITJrtux+ymbUfsF7jeGefqNe
utJBItCGps7hj6i4DpvXUgsTl97iqhs2neti2fWZ0Vmtb8ZatEVjCHvF0XuX
QHBGZKRudN5m/u5dO3IPYPvUZVT0C6UrZhM+8jswoTubuIHzlbj/WpIoKWSc
4HUt6DBkMN3qHAwUlYTYFIQ5AMKWm2xYrV3uv5degLPis/Aa3FBHTrkm5OrN
KRnEmk4IPhjLRhSW6N61dpGQ6DLuh2AmUMEo0MW1Mer89PxkLo9wZ7fU5giD
RgslilOpTj5UV+T2holmJdbN2O6/rXynTD7sW7AvCLhEqzOJd/WcEGDUb0BC
n0nQ56tw5NQXRjIxYBKAhOsOlaErXvUoJn2iA1BiDBHpL53/cs7XyhmNxoBn
yTfwYFe3M17GdusQZC0EGmjum9RuDDl8XUzZp1PVxBMX7LhY9wg6UNPVBM6T
8cFVlz0LdtMlVUjliCKJGjotWVY+s8+0LKkvHqh4rREMRxW/oUvf+dvliq00
fMbHdXTuz2Efifcmre+W7S/pm0T3rDnTVVGJYBz1fYe3VD1gKtLtTC7D4FQK
pxmbGn+FK+saj7bhq/TzbjhDz3YIXrDHNofjaz1L67zTrhp2pZpOXQsqeUm3
k/fl5A51ApsnSUK4S7tdIN2F2qHzN4lq5YmKwp6oKC0QyccZVagjiwvtudd+
TMnt78FwuUbgHmWhkiz2sJde5Q5sShlA4L6wic/UujSoS1KX1NUWKUX/8Vxe
3/FNZK5ijlNHCs8mOU4SSb5J3N/D9Ix2D+m57uJd11wofQ/zivqRtxvqpKtA
nBPZ97TgprSd/jDfFz/BFa1NjjstDMC+y10FSE2aHwmzBEGFy/27uqB12UbX
FRnXyk25qooVua4YtZJz+EKH2pClHYaCLBEkqpwx1EGks5LKuwRtabHFMLdn
MMwkbw6fUaRCATrFRGS6NIUhFS4PmOjiF4fLfMAj0DASoe2Eff/WVC8I6y0V
3vrZkjvv3bO0rjdshSiv5bkS+cxRv3+G8Zu8wLWToe+lr7mWU24kSwh9MK6b
CH6srtYO8dCrIJvoG84yDf3bDow2XFJ5yPrIG+tccpdX3Ja98C0zIZd0Q6cY
RE+xvTRt9psbQ4+9pZQL9aj3rJ7T+Pc+vOI2H8gVmOA6wQOudPmKHoyiFwll
AZh2LT0qDscIsqsWi7bs6qG7GGwwuOB3F60/QE8CnHkyDhniHvW0pRgw6Erv
Bbu4zcQBjAnXwcUdxO35PpflXI0ET9SAXD28pv6YFa1rQSZQuYPGOXPEjTMp
J5kkV+VThyw65qOv1+wwkm0eByuS0yXFlWwRK4pQKI1KTF4cGPjjcM7DdW4J
bhWt9KI9UhB0D4wPiKoDTxa/k1O4HrEoXdA/ohJ3xEB2z/5JSHDnnU+mplCt
1adP/Lbr58+cNOCMeowYB4MXG+kwKAUK7jTq+0alHRGhlxPaGvTlzlYSrnvt
Gc6VFn6zhhlC4aqk9rp3WbrmAsCw0CP9g3SNeZODFV9VCDrroW/V6TEwZJ4x
aKSuXPcMb2wf3BnOBrhgQSzgXvpQ5SCjAIe7XLLqlZRam5WsB5L754sOUdBk
E/zC1NDbEYwNL/qc2sqWhXa0POqs6Mp0O614bBQZE6Wx0Eqqid4gIyMzTbhC
/z8o0LPVu+Ds6JV/CwkniSTQoy4g4Cjr8kDSN0KVDskE06Ejx7HH79io1OcQ
zBr+0jRqXbU4fVgnzvz0Mg0X769HlMyX5JeLqH3ed6vBneBfAY9AzXVzIIte
I4CNgE3UKUget7eMgFVfEeQW0P5LlKKOrl+uP6pqG/cihxATBeQufbwHTKas
wzRwKIhIEhC9bJ/Pg6ewLptfncC03MxKXcCVZUvnm1pda9y+Htd+pZ5ST628
D+SSUDp+y3uygSu25lc9+o9/v2WMMfV5XjfYhf3+3YKuTdjpB/3eRe2K/NKq
YCU85beayFVxpxSH0lIZbui/cN7MNAY2frM8wn/cx971AzmpbMQ+ceYwSrww
wqiWTpbjjo7dYmQUm3bNnn64WI0Obm+i7nK+5/hNEm6LdRmytqZ4lAKWKwEE
OxwOp/xvJ84EHQaFinMvXRKPBHXu5cADTk9MrgmkOGQaHM2wS8/IednpFOZe
i07L2YEoqJxCbzBfvLvYqdK9+uqZ/AuiWeP1ZUaQsXbIY3+3jQu/32t6nYVW
eYubodp+rwferQX0KiVh+kERsZL7X1titx6M+MFWP1FMwdClkYRUy79cUHap
Ir+vs8fBLXx6ZKDISdQ8l3iKO6cw7ibgsfsxHCkvVk2VVYX77ZtE3ULMWjt2
LzZzdFHQFMaExy4ZE2LeeqyuX969onnxGyOBDYf2aIzb74j7vNOdi7k3rn0x
8g3jnW5Debmd0ixspSSdI429hgK95ORk8Bt1Ta+mqdOnz9UhA4wu4e7enseh
j1S7zHlDajsbRbPO1SE3760MjMkUOJO2O1I6pzomgXH/ndhqeTmfW7SjVZ5g
lXe6oUIyORyVueDyyElf+EkaFQKXUe8cp2Gts5MT+r0P6hD6I7d5+raOuEq0
0t3mZ6dPxuolt3pQZL4/+c9pFTGyDilG6tWl3PJOmC0LhSvRBbHoU33WEXH+
/Vh9cCzu0Xx5k2TWJuL0kvNuxuOTfTNIBMBJfskvrsuDq9HU07FYCCuv90Jn
2Gr0j9WNf3JCP7qT1tJi26lFfJaIsuePI4bSe36pp6yb6gefnzzH4CAsFDaW
7TJ6/HQMCMW2NkxO3pippnxkj4DH3aSnON8NFcyw/1W1ph94uu8/7QRESt1k
oAF+lwiNXGCyK8C93Z506z07G6vbDKFjrjrIGfWWbSQa6beV2Wj++Vi9oCxx
N5vKQpwM6u35NMx5cgYWd3rKSfl13MHnlYnyG0OVI7AlDI7572/Us2dPOvaE
BEjwejtvugk/+q+39eh6Fuh6RrztJCWEXn41D0rl7f6eQbedRj47PyEC+cdO
trWYseCf6F19CQTDnJN4DvfG8lDbNQNH+4ALz58977iwK1pd81SwXzgLGW51
isuPj/9cFvz++RMSVWnl5lMTuLDyWxiCD9nzj/wtQLIvcum+YXHpgr099gUz
Tk9OmLuU0aEWRJfUYa4QwvK/PLGTfvGEfu/XeQrpeYVtFrrmtxH551aYXQee
VA9ZmOSD3jqnJ34dkvw3l1sW/g8t/ZgBdaxn83sdaH+O+7l2NSDup7bNpoge
n/nbCO+kLCSGJirChfvh3z+LrUafgAXiepYMGnl6HmwBgCODxOg3TsKgbvdS
c6JMHFR86tMw+DENhpoCwzfsXT3J/QlnfsJTHP3iyvnI/phzP+YZyPxJl2nd
7B332I07O9teC7JLvzRU6HzGiU07+DQuW2o21/nvDqZpYfXBZwCttLxn3X6b
wjO8qzi5Mk8Xw637GsKT1bAnL7DUr7oY0gf1U62BAxpNHcV3ad2W6gXMWIqn
N9VGQB6nYv+UWlMYfJPWVVmtMJh68KnOgHX/UJUpIgWT3fPYt1TUKBGsVQvr
W7C4LlkFE+x75l0yjpWPsWD/Z4e4e6MkB8nwjCuvHBs6qRgN/hM0bfavUlEA
AA==

-->
</rfc>