Re: ACTION-326 and ACTION-327 BLOCKED on ISSUE-5

On Nov 14, 2012, at 9:47 AM, Thomas Roessler wrote:

> On 2012-11-14, at 18:30 +0100, Shane Wiley <wileys@yahoo-inc.com> wrote:
> 
>> Thomas,
>> 
>> To this statement: “tracking" (a term which doesn't show up in the current normative language…“
>>  
>> Please note the title of both documents.  J  To me that is clearly “normative” in context.  Fair?
> 
> Actually, no -- the title of a specification isn't normative.  Sometimes, the title of a document is even just some acronym, like "HTML."

The charter uses the term tracking.  The browsers use the terms
tracking or "to track" or "do not track".  TPE cannot avoid using
the term tracking as that is the user expression that is being
expressed by the protocol.  The Compliance specification is a
charter deliverable to define tracking and related terms.

In short, I am extremely annoyed that I have to explain this again
and again and again...  THIS working group will not successfully
pretend to define the DNT header field without a definition of
tracking.  If we don't agree on a definition of what the user is
communicating in a way that is consistent with how DNT has been
implemented in practice, or at least how practitioners agree to
change their implementations, then our specs do not qualify as
a definition of the protocol.  As such, this process will have
failed even if we try to go to LC with such an inherently
useless specification.

> It would be good if you could point out where the definition of "tracking" influences the requirements that are placed on implementers, and it would be good if you could articulate what specific result you are trying to accomplish by defining "tracking".

1) Compliance with application-level protocol semantics is determined
   by comparing those semantics to the context in which the protocol
   is being communicated.  Since this is a user preference protocol
   and voluntary compliance is motivated by the user's expression,
   it is required that both parties have a shared understanding of
   what that expression means.  This is particularly important for
   ensuring that the user is not misled about what the configuration
   of DNT:1 will mean to servers, both in the general config and
   in the (unspecified) communication around asking for a UGE.

2) The specific result is that we will make some progress on
   closing irrelevant issues that are far outside the mandate
   of our charter, and narrowing points of debate on other issues
   such that industry can make decisions on whether they can
   implement a requirement without promising the impossible.

3) The people who have to implement Compliance have said,
   repeatedly, that they will not accept blanket prohibition on
   all data collection as a requirement since that is not under
   their control and not implementable while using Web protocols.
   However, most will accept prohibitions on what a user would
   consider tracking, aside from what is *necessary* for
   non-personalized security/fraud/billing, and that includes
   minimizing retention of data that could be used for tracking.
   Likewise, there are some middle ground opinions on specific,
   limited tracking for the sake of frequency capping and audits
   of such capping, since disabling that would result in a much
   worse user experience for DNT:1 users.

Hence, defining tracking in a way that is generally agreed will
give us a path to consensus because it allows us to describe
data collection and retention requirements in a concrete way
that will be implementable by industry and able to be communicated
to the user selecting a preference.

....Roy