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

WWW/2011/tracking-protection/drafts tracking-dnt.html,1.111,1.112

From: Roy Fielding via cvs-syncmail <cvsmail@w3.org>
Date: Sun, 29 Apr 2012 11:01:57 +0000
To: public-tracking-commit@w3.org
Message-Id: <E1SORt7-0006O6-2g@lionel-hutz.w3.org>
Update of /w3ccvs/WWW/2011/tracking-protection/drafts
In directory hutz:/tmp/cvs-serv22695

Modified Files:
	tracking-dnt.html 
Log Message:
ACTION-171 Insert the tk/uri hybrid into the tracking-dnt draft.
I merged the hybrid resource/header proposal from Tom's ACTION-145 with various
simplifications to address comments from Heather and JC.
Renamed "same-site" to "same-party" to make it obvious why it exists.


Index: tracking-dnt.html
===================================================================
RCS file: /w3ccvs/WWW/2011/tracking-protection/drafts/tracking-dnt.html,v
retrieving revision 1.111
retrieving revision 1.112
diff -u -d -r1.111 -r1.112
--- tracking-dnt.html	18 Apr 2012 01:18:04 -0000	1.111
+++ tracking-dnt.html	29 Apr 2012 11:01:54 -0000	1.112
@@ -463,100 +463,115 @@
     <section id='responding'>
       <h2>Communicating a Tracking Status</h2>
 
-      <div class='note'>
+      <section id='response-overview'>
+        <h3>Overview</h3>
+
         <p>
-          The next two sections detail two proposals how to communicate
-          tracking status:
+          The Tracking Protection 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.
+          However, there is also a desire to support verification or
+          pre-flight testing of a site's conformance with this protocol for
+          evaluating conformance before sending data, enabling specialized
+          user interfaces, discovering the scope of protocol deployment, and
+          testing adherence to potential regulations.
         </p>
-        <ul>
-          <li>Well-known URI to allow user agent to retrieve tracking status
-              for a site</li>
-          <li>HTTP Response header to communicate tracking status for a
-              request</li>
-        </ul>
         <p>
-          This is work in progress. The WG has not yet decided which of these
-          options (or both) to choose. The WG is currently working on a
-          resolution but nevertheless appreciates input on this open issue.
-          We are currently working on a proposal which combines the Tk
-          response header and Tracking Status Resource. It would make the TSR
-          compulsory and the Tk header optional. However, it would be
-          required to use the Tk header to notify the user when something in
-          the TSR has changed in real time.
+          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.
         </p>
-      </div>
+      </section>
 
-      <section id='status-resource' class="option">
+      <section id='status-resource'>
         <h3>Tracking Status Resource</h3>
