Re: Relaying and Tracing the purpose (email subject changed)

> On Oct 22, 2017, at 5:45 PM, David Singer <singer@apple.com> wrote:

[…snip…]

>> To get round the transparency issue of parties having different codings for purposes, we could insist there is a mandatory field in the TSR (which is designed to be dynamic i.e. it can depend on the whole DNT header) which contains a URI to a page that explains the specific purposes the user has agreed to in human readable terms.
> 
> yes, I agree that the TSR should somehow explain the DNT extensions, if we go this route


[…snip…]

+1 on having a URI point to a human-readable decoder ring. The text on the page MUST match the text as presented to the user when requesting consent, and MAY contain additional information.

It occurs to me that URI then *becomes* the unique prefix that I’d been looking for. I hear Shane’s scoping argument, but I think it will save great angst to avoid accidental collisions. If we know “a:1 b:0 c:1” goes with www.iab.com/dnt.html, vs. www.eff.org/dnt.html, there’s less chance someone will get confused while writing / maintaining code. Given large-scale privacy invasions and lawsuits are possible outcomes of getting it wrong, I’d like to support defensive programming. 

Bonus points if the URI *itself* contains version information, since these things may change over time, and orgs will certainly want to manage what it is the “a” in a:1 meant at the time consent was given/revoked. There are many ways to do so, hence only “bonus points."

Translated, I’m suggesting a MUST for a URI that accompanies the extension, plus an example that shows www.example.com/dnt1017.html with a date or version number embedded and discussion of that as a best practice, rather than even a SHOULD. 

 Aleecia