- From: Roy Fielding via cvs-syncmail <cvsmail@w3.org>
- Date: Tue, 07 Aug 2012 06:38:46 +0000
- To: public-tracking-commit@w3.org
Update of /w3ccvs/WWW/2011/tracking-protection/drafts
In directory hutz:/tmp/cvs-serv14004
Modified Files:
tracking-dnt.html
Log Message:
ISSUE-124: (complete) Redefine Tk header field in terms of tracking status value
Index: tracking-dnt.html
===================================================================
RCS file: /w3ccvs/WWW/2011/tracking-protection/drafts/tracking-dnt.html,v
retrieving revision 1.140
retrieving revision 1.141
diff -u -d -r1.140 -r1.141
--- tracking-dnt.html 7 Aug 2012 01:58:18 -0000 1.140
+++ tracking-dnt.html 7 Aug 2012 06:38:44 -0000 1.141
@@ -530,6 +530,18 @@
user to a request-specific tracking status resource applicable to
the current request.
</p>
+
+ <p class='issue'><a href="http://www.w3.org/2011/tracking-protection/track/issues/120">ISSUE-120</a>: Should the response header be mandatory (MUST) or recommended (SHOULD)</br>
+ <b>[PENDING REVIEW]</b> The site-wide resource is mandatory; the
+ header field is optional, except for the single MUST case above.
+ </p>
+ <p class='issue'><a href="http://www.w3.org/2011/tracking-protection/track/issues/124">ISSUE-124</a>: Alternative DNT implementations that replace HTTP headers with something else<br />
+ <b>[PENDING REVIEW]</b> The tracking status resource minimizes
+ bandwidth usage because only a small proportion of user agents
+ are expected to perform active verification, status would only be
+ requested once per site per day, and the response can be
+ extensively cached.
+ </p>
</section>
<section id='tracking-status-value'>
@@ -537,82 +549,105 @@
<p>
A <dfn>tracking status value</dfn> is a short notation for
- communicating how a designated resource conforms to this protocol.
+ communicating how a designated resource conforms to the tracking
+ protection protocol, as defined by this document and
+ [[!TRACKING-COMPLIANCE]]. There is no form of negative response;
+ i.e., an origin server that does not wish to claim conformance
+ to this protocol would not supply a tracking status resource and
+ would not send a Tk header field in responses.
+ </p>
+ <p>
For a site-wide tracking status resource, the designated resource
- is any resource on the same origin server. For a <a>Tk</a> response
- header field, the corresponding request target is the designated
- resource and remains so for any subsequent request-specific
- tracking status resource referred to by the <a>Tk</a> field's status-id.
+ to which the tracking status applies is any resource on the same
+ origin server. For a <a>Tk</a> response header field, the
+ corresponding request target is the designated resource and
+ remains so for any subsequent request-specific tracking status
+ resource referred to by that field.
</p>
<p>
- Each of the response mechanisms use a common format to indicate
- the tracking status for a designated resource. This
- <dfn>tracking status value</dfn> is a single character from a
- limited set, where the meaning of each allowed character is
- defined in the following table.
+ All of the tracking status mechanisms use a common format for the
+ tracking status value: a single character from a limited set.
+ The meaning of each allowed character is defined in the following
+ table.
</p>
<table class="simple" width="80%" align="center">
- <tr><th>status</th>
+ <tr valign="top">
+ <th>status</th>
<th>meaning</th>
</tr>
- <tr><td align="middle"><dfn>N</dfn></td>
+ <tr valign="top"><td align="middle"><dfn>N</dfn></td>
<td><strong>None</strong>: The designated resource does not
- perform tracking or make use of any data collected from
- tracking, not even for permitted uses.<td>
+ perform tracking of any kind, not even for permitted uses,
+ and does not make use of any data collected from tracking.</td>
</tr>
- <tr><td align="middle"><dfn>1</dfn></td>
+ <tr valign="top"><td align="middle"><dfn>1</dfn></td>
<td><strong>First party</strong>: The designated resource is
- designed for use within a first-party context and conforms to
+ designed for use within a first party context and conforms to
the requirements on a first party.</td>
</tr>
- <tr><td align="middle"><dfn>3</dfn></td>
+ <tr valign="top"><td align="middle"><dfn>3</dfn></td>
<td><strong>Third party</strong>: The designated resource is
- designed for use within a first-party context and conforms to
- the requirements on a third party.<td>
+ designed for use within a third party context and conforms to
+ the requirements on a third party.</td>
</tr>
- <tr><td align="middle"><dfn>X</dfn></td>
+ <tr valign="top"><td align="middle"><dfn>X</dfn></td>
<td><strong>Dynamic</strong>: The designated resource is
designed for use in both first and third party contexts and
dynamically adjusts tracking status accordingly.
If <code>X</code> is present in the site-wide tracking status,
- more information will be provided via the <a>Tk</a> response
- header field when accessing the designated resource.
+ more information MUST be provided via the <a>Tk</a> response
+ header field when accessing a designated resource.
If <code>X</code> is present in the <a>Tk</a> header field,
- more information will be provided in the request-specific
+ more information will be provided in a request-specific
tracking status resource referred to by the <a>status-id</a>.
An origin server MUST NOT send <code>X</code> as the
tracking status value in the representation of a
- request-specific tracking status resource.<td>
+ request-specific tracking status resource.</td>
</tr>
- <tr><td align="middle"><dfn>S</dfn></td>
+ <tr valign="top"><td align="middle"><dfn>S</dfn></td>
<td><strong>Service provider</strong>: The designated resource
is operated by a service provider acting on behalf of the
first party and conforms to the requirements for both a first
- party and a service provider acting as a first party.<td>
+ party and a service provider acting as a first party.</td>
</tr>
- <tr><td align="middle"><dfn>C</dfn></td>
+ <tr valign="top"><td align="middle"><dfn>C</dfn></td>
<td><strong>Consent</strong>: The designated resource believes
- it has received prior explicit and informed consent for
- tracking this user, user agent, or device, perhaps via some
- mechanism not defined by this specification, and that prior
- consent overrides the tracking preference expressed by this
- protocol.
+ it has received prior consent for tracking this user, user
+ agent, or device, perhaps via some mechanism not defined by
+ this specification, and that prior consent overrides the
+ tracking preference expressed by this protocol.</td>
</tr>
- <tr><td align="middle"><dfn>U</dfn></td>
+ <tr valign="top"><td align="middle"><dfn>U</dfn></td>
<td><strong>Updated</strong>: The request resulted in a
potential change to the tracking status applicable to this
- user, user agent, or device. If the user agent relies on a
- cached tracking status, it SHOULD update the cache entry with
+ user, user agent, or device. A user agent that relies on a
+ cached tracking status SHOULD update the cache entry with
the current status by making a new request on the applicable
tracking status resource. An origin server MUST NOT send
<code>U</code> as a tracking status value anywhere other than
a <a>Tk</a> header field that is in response to a
- state-changing request.
+ state-changing request.</td>
</tr>
</table>
<p>
+ For the site-wide tracking status and Tk header field, the tracking
+ status values <code><a>1</a></code> and <code><a>3</a></code>
+ indicate how the designated resource is designed to conform, not
+ the nature of the request. Hence, if a user agent is making a
+ request in what appears to be a third-party context and the
+ tracking status value indicates that the designated resource is
+ designed only for first-party conformance, then either the context
+ has been misunderstood (both are actually the same party) or the
+ resource has been referenced incorrectly. For the request-specific
+ tracking status resource, an indication of first or third party
+ status value describes how the resource conformed to that specific
+ request, and thus indicates both the nature of the request (as
+ viewed by the origin server) and the applicable set of requirements
+ to which the server claims to conform for that request.
+ </p>
+ <p>
The tracking status value is case sensitive, as defined formally
- by the following ABNF:
+ by the following ABNF.
</p>
<pre class="abnf">
<dfn>tracking-v</dfn> = "1" ; "1" — first-party
@@ -642,82 +677,77 @@
<h4>Definition</h4>
<p>
- As a supplement to the tracking status resource, the <dfn>Tk</dfn>
- response header field is defined as an OPTIONAL means for
- indicating DNT conformance and as a REQUIRED means for
+ The <dfn>Tk</dfn> response header field is hereby defined as an
+ OPTIONAL means for indicating the tracking status that applied
+ to the corresponding request and as a REQUIRED means for
indicating that a state-changing request has resulted in an
- interactive change to the tracking status for this user agent.
+ interactive change to the tracking status.
</p>
<pre class="abnf">
-<dfn>Tk-field-name</dfn> = "Tk" ; case-insensitive
-<dfn>Tk-field-value</dfn> = tracking-design [ ";" status-id ]
-<dfn>tracking-design</dfn> = tracking-never
- / tracking-first
- / tracking-third
- / update-needed
-<dfn>tracking-never</dfn> = "0"
-<dfn>tracking-first</dfn> = "1"
-<dfn>tracking-third</dfn> = "3"
-<dfn>update-needed</dfn> = %x75 ; lowercase "u"
+<dfn>Tk-field-name</dfn> = "Tk" ; case-insensitive
+<dfn>Tk-field-value</dfn> = tracking-v [ ";" status-id ]
</pre>
+ <p>
+ The Tk field-value begins with a tracking status value
+ (<a href="#tracking-status-value" class="sectionRef"></a>),
+ optionally followed by a semicolon and a <code>status-id</code>
+ that refers to a request-specific tracking status resource
+ (<a href="#referring-status-id" class="sectionRef"></a>).
+ </p>
+ <p>
+ For example, a Tk header field for a resource that claims not to
+ be tracking would look like:
+ </p>
+ <pre class="example">Tk: N</pre>
+ <p>
+ whereas a <a>Tk</a> header field for a resource that might perform
+ tracking (though not necessarily for every request) and conforms
+ to the third-party requirements of [[!TRACKING-COMPLIANCE]] would
+ look like:
+ </p>
+ <pre class="example">Tk: 3</pre>
+
<p class='issue'><a href="http://www.w3.org/2011/tracking-protection/track/issues/107">ISSUE-107</a>: Exact format of the response header?<br />
<b>[PENDING REVIEW]</b> See the proposal in this section.
</p>
</section>
- <section id='Tk-header-use'>
- <h4>Indicating Tracking Design</h4>
-
- <p>
- The <a>Tk</a> field-value begins with a single character
- <a>tracking-design</a> that indicates how the target resource
- conforms to [[!TRACKING-COMPLIANCE]]. We refer to this as the
- tracking design because it reflects only how the resource is
- designed to work, rather than the current status of tracking
- for this requesting user agent or received DNT field-value.
- Separating the design and status allows conformance to this
- protocol to be indicated without having a negative impact on
- caching of responses.
- </p>
+ <section id='referring-status-id'>
+ <h4>Referring to a Request-specific Tracking Status Resource</h4>
<p>
- An origin server MAY send a <a>Tk</a> header field in a response
- with a tracking-design of "0" to indicate that the resource never
- performs tracking as it is defined by [[!TRACKING-COMPLIANCE]].
- This has the same meaning as <code>{"tracking": "false"}</code>
- in the tracking status resource.
+ If an origin server has multiple, request-specific tracking
+ policies, such that the tracking status might differ depending on
+ some aspect of the request (e.g., method, target URI, header
+ fields, data, etc.), the origin server MAY provide an additional
+ subtree of well-known resources corresponding to each of those
+ distinct tracking statuses. The OPTIONAL <a>status-id</a> portion
+ of the <a>Tk</a> field-value indicates which specific tracking
+ status resource applies to the current request.
</p>
- <pre class="example">
-Tk: 0
+ <pre class="abnf">
+<dfn>status-id</dfn> = 1*id-char ; case-sensitive
+<dfn>id-char</dfn> = ALPHA / DIGIT / "_" / "-" / "+" / "=" / "/"
</pre>
<p>
- An origin server MAY send a <a>Tk</a> header field in a response
- with a tracking-design of "1" to indicate that the resource does
- perform tracking (though not necessarily for every request),
- conforms to [[!TRACKING-COMPLIANCE]], and considers itself to be
- the first-party for this request.
+ For example, a response containing
</p>
- <pre class="example">
-Tk: 1
- </pre>
+ <pre class="example">Tk: 1;fRx42</pre>
<p>
- An origin server MAY send a <a>Tk</a> header field in a response
- with a tracking-design of "3" to indicate that the resource does
- perform tracking (though not necessarily for every request),
- conforms to [[!TRACKING-COMPLIANCE]], and considers itself to be
- a third-party for this request.
+ indicates that the target resource claims to conform to the
+ first-party requirements of [[!TRACKING-COMPLIANCE]] and that
+ an applicable tracking status representation can be obtained by
+ performing a retrieval request on
</p>
- <pre class="example">
-Tk: 3
- </pre>
- <p class='issue'><a href="http://www.w3.org/2011/tracking-protection/track/issues/120">ISSUE-120</a>: Should the response header be mandatory (MUST) or recommended (SHOULD)</br>
- <b>[PENDING REVIEW]</b> The site-wide resource is mandatory; the
- header field is optional, except for the single MUST case below.
+ <pre>/.well-known/dnt/fRx42</pre>
+ <p>
+ If a Tk field-value has a tracking status value of
+ <code><a>X</a></code> (dynamic), then a
+ <code><a>status-id</a></code> MUST be included in the field-value.
</p>
</section>
-
+
<section id='interactive-status-change'>
<h4>Indicating an Interactive Status Change</h4>
-
<p>
We anticipate that interactive mechanisms might be used, beyond
the scope of this specification, that have the effect of asking
@@ -736,38 +766,12 @@
when a state-changing request has resulted in a change to the
tracking status for that server. This indication of an
interactive status change is accomplished by sending a
- <a>Tk</a> header field in the response with a tracking-design of
- lowercase "u" (<a>update-needed</a>).
+ <a>Tk</a> header field in the response with a tracking status
+ value of <code><a>U</a></code> (updated).
</p>
- <pre class="example">
-Tk: u
- </pre>
+ <pre class="example">Tk: U</pre>
</section>
- <section id='indicating-status-id'>
- <h4>Indicating a Specific Tracking Status Resource</h4>
-
- <p>
- If an origin server has multiple, resource-specific tracking
- policies, such that the tracking status might differ depending on
- some aspect of the request (e.g., method, target URI, header
- fields, data, etc.), the origin server MAY provide an additional
- subtree of well-known resources corresponding to each of those
- distinct tracking statuses. The OPTIONAL <a>status-id</a> portion
- of the <a>Tk</a> field-value indicates which specific tracking
- status resource applies to the current request.
- </p>
- <p>
- For example, a response containing
- </p>
- <pre>Tk: 1;fRx42</pre>
- <p>
- indicates that the target resource conforms to this protocol as a
- first-party and the current tracking status can be obtained by
- performing a retrieval request on
- </p>
- <pre>/.well-known/dnt/fRx42</pre>
- </section>
</section>
<section id='status-resource'>
@@ -776,7 +780,7 @@
<section id='site-wide-status-resource'>
<h4>Site-wide Tracking Status</h4>
<p>
- An origin server MUST provide a <dfn>tracking status
+ An origin server MUST provide a <dfn>site-wide tracking status
resource</dfn> at the well-known identifier [[RFC5785]]
</p>
<pre>/.well-known/dnt</pre>
@@ -812,8 +816,6 @@
(<a href="#response-header-field" class="sectionRef"></a>) can
include a <a>status-id</a> to indicate which specific tracking
status resource applies to the current request.
- This subtree of resources is called the <dfn>tracking status
- resource space</dfn>.
</p>
<p>
The <dfn>tracking status resource space</dfn> is defined by the
@@ -825,11 +827,11 @@
characters provided by a <a>Tk</a> field-value in response to a
prior request. For example, a prior response containing
</p>
- <pre>Tk: 1;fRx42</pre>
+ <pre class="example">Tk: 1;ahoy</pre>
<p>
refers to the specific tracking status resource
</p>
- <pre>/.well-known/dnt/fRx42</pre>
+ <pre>/.well-known/dnt/ahoy</pre>
<p>
Resources within the request-specific tracking status resource
space are represented using the same format as a site-wide
@@ -837,8 +839,8 @@
</p>
</section>
- <section id='request-specific-status-resource'>
- <h4>Tracking Status is Not Tracked</h4>
+ <section id='status-checks-not-tracked'>
+ <h4>Status Checks are Not Tracked</h4>
<p>
When sending a request for the tracking status, a user agent
SHOULD include any cookie data [[COOKIES]] (set prior to the
@@ -981,18 +983,10 @@
<b>[PENDING REVIEW]</b> The same-party and partners members provide
a means to list first-party and third-party domains, respectively.
</p>
- <p class='issue'><a href="http://www.w3.org/2011/tracking-protection/track/issues/124">ISSUE-124</a>: Alternative DNT implementations that replace HTTP headers with something else<br />
- <b>[PENDING REVIEW]</b> The tracking status resource minimizes
- bandwidth usage because only a small proportion of user agents
- are expected to perform active verification, status would only be
- requested once per site per day, and the response can be
- extensively cached.
- </p>
</section>
<section id='status-caching'>
<h3>Caching</h3>
-
<p>
If the tracking status is applicable to all users, regardless of
the received <a>DNT-field-value</a> or other data received via the
@@ -1044,7 +1038,6 @@
<section id='status-abnf'>
<h3>Status-object ABNF</h3>
-
<p>
The representation of a site's machine-readable tracking status
MUST conform to the following ABNF for <a>status-object</a>,
@@ -1102,7 +1095,6 @@
<section id='response-error'>
<h3>Status Code for Tracking Required</h3>
-
<p>
If an origin server receives a request with <code>DNT:1</code>,
does not have out-of-band consent for tracking this user, and
@@ -1125,7 +1117,6 @@
<section id='using-tracking-status'>
<h3>Using the Tracking Status</h3>
-
<p>
A key advantage of providing the tracking status at a resource
separate from the site's normal services is that the status can
Received on Tuesday, 7 August 2012 06:38:48 UTC