Fwd: Moving "C"onsent from Tracking Status to Permitted Use?

My comments are included below. Ronan has since indicated that I may be misunderstanding his use case to begin with, so please take this with that grain of salt, we may actually all be in violent agreement!
—Nick

Begin forwarded message:
> From: Nicholas Doty <npdoty@w3.org>
> Subject: Re: Moving "C"onsent from Tracking Status to Permitted Use?
> Date: April 15, 2013 2:56:19 PM PDT
> 
> I certainly understand that database synchronization can take some time. Is there some particular reason that implementers who are in the process of synchronization can't just not track during that time? If it took me 36 hours to push out changes to all my endpoints, then I don't retain data from DNT:1 users during those 36 hours until knowledge of the out-of-band consent has reached the endpoint and I can respond with "Tk: C"?
> 
> I agree with David that "check back in 36 hours" for potentially every HTTP request I ever make simply isn't an informative response. 
> 
> Services that don't wish to respond with information may not be interested in implementing the Tracking Preference Expression protocol. (They still might limit the data they retain in response to DNT:1 signals, but if you can't send a meaningful Tk response, I'm not sure what the advantage is in claiming compliance when you won't indicate to the user whether you're complying currently.)
> 
> —Nick
> 
> On Apr 15, 2013, at 12:27 PM, Matthias Schunter <mts@schunter.org> wrote:
> 
>> Hi David,
>> 
>> 
>> I agree that a immediate and definively correct response would be optimal.
>> 
>> The background on a non-zero delay is that enterprises often use database synchronisation for such web-facing sites (e.g., nightly sync of the web-facing mysql with the internal oracle DB). This has a consequence, that the mysql data is not always accurate.
>> 
>> 1.  If a user retrieves the "control" URI, he usually gets the right result
>> 2. If he recently changed things, he needs to wait for 24h to ensure that the correct result is displayed.
>> 
>> If we keep the text vague like "the control link allows a user to invesigate out of band consent." then these technical implementation details would not affect our standard.
>> 
>> Opinions?
>> 
>> Regards,
>> matthias
>> 
>> 
>> 
>> On 15/04/2013 08:42, David Singer wrote:
>>> On Apr 11, 2013, at 15:13 , Matthias Schunter (Intel Corporation) <mts-std@schunter.org> wrote:
>>> 
>>>> Hi Ronan,
>>>> 
>>>> 
>>>> thanks for the interesting discussion on out-of-band consent.
>>>> 
>>>> Could you try to convert our discussions into proposed text changes and proposed additions for the TPE spec?
>>>> 
>>>> Items we IMHO seem to converge on:
>>>> - Data can be retained for a while (say 24h) and cleansed based on the out of band consent collected
>>>> - Out of band consent is signaled with the "C" (data processed under out of band consent)
>>>> - If "C" is signaled to the user, then the user can retrieve whether out-of-band consent has been used within 36hours from the URL
>>> s/within 36hours/immediately/
>>> 
>>> I can't see how 'come back in a day and a half' is any meaningful disclosure, or control.
>>> 
>>> It's a hole the mis-behaved could (and would) drive a truck through.  How do I even identify the transaction 36 hours later?
>>> 
>>> David Singer
>>> Multimedia and Software Standards, Apple Inc.
>>> 
>>> 
>> 
>> 
> 
>