- From: Peter Cranstone <peter.cranstone@gmail.com>
- Date: Fri, 22 Jun 2012 13:07:25 -0600
- To: Rigo Wenning <rigo@w3.org>, Tamir Israel <tisrael@cippic.ca>
- CC: David Singer <singer@apple.com>, <public-tracking@w3.org>, Matthias Schunter <mts-std@schunter.org>, Justin Brookman <justin@cdt.org>
- Message-ID: <CC0A1BC0.4197%peter.cranstone@gmail.com>
As I understand protocols they can be either ACK based or NAK based (if there's a problem). So in your example below the server is compliant (implemented all the MUSTs and SHOULDs) if they EITHER do not respond or respond with a NAK. So the client sends a DNT:1 - the server is compliant, but detects a problem (not sure what the problem could be) but anyway decides NOT to respond or it sends a NAK. Lets take the first case: * Does NOT respond so what exactly is the server doing at this stage? > * My guess is that it's tracking you * Does respond with a NAK > * Exactly where does this NAK go to? >> * My guess is back to the browser what happens then I have no idea >> * And if in the case of a NAK what exactly is the server doing? >>> * My guess is tracking you So unless I'm completely misunderstanding this, the browser can send a valid DNT:1 header, the server can be 100% compliant (def above) and it can choose to ignore the DNT header (but then it wouldn't be compliant I get it). If that's the case then how does the user verify that a DNT signal has actually been received and acknowledged as valid. The server has rejected the header doesn't the customer have a right to know that it's been rejected? And a follow up question. If the NAK acknowledgement is "outside" the scope of this protocol and to be left to the 3rd parties to implement how do we intercept a NAK? Which of course also begs the question if the server just decides not to honor anything and not send a NAK how do we verify that with 3rd party tools? Peter ___________________________________ Peter J. Cranstone 720.663.1752 -----Original Message----- From: Rigo Wenning <rigo@w3.org> Organization: W3C Date: Friday, June 22, 2012 8:18 AM To: Tamir Israel <tisrael@cippic.ca> Cc: David Singer <singer@apple.com>, W3 Tracking <public-tracking@w3.org>, Matthias Schunter <mts-std@schunter.org>, Justin Brookman <justin@cdt.org> Subject: Re: tracking-ISSUE-150: DNT conflicts from multiple user agents [Tracking Definitions and Compliance] Resent-From: W3 Tracking <public-tracking@w3.org> Resent-Date: Fri, 22 Jun 2012 18:50:00 +0000 > Tamir, > > On Thursday 21 June 2012 20:34:25 Tamir Israel wrote: >> My concern is that in this 'exchange' users will inevitably lose >> out since servers will have the more or less final say in all >> instances. Taking a pure contractual analysis stance for a >> moment, under what terms could you enforce /any /DNT-1 against a >> server that has decided to ignore it (and has told you so)? > > This is my central argument in this debate since weeks. Ian Fette > seems to be on the same page. It seems that some techies still have > trouble understanding that. The question remains how this is wrapped > into messages and into DNT marketing and politics. > > For the moment, "honoring the DNT-Header preference" is called "DNT- > compliant" in the market place. Those market semantics are at odds > with typical specification and standardization semantics. There, > "DNT-compliant" means: "Has implemented all the MUSTs and SHOULDs". > > A site that does not respond or responds with NACK has "implemented > all the MUSTs and SHOULDs", but does NOT "honor the DNT-Header > preference". Such a site is "compliant" according to the classic > semantics and "non-compliant" according to the market semantics. > > A way out is to define those two things in a conformance section. > And to rename them. An addition to the TPE Specification would read: > > Conformance section > > 1. An implementation of this Specification that implements all the > MUSTs and SHOULDs relevant for it is called "Specification > complete". > > 2/ An implementation that confirms to follow users' Tracking- > Preferences as defined by section 4 and 5 of this Specification is > called "DNT-compliant". > > This way, the semantic odds are cleared. And it is clear that while > a site has a perfect right to reject the header, it can't call that > behavior "DNT-compliant". > > Best, > > Rigo > > >
Received on Friday, 22 June 2012 19:08:05 UTC