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

WWW/2011/tracking-protection/drafts tracking-dnt.html,1.163,1.164

From: David Singer via cvs-syncmail <cvsmail@w3.org>
Date: Thu, 27 Sep 2012 17:28:52 +0000
To: public-tracking-commit@w3.org
Message-Id: <E1THHtM-0006sA-8m@lionel-hutz.w3.org>
Update of /w3ccvs/WWW/2011/tracking-protection/drafts
In directory hutz:/tmp/cvs-serv26343

Modified Files:
	tracking-dnt.html 
Log Message:
removed closed issues



Index: tracking-dnt.html
===================================================================
RCS file: /w3ccvs/WWW/2011/tracking-protection/drafts/tracking-dnt.html,v
retrieving revision 1.163
retrieving revision 1.164
diff -u -d -r1.163 -r1.164
--- tracking-dnt.html	27 Sep 2012 00:57:34 -0000	1.163
+++ tracking-dnt.html	27 Sep 2012 17:28:49 -0000	1.164
@@ -455,10 +455,6 @@
           A server MUST treat the user's most recently received preference as
           authoritative.
         </p>
-        <p class="issue" data-number="84" title="Make DNT status available to JavaScript">
-          <strong>[PENDING REVIEW]</strong>
-          Updated text in this section.
-        </p>
         <p class="issue" data-number="116" title="How can we build a JS DOM property which doesn't allow inline JS to receive mixed signals?">
           <strong>[PENDING REVIEW]</strong>
           Updated text in this section.
@@ -544,17 +540,6 @@
           the current request.
         </p>
 
-        <p class="issue" data-number="120" title="Should the response header be mandatory (MUST) or recommended (SHOULD)">
-          <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" data-number="124" title="Alternative DNT implementations that replace HTTP headers with something else">
-          <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'>
@@ -688,7 +673,8 @@
             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 />
+          <p class="issue" data-number="136" title="Resolve dependencies of the 
+          TPE on the compliance specification">
             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.
@@ -799,9 +785,6 @@
           </p>
           <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.
-          </p>
         </section>
 
         <section id='referring-status-id'>
@@ -1114,16 +1097,6 @@
   "control": "/your/data",
 }
 </pre>
-          <p class="issue" data-number="47" title="Should the response from the server indicate a policy that describes the DNT practices of the server?">
-            <b>[PENDING REVIEW]</b> The tracking status resource is a
-            machine-readable policy and provides a mechanism for supplying a
-            link to a human-readable policy.
-          </p>
-          <p class="issue" data-number="61" title="A site could publish a list of the other domains that are associated with them">
-            <b>[PENDING REVIEW]</b> The <a>same-party</a> and <a>third-party</a>
-            members provide a means to list first-party and third-party domains,
-            respectively.
-          </p>
         </section>
 
         <section id='status-checks-not-tracked'>
@@ -1221,9 +1194,6 @@
           the header fields and/or message body if user login is one of the
           ways through which access is granted.
         </p>
-        <p class="issue" data-number="128" title="HTTP error status code to signal that tracking is required?">
-          <b>[PENDING REVIEW]</b> As defined by this section.
-        </p>
       </section>
 
       <section id='using-tracking-status'>
@@ -1477,13 +1447,6 @@
               with this user preference (see below).
             </li>
           </ol>
-          <p class="issue" data-number="158" title="What is the effect of re-directs for content on the operation of exceptions?">
-            What is the effect of re-directs, when the source of the re-direct
-            would get a different DNT header than the target, using these
-            matching rules?<br />
-            <b>Proposal</b>: The re-direct is not relevant; each site gets the
-            DNT header controlled by the list of grants.
-          </p>
           <p class="issue" data-number="159" title="How do we allow sites that mash-in add-supported content to maintain their own trusted third parties?">
             This model does not support mashed-up content which is in turn
             supported by ads; it's not clear how to distinguish between
@@ -1743,8 +1706,8 @@
 
       <section id="exceptions-enquiry" >
         <h2>Querying a host's exception status</h2>
-                <p class="issue" data-number="160" title="Do we need an exception-query API?">
-            It might be useful, and 'complete the model', if we had a JS API that told a host what its current exception status is in a given context.<br />
+                <p class="issue" data-number="160" title="Do we need an exception-query API?"><b>[PENDING REVIEW]</b>
+            It might be useful, and 'complete the model', if we had a JS API that told a host what its current exception status is in a given context. See proposal here.<br />
             <b>Proposal</b>: Specifically, an API QueryExceptionStatus() which examines the <b>document origin</b> of the script, the current <b>top-level domain</b> and returns an empty string if no DNT header would be sent to that document origin, or the exact DNT header (DNT:1 or DNT:0) that would be sent otherwise.
           </p>
           <dl class="idl" title='[NoInterfaceObject] interface NavigatorDoNotTrack'>
@@ -1892,7 +1855,7 @@
         </p>
 
         <p class="issue" data-number="140" title="Do we need site-specific exceptions, i.e., concrete list of permitted third parties for a site?">
-          <b>[PENDING REVIEW]</b>: In this section; yes, as some sites may
+          <b>[PENDING REVIEW]</b> In this section; yes, as some sites may
           have a mix of trusted/needed third parties, and others that either
           don't need to track, or aren't as trusted, or both. But all sites
           are (a) told what they got granted (list, or *) and (b) are assured
Received on Thursday, 27 September 2012 17:28:56 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 27 September 2012 17:28:57 GMT