ISSUE-45 ACTION-246 Clarified proposal on compliance statements

ACTION-246 
(http://www.w3.org/2011/tracking-protection/track/actions/246), which 
relates to ISSUE-45 
(http://www.w3.org/2011/tracking-protection/track/issues/45).

Hello all,

This is a clarification of my previous proposal 
(http://lists.w3.org/Archives/Public/public-tracking/2012Sep/0012.html). 
I'm launching it on a fresh thread, because the previous one got a bit 
wild and off-topic.

Recall that this arose out of the problem of how or where parties may or 
must make statements regarding their DNT compliance. One proposal, which 
many of us strongly objected to, was to make provision of the tracking 
status resource in and of itself an assertion of compliance with the DNT 
spec. That proposal was a replacement for an initial proposal to require 
a public statement of compliance, but without specifying where or how 
that statement must be made.

The problems with these proposals are that the one is overly strict, 
does not provide any flexibility, and sets up a legal landmine that 
companies will avoid by not providing the WKL, and the other is too 
loose; it allows for potentially unlimited variation in how companies 
honor DNT and where and how they make their commitments to do so.

This proposal solves these problems by requiring a statement in the 
status resource regarding compliance with /one of a limited set of DNT 
variations/. Although I understand the desire for and attractiveness of 
a single universal specification for DNT compliance, the reality is that 
we will have to accommodate some variation based on, e.g., business 
model, geography, etc. Examples of this problem arose during the 
Amsterdam meeting. If we want to ensure wide adoption and enforceability 
of DNT, this is the way to do it.

The proposal is the following:

Add a required "compliance" field to the tracking status resource in the 
TPE, where the value indicates the compliance regime under which the 
server is honoring the DNT signal. In 5.5.3 of the TPE:

/    A status-object MUST have a member named /_/compliance/_/that 
contains a single compliance mode token//./

 From here, I look to the group for discussion regarding how and where 
to define compliance mode tokens. My initial version of this proposal 
suggested looking to IANA to manage a limited set of tokens to prevent 
collisions. I think there was some misunderstanding and concern about 
how this would work. No -- companies should not just create their own 
arbitrary values. My view is that each token must have a well-defined 
and widely-accepted meaning. How's this:

/Compliance mode tokens //must be associated with a legislative or 
regulatory regime in a relevant jurisdiction, or with a relevant and 
established self-regulatory regime./

I'm open to other ideas for this.

Cheers,

David