-	   <section id='status-resource-defn'>
-        <h4>Resource Definition</h4>
-        <p>
-          An origin server MUST provide a <dfn>tracking status resource</dfn>
-          at the well-known identifier [[RFC5785]]
-        </p>
-        <pre>/.well-known/dnt</pre>
-        <p>
-         (relative to the URI of that origin server) for obtaining information
-         about the potential tracking behavior of services provided by
-         that origin server.  A tracking status resource MAY be used for
-         verification of DNT support, as described in
-          <a href="#using-tracking-status" class="sectionRef"></a>.
-        </p>
-        <p>
-          A valid retrieval request (e.g., a <code>GET</code> in [[!HTTP11]])
-          on the well-known URI MUST result in either a successful response
-          containing a machine-readable representation of the site-wide
-          tracking status, as defined below, or a sequence of redirects that
-          leads to such a representation.
-          A user agent MAY consider failure to provide access to such a
-          representation equivalent to the origin server not implementing
-          this protocol.  The representation might be cached, as described
-          in <a href="#status-caching" class="sectionRef"></a>.
-        </p>
-        <p>
-          If an origin server contains multiple services that are controlled
-          by distinct parties or that might have differing behavior or
-          policies regarding tracking, then it MAY also provide a space of
-          well-known resources for obtaining information about the potential
-          tracking behavior of each specific service.  This parallel tree of
-          resources is called the <dfn>tracking status resource space</dfn>.
-        </p>
-        <p>
-          The tracking status resource space is defined by the
-          following URI Template [[URI-TEMPLATE]]:
-        </p>
-        <pre>/.well-known/dnt{+pathinfo}</pre>
-        <p>
-          where the value of <code>pathinfo</code> is equal to the
-          path component [[RFC3986]] of a given reference to that
-          origin server, excluding those references already within the above
-          resource space.  For example, a reference to
-        </p>
-        <pre>http://example.com/over/here?q=hello#top</pre>
-        <p>
-          MAY have a corresponding tracking status resource identified by
-        </p>
-        <pre>http://example.com/.well-known/dnt/over/here</pre>
-        <p>
-          Resources within the tracking status resource space are represented
-          using the same format as a site-wide tracking status resource.
-        </p>
-        <p>
-          All requests for well-known URIs defined here MUST NOT be tracked,
-          irrespective of the presence, value, or absence of a DNT header,
-          cookies, or any other information in the request. In addition, all
-          responses to requests on a tracking status resource, including
-          redirected requests, MUST NOT include Set-Cookie or Set-Cookie2
-          header fields [[COOKIES]] and MUST NOT include content that would
-          have the effect of initiating tracking beyond what is already
-          present for 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-resource-defn'>
+          <h4>Definition</h4>
+
+          <p>
+            An origin server MUST provide a <dfn>tracking status
+            resource</dfn> at the well-known identifier [[RFC5785]]
+          </p>
+          <pre>/.well-known/dnt</pre>
+          <p>
+           (relative to the URI of that origin server) for obtaining
+           information about the potential tracking behavior of resources
+           provided by that origin server.  A tracking status resource MAY be
+           used for verification of DNT support, as described in
+           <a href="#using-tracking-status" class="sectionRef"></a>.
+          </p>
+          <p>
+            A valid retrieval request (e.g., a <code>GET</code> in HTTP)
+            on the well-known URI MUST result in either a successful response
+            containing a machine-readable representation of the site-wide
+            tracking status, as defined below, or a sequence of redirects that
+            leads to such a representation.
+            A user agent MAY consider failure to provide access to such a
+            representation equivalent to the origin server not implementing
+            this protocol.  The representation might be cached, as described
+            in <a href="#status-caching" class="sectionRef"></a>.
+          </p>
+          <p>
+            If an origin server contains multiple services that are controlled
+            by distinct parties or that might have differing behavior or
+            policies regarding tracking, then it MAY also provide a space of
+            well-known resources for obtaining information about the potential
+            tracking behavior of each specific service.  This parallel tree of
+            resources is called the <dfn>tracking status resource space</dfn>.
+          </p>
+          <p>
+            The <dfn>tracking status resource space</dfn> is defined by the
+            following URI Template [[URI-TEMPLATE]]:
+          </p>
+          <pre>/.well-known/dnt{+pathinfo}</pre>
+          <p>
+            where the value of <code>pathinfo</code> is equal to the
+            path component [[RFC3986]] of a given reference to that
+            origin server, excluding those references already within the above
+            resource space.  For example, a reference to
+          </p>
+          <pre>http://example.com/over/here?q=hello#top</pre>
+          <p>
+            MAY have a corresponding tracking status resource identified by
+          </p>
+          <pre>http://example.com/.well-known/dnt/over/here</pre>
+          <p>
+            Resources within the tracking status resource space are
+            represented using the same format as a site-wide tracking status
+            resource.
+          </p>
+          <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-representation'>
-          <h3>Tracking Status Representation</h3>
+          <h3>Representation</h3>
           <p>
             The representation of a tracking status resource SHALL be provided
             in the "application/json" format [[!RFC4627]] and MUST conform to
@@ -571,7 +586,7 @@
   "tracking": true,
   "received": "1",
   "response": "t1",
