WWW/2011/tracking-protection/drafts tracking-dnt.html,1.124,1.125

Update of /w3ccvs/WWW/2011/tracking-protection/drafts
In directory hutz:/tmp/cvs-serv4863

Modified Files:
	tracking-dnt.html 
Log Message:
ISSUE-124: revise response overview as per proposal discussed at Bellevue

Index: tracking-dnt.html
===================================================================
RCS file: /w3ccvs/WWW/2011/tracking-protection/drafts/tracking-dnt.html,v
retrieving revision 1.124
retrieving revision 1.125
diff -u -d -r1.124 -r1.125
--- tracking-dnt.html	18 Jul 2012 06:41:07 -0000	1.124
+++ tracking-dnt.html	18 Jul 2012 06:55:05 -0000	1.125
@@ -234,8 +234,8 @@
       </p>
       <p>
         If the user's choice is <code>DNT:1</code> or <code>DNT:0</code>, the
-        tracking preference is called <dfn>enabled</dfn>; otherwise, the
-        tracking preference is called <dfn>not enabled</dfn>.
+        tracking preference is <dfn>enabled</dfn>; otherwise, the
+        tracking preference is <dfn>not enabled</dfn>.
       </p>
       <p>
         A user agent MUST have a default tracking preference of
@@ -276,8 +276,7 @@
         altered by the network environment, aside from blanket limitations
         on what resources can or cannot be accessed through that network.
         Implementations of HTTP that are not under control of the user
-        MUST NOT express a tracking preference that does not reflect
-        the user's preference.
+        MUST NOT generate or modify a tracking preference.
       </p>
     </section>
 
@@ -308,7 +307,8 @@
         </table>
       </p>
       <p>
-        If a tracking preference is <a>not enabled</a>, then this protocol MUST NOT express a preference.  This means that no
+        A user agent MUST NOT send a tracking preference expression if
+        a tracking preference is <a>not enabled</a>.  This means that no
         expression is sent for each of the following cases:
         <ul>
           <li>the user agent does not implement this protocol;</li>
@@ -513,21 +513,33 @@
         <h3>Overview</h3>
 
         <p>
-          The TPE protocol is designed to be applicable
-          regardless of the response from servers that receive the tracking
-          preference expression, allowing conformance to be achieved without
-          impacting the operational performance of site resources.
+          The primary goals of this protocol—expressing the user's preference
+          and adhering to that preference—can be accomplished without any
+          response from the server. However, the protocol also seeks to
+          improve the transparency of tracking behavior by providing a
+          machine-readable means for discovering claims of compliance and
+          determining the current tracking status.
+        </p> 
+        <p>
+          Unfortunately, providing a dynamic indication of tracking compliance
+          on every HTTP response is not feasible, since it would have the
+          effect of disabling caching for the entire Web. Instead, this
+          protocol defines a combination of response mechanisms that allow
+          the information to be communicated without making every response
+          dynamic.
         </p> 
-        <p> To support feedback from a site how the user preferences are honored (either pre-flight or within a HTTP response), this section describes a <a>tracking status resource</a> as well as a <a>Tk</a> response header that specify how a site conforms with DNT.
-        </p>
         <p>
           This section explains how a user agent MAY discover an origin
-          server's tracking status for a given resource.  It defines a
-          REQUIRED well-known <a>tracking status resource</a> for describing
-          a machine-readable tracking status and a <a>Tk</a> response header
-          field that MAY be sent in any HTTP response and MUST be sent in
-          responses to requests that modify the tracking status for that
-          user agent.
+          server's tracking status for a given resource.
+          It defines a REQUIRED <a>site-wide tracking status resource</a> at
+          a specific well-known location and an OPTIONAL space of
+          <a>request-specific tracking status resources</a> for sites where
+          the tracking status might vary based on data within the request.
+          It also defines a <a>Tk</a> response header field that MAY be sent
+          in any HTTP response, MUST be sent in responses to requests that
+          modify the tracking status for a user agent, and MAY direct the
+          user to a request-specific tracking status resource applicable to
+          the current request.
         </p>
       </section>

Received on Wednesday, 18 July 2012 06:55:12 UTC