W3C home > Mailing lists > Public > public-tracking@w3.org > March 2014

Re: TPE Editorial Proposal to Remove Another Hard Dependency on the Compliance Specification

From: Justin Brookman <jbrookman@cdt.org>
Date: Thu, 6 Mar 2014 21:45:25 -0500
Message-ID: <2590280436-734007296@mail.maclaboratory.net>
To: Shane M Wiley <wileys@yahoo-inc.com>
Cc: "public-tracking@w3.org (public-tracking@w3.org)" <public-tracking@w3.org>
That's not how I read Roy's comments.

The signal means what it means.  If we define the signal to mean, "hey, don't do X, Y, and Z," you can't respond back "we interpret the signal to mean don't do A."  That's not what the protocol is designed to do.  Instead, you can respond back, "we respond to your request by not doing A," or "we respond to your request by not doing X, Y, and Z," or "we respond to your request by not doing X and Y," or "we respond to you request by not doing V, W, X, Y, & Z."  And then the user or user agent will have to intermediate those responses and decide how to treat the resource accordingly.

In any event, the compliance spec as currently formulated allows for some collection and use of data beyond what the user requests with a DNT:1 signal.  I expect other compliance regimes might do the same thing (though a few implementations today adhere to an absolute Do Not Collect standard that would strictly comply with the DNT:1 request).

But you can't redefine what the header signifies.

Shane M Wiley <wileys@yahoo-inc.com> , 3/6/2014 9:17 PM:
   

Roy, 

  

Thank you for the thoughtful response. 

  

Based on your comments below it appears you would feel comfortable if a Server sent back the “T” and a resource link explaining what “Tracking” means to them  and how they manage DNT requests?  I believe the core concern is that the TPE hard coded a definition for Tracking where a compliance standard may have a slightly different definition.  I’m looking for a way to bridge the two worlds. 

  

“The existing value of "T" is already sufficient to cover this use case.  It says that the server *might* be tracking as defined by TPE and that compliance  (or not) to the user's expressed preference is defined by the combination of the identified compliance regime(s) and the accompanied qualifier values as defined by that regime(s).” 

  

- Shane 

    

From: Roy T. Fielding [mailto:fielding@gbiv.com] 
 Sent: Thursday, March 06, 2014 7:50 PM
 To: Jack Hobaugh
 Cc: Matthias Schunter (Intel Corporation); Justin Brookman; Carl Cargill; public-tracking@w3.org (public-tracking@w3.org)
 Subject: Re: TPE Editorial Proposal to Remove Another Hard Dependency on the Compliance Specification   

    

On Mar 6, 2014, at 10:06 AM, Jack Hobaugh wrote:  


 
        

[JLH: Respectfully, I agree that if a compliance regime has a conflicting definition of tracking        

   

That is not a relevant concern.  No compliance spec can redefine what   

has already been defined by the protocol.  It can fail to implement the   

protocol, but not redefine it.   

           

, it does not change the meaning of the DNT signal or the definition of tracking in the TPE and I agree that the compliance regime will specify how sites respond  and also the meaning of those responses.  That is exactly the flexibility that I am requesting through the editorial addition of a TSV “R” value that refers the user to the compliance regime being used by the server.  I am specifically asking for an editorial  change to the syntax in adding a TSV value of “R” to the set of current TSV values.  Again, this editorial change does not affect the TPE definition of "tracking" nor does it affect the meaning of the DNT signal.]         

   

What you are requesting is the ability to not respond in a meaningful way   

to the user.  The WG has already made clear that a meaningful response is   

necessary (in the form of a TSR or header field) in order for the server   

to implement the protocol.  Introducing a new response that effectively   

says nothing is therefore not an editorial change.   

           

(B) If a site posts a link to a compliance regime at the well-known resource, then this indicates that a site follows this compliance regime and adheres to it.    

     

[JLH: I agree and the “R” TSV value alerts the user to look to that link.  It [R]efers the user to that compliance link.]         

    

The existing value of "T" is already sufficient to cover this use case.   

It says that the server *might* be tracking as defined by TPE and   

that compliance (or not) to the user's expressed preference is defined   

by the combination of the identified compliance regime(s) and the   

accompanied qualifier values as defined by that regime(s).   

         

[JLH: The “R” TSV value is only redundant if the server adopts the W3C TCS because the definition of "tracking" will be the same definition in both the TPE and  the TCS as the "tracking" definition plus other definitions in the TPE were "ported" from the TCS into the TPE.   But in cases where the server adopts a non-W3C compliance regime, the "R" value is not redundant as it provides a signal to the user to refer  to the compliance link for how the server will treat the DNT signal.  This editorial change proposal is within the spirit of Issue-136, removing dependencies on the TCS.  If the server can only respond with a "T," which is tied to a definition from the TCS,  then the server is effectively forced to implement at least part of the TCS and again, that may conflict with the non-W3C compliance regime in place on the server.  An "R" value permits the TPE and TCS to be completely uncoupled and provides the possibility  for a sever to comply with both the TPE and a non-W3C compliance regime.]        

   

The definition of tracking is in TPE.  Where it came from is irrelevant,   

particularly given that the chosen definition was specifically proposed   

to be within TPE and never actually appeared in TCS before that.   

It was not "ported" from any other document, though that too is irrelevant   

to a WG decision. It is part of the protocol.   

    

In short, this is issue-5 and it is closed.  If you don't like it, new   

information must be provided (that was not considered in the discussion   

leading to the decision on issue-5) if you would like the chairs to   

consider reopening it.  Failing that, the choice is to either implement   

the protocol as defined or don't claim to be conformant.  

      

Cheers,
 
 Roy T. Fielding                     <http://roy.gbiv.com/>
 Senior Principal Scientist, Adobe   <http://www.adobe.com/>     

   
Received on Friday, 7 March 2014 02:45:54 UTC

This archive was generated by hypermail 2.3.1 : Friday, 3 November 2017 21:45:21 UTC