- From: Mike O'Neill <michael.oneill@baycloud.com>
- Date: Thu, 5 Dec 2013 22:19:49 -0000
- To: "'Walter van Holst'" <walter.van.holst@xs4all.nl>, <public-tracking@w3.org>
- Message-ID: <08c001cef208$1d250a70$576f1f50$@baycloud.com>
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I makes no sense for an intermediary to override DNT:0 because that would be an indication for the most part that a UGE has been properly registered by the UA. On the other hand it makes no sense for an intermediary NOT be able to override DNT unset because a person should be able to buy a router for their home that can demand no tracking of any device there. The UA should be able to respond to a UGE, communicate that clearly to the user etc. UAs SHOULD implement the JS UGE, intermediaries SHOULD NOT change an existing DNT setting but they MAY set DNT if it was originally unset if the user has requested that by, for example, configuring their router. Mike From: Walter van Holst [mailto:walter.van.holst@xs4all.nl] Sent: 05 December 2013 20:55 To: public-tracking@w3.org Subject: Re: any additional Proposals on UA requirement to handle exceptions On 05/12/2013 21:48, Jack L. Hobaugh Jr wrote: Nick, To maintain the balance or symmetry as proposed by Shane below, I would also add: To the extent that HTTP intermediaries are permitted by the TPE to inject a “DNT:1” signal (see TPE 4.2), the “HTTP intermediary” MUST also support User Granted Exceptions (“UGE”) to be compliant with the standard. What about "Intermediaries SHALL not inject a DNT:1 signal when a DNT:0 signal is present"? That should achieve the same. The problem with your suggestion is that with the current way UGE is proposed intermediaries cannot support UGE at all. It is not machine readable at a semantic level. So an intermediary cannot reliably notice a UGE request and simply has to pass in on to the UA. If the intermediary subsequently obediently leaves alone subsequent DNT:0 signals from the UA, all is well. Not that you could possibly detect it if it weren't the case... Regards, Walter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (MingW32) Comment: Using gpg4o v3.1.107.3564 - http://www.gpg4o.de/ Charset: utf-8 iQEcBAEBAgAGBQJSoPwEAAoJEHMxUy4uXm2JDzUH/0BZqX6NQqSrt2Expmlhb6cM xuLesrJZz7bybgCiEiZRQ+vhpL/WKct6EDkcM70khNR+iF1+tnfiuVC2+a8SUHr4 Rht5rhv3mGPuAr6+ljhVfK7fXPlzwcT4wkuHbKAc9rpHveSs/pSm3mqd8RGZxnZV TlwKkF5MRU235TlszfsD0iG3X3tq/EwoISg39qik25lzfriAFqAnEIjVMDN0qeay 6oP/HTx1hzPvDaLE1SRgbe42XwkB1CLNr28Qbp0ilZBCTOr0SsQ0xG2zjgjzY62Y ICQs7hOcapeAlGRI5uFd8XYrqK/HQqJltgi228ti0NMr9Z6wu/RFpdq/sxkmrMs= =E4Bp -----END PGP SIGNATURE-----
Attachments
- text/html attachment: PGPexch.htm
- application/octet-stream attachment: PGPexch.htm.sig
Received on Thursday, 5 December 2013 22:20:24 UTC