Re: action-231, issue-153 requirements on other software that sets DNT headers

On Aug 21, 2012, at 11:40 , Tamir Israel <tisrael@cippic.ca> wrote:

> I still think a lot of problems can be solved and confusion avoided if the TPE incorporates a mechanism for confirming user preferences in cases of conflict.

What conflict?  On the wire, only one DNT header is allowed.  UAs etc. have to make sure of that (and resolve any conflicts) before anything goes on the wire.

> 
> Best,
> Tamir
> 
> On 8/21/2012 2:26 PM, Dobbs, Brooks wrote:
>> David,
>> 
>> I would suggest that this is already implicit and much more basic.  We all
>> agree that UAs MUST only send a signal that reflects a user's preference
>> (unless someone wants to flip this and say that it is okay to send a
>> signal which does not reflect a user's preference).  What this means then
>> is that if you want the advantages coming from the ability to send any
>> signal, you have the responsibility to ensure that the signal you send
>> accurately reflects a user's preference.  I am assuming we are on safe
>> ground to say that if a UA sends a signal which does not reflect user
>> preference it is out of compliance?
>> 
>> 
>> I have no doubt that doing this might, in reality, mean that that the UA
>> must be the only one to seek preference, but I am not sure there is an
>> easy way around this.  If my duty (form which I gain benefit) is to
>> represent someone else's preference accurately, I need to: 1) ensure they
>> are adequately informed about the issue on which they are rendering a
>> preference and 2) only where 1) is satisfied represent that determined
>> preference.  If you don't have this, you have a hole you can drive a truck
>> through.  A user could elect 1 or 0 as their true preference; 3rd party
>> software can reverse the decision and UA sends new "false" signal.  If it
>> isn't the UA's responsibility to maintain preference, who would be "out of
>> compliance"?  The answer "no one" undermines the spec.
>> 
>> -Brooks

David Singer
Multimedia and Software Standards, Apple Inc.

Received on Tuesday, 21 August 2012 19:06:14 UTC