W3C home > Mailing lists > Public > public-tracking-commit@w3.org > August 2012

WWW/2011/tracking-protection/drafts tracking-dnt.html,1.140,1.141

From: Roy Fielding via cvs-syncmail <cvsmail@w3.org>
Date: Tue, 07 Aug 2012 06:38:46 +0000
To: public-tracking-commit@w3.org
Message-Id: <E1SydRG-0003ev-Fa@lionel-hutz.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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 7 August 2012 06:38:48 GMT