- From: David Singer <singer@apple.com>
- Date: Fri, 23 Sep 2016 18:45:19 +0100
- To: "Roy T. Fielding" <fielding@gbiv.com>
- Cc: Matthias Schunter <mts-std@schunter.org>, "public-tracking@w3.org (public-tracking@w3.org)" <public-tracking@w3.org>
> On Sep 23, 2016, at 17:05 , Roy T. Fielding <fielding@gbiv.com> wrote: > >> On Sep 23, 2016, at 2:00 AM, David Singer <singer@apple.com> wrote: >>> On Sep 22, 2016, at 20:04 , Roy T. Fielding <fielding@gbiv.com> wrote: >>>> On Sep 22, 2016, at 4:09 AM, Matthias Schunter (Intel Corporation) <mts-std@schunter.org> wrote: >>> >>>> - Change definition of "enabled" to also include exceptions: Once you >>>> recorded an exception, you implicitly enabled the feature. >>> >>> That would not be editorial because the term is used in normative requirements. >>> In any case, it isn't necessary: read the last two paragraphs of >>> >>> https://www.w3.org/TR/tracking-dnt/#determining >> >> OK. But we have a bug; we currently have text that says the header is only sent when DNT is enabled, but later we learn that a site can register an exception even when it’s not, which will cause a DNT header to be sent when applicable, even though the general preference is not enabled. That’s an editorial bug (the statement that it’s only sent when enabled claims to be a statement of fact, not a requirement). > > Sorry, I wasn't clear. Enabled just means the user has made a choice to send DNT. > The spec already states that choice can be made anywhere. That includes making > a decision via the exception API. > > What I mean is that we don't need to change the definition of enabled because > it already encompasses this case. There is no bug. We could add it explicitly > to the list of examples, but that doesn't change the definition of enabled. > > … > Roy > Got it. I fear that it may be misunderstood or seen as a contradiction, so I’d suggest a minor editorial to deal with it thx David Singer Manager, Software Standards, Apple Inc.
Received on Friday, 23 September 2016 17:45:52 UTC