rfc8942xml2.original.xml   rfc8942.xml 
<?xml version="1.0" encoding="UTF-8"?> <?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.13 -->
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.2.13 --> <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<!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"?>
<rfc ipr="trust200902" docName="draft-ietf-httpbis-client-hints-latest" category
="exp">
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902"
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> <front>
<title>HTTP Client Hints</title> <title>HTTP Client Hints</title>
<seriesInfo name="RFC" value="8942"/>
<author initials="I." surname="Grigorik" fullname="Ilya Grigorik"> <author initials="I." surname="Grigorik" fullname="Ilya Grigorik">
<organization>Google</organization> <organization>Google</organization>
<address> <address>
<email>ilya@igvita.com</email> <email>ilya@igvita.com</email>
<uri>https://www.igvita.com/</uri> <uri>https://www.igvita.com/</uri>
</address> </address>
</author> </author>
<author initials="Y." surname="Weiss" fullname="Yoav Weiss"> <author initials="Y." surname="Weiss" fullname="Yoav Weiss">
<organization>Google</organization> <organization>Google</organization>
<address> <address>
<email>yoav@yoav.ws</email> <email>yoav@yoav.ws</email>
<uri>https://blog.yoav.ws/</uri> <uri>https://blog.yoav.ws/</uri>
</address> </address>
</author> </author>
<date month="January" year="2021"/>
<date />
<area>Applications and Real-Time</area> <area>Applications and Real-Time</area>
<workgroup>HTTP</workgroup> <workgroup>HTTP</workgroup>
<keyword>Content Negotiation</keyword>
<keyword>Content Negotiation</keyword>
<abstract> <abstract>
<t>HTTP defines proactive content negotiation to allow servers to select
<t>HTTP defines proactive content negotiation to allow servers to select the app the appropriate response for a given request, based upon the user
ropriate response for a given request, based upon the user agent’s characteristi agent's characteristics, as expressed in request headers. In practice,
cs, as expressed in request headers. In practice, user agents are often unwillin user agents are often unwilling to send those request headers, because
g to send those request headers, because it is not clear whether they will be us it is not clear whether they will be used, and sending them impacts both
ed, and sending them impacts both performance and privacy.</t> performance and privacy.</t>
<t>This document defines an Accept-CH response header that servers can
<t>This document defines an Accept-CH response header that servers can use to ad use to advertise their use of request headers for proactive content
vertise their use of request headers for proactive content negotiation, along wi negotiation, along with a set of guidelines for the creation of such
th a set of guidelines for the creation of such headers, colloquially known as “ headers, colloquially known as "Client Hints."</t>
Client Hints.”</t>
</abstract> </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/A
rchives/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> </front>
<middle> <middle>
<section anchor="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 (<xref
target="RFC7231" sectionFormat="of" section="5.5.3"/>) against an establis
hed database of
user agent signatures), use HTTP cookies <xref 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 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
are in use during the negotiation:</t>
<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.</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.</li>
<li>URL parameters, similar to cookie-based approaches, suffer from
lack of portability and are hard to deploy due to a requirement to
encode content negotiation data inside of the URL of each
resource.</li>
</ul>
<t>Proactive content negotiation (<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>
<section anchor="introduction" title="Introduction"> <t>However, traditional proactive content negotiation techniques often
mean that user agents send these request headers prolifically. This
<t>There are thousands of different devices accessing the web, each with differe causes performance concerns (because it creates "bloat" in requests), as
nt device capabilities and preference information. These device capabilities inc well as privacy issues; passively providing such information allows
lude hardware and software characteristics, as well as dynamic user and user age servers to silently fingerprint the user.</t>
nt preferences. Historically, applications that wanted the server to optimize co
ntent delivery and user experience based on such capabilities had to rely on pas
sive identification (e.g., by matching the User-Agent header field (Section 5.5.
3 of <xref target="RFC7231"/>) against an established database of user agent sig
natures), use HTTP cookies <xref target="RFC6265"/> and URL parameters, or use s
ome combination of these and similar mechanisms to enable ad hoc content negotia
tion.</t>
<t>Such techniques are expensive to set up and maintain, and are not portable ac
ross both applications and servers. They also make it hard for both user agent a
nd server to understand which data are required and is in use during the negotia
tion:</t>
<t><list style="symbols">
<t>User agent detection cannot reliably identify all static variables, cannot
infer dynamic user agent preferences, requires an external device database, is n
ot cache friendly, and is reliant on a passive fingerprinting surface.</t>
<t>Cookie-based approaches are not portable across applications and servers, i
mpose additional client-side latency by requiring JavaScript execution, and are
not cache friendly.</t>
<t>URL parameters, similar to cookie-based approaches, suffer from lack of por
tability, and are hard to deploy due to a requirement to encode content negotiat
ion data inside of the URL of each resource.</t>
</list></t>
<t>Proactive content negotiation (Section 3.4.1 of <xref target="RFC7231"/>) off
ers an alternative approach; user agents use specified, well-defined request hea
ders to advertise their capabilities and characteristics, so that servers can se
lect (or formulate) an appropriate response based on those request headers (or o
n other, implicit characteristics).</t>
<t>However, traditional proactive content negotiation techniques often mean that
user agents send these request headers prolifically. This causes performance co
ncerns (because it creates “bloat” in requests), as well as privacy issues; pass
ively providing such information allows servers to silently fingerprint the user
.</t>
<t>This document defines Client Hints, a framework that enables servers to opt-i
n to specific proactive content negotiation features, adapting their content acc
ordingly, 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 orig
in 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 actually going to be used, and privac
y 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 hea
der, turning passive fingerprinting vectors into active ones.</t>
<t>The document does not define specific usages of Client Hints. Such usages nee
d to be defined in their respective specifications.</t>
<t>One example of such usage is the User Agent Client Hints <xref target="UA-CH"
/>.</t>
<section anchor="notational-conventions" title="Notational Conventions">
<t>The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”,
“SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this d
ocument are to be interpreted as described in BCP 14 <xref target="RFC2119"/> <x
ref target="RFC8174"/> when, and only when, they appear in all capitals, as show
n here.</t>
<t>This document uses the Augmented Backus-Naur Form (ABNF) notation of <xref ta
rget="RFC5234"/>.</t>
</section>
</section>
<section anchor="client-hint-request-header-fields" title="Client Hint Request H
eader Fields">
<t>A Client Hint request header field is a HTTP header field that is used by HTT
P user agents to indicate data that can be used by the server to select an appro
priate response. Each one conveys user agent preferences that the server can use
to adapt and optimize the response.</t>
<section anchor="sending-client-hints" title="Sending Client Hints">
<t>User agents choose what Client Hints to send in a request based on their defa
ult settings, user configuration, and server preferences expressed in <spanx sty
le="verb">Accept-CH</spanx>.
The user agent and server can use an opt-in mechanism outlined below to negotiat
e which header fields need to be sent to allow for efficient content adaption, a
nd optionally use additional mechanisms (e.g., as outlined in <xref target="CLIE
NT-HINTS-INFRASTRUCTURE"/>) to negotiate delegation policies that control access
of third parties to those same header fields.
User agents SHOULD require an opt-in to send any hints that are not listed in th
e low-entropy hint table at <xref target="CLIENT-HINTS-INFRASTRUCTURE"/>.</t>
<t>Implementers need to be aware of the fingerprinting implications when impleme
nting support for Client Hints, and follow the considerations outlined in the <x
ref target="security-considerations">Security Considerations</xref> section of t
his document.</t>
</section>
<section anchor="server-processing-of-client-hints" title="Server Processing of
Client Hints">
<t>When presented with a request that contains one or more Client Hint header fi
elds, servers can optimize the response based upon the information in them. When
doing so, and if the resource is cacheable, the server MUST also generate a Var
y response header field (Section 7.1.4 of <xref target="RFC7231"/>) to indicate
which hints can affect the selected response and whether the selected response i
s appropriate for a later request.</t>
<t>Servers MUST ignore hints they do not understand nor support. There is no mec
hanism for servers to indicate to user agents that hints were ignored.</t>
<t>Furthermore, the server can generate additional response header fields (as sp
ecified by the hint or hints in use) that convey related values to aid client pr
ocessing.</t>
</section>
</section>
<section anchor="advertising-server-support" title="Advertising Server Support">
<t>Servers can advertise support for Client Hints using the mechanism described
below.</t>
<section anchor="accept-ch" title="The Accept-CH Response Header Field"> <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>The Accept-CH response header field indicates server support for the hints in <t>Client Hints mitigate performance concerns by assuring that user
dicated in its value. agents will only send the request headers when they're actually going to
Servers wishing to receive user agent information through Client Hints SHOULD ad be used, and they mitigate privacy concerns of passive fingerprinting by r
d Accept-CH response header to their responses as early as possible.</t> equiring
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 Client Hints <xref
target="UA-CH" format="default"/>.</t>
<section anchor="notational-conventions" numbered="true" toc="default">
<name>Notational Conventions</name>
<t>
The key words "<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 "<bcp14>OPTIONAL</bcp14>" in this document are
to be interpreted as
described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
<t>This document uses the Augmented Backus-Naur Form (ABNF) notation
of <xref target="RFC5234" format="default"/>.</t>
</section>
</section>
<section anchor="client-hint-request-header-fields" numbered="true" toc="def
ault">
<name>Client Hints Request Header Fields</name>
<t>A Client Hints request header field is 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
preferences that the server can use to adapt and optimize the
response.</t>
<t>Accept-CH is a Structured Header <xref target="I-D.ietf-httpbis-header-struct <section anchor="sending-client-hints" numbered="true" toc="default">
ure"/>. Its value MUST be an sf-list (Section 3.1 of <xref target="I-D.ietf-http <name>Sending Client Hints</name>
bis-header-structure"/>) whose members are tokens (Section 3.3.4 of <xref target <t>User agents choose what Client Hints to send in a request based on
="I-D.ietf-httpbis-header-structure"/>). Its ABNF is:</t> their default settings, user configuration, and server preferences
expressed in <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 optional
ly use
additional mechanisms (e.g., as outlined in <xref
target="CLIENT-HINTS-INFRASTRUCTURE" format="default"/>) to negotiate
delegation policies that control access of third parties to those same
header fields. User agents <bcp14>SHOULD</bcp14> require an opt-in to sen
d any hints
that are not considered low-entropy. See the low-entropy hint table
at <xref 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 and follow the
considerations outlined in the Security Considerations section of this
document (see <xref target="security-considerations"
format="default"/>).</t>
</section>
<section anchor="server-processing-of-client-hints" numbered="true" toc="d
efault">
<name>Server Processing of Client Hints</name>
<t>When presented with a request that contains one or more Client 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 <bcp14>MUST</bcp14> also generate a Vary response header field
(<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 <bcp14>MUST</bcp14> ignore hints they do not understand nor s
upport. 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" numbered="true" toc="default">
<name>Advertising Server Support</name>
<t>Servers can advertise support for Client Hints using the mechanism desc
ribed below.</t>
<section anchor="accept-ch" numbered="true" toc="default">
<name>The Accept-CH Response Header 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 <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="RFC8941" format="default"/>. Its
value <bcp14>MUST</bcp14> be an sf-list (<xref
target="RFC8941" sectionFormat="of"
section="3.1"/>) whose members are Tokens (<xref
target="RFC8941" sectionFormat="of"
section="3.3.4"/>). Its ABNF is:</t>
<figure><artwork type="abnf"><![CDATA[ <sourcecode type="abnf"><![CDATA[
Accept-CH = sf-list Accept-CH = sf-list
]]></artwork></figure> ]]></sourcecode>
<t>For example:</t>
<t>For example:</t> <sourcecode type="http-message"><![CDATA[
Accept-CH: Sec-CH-Example, Sec-CH-Example-2
<figure><artwork type="example"><![CDATA[ ]]></sourcecode>
Accept-CH: Sec-CH-Example, Sec-CH-Example-2 <t>When a user agent receives an HTTP response containing
]]></artwork></figure> <tt>Accept-CH</tt>, it indicates that the origin opts-in to receive
the indicated request header fields for subsequent same-origin
<t>When a user agent receives an HTTP response containing <spanx style="verb">Ac requests. The opt-in <bcp14>MUST</bcp14> be ignored if delivered over non
cept-CH</spanx>, that indicates that the origin opts-in to receive the indicated -secure
request header fields for subsequent same-origin requests. transport (using a scheme different from HTTPS). It <bcp14>SHOULD</bcp14>
The opt-in MUST be ignored if delivered over non-secure transport (using a schem be
e different from HTTPS). persisted and bound to the origin to enable delivery of Client Hints
It SHOULD be persisted and bound to the origin to enable delivery of Client Hint on subsequent requests to the server's origin, for the duration of the
s on subsequent requests to the server’s origin, for the duration of the user’s user's session (as defined by the user agent). An opt-in overrides
session (as defined by the user agent). previous persisted opt-in values and <bcp14>SHOULD</bcp14> be persisted i
An opt-in overrides previous persisted opt-in values and SHOULD be persisted in n its
its stead.</t> stead.</t>
<t>Based on the Accept-CH example above, which is received in response
<t>Based on the Accept-CH example above, which is received in response to a user to a user agent navigating to "https://site.example", and delivered
agent navigating to “https://site.example”, and delivered over a secure transpo over a secure transport, persisted Accept-CH preferences will be bound
rt, persisted Accept-CH preferences will be bound to “https://site.example”. to "https://site.example". It will then use it for navigations to
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, for example,
but not to e.g., “https://foobar.site.example/”. "https://foobar.site.example/". It will similarly use the preference
It will similarly use the preference for any same-origin resource requests (e.g. for any same-origin resource requests (e.g., to
, to “https://site.example/image.jpg”) initiated by the page constructed from th "https://site.example/image.jpg") initiated by the page constructed
e navigation’s response, but not to cross-origin resource requests (e.g., “https from the navigation's response, but not to cross-origin resource
://thirdparty.example/resource.js”). requests (e.g., "https://thirdparty.example/resource.js"). This
This preference will not extend to resource requests initiated to “https://site. preference will not extend to resource requests initiated to
example” from other origins (e.g., from navigations to “https://other.example/”) "https://site.example" from other origins (e.g., from navigations to
.</t> "https://other.example/").</t>
</section>
</section> <section anchor="interaction-with-caches" numbered="true" toc="default">
<section anchor="interaction-with-caches" title="Interaction with Caches"> <name>Interaction with Caches</name>
<t>When selecting a response based on one or more Client Hints, and if
<t>When selecting a response based on one or more Client Hints, and if the resou the resource is cacheable, the server needs to generate a Vary
rce is cacheable, the server needs to generate a Vary response header field (<xr response header field <xref target="RFC7234" format="default"/> to
ef target="RFC7234"/>) to indicate which hints can affect the selected response indicate which hints can affect the selected response and whether the
and whether the selected response is appropriate for a later request.</t> selected response is appropriate for a later request.</t>
<figure><artwork type="example"><![CDATA[
Vary: Sec-CH-Example
]]></artwork></figure>
<t>The above example indicates that the cache key needs to include the Sec-CH-Ex
ample header field.</t>
<figure><artwork type="example"><![CDATA[
Vary: Sec-CH-Example, Sec-CH-Example-2
]]></artwork></figure>
<t>The above example indicates that the cache key needs to include the Sec-CH-Ex
ample and Sec-CH-Example-2 header fields.</t>
</section>
</section>
<section anchor="security-considerations" title="Security Considerations">
<section anchor="information-exposure" title="Information Exposure">
<t>Request header fields used in features relying on this document expose inform
ation about the user’s environment to enable privacy-preserving proactive conten
t 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 po
licies that prevent abuse of the information exposed by features using Client Hi
nts.</t>
<t>The information exposed by features might reveal new information about the us
er and implementers ought to consider the following considerations, recommendati
ons, and best practices.</t>
<t>The underlying assumption is that exposing information about the user as a re
quest header is equivalent (from a security perspective) to exposing this inform
ation by other means. (For example, if the request’s origin can access that info
rmation using JavaScript APIs, and transmit it to its servers).</t>
<t>Because Client Hints is an explicit opt-in mechanism, that means that servers
that want access to information about the user’s environment need to actively a
sk for it, enabling clients and privacy researchers to keep track of which origi
ns collect that data, and potentially act upon it.
The header-based opt-in means that removal of passive fingerprinting vectors is
possible, such as the User-Agent string (enabling active access to that informat
ion through User-Agent Client Hints (<xref target="UA-CH"/>) or otherwise expose
information already available through script (e.g., the <eref target="https://w
icg.github.io/savedata/#save-data-request-header-field">Save-Data Client Hint</e
ref>), without increasing the passive fingerprinting surface. User agents suppor
ting Client Hints features which send certain information to opted-in servers SH
OULD avoid sending the equivalent information passively.</t>
<t>Therefore, features relying on this document to define Client Hint headers MU
ST NOT provide new information that is otherwise not made available to the appli
cation by the user agent, such as existing request headers, HTML, CSS, or JavaSc
ript.</t>
<t>Such features need to take into account the following aspects of the informat
ion exposed:</t>
<t><list style="symbols">
<t>Entropy - 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 t
he advertised value is close to but is not an exact representation of the curren
t value, can improve privacy and reduce risk of linkability by ensuring that the
same value is sent by multiple users.</t>
<t>Sensitivity - The feature SHOULD NOT expose user-sensitive information. To
that end, information available to the application, but gated behind specific u
ser actions (e.g., a permission prompt or user activation) SHOULD NOT be exposed
as a Client Hint.</t>
<t>Change over time - The feature SHOULD NOT expose user information that chan
ges over time, unless the state change itself is also exposed (e.g., through Jav
aScript callbacks).</t>
</list></t>
<t>Different features will be positioned in different points in the space betwee
n low-entropy, non-sensitive and static information (e.g., user agent informatio
n), and high-entropy, sensitive and dynamic information (e.g., geolocation). Use
r agents need to consider the value provided by a particular feature vs these co
nsiderations, 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 mechanisms a <sourcecode type="http-message"><![CDATA[
nd policies to control which Client Hints header fields are advertised:</t> Vary: Sec-CH-Example
]]></sourcecode>
<t>The above example indicates that the cache key needs to include the
Sec-CH-Example header field.</t>
<t><list style="symbols"> <sourcecode type="http-message"><![CDATA[
<t>Implementers SHOULD restrict delivery of some or all Client Hints header fi Vary: Sec-CH-Example, Sec-CH-Example-2
elds to the opt-in origin only, unless the opt-in origin has explicitly delegate ]]></sourcecode>
d permission to another origin to request Client Hints header fields.</t> <t>The above example indicates that the cache key needs to include the
<t>Implementers considering providing user choice mechanisms that allow users Sec-CH-Example and Sec-CH-Example-2 header fields.</t>
to balance privacy concerns against bandwidth limitations need to also consider </section>
that explaining to users the privacy implications involved, such as the risks of </section>
passive fingerprinting, may be challenging or even impractical.</t> <section anchor="security-considerations" numbered="true" toc="default">
<t>Implementations specific to certain use cases or threat models MAY avoid tr <name>Security Considerations</name>
ansmitting some or all of Client Hints header fields. For example, avoid transmi <section anchor="information-exposure" numbered="true" toc="default">
ssion of header fields that can carry higher risks of linkability.</t> <name>Information Exposure</name>
</list></t> <t>Request header fields used in features relying on this document
expose information about the user's environment to enable
privacy-preserving proactive content 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>User agents MUST clear persisted opt-in preferences when any one of site data <t>The information exposed by features might reveal new information
, browsing history, browsing cache, cookies, or similar, are cleared.</t> about the user, and implementers ought to consider the following
considerations, recommendations, and best practices.</t>
</section> <t>The underlying assumption is that exposing information about the
<section anchor="deployment-and-security-risks" title="Deployment and Security R user as a request header is equivalent (from a security perspective)
isks"> to exposing this information by other means. (For example, if the
<t>Deployment of new request headers requires several considerations:</t> request's origin can access that information using JavaScript APIs
and transmit it to its servers.)</t>
<t><list style="symbols"> <t>Because Client Hints is an explicit opt-in mechanism, it means
<t>Potential conflicts due to existing use of header field name</t> that servers wanting access to information about the user's
<t>Properties of the data communicated in header field value</t> environment need to actively ask for it, enabling clients and privacy
</list></t> 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. As an example, the user agent can reduce the information
exposed by the User-Agent string, while enabling active access to that
information through User-Agent Client Hints <xref target="UA-CH"
format="default"/>.
Otherwise, the user agent can expose information already available through
script (e.g., the Save-Data Client Hints <eref brackets="angle"
target="https://wicg.github.io/savedata/#save-data-request-header-field"></e
ref>),
without increasing the passive fingerprinting surface. User agents supportin
g
Client Hints features which send certain information to opted-in servers
<bcp14>SHOULD</bcp14> avoid sending the equivalent information passively.</t
>
<t>Authors of new Client Hints are advised to carefully consider whether they ne <t>Therefore, features relying on this document to define Client Hint
ed to be able to be added by client-side content (e.g., scripts), or whether the headers <bcp14>MUST NOT</bcp14> provide new information that is otherwise
y need to be exclusively set by the user agent. In the latter case, the Sec- pre not made
fix on the header field name has the effect of preventing scripts and other appl available to the application by the user agent, such as existing
ication content from setting them in user agents. request headers, HTML, CSS, or JavaScript.</t>
Using the “Sec-“ prefix signals to servers that the user agent - and not applica
tion content - generated the values. See <xref target="FETCH"/> for more informa
tion.</t>
<t>By convention, request headers that are Client Hints are encouraged to use a <t>Such features need to take into account the following aspects of
CH- prefix, to make them easier to identify as using this framework; for example the exposed information:</t>
, CH-Foo or, with a “Sec-“ prefix, Sec-CH-Foo. Doing so makes them easier to ide
ntify programmatically (e.g., for stripping unrecognised hints from requests by
privacy filters).</t>
<t>A Client Hints request header negotiated using the Accept-CH opt-in mechanism <dl newline="false" spacing="normal">
MUST have a field name that matches sf-token (Section 3.3.4 of <xref target="I- <dt>Entropy:</dt>
D.ietf-httpbis-header-structure"/>).</t> <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.</dd>
</section> <dt>Sensitivity:</dt>
<section anchor="abuse-detection" title="Abuse Detection"> <dd>The feature <bcp14>SHOULD NOT</bcp14> expose user-sensitive
<t>A user agent that tracks access to active fingerprinting information SHOULD c information. To that end, information available to the application,
onsider emission of Client Hints headers similarly to the way it would consider but gated behind specific user actions (e.g., a permission prompt or
access to the equivalent API.</t> user activation), <bcp14>SHOULD NOT</bcp14> be exposed as a Client Hint
.</dd>
<t>Research into abuse of Client Hints might look at how HTTP responses to reque <dt>Change over time:</dt>
sts that contain Client Hints differ from those with different values, and from <dd>The feature <bcp14>SHOULD NOT</bcp14> expose user
those without. This might be used to reveal which Client Hints are in use, allow information that changes over time, unless the state change itself
ing researchers to further analyze that use.</t> is also exposed (e.g., through JavaScript callbacks).</dd>
</dl>
<t>Different features will be positioned in different points in the
space between low-entropy, non-sensitive, and static information (e.g.,
user agent information) and high-entropy, sensitive, and dynamic
information (e.g., geolocation). User agents need to consider the
value provided by a particular feature vs. these considerations and
may wish to have different policies regarding that tradeoff on a
per-feature or other fine-grained basis.</t>
</section> <t>Implementers ought to consider both user- and server-controlled
</section> mechanisms and policies to control which Client Hints header fields
<section anchor="cost-of-sending-hints" title="Cost of Sending Hints"> are advertised:</t>
<t>Sending Client Hints to the server incurs an increase in request byte size. S <ul spacing="normal">
ome of this increase can be mitigated by HTTP header compression schemes, but ea <li>Implementers <bcp14>SHOULD</bcp14> restrict delivery of some or al
ch new hint sent will still lead to some increased bandwidth usage. l Client
Servers SHOULD take that into account when opting in to receive Client Hints, an Hints header fields to the opt-in origin only, unless the opt-in
d SHOULD NOT opt-in to receive hints unless they are to be used for content adap origin has explicitly delegated permission to another origin to
tation purposes.</t> request Client Hints header fields.</li>
<li>Implementers that consider providing user-choice mechanisms that
allow users to balance privacy concerns against bandwidth
limitations need to also consider that explaining the
privacy implications involved to users, such as the risks of passive
fingerprinting, may be challenging or even impractical.</li>
<li>Implementations specific to certain use cases or threat models
<bcp14>MAY</bcp14> avoid transmitting some or all of the Client Hints h
eader
fields. For example, avoid transmission of header fields that can
carry higher risks of linkability.</li>
</ul>
<t>Due to request byte size increase, features relying on this document to defin <t>User agents <bcp14>MUST</bcp14> clear persisted opt-in preferences when
e Client Hints MAY consider restricting sending those hints to certain request d any one of
estinations <xref target="FETCH"/>, where they are more likely to be useful.</t> site data, browsing cache, cookies, or similar are cleared.</t>
</section>
<section anchor="deployment-and-security-risks" numbered="true" toc="defau
lt">
<name>Deployment and Security Risks</name>
<t>Deployment of new request headers requires several considerations:</t
>
<ul spacing="compact">
<li>Potential conflicts due to existing use of a header field name</li
>
</section> <li>Properties of the data communicated in a header field value</li>
<section anchor="iana-considerations" title="IANA Considerations"> </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) or whether the Client Hints need to be exclusively set by the us
er
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-" prefix signals to
servers that the user agent -- and not application content -- generated
the values. See <xref target="FETCH" format="default"/> for more
information.</t>
<t>Features relying on this document are expected to register added request head <t>By convention, request headers that are Client Hints are encouraged
er fields in the Permanent Message Header Fields registry (<xref target="RFC3864 to use a CH- prefix, to make them easier to identify as using this
"/>).</t> framework; for example, CH-Foo or, with a "Sec-" prefix,
Sec-CH-Foo. Doing so makes them easier to identify programmatically
(e.g., for stripping unrecognized hints from requests by privacy
filters).</t>
<t>A Client Hints request header negotiated using the Accept-CH opt-in
mechanism <bcp14>MUST</bcp14> have a field name that matches sf-token
(<xref target="RFC8941" sectionFormat="of"
section="3.3.4"/>).</t>
</section>
<section anchor="abuse-detection" numbered="true" toc="default">
<name>Abuse Detection</name>
<t>A user agent that tracks access to active fingerprinting
information <bcp14>SHOULD</bcp14> consider emission of Client Hints heade
rs similar
to the way it would consider access to the equivalent API.</t>
<t>This document defines the “Accept-CH” HTTP response header field, and registe <t>Research into abuse of Client Hints might look at how HTTP
rs it in the same registry.</t> responses to requests that contain Client Hints differ from those with
different values and from those without values. This might be used to rev
eal
which Client Hints are in use, allowing researchers to further analyze
that use.</t>
</section>
</section>
<section anchor="cost-of-sending-hints" numbered="true" toc="default">
<name>Cost of Sending Hints</name>
<t>Sending Client Hints to the server incurs an increase in request byte
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 <bcp14>SHOULD</bcp14> take that into ac
count when
opting in to receive Client Hints and <bcp14>SHOULD NOT</bcp14> opt-in to
receive
hints unless they are to be used for content adaptation purposes.</t>
<section anchor="iana-accept-ch" title="Accept-CH"> <t>Due to request byte size increase, features relying on this document
<t><list style="symbols"> to define Client Hints <bcp14>MAY</bcp14> consider restricting sending tho
<t>Header field name: Accept-CH</t> se hints to
<t>Applicable protocol: HTTP</t> certain request destinations <xref target="FETCH" format="default"/>,
<t>Status: experimental</t> where they are more likely to be useful.</t>
<t>Author/Change controller: IETF</t> </section>
<t>Specification document(s): <xref target="accept-ch"/> of this document</t> <section anchor="iana-considerations" numbered="true" toc="default">
<t>Related information: for Client Hints</t> <name>IANA Considerations</name>
</list></t> <t>Features relying on this document are expected to register added
request header fields in the "Permanent Message Header Field Names" regist
ry
<xref target="RFC3864" format="default"/>.</t>
</section> <t>This document defines the "Accept-CH" HTTP response header field;
</section> IANA has registered it in the same registry.</t>
<section anchor="iana-accept-ch" numbered="true" toc="default">
<name>Accept-CH</name>
<dl newline="false" spacing="normal">
<dt>Header field 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
RFC</dd>
<dt>Related information:</dt>
<dd>for Client Hints</dd>
</dl>
</section>
</section>
</middle> </middle>
<back> <back>
<references>
<name>References</name>
<references>
<name>Normative References</name>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.3864.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.5234.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.7231.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.7234.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.2119.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8174.xml"/>
<references title='Normative References'> <!-- draft-ietf-httpbis-header-structure-19: RFC 8941 -->
<reference anchor='RFC8941' target='https://www.rfc-editor.org/info/rfc8941'>
<reference anchor="RFC3864" target='https://www.rfc-editor.org/info/rfc3864'>
<front>
<title>Registration Procedures for Message Header Fields</title>
<author initials='G.' surname='Klyne' fullname='G. Klyne'><organization /></auth
or>
<author initials='M.' surname='Nottingham' fullname='M. Nottingham'><organizatio
n /></author>
<author initials='J.' surname='Mogul' fullname='J. Mogul'><organization /></auth
or>
<date year='2004' month='September' />
<abstract><t>This specification defines registration procedures for the message
header fields used by Internet mail, HTTP, Netnews and other applications. This
document specifies an Internet Best Current Practices for the Internet Communit
y, and requests discussion and suggestions for improvements.</t></abstract>
</front>
<seriesInfo name='BCP' value='90'/>
<seriesInfo name='RFC' value='3864'/>
<seriesInfo name='DOI' value='10.17487/RFC3864'/>
</reference>
<reference anchor="RFC5234" target='https://www.rfc-editor.org/info/rfc5234'>
<front>
<title>Augmented BNF for Syntax Specifications: ABNF</title>
<author initials='D.' surname='Crocker' fullname='D. Crocker' role='editor'><org
anization /></author>
<author initials='P.' surname='Overell' fullname='P. Overell'><organization /></
author>
<date year='2008' month='January' />
<abstract><t>Internet technical specifications often need to define a formal syn
tax. Over the years, a modified version of Backus-Naur Form (BNF), called Augme
nted BNF (ABNF), has been popular among many Internet specifications. The curre
nt specification documents ABNF. It balances compactness and simplicity with rea
sonable representational power. The differences between standard BNF and ABNF i
nvolve naming rules, repetition, alternatives, order-independence, and value ran
ges. This specification also supplies additional rule definitions and encoding
for a core lexical analyzer of the type common to several Internet specification
s. [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='STD' value='68'/>
<seriesInfo name='RFC' value='5234'/>
<seriesInfo name='DOI' value='10.17487/RFC5234'/>
</reference>
<reference anchor="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'><o
rganization /></author>
<author initials='J.' surname='Reschke' fullname='J. Reschke' role='editor'><org
anization /></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 reque
st methods, request header fields, response status codes, and response header fi
elds, along with the payload of messages (metadata and body content) and mechani
sms 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'><o
rganization /></author>
<author initials='M.' surname='Nottingham' fullname='M. Nottingham' role='editor
'><organization /></author>
<author initials='J.' surname='Reschke' fullname='J. Reschke' role='editor'><org
anization /></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/c
lient-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 Comm
unity, 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 /></auth
or>
<date year='2017' month='May' />
<abstract><t>RFC 2119 specifies common key words that may be used in protocol s
pecifications. This document aims to reduce the ambiguity by clarifying that on
ly UPPERCASE usage of the key words have the defined special meanings.</t></abs
tract>
</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> <front>
<title>Structured Field Values for HTTP</title> <title>Structured Field Values for HTTP</title>
<author initials='M' surname='Nottingham' fullname='Mark Nottingham'> <author initials='M' surname='Nottingham' fullname='Mark Nottingham'>
<organization /> <organization />
</author> </author>
<author initials='P-H.' surname='Kamp' fullname='Poul-Henning Kamp'>
<author initials='P' surname='Kamp' fullname='Poul-Henning Kamp'>
<organization /> <organization />
</author> </author>
<date month='January' year='2021' />
<date month='June' day='3' year='2020' />
<abstract><t>This document describes a set of data types and associated algorith
ms that are intended to make it easier and safer to define and handle HTTP heade
r and trailer fields, known as "Structured Fields", "Structured Headers", or "St
ructured 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> </front>
<seriesInfo name='RFC' value='8941' />
<seriesInfo name='Internet-Draft' value='draft-ietf-httpbis-header-structure-19' <seriesInfo name='DOI' value='10.17487/RFC8941' />
/>
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-ietf-httpbis-header-st
ructure-19.txt' />
</reference> </reference>
</references>
</references> <references>
<name>Informative References</name>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.6265.xml"/>
<references title='Informative References'> <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 month="August" year="2020"/>
</front>
</reference>
<reference anchor="RFC6265" target='https://www.rfc-editor.org/info/rfc6265'> <reference anchor="CLIENT-HINTS-INFRASTRUCTURE" target="https://wicg.git
<front> hub.io/client-hints-infrastructure/">
<title>HTTP State Management Mechanism</title> <front>
<author initials='A.' surname='Barth' fullname='A. Barth'><organization /></auth <title>Client Hints Infrastructure</title>
or> <author initials="Y." surname="Weiss" fullname="Yoav Weiss">
<date year='2011' month='April' /> <organization>Google</organization>
<abstract><t>This document defines the HTTP Cookie and Set-Cookie header fields. </author>
These header fields can be used by HTTP servers to store state (called cookies) <date month='July' year='2020'/>
at HTTP user agents, letting the servers maintain a stateful session over the m </front>
ostly stateless HTTP protocol. Although cookies have many historical infeliciti </reference>
es that degrade their security and privacy, the Cookie and Set-Cookie header fie
lds are widely used on the Internet. This document obsoletes RFC 2965. [STANDA
RDS-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/"> <reference anchor="FETCH" target="https://fetch.spec.whatwg.org/">
<front> <front>
<title>User Agent Client Hints</title> <title>Fetch - Living Standard</title>
<author initials="M." surname="West" fullname="Mike West"> <author>
<organization>Google</organization> <organization>WHATWG</organization>
</author> </author>
<author initials="Y." surname="Weiss" fullname="Yoav Weiss"> <date month="September" year="2020"/>
<organization>Google</organization> </front>
</author> <refcontent>Living Standard</refcontent>
<date year="n.d."/> </reference>
</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>
</author>
<date year="n.d."/>
</front>
</reference>
</references>
</references> </references>
<section anchor="changes" title="Changes"> <section numbered="false" anchor="acknowledgements" toc="default">
<name>Acknowledgements</name>
<section anchor="since-00" title="Since -00"> <t>Thanks to <contact fullname="Mark Nottingham"/>, <contact
<t><list style="symbols"> fullname="Julian Reschke"/>, <contact fullname="Chris Bentzel"/>,
<t>Issue 168 (make Save-Data extensible) updated ABNF.</t> <contact fullname="Ben Greenstein"/>, <contact fullname="Tarun
<t>Issue 163 (CH review feedback) editorial feedback from httpwg list.</t> Bansal"/>, <contact fullname="Roy Fielding"/>, <contact
<t>Issue 153 (NetInfo API citation) added normative reference.</t> fullname="Vasiliy Faronov"/>, <contact fullname="Ted Hardie"/>,
</list></t> <contact fullname="Jonas Sicking"/>, <contact fullname="Martin
Thomson"/>, and numerous other members of the IETF
</section> HTTP Working Group for invaluable help and feedback.</t>
<section anchor="since-01" title="Since -01"> </section>
<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>
<section numbered="false" anchor="acknowledgements" title="Acknowledgements">
<t>Thanks to Mark Nottingham, Julian Reschke, Chris Bentzel, Ben Greenstein, Tar
un Bansal, Roy Fielding, Vasiliy Faronov, Ted Hardie, Jonas Sicking, Martin Thom
son, and numerous other members of the IETF HTTP Working Group for invaluable he
lp and feedback.</t>
</section>
</back> </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> </rfc>
 End of changes. 50 change blocks. 
869 lines changed or deleted 476 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/