- From: CVS User rfieldin <cvsmail@w3.org>
- Date: Wed, 15 Jan 2014 00:33:31 +0000
- To: public-tracking-commit@w3.org
Update of /w3ccvs/WWW/2011/tracking-protection/drafts
In directory gil:/tmp/cvs-serv10033
Modified Files:
tracking-dnt.html
Log Message:
(editorial) move section on tracking status representation up a level in TOC so that we can later split it into subsections; no content is changed by this commit
--- /w3ccvs/WWW/2011/tracking-protection/drafts/tracking-dnt.html 2013/12/08 07:30:19 1.229
+++ /w3ccvs/WWW/2011/tracking-protection/drafts/tracking-dnt.html 2014/01/15 00:33:31 1.230
@@ -913,6 +913,88 @@
</p>
</section>
+ <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
+ request) that would be sent in a normal request to that origin
+ server, since that data might be needed by the server to determine
+ the current tracking status. For example, the cookie data might
+ indicate a prior out-of-band decision by the user to opt-out or
+ consent to tracking by that origin server.
+ </p>
+ <p>
+ All requests on the tracking status resource space, including
+ the site-wide tracking status resource, MUST NOT be tracked,
+ irrespective of the presence, value, or absence of a DNT header
+ field, cookies, or any other information in the request.
+ In addition, all responses to those requests, including the
+ responses to redirected tracking status requests, MUST NOT
+ have Set-Cookie or Set-Cookie2 header fields and
+ MUST NOT have content that initiates tracking beyond what was
+ already present in the request.
+ A user agent SHOULD ignore, or treat as an error, any Set-Cookie
+ or Set-Cookie2 header field received in such a response.
+ </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
+ request, then the origin server SHOULD mark the response as
+ cacheable [[!HTTP-cache]] and assign a time-to-live (expiration or
+ max-use) that is sufficient to enable shared caching but not
+ greater than the earliest point at which the service's tracking
+ behavior might increase.
+ </p>
+ <p>
+ For example, if the tracking status response is set to expire in
+ seven days, then the earliest point in time that the service's
+ tracking behavior can be increased is seven days after the
+ tracking status representation has been
+ updated to reflect the new behavior, since old copies might
+ persist in caches until the expiration is triggered. A service's
+ tracking behavior can be reduced at any time, with or without a
+ corresponding change to the tracking status resource.
+ </p>
+ <p>
+ If the tracking status is only applicable to all users that have
+ the same <q>DNT-field-value</q>, then the response MUST either be
+ marked with a Vary header field that includes "DNT" in its
+ field-value or marked as not reusable by a shared cache without
+ revalidation with a Cache-Control header field containing one of
+ the following directives: "private", "no-cache", "no-store", or
+ "max-age=0".
+ </p>
+ <p>
+ If the tracking status is only applicable to the specific user
+ that requested it, then the response MUST include a Cache-Control
+ header field containing one of the following directives:
+ "private", "no-cache", or "no-store".
+ </p>
+ <p>
+ Regardless of the cache-control settings, it is expected that
+ user agents will check the tracking status of a service only once
+ per session (at most). A public Internet site that intends to
+ change its tracking status to increase tracking behavior MUST
+ update the tracking status resource in accordance with that
+ planned behavior at least twenty-four hours prior to activating
+ that new behavior on the service.
+ </p>
+ <p>
+ A user agent that adjusts behavior based on active verification
+ of tracking status, relying on cached tracking status responses
+ to do so, SHOULD check responses to its state-changing requests
+ (e.g., POST, PUT, DELETE, etc.) for a <a>Tk</a> header field
+ with the <a>U</a> tracking status value, as described in
+ <a href="#interactive-status-change" class="sectionRef"></a>.
+ </p>
+ </section>
+ </section>
+
<section id='status-representation'>
<h3>Representation</h3>
<p>
@@ -1176,88 +1258,6 @@
</section>
- <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
- request) that would be sent in a normal request to that origin
- server, since that data might be needed by the server to determine
- the current tracking status. For example, the cookie data might
- indicate a prior out-of-band decision by the user to opt-out or
- consent to tracking by that origin server.
- </p>
- <p>
- All requests on the tracking status resource space, including
- the site-wide tracking status resource, MUST NOT be tracked,
- irrespective of the presence, value, or absence of a DNT header
- field, cookies, or any other information in the request.
- In addition, all responses to those requests, including the
- responses to redirected tracking status requests, MUST NOT
- have Set-Cookie or Set-Cookie2 header fields and
- MUST NOT have content that initiates tracking beyond what was
- already present in the request.
- A user agent SHOULD ignore, or treat as an error, any Set-Cookie
- or Set-Cookie2 header field received in such a response.
- </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
- request, then the origin server SHOULD mark the response as
- cacheable [[!HTTP-cache]] and assign a time-to-live (expiration or
- max-use) that is sufficient to enable shared caching but not
- greater than the earliest point at which the service's tracking
- behavior might increase.
- </p>
- <p>
- For example, if the tracking status response is set to expire in
- seven days, then the earliest point in time that the service's
- tracking behavior can be increased is seven days after the
- tracking status representation has been
- updated to reflect the new behavior, since old copies might
- persist in caches until the expiration is triggered. A service's
- tracking behavior can be reduced at any time, with or without a
- corresponding change to the tracking status resource.
- </p>
- <p>
- If the tracking status is only applicable to all users that have
- the same <q>DNT-field-value</q>, then the response MUST either be
- marked with a Vary header field that includes "DNT" in its
- field-value or marked as not reusable by a shared cache without
- revalidation with a Cache-Control header field containing one of
- the following directives: "private", "no-cache", "no-store", or
- "max-age=0".
- </p>
- <p>
- If the tracking status is only applicable to the specific user
- that requested it, then the response MUST include a Cache-Control
- header field containing one of the following directives:
- "private", "no-cache", or "no-store".
- </p>
- <p>
- Regardless of the cache-control settings, it is expected that
- user agents will check the tracking status of a service only once
- per session (at most). A public Internet site that intends to
- change its tracking status to increase tracking behavior MUST
- update the tracking status resource in accordance with that
- planned behavior at least twenty-four hours prior to activating
- that new behavior on the service.
- </p>
- <p>
- A user agent that adjusts behavior based on active verification
- of tracking status, relying on cached tracking status responses
- to do so, SHOULD check responses to its state-changing requests
- (e.g., POST, PUT, DELETE, etc.) for a <a>Tk</a> header field
- with the <a>U</a> tracking status value, as described in
- <a href="#interactive-status-change" class="sectionRef"></a>.
- </p>
- </section>
- </section>
-
<section id='response-error'>
<h3>Status Code for Tracking Required</h3>
<p>
Received on Wednesday, 15 January 2014 00:33:33 UTC