- From: Roy Fielding via cvs-syncmail <cvsmail@w3.org>
- Date: Tue, 07 Aug 2012 01:11:26 +0000
- To: public-tracking-commit@w3.org
Update of /w3ccvs/WWW/2011/tracking-protection/drafts
In directory hutz:/tmp/cvs-serv2017
Modified Files:
tracking-dnt.html
Log Message:
(editorial) move tracking status sections around for simpler reading and to end with use cases
Index: tracking-dnt.html
===================================================================
RCS file: /w3ccvs/WWW/2011/tracking-protection/drafts/tracking-dnt.html,v
retrieving revision 1.137
retrieving revision 1.138
diff -u -d -r1.137 -r1.138
--- tracking-dnt.html 6 Aug 2012 21:33:30 -0000 1.137
+++ tracking-dnt.html 7 Aug 2012 01:11:24 -0000 1.138
@@ -610,6 +610,20 @@
state-changing request.
</tr>
</table>
+ <p>
+ The tracking status value is case sensitive, as defined formally
+ by the following ABNF:
+ </p>
+ <pre class="abnf">
+<dfn>tracking-v</dfn> = "1" ; "1" — first-party
+ / "3" ; "3" — third-party
+ / %x43 ; "C" - consent
+ / %x4E ; "N" - none
+ / %x53 ; "S" - service provider
+ / %x55 ; "U" - updated
+ / %x58 ; "X" - dynamic
+ </pre>
+
<p class="issue"><a href="http://www.w3.org/2011/tracking-protection/track/issues/137">ISSUE-137</a>: Does hybrid tracking status need to distinguish between first party (1) and outsourcing service provider acting as a first party (s)<br />
<b>[OPEN]</b> There is significant disagreement over whether a
service provider acting on behalf of a first party needs to
@@ -621,12 +635,146 @@
</p>
</section>
- <section id='status-resource'>
- <h3>Tracking Status Resource</h3>
+ <section id='response-header-field'>
+ <h3>Tk Header Field for HTTP Responses</h3>
- <section id='status-resource-defn'>
+ <section id='Tk-header-defn'>
<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
+ indicating that a state-changing request has resulted in an
+ interactive change to the tracking status for this user agent.
+ </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"
+ </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>
+ <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.
+ </p>
+ <pre class="example">
+Tk: 0
+ </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.
+ </p>
+ <pre class="example">
+Tk: 1
+ </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.
+ </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.
+ </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
+ for and obtaining prior consent for tracking, or for modifying
+ prior indications of consent. For example, the tracking status
+ resource's status-object defines a <code><a>control</a></code>
+ member that can refer to such a mechanism. Although such
+ out-of-band mechanisms are not defined by this specification,
+ their presence might influence the tracking status object's
+ response value.
+ </p>
+ <p>
+ When an origin server provides a mechanism via HTTP for
+ establishing or modifying out-of-band tracking preferences,
+ the origin server MUST indicate within the mechanism's response
+ 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>).
+ </p>
+ <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'>
+ <h3>Tracking Status Resource</h3>
+ <section id='site-wide-status-resource'>
+ <h4>Site-wide Tracking Status</h4>
<p>
An origin server MUST provide a <dfn>tracking status
resource</dfn> at the well-known identifier [[RFC5785]]
@@ -650,8 +798,12 @@
this protocol. The representation MAY be cached, as described
in <a href="#status-caching" class="sectionRef"></a>.
</p>
+ </section>
+
+ <section id='request-specific-status-resource'>
+ <h4>Request-specific Tracking Status</h4>
<p>
- If an origin server has multiple, resource-specific tracking
+ 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
@@ -679,10 +831,14 @@
</p>
<pre>/.well-known/dnt/fRx42</pre>
<p>
- Resources within the tracking status resource space are
- represented using the same format as a site-wide tracking status
- resource.
+ Resources within the request-specific tracking status resource
+ space are represented using the same format as a site-wide
+ tracking status resource.
</p>
+ </section>
+
+ <section id='request-specific-status-resource'>
+ <h4>Tracking Status is 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
@@ -901,72 +1057,6 @@
</p>
</section>
- <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
- be accessed and reviewed prior to making use of those services
- and prior to making requests on third-party resources referenced
- by those services. In addition, the presence (or absence) of a
- site-wide tracking status representation is a means for testing
- deployment of this standard and verifying that a site's claims
- regarding tracking are consistent with the site's observed
- behavior over time.
- </p>
- <p>
- A user agent MAY check the tracking status for a designated
- resource by making a retrieval request for the well-known address
- </q><code>/.well-known/dnt</code></q> relative to the URI of the
- designated resource.
- </p>
- <p>
- If the response is an error, then the service does not implement
- this standard. If the response is a redirect, then follow the
- redirect to obtain the tracking status (up to some reasonable
- maximum of redirects to avoid misconfigured infinite request
- loops). If the response is successful, obtain the tracking status
- representation from the message payload, if possible, or consider
- it an error.
- </p>
- <p>
- Once the tracking status representation is obtained,
- parse the representation as JSON to extract the Javascript
- <a>status-object</a>.
- If parsing results in a syntax error, the user agent SHOULD
- consider the site to be non-conformant with this protocol.
- </p>
- <p>
- The <a>status-object</a> is supposed to have a member named
- <code><a>tracking</a></code> containing the tracking status value.
- </p>
- <p>
- If the tracking status value is <a>N</a>, then the origin server
- claims that no tracking is performed for the designated resource
- for at least the next 24 hours or until the Cache-Control
- information indicates that this response expires.
- </p>
- <p>
- If the tracking status value is not <a>N</a>, then the origin
- server claims that it might track the user agent for requests on
- the URI being checked for at least the next 24 hours or until the
- Cache-Control information indicates that this response expires.
- </p>
- <p>
- The meaning of each tracking status value is defined in
- <a href="#tracking-status-value" class="sectionRef"></a>.
- </p>
- <p>
- The others members of the <a>status-object</a> MAY be used to
- help the user agent differentiate between a site's first-party
- and third-party services, to provide links to additional
- human-readable information related to the tracking policy, and
- to provide links for control over past data collected or over
- some consent mechanism outside the scope of this protocol.
- </p>
- </section>
-
<section id='status-caching'>
<h3>Caching</h3>
@@ -1040,14 +1130,6 @@
*( vs extension )
<dfn>tracking</dfn> = %x22 "tracking" %x22
-<dfn>tracking-v</dfn> = "1" ; "1" — first-party
- / "3" ; "3" — third-party
- / %x43 ; "C" - consent
- / %x4E ; "N" - none
- / %x53 ; "S" - service provider
- / %x55 ; "U" - updated
- / %x58 ; "X" - dynamic
-
<dfn>uses</dfn> = %x22 "uses" %x22
<dfn>uses-v</dfn> = %x22 *<a>qualifier</a> %x22
@@ -1098,141 +1180,6 @@
</section>
</section>
- <section id='response-header-field'>
- <h3>Tk Header Field for HTTP Responses</h3>
-
- <section id='Tk-header-defn'>
- <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
- indicating that a state-changing request has resulted in an
- interactive change to the tracking status for this user agent.
- </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"
- </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>
- <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.
- </p>
- <pre class="example">
-Tk: 0
- </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.
- </p>
- <pre class="example">
-Tk: 1
- </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.
- </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.
- </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
- for and obtaining prior consent for tracking, or for modifying
- prior indications of consent. For example, the tracking status
- resource's status-object defines a <code><a>control</a></code>
- member that can refer to such a mechanism. Although such
- out-of-band mechanisms are not defined by this specification,
- their presence might influence the tracking status object's
- response value.
- </p>
- <p>
- When an origin server provides a mechanism via HTTP for
- establishing or modifying out-of-band tracking preferences,
- the origin server MUST indicate within the mechanism's response
- 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>).
- </p>
- <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='response-error'>
<h3>Status Code for Tracking Required</h3>
@@ -1244,6 +1191,72 @@
</p>
<p class='issue'><a href="http://www.w3.org/2011/tracking-protection/track/issues/128">ISSUE-128</a>: HTTP error status code to signal that tracking is required?</p>
</section>
+
+ <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
+ be accessed and reviewed prior to making use of those services
+ and prior to making requests on third-party resources referenced
+ by those services. In addition, the presence (or absence) of a
+ site-wide tracking status representation is a means for testing
+ deployment of this standard and verifying that a site's claims
+ regarding tracking are consistent with the site's observed
+ behavior over time.
+ </p>
+ <p>
+ A user agent MAY check the tracking status for a designated
+ resource by making a retrieval request for the well-known address
+ </q><code>/.well-known/dnt</code></q> relative to the URI of the
+ designated resource.
+ </p>
+ <p>
+ If the response is an error, then the service does not implement
+ this standard. If the response is a redirect, then follow the
+ redirect to obtain the tracking status (up to some reasonable
+ maximum of redirects to avoid misconfigured infinite request
+ loops). If the response is successful, obtain the tracking status
+ representation from the message payload, if possible, or consider
+ it an error.
+ </p>
+ <p>
+ Once the tracking status representation is obtained,
+ parse the representation as JSON to extract the Javascript
+ <a>status-object</a>.
+ If parsing results in a syntax error, the user agent SHOULD
+ consider the site to be non-conformant with this protocol.
+ </p>
+ <p>
+ The <a>status-object</a> is supposed to have a member named
+ <code><a>tracking</a></code> containing the tracking status value.
+ </p>
+ <p>
+ If the tracking status value is <a>N</a>, then the origin server
+ claims that no tracking is performed for the designated resource
+ for at least the next 24 hours or until the Cache-Control
+ information indicates that this response expires.
+ </p>
+ <p>
+ If the tracking status value is not <a>N</a>, then the origin
+ server claims that it might track the user agent for requests on
+ the URI being checked for at least the next 24 hours or until the
+ Cache-Control information indicates that this response expires.
+ </p>
+ <p>
+ The meaning of each tracking status value is defined in
+ <a href="#tracking-status-value" class="sectionRef"></a>.
+ </p>
+ <p>
+ The others members of the <a>status-object</a> MAY be used to
+ help the user agent differentiate between a site's first-party
+ and third-party services, to provide links to additional
+ human-readable information related to the tracking policy, and
+ to provide links for control over past data collected or over
+ some consent mechanism outside the scope of this protocol.
+ </p>
+ </section>
</section>
<section id='exceptions' class="option">
Received on Tuesday, 7 August 2012 01:11:28 UTC