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

WWW/2011/tracking-protection/drafts tracking-dnt.html,1.154,1.155

From: David Singer via cvs-syncmail <cvsmail@w3.org>
Date: Thu, 23 Aug 2012 22:18:19 +0000
To: public-tracking-commit@w3.org
Message-Id: <E1T4fjH-0000Aq-67@lionel-hutz.w3.org>
Update of /w3ccvs/WWW/2011/tracking-protection/drafts
In directory hutz:/tmp/cvs-serv31409

Modified Files:
	tracking-dnt.html 
Log Message:
restored the tracking status qualifier values, integrated the BNF, as instructed
improved the documentation of the requestDNTStatus call, aligned with the general preference attribute



Index: tracking-dnt.html
===================================================================
RCS file: /w3ccvs/WWW/2011/tracking-protection/drafts/tracking-dnt.html,v
retrieving revision 1.154
retrieving revision 1.155
diff -u -d -r1.154 -r1.155
--- tracking-dnt.html	22 Aug 2012 21:47:07 -0000	1.154
+++ tracking-dnt.html	23 Aug 2012 22:18:17 -0000	1.155
@@ -679,6 +679,86 @@
         </p>
       </section>
 
+        <section id='status-qualifier-value'>
+          <h3>Tracking Status Qualifier Values</h3>
+
+          <p>
+            When present, the tracking status qualifier member's value
+            consists of a string of characters indicating what permitted
+            uses for tracking are being used.
+            Multiple qualifiers can be provided.
+          </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 match one to one to the permitted uses 
+            identified by [[!TRACKING-COMPLIANCE]], using references to the
+            definitions there. The list will then be updated accordingly.
+          </p> 
+
+          <table class="simple" width="80%" align="center">
+            <tr><th>qualifier</th>
+                <th>meaning</th>
+            </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">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
+            value of <code>N</code> (not tracking).
+          </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>
+			  The tracking qualifier value is case sensitive, as defined formally
+			  by the following ABNF.
+		  </p>
+		  <pre class="abnf">
+	<dfn>tracking-q</dfn>    = tracking-q-v*
+	<dfn>tracking-q-v</dfn>  = %x61   ; "a" - audit
+			  / %x63  ; "c" — third-party
+			  / %x66  ; "f" - consent
+			  / %x6C  ; "l" - none
+			  / %x72  ; "r" - updated
+			</pre>
+
+        </section>
+        
       <section id='response-header-field'>
         <h3>Tk Header Field for HTTP Responses</h3>
 
@@ -694,7 +774,7 @@
           </p>
           <pre class="abnf">
 <dfn>Tk-field-name</dfn>   =  "Tk"       ; case-insensitive
-<dfn>Tk-field-value</dfn>  =  tracking-v [ ";" status-id ]
+<dfn>Tk-field-value</dfn>  =  tracking-v [tracking-q] [ ";" status-id ]
           </pre>
           <p>
             The Tk field-value begins with a tracking status value
@@ -711,10 +791,11 @@
           <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
+            to the third-party requirements of [[!TRACKING-COMPLIANCE]], while
+            claiming the audit exception, would
             look like:
           </p>
-          <pre class="example">Tk: 3</pre>
+          <pre class="example">Tk: 3a</pre>
 
           <p class="issue" data-number="107" title="Exact format of the response header?">
             <b>[PENDING REVIEW]</b> See the proposal in this section.
@@ -887,7 +968,7 @@
           <pre class="abnf">
 <dfn>status-object</dfn> = begin-object member-list end-object
 
-<dfn>member-list</dfn>   = tracking         ns tracking-v
+<dfn>member-list</dfn>   = tracking         ns tracking-v [tracking-q]
                 [ vs same-party  ns same-party-v  ]
                 [ vs third-party ns third-party-v ]
                 [ vs audit       ns audit-v       ]
@@ -1660,12 +1741,13 @@
           <dl class="idl" title='[NoInterfaceObject] interface NavigatorDoNotTrack'>
             <dt>DOMString requestDNTStatus( )</dt>
             <dd>
-              Returns the string of the value of the DNT header that would be
-              sent in an HTTP request to the <strong>target</strong> that is the
+              Returns the same string value that would be sent in a
+            <a>DNT-field-value</a> (<a href="#dnt-header-field"
+            class="sectionRef"></a>) to a <strong>target</strong> that is the
               document-origin of the request, in the
-              context of the current <strong>top-level domain</strong>. The return
-              value is an empty string if no DNT header would be sent (for example, 
-              if DNT is not configured).
+              context of the current <strong>top-level domain</strong>. If no DNT
+              header would be sent (e.g. because a tracking preference is 
+              <a>not enabled</a>) the return value is <code>null</code>.
             </dd>
           </dl>
 
Received on Thursday, 23 August 2012 22:18:22 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 23 August 2012 22:18:23 GMT