-  "same-site": [
+  "same-party": [
     "example.com",
     "example_vids.net",
     "example_stats.com"
@@ -655,41 +670,14 @@
             this user in light of the received <a>DNT-field-value</a>.
             The string value begins with "t" (tracking) or "n" (not tracking)
             and MAY be followed by alphanumeric characters that indicate
-            reasons for that status, as described in the following table.
+            qualifiers for that status.
+            The defined qualifier characters and their meanings are described
+            in <a href="#status-reponse-value" class="sectionRef"></a>.
           </p>
-          <table class="simple" width="80%" align="center">
-            <tr><th>reasons</th>
-                <th>meaning</th>
-            </tr>
-            <tr><td align="middle">1</td>
-                <td>Designed for use as a first-party only</td>
-            </tr>
-            <tr><td align="middle">3</td>
-                <td>Designed for use as a third-party<td>
-            </tr>
-            <tr><td align="middle">a</td>
-                <td>Limited to advertising audits<td>
-            </tr>
-            <tr><td align="middle">c</td>
-                <td>Prior consent received from this user agent<td>
-            </tr>
-            <tr><td align="middle">f</td>
-                <td>Limited to fraud prevention<td>
-            </tr>
-            <tr><td align="middle">g</td>
-                <td>For compliance with regional/geographic constraints<td>
-            </tr>
-            <tr><td align="middle">q</td>
-                <td>Limited to advertising frequency capping<td>
-            </tr>
-            <tr><td align="middle">r</td>
-                <td>Limited to referral information<td>
-            </tr>
-          </table>
           <p>
-            An OPTIONAL member named <code><a>same-site</a></code> MAY be
+            An OPTIONAL member named <code><a>same-party</a></code> MAY be
             provided with an array value containing a list of domain names
-            that the origin server claims are the same site, to the extent
+            that the origin server claims are the same party, to the extent
             they are referenced on this site, since all data collected via
             those references share the same data controller.
           </p>
@@ -752,11 +740,11 @@
             link to a human-readable policy.
           </p>
           <p class='issue'><a href="http://www.w3.org/2011/tracking-protection/track/issues/61">ISSUE-61</a>: A site could publish a list of the other domains that are associated with them<br />
-            <b>[OPEN]</b> The same-site and partners members provide
+            <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>[OPEN]</b> The tracking status resource minimizes
+            <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
@@ -764,8 +752,122 @@
           </p>
         </section>
 
+        <section id='status-response-value'>
+          <h3>Response Value</h3>
+
+          <p>
+            When present, the tracking status response member's value
+            consists of a string of characters that starts with the tracking
+            status, signified by <code>t</code> (tracking) or <code>n</code>
+            (not tracking), and MAY be followed by a set of qualifier
+            characters indicating reasons or limitations applicable to
+            that status. Multiple qualifiers can be provided.
+          </p>
+          <table class="simple" width="80%" align="center">
+            <tr><th>qualifier</th>
+                <th>meaning</th>
+            </tr>
+            <tr><td align="middle">1</td>
+                <td>First-party: The origin server acts as a first-party for
+                  requests on this resource, either in all contexts when no
+                  "3" qualifier is present or only for the domains listed in
+                  <a>same-party</a>.</td>
+            </tr>
+            <tr><td align="middle">3</td>
+                <td>Third-party: The origin server acts as a third-party for
+                  requests on this resource, either in all contexts when no
+                  "1" qualifier is present or only for the domains not listed
+                  in <a>same-party</a>.<td>
+            </tr>
+            <tr><td align="middle">a</td>
+                <td>Audit: Tracking is limited to that necessary for an
+                  external audit of the service context and the data
+                  collected is minimized accordingly.<td>
+            </tr>
+            <tr><td align="middle">c</td>
+                <td>Ad frequency capping: Tracking is limited to frequency
+                  capping and the data collected is minimized accordingly.<td>
+            </tr>
+            <tr><td align="middle">p</td>
+                <td>Prior consent: The origin server believes it has received
+                  prior explicit and informed consent for tracking this user,
+                  user agent, or device.<td>
+            </tr>
+            <tr><td align="middle">f</td>
+                <td>Fraud prevention: Tracking is limited to that necessary
+                  for preventing or investigating fraudulent behavior and
+                  security violations; the data collected is minimized
+                  accordingly.<td>
+            </tr>
+            <tr><td align="middle">l</td>
+                <td>Local constraints: Tracking is limited to what is
+                  required by local law, rule, or regulation and the
+                  data collected is minimized accordingly.<td>
+            </tr>
+            <tr><td align="middle">r</td>
+                <td>Referrals: Tracking is limited to collecting referral
+                  information and the data collected is minimized
+                  accordingly.<td>
+            </tr>
+          </table>
+          <p>
+            Qualifiers that indicate limitations on tracking correspond to
+            the specific permitted uses in [[!TRACKING-COMPLIANCE]]. An
+            origin server indicating one or more of those permitted uses
+            also indicates that it conforms to the requirements associated
+            with those permitted uses. Multiple limitation qualifiers mean
+            that multiple permitted uses of tracking might be present and
+            that each such use conforms to the associated requirements.
+            All limitation qualifiers imply some form of tracking might
+            be used and thus MUST NOT be provided with a tracking status
+            that begins with <code>n</code> (not tracking).
+          </p>
+          <p>
+            A <code>1</code> qualifier indicates that the resource has been
+            designed for use within a first-party context and will conform to
+            the requirements on tracking by a first-party.
+            A <code>3</code> qualifier indicates that the resource has been
+            designed for use within a third-party context and will conform to
+            the requirements on tracking by a third-party.
+            If both qualifiers are present, the resource is designed to
+            dynamically adjust its tracking behavior according to the context
+            in which it is used, and thus conforms to first-party requirements
+            when used in a first-party context and third-party requirements
+            when used in a third-party context.
+          </p>
+          <p>
+            A <code>p</code> qualifier indicates that the origin server
+            believes it has obtained prior explicit and informed consent for
+            tracking the requesting user agent, perhaps via some mechanism
+            not defined by this specification, and that prior consent
+            overrides the tracking preference expressed by this protocol.
+            When prior consent is indicated, the tracking status object
+            SHOULD include an <code><a>options</a></code> member that
+            references a resource for modifying this consent. 
+          </p>
+          <p>
+            Future extensions to this protocol might define additional
+            characters as qualifiers from the
+            <code><a>ext-qualifier</a></code> set (consisting of the
+            remaining unused lowercase letters, dot, dash, and underscore).
+            Recipients SHOULD ignore extension qualifiers that they do not
+            understand.
+          </p>
+    	    <p class="issue"><a href="http://www.w3.org/2011/tracking-protection/track/issues/136">ISSUE-136</a>: Resolve dependencies of the TPE on the compliance specification.<br />
+            The list of qualifiers is intended to correspond to constraints
+            and permitted uses identified by [[!TRACKING-COMPLIANCE]].  The
+            above list will be updated accordingly.
+          </p> 
+    	    <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>[PENDING REVIEW]</b> No, a third party that satisfies the
+    	      requirements for acting as a first party will communicate to
+    	      users as the first party.
+          </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
@@ -846,8 +948,8 @@
           </p>
           <p>
             The remaining characters of the <code><a>response</a></code> value
-            might indicate reasons for the above choices or limitations that
-            the origin server will place on its tracking.
+            might indicate qualifiers for the above choices or limitations
+            that the origin server will place on its tracking.
           </p>
           <p>
             The others members of the <a>status-object</a> MAY be used to
@@ -860,7 +962,7 @@
         </section>
 
         <section id='status-caching'>
-          <h3>Tracking Status Caching</h3>
+          <h3>Caching</h3>
 
           <p>
             If the tracking status is applicable to all users, regardless of
@@ -900,27 +1002,36 @@
             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>update-needed</a> field-value, as described in
+            <a href="#interactive-status-change" class="sectionRef"></a>.
+          </p>
         </section>
 
         <section id='status-abnf'>
-          <h3>Tracking Status ABNF</h3>
+          <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>,
             except that the members within each member-list MAY be provided
             in any order.
           </p>
-        <pre class="abnf">
+          <pre class="abnf">
 <dfn>status-object</dfn> = begin-object member-list end-object
-<dfn>member-list</dfn>   = [ path ns path-v vs      ]
-                tracking       ns tracking-v
-                [ vs received  ns received-v  ]
-                [ vs response  ns response-v  ]
-                [ vs same-site ns same-site-v ]
-                [ vs partners  ns partners-v  ]
-                [ vs policy    ns policy-v    ]
-                [ vs edit      ns edit-v      ]
-                [ vs options   ns options-v   ]
+<dfn>member-list</dfn>   = [ path ns path-v vs ]
+                tracking        ns tracking-v
+                [ vs received   ns received-v   ]
+                [ vs response   ns response-v   ]
+                [ vs same-party ns same-party-v ]
+                [ vs partners   ns partners-v   ]
+                [ vs policy     ns policy-v     ]
+                [ vs edit       ns edit-v       ]
+                [ vs options    ns options-v    ]
                 *( vs extension )
 
 <dfn>path</dfn>          = %x22 "path" %x22
@@ -935,20 +1046,24 @@
 <dfn>response</dfn>      = %x22 "response" %x22
 <dfn>response-v</dfn>    = %x22 <a>r-codes</a> %x22
 
-<dfn>r-codes</dfn>       = ("t" / "n") *reasons
+<dfn>r-codes</dfn>       = ("t" / "n") *qualifier
 
-<dfn>reasons</dfn>       = "1"              ; first-party
-              / "3"              ; third-party
-              / "a"              ; advertising audits
-              / "c"              ; prior consent
-              / "f"              ; fraud prevention
-              / "g"              ; geographic/regional compliance
-              / "q"              ; frequency capping
-              / "r"              ; referrals
-              / ALPHA / DIGIT    ; TBD
+<dfn>qualifier</dfn>     = "1"   ; "1" — first-party
+              / "3"   ; "3" — third-party
+              / %x61  ; "a" — audit
+              / %x63  ; "c" — ad frequency capping
+              / %x66  ; "f" — fraud prevention
+              / %x6C  ; "l" — local law, rule, or regulation
+              / %x70  ; "p" — prior consent
+              / %x72  ; "r" — referrals
+              / ext-qualifier
 
-<dfn>same-site</dfn>     = %x22 "same-site" %x22
-<dfn>same-site-v</dfn>   = array-of-strings
+<dfn>ext-qualifier</dfn> = %x2D-2E / "0" / "2" / %x34-39 / %x5F
+              / %x62 / %x64-65 / %x67-6B / %x6D-%x6F
+              / %x71 / %x73-7A
+
+<dfn>same-party</dfn>    = %x22 "same-party" %x22
+<dfn>same-party-v</dfn>  = array-of-strings
 
 <dfn>partners</dfn>      = %x22 "partners" %x22
 <dfn>partners-v</dfn>    = array-of-strings
@@ -980,204 +1095,95 @@
 <dfn>true</dfn>          = &lt;true,   as defined in [[!RFC4627]]&gt;
 <dfn>false</dfn>         = &lt;false,  as defined in [[!RFC4627]]&gt;
 <dfn>null</dfn>          = &lt;null,   as defined in [[!RFC4627]]&gt;
-        </pre>
+          </pre>
         </section>
       </section>
 
-      <section id='response-header-field' class="option">
+      <section id='response-header-field'>
         <h3>Tk Header Field for HTTP Responses</h3>
-		<section id='response-intro'><h4>Motivation</h4>
-
-        <p>This specification defines an HTTP response header, in order to meet the following needs:</p>
-          <ul>
-            <li>User-agents can confirm that the server with which they are
-              communicating has received their DNT request.</li>
-            <li>User-agents can determine which class of practices the server
-              intends to follow when processing this particular request.</li>
-            <li>User-agents can determine if a server believes that the user
-              has out-of-band consented to let them do additional tracking,
-              and may be able to review or modify that consent.</li>
-            <li>Servers make a clear promise about how they will process data
-              gathered from this particular request.</li>
-            <li>Servers have a well-known place to point to more information
-              about their tracking/privacy practice.</li>
-            <li>Servers can provide customized information to clients if
-              desired.</li>
-          </ul>
-
-		<p>
-          An origin server MAY indicate the tracking status for a particular
-          request by including a <a>Tk</a> header field in the corresponding
-          response.  If a request contains a <a>DNT-field-value</a> starting
-          with "1", an origin server SHOULD send a <a>Tk</a> header field in
-          the corresponding response.
-        </p>
-        
-        <p>
-          If an origin server chooses not to send a Tk header field, then
-          the user agent will not know if the tracking preference has been
-          received or if it will be honored.  This may have negative
-          consequences for the site, such as triggering preventive measures
-          on the user agent or being flagged as non-compliant by tools that
-          look for response header fields.
-        </p>
-        <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>[OPEN]</b> See the proposal in this section.
-        </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>[OPEN]</b> Text in above paragraphs.
-        </p>
-        <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)?
-        </p>
-        
-        </section>
 
-		<section id='response-abnf'><h4>Tk ABNF</h4>
-        <p>
-          The <dfn>Tk</dfn> header field is defined as follows:
-        </p>
-        <pre class="abnf">
-          <dfn>Tk-Response</dfn>      = "Tk:" [CFWS] Tk-Status [CFWS] [ opt-in-flag ] [CFWS] [ reason-code ]
-          <dfn>Tk-Status</dfn>        = no-dnt
-                           / not-tracking
-                           / first-party
-                           / service-provider
-          <dfn>no-dnt</dfn>           = "0"
-          <dfn>not-tracking</dfn>     = "1"
-          <dfn>first-party</dfn>      = %x66   ; lowercase f
-          <dfn>service-provider</dfn> = %x73   ; lowercase s
-          <dfn>opt-in-flag</dfn>      = "1"
-          <dfn>reason-code</dfn>      = ALPHA
-        </pre>
-		</section>
-		
-		<section id='response-meaning'><h4>Tk Semantics</h4>
-        <p>
-          <b>Tk: 0</b> (<a>no-dnt</a>) indicates that this party does not
-          comply with [[!TRACKING-COMPLIANCE]].
-        </p>
-        <p>
-          <b>Tk: 1</b> (<a>not-tracking</a>) indicates that:
-        </p>
-        <ul>
-          <li>this party complies with [[!TRACKING-COMPLIANCE]],
-            and</li>
-          <li>this party will process this request according to the
-            specification for 3rd parties in [[!TRACKING-COMPLIANCE]].
-        </ul>
-        <p>
-          <b>Tk: f</b> (<a>first-party</a>) indicates that:
-        </p>
-        <ul>
-          <li>this party complies with [[!TRACKING-COMPLIANCE]],</li>
-          <li>this resource is intended to be served as a first party, and</li>
-          <li>this party will process this request according to the
-            specifications for 1st parties in [[!TRACKING-COMPLIANCE]].</li>
-        </ul>
-        <p>
-          <b>Tk: s</b> (<a>service-provider</a>) indicates that:
-        </p>
-        <ul>
-          <li>this party complies with [[!TRACKING-COMPLIANCE]],</li>
-          <li>this resource is intended to be used in the context of third party  		acting as an outsourced service provider for a first party, and</li>
-		      <li>this party will process this request according to the exemption
-		        for a third party acting as an outsourced service provider for a
-		        first party, as described in [[!TRACKING-COMPLIANCE]].</li>
-        </ul>
-        <p>
-          The <a>opt-in-flag</a> indicates that the server believes that the
-          user has affirmatively consented to allow this party additional
-          permission to track them. Unless the <a>opt-in-flag</a> is included,
-          the server asserts that will act in responding to this request as if
-          the user has not affirmatively consented to allow this party
-          additional permission to track them. 
-    	</p>
-    	<p>
-    	 The <a>reason-code</a> can be used when requesting more information (see below).
-    	</p>
-        </section>
-        
-		<section id='response-more'><h4>More Information</h4>
+        <section id='Tk-header-defn'>
+          <h4>Definition</h4>
           
-          <p>If a <a>reason code</a> is specified in the response, the well-known resource defined here MUST exist; if an <a>opt-in-flag</a> is included, the wel--known resource defined here SHOULD exist; otherwise it MAY exist.</p>
-            
-          <p>The user can understand and manage their
-          opt-in by visiting the well-known URI
-          <pre>/.well-known/dnt?status={Tk-status}&amp;opt-in={opt-in-flag}&amp;r={reason-code}</pre>
-          relative to the request-target.
-        </p>
-        <p>
-          The information at this URI provides additional information about this party's privacy practices and practices, particularly concerning the <a>opt-in-flag</a>.
-        </p>
-        
-        <p class="note">
-          The above well-known URI has not yet been reconciled with the
-          similar but distinct definition for the tracking status
-          resource. We anticipate that one or the other will be adopted,
-          or the two proposals will be merged.
-        </p>
-
+          <p>
+            As a supplement to the tracking status resource, the <dfn>Tk</dfn>
+            response header field is defined as an OPTIONAL means for
+            indicating basic tracking behavior 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-false / tracking-true / update-needed
+<dfn>tracking-false</dfn>  =  "0"
+<dfn>tracking-true</dfn>   =  "1"
+<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='response-impl'><h4>Implementation and Usage Considerations</h4>
-        
+        <section id='Tk-header-use'>
+          <h4>Indicating Tracking</h4>
+          
           <p>
-            Implementers should use caution when allowing caching of resources
-            on which an opt-in flag is included. If caching is not carefully
-            managed, there is a risk of sending a response intended for
-            opted-in users to users who haven't opted in.
+            An origin server MAY send a <a>Tk</a> header field in a response
+            with a field-value of "0" to indicate that the resource does not
+            perform 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>
-            Implementers should carefully choose the cache properties of the
-            items at the well-known URI. The content at these locations must
-            be correct for the entire cache duration, otherwise users who load
-            stale cached copies of these resources may be misled.
+            An origin server MAY send a <a>Tk</a> header field in a response
+            with a field-value of "1" to indicate that the resource does
+            perform tracking, though not necessarily for this request, and
+            claims to conform to applicable tracking compliance requirements.
+            This has the same meaning as <code>{"tracking": "true"}</code>
+            in the tracking status resource.
           </p>
-          <p>
-            Any party can use the <a>not-tracking</a> response: this response
-            just indicates a behavior. If a first party complies with the
-            third-party definition, they are free to send this response.
-            However, the <a>first-party</a> and <a>service provider</a>
-            responses indicate both a behavior and an intention about that
-            party's status. It would be deceptive to send the <a>first-party</a>
-            header on a resource which is only ever embedded as a third party.
+          <pre class="example">
+Tk: 1
+          </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 resource is mandatory and 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>
-            The <a>no-dnt</a> response should not be used on requests which
-            are processed in accordance with [[!TRACKING-COMPLIANCE]].
-            An entity which implements DNT should not use this response.
+            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 <code><a>edit</a></code> and
+            <code><a>options</a></code> members that might be used to refer
+            to such mechanisms. Although such mechanisms are not defined by
+            this specification, their presence might influence the tracking
+            status object's response value.
           </p>
           <p>
-            When embedding content from other sites, consider how that site
-            expects their content to be used. If you embed/link to an
-            object on another site, it's possible that the resource will send
-            a <a>first-party</a> response even though it is now in a
-            third-party context because the designer of that site never
-            intended that object to be embedded. If a resource always sends a
-            <a>third-party</a> response, there is no risk of this inconsistent
-            response. Only the first-party outsourcer of
-            <a>service-provider</a> objects should ever embed them.
+            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 field-value of
+            lowercase "u" (<a>update-needed</a>).
           </p>
+          <pre class="example">
+Tk: u
+          </pre>
         </section>
-		<section id='response-example'><h4>Examples</h4>
-        <pre class="example">
-Tk: 1
-        </pre>
-		  <p>
-		  	The site is a third or first party, in compliance with the definitions of a 3rd party that is not tracking.
-		  </p>
-        <pre class="example">
-Tk: 1 1 agreed
-        </pre>
-		  <p>
-		  	The site is a third party, that believes it has an explicit opt-in from the user; more information can be found at:
-			<pre>/.well-known/dnt?status=1&amp;opt-in=1&amp;r=agreed</pre>
-		  </p>
-		</section>        
-        </div>
       </section>
- 
+		
       <section id='response-error'>
         <h3>Status Code for Tracking Required</h3>
 
Received on Sunday, 29 April 2012 11:02:01 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 29 April 2012 11:02:01 GMT