- From: David Singer via cvs-syncmail <cvsmail@w3.org>
- Date: Thu, 27 Sep 2012 17:28:52 +0000
- To: public-tracking-commit@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 UTC