DntResponseHeaderOrURI

Scale used:

Comparison:

V01: At this point, the table summarizes mschunter's personal opinion (2012-02-24)

Criteria	Response Header	Well-known URI	Notes
Transmits tracking status for retrieved object at URL	++	+(may need dynamic generation)	MSchunter believes that sending individualised (per user) status is easier with headers since they can be locally generated and attached. This seems easier than dynamically generating a centralised resource at a well-known URI.
Enables enforcement by regulators	++	+	Headers are slightly less ambiguous due to their narrow scope
Granularity	++ (per request; very fine-grained)	+ (per sub-site; coarser-grained)	To support DNT for each URL, the site needs to be replicated under the well-known URL.
Simplicity of user agent	++ (info along with page)	0 (separate lookup)
Traffic generated	++ (info along with page)	0 (separate lookup)	It seems as -worst case-, the URI proposal may generate 2x the number of requests?
Robustness wrt caching	-	++	Some cache implementations do not properly handle headers while all caches can cache a well-known URL.
Tracking protection on info resource	+	-	URI can be declared 'no tracking area' and retrieved before actual request. For headers, tracking may have happened while returning a header?
Maintainability of site	+	-	URI requires all site stakeholders to agree and populate the well-known URI (difficult); header allows resource-owner to just attach a header
Ability to transmit complex data	-	+	Status object can transmit larger data sets (partner-sites, options, ...) while this would overload header.
[More criteria needed...]

Comments / Questions for Response Headers:

Comments / Questions for Well-known URIs:

Is there a way to prevent that each URL needs to always be checked at the well-known location? E.g., retrieving foo.com/bar/one requires checking foo.com/.well-known/dnt/bar/one. If I now want to retrieve foo.com or foo.com/bar/one/sub, I need to re-check. Don't I? Wouldnt this double the web traffic (sort-of?)