W3C home > Mailing lists > Public > public-tracking@w3.org > May 2012

Re: Call for feedback on hybrid URI/header proposal

From: Rigo Wenning <rigo@w3.org>
Date: Tue, 15 May 2012 09:54:18 +0200
To: public-tracking@w3.org
Cc: Matthias Schunter <mts-std@schunter.org>
Message-ID: <2324980.5CHWGlzVXH@hegel.sophia.w3.org>
Hi Matthias, 

currently, the URI/header proposal is just a URI proposal. It says the 
server MUST provide a tracking status resource  at teh well-known 
identifier. 

I suggest to replace that by: 

"An origin server MUST provide a tracking status resource either by a header 
or at the well-known location. This status is considered to be a matching 
response to the DNT header field sent with the HTTP Request."

Complex sites may want to provide header responses only. Mandating a well-
known location is harmful to that. There MUST be a possibility to have 
header-only solutions. 

This also has repercussions on 5.3.1.

We MAY want to include the expression semantics of the WKL into the header, 
but I don't care too much about that, because I believe the WKL contains way 
too many semantics anyway. So I don't mind not to extend 5.3.1. But we have 
to add a sentence to say:

"If the origin server does not provide a response to the DNT header field at 
the well-known location, it MUST provide a response header as specified 
below"

Rationale: We need a response header for the EU consent mechanism and for 
the legal hooks for enforcement. This needs a response that is a valid 
commitment. But the current proposal for tracking-status at the well-known 
location just looks like a bare carcass of something resembling very much to  
P3P. I don't mind as long as the initial technology of header responses 
remains. But turning the WKL into the one and only mechanism for responses 
is a no-no for me. 

Best, 

Rigo


On Monday 14 May 2012 23:23:02 Matthias Schunter wrote:
> Hi Folks,
> 
> 
> I'd like to re-emphasize my call for feedback on the URI/header proposal
> (TPE spec; chapter 5).
> 
> The feedback needed (in decreasing order of preference):
> 1. Concrete text proposals enhancing/improving the current draft
> 2. Concrete requirements & use cases that are not met by the current spec
> 3. Other concrete comments on the drafts
> 
> If you do not comment on the current proposal, I will interpret silence
> as agreement ;-)
> 
> If you need more information / explanation, feel free to ping me.
> 
> 
> Regards,
> matthias
Received on Tuesday, 15 May 2012 07:54:48 UTC

This archive was generated by hypermail 2.3.1 : Friday, 21 June 2013 10:11:28 UTC