WWW/2011/tracking-protection/drafts tracking-dnt.html,1.150,1.151

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

Modified Files:
	tracking-dnt.html 
Log Message:
(editorial) change section on Using the Tracking Status to a list of
subsections that will answer each use case, once we have the text ready.


Index: tracking-dnt.html
===================================================================
RCS file: /w3ccvs/WWW/2011/tracking-protection/drafts/tracking-dnt.html,v
retrieving revision 1.150
retrieving revision 1.151
diff -u -d -r1.150 -r1.151
--- tracking-dnt.html	14 Aug 2012 01:17:12 -0000	1.150
+++ tracking-dnt.html	14 Aug 2012 01:33:21 -0000	1.151
@@ -1145,67 +1145,71 @@
 
       <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
-          be accessed and reviewed prior to making use of those services
-          and prior to making requests on third-party resources referenced
-          by those services.  In addition, the presence (or absence) of a
-          site-wide tracking status representation is a means for testing
-          deployment of this standard and verifying that a site's claims
-          regarding tracking are consistent with the site's observed
-          behavior over time.
-        </p>
-        <p>
-          A user agent MAY check the tracking status for a designated
-          resource by making a retrieval request for the well-known address
-          </q><code>/.well-known/dnt</code></q> relative to the URI of the
-          designated resource.
-        </p>
-        <p>
-          If the response is an error, then the service does not implement
-          this standard. If the response is a redirect, then follow the
-          redirect to obtain the tracking status (up to some reasonable
-          maximum of redirects to avoid misconfigured infinite request
-          loops). If the response is successful, obtain the tracking status
-          representation from the message payload, if possible, or consider
-          it an error.
-        </p>
-        <p>
-          Once the tracking status representation is obtained,
-          parse the representation as JSON to extract the Javascript
-          <a>status-object</a>.
-          If parsing results in a syntax error, the user agent SHOULD
-          consider the site to be non-conformant with this protocol.
-        </p>
-        <p>
-          The <a>status-object</a> is supposed to have a member named
-          <code><a>tracking</a></code> containing the tracking status value.
-        </p>
-        <p>
-          If the tracking status value is <a>N</a>, then the origin server
-          claims that no tracking is performed for the designated resource
-          for at least the next 24 hours or until the Cache-Control
-          information indicates that this response expires.
-        </p>
-        <p>
-          If the tracking status value is not <a>N</a>, then the origin
-          server claims that it might track the user agent for requests on
-          the URI being checked for at least the next 24 hours or until the
-          Cache-Control information indicates that this response expires.
-        </p>
-        <p>
-          The meaning of each tracking status value is defined in
-          <a href="#tracking-status-value" class="sectionRef"></a>.
-        </p>
-        <p>
-          The others members of the <a>status-object</a> MAY be used to
-          help the user agent differentiate between a site's first-party
-          and third-party services, to provide links to additional
-          human-readable information related to the tracking policy, and
-          to provide links for control over past data collected or over
-          some consent mechanism outside the scope of this protocol.
+        <p class="note">
+          This section is for collecting use cases that describe questions a
+          user agent might have about tracking status and how the protocol
+          can be used to answer such questions.  More cases are needed.
         </p>
+
+        <section id='using-deployment'>
+          <h4>Discovering Deployment</h4>
+          <p>
+            The presence of a site-wide tracking status representation is a
+            claim that the service conforms to this protocol for a given user
+            agent.  Hence, deployment of this protocol for a given service can
+            be discovered by making a retrieval request on the site-wide
+            tracking resource <q><code>/.well-known/dnt</code></q> relative
+            to the service URI.
+          </p>
+          <p>
+            If the response is an error, then the service does not implement
+            this standard. If the response is a redirect, then follow the
+            redirect to obtain the tracking status (up to some reasonable
+            maximum of redirects to avoid misconfigured infinite request
+            loops). If the response is successful, obtain the tracking status
+            representation from the message payload, if possible, or consider
+            it an error.
+          </p>
+        </section>
+
+        <section id='using-preflight'>
+          <h4>Preflight Checks</h4>
+          <p>
+            A key advantage of providing the tracking status at a resource
+            separate from the site's normal services is that the status can
+            be accessed and reviewed prior to making use of those services
+            and prior to making requests on third-party resources referenced
+            by those services.
+          </p>
+          <p>
+            A user agent MAY check the tracking status for a designated
+            resource by first making a retrieval request for the site-wide
+            tracking status representation, as described above, and then
+            parsing the representation as JSON to extract the Javascript
+            <a>status-object</a>.
+            If retrieval is unsuccessful or parsing results in a syntax error,
+            the user agent SHOULD consider the site to be non-conformant with
+            this protocol.
+          </p>
+          <p>
+            The <a>status-object</a> is supposed to have a member named
+            <code><a>tracking</a></code> containing the tracking status value.
+            The meaning of each tracking status value is defined in
+            <a href="#tracking-status-value" class="sectionRef"></a>.
+          </p>
+          <p>
+            If the tracking status value is <a>N</a>, then the origin server
+            claims that no tracking is performed for the designated resource
+            for at least the next 24 hours or until the Cache-Control
+            information indicates that this response expires.
+          </p>
+          <p>
+            If the tracking status value is not <a>N</a>, then the origin
+            server claims that it might track the user agent for requests on
+            the URI being checked for at least the next 24 hours or until the
+            Cache-Control information indicates that this response expires.
+          </p>
+        </section>
       </section>
     </section>
 

Received on Tuesday, 14 August 2012 01:33:24 UTC