RE: Issue-207

Rob,

Respectfully I believe adding "unambiguous" adds ambiguity to the standard.  Whereas "clear" has stronger roots in objective based measures, "unambiguous" is vastly more open to individual interpretation as to what is and is not ambiguous.  I believe the main goal is achieved with the term "clear" and there is no need to pile on with arguable more subjective elements such as "unambiguous".

- Shane

-----Original Message-----
From: Rob van Eijk [mailto:rob@blaeu.com] 
Sent: Wednesday, May 14, 2014 12:27 AM
To: Nicholas Doty
Cc: Mike O'Neill; public-tracking@w3.org; Justin Brookman; Jack Hobaugh
Subject: Re: Issue-207

Thanks Nick,

>> A party to a given user action that disregards a DNT signal MUST 
>> indicate so to the user agent, using the response mechanism defined 
>> in the [TRACKING-DNT] recommendation. The party MUST provide 
>> information in its privacy policy listing the specific reasons for 
>> not honoring the user's expressed preference. The party's 
>> representation MUST be clear and easily discoverable.


It may be a language issue, but for me the word unambigous does add value. I propose to ammend your change to:

(..) representation MUST be clear, unambiguous and easily discoverable.

Rob


Nicholas Doty schreef op 2014-05-14 08:49:
> I meant to follow up after last week's call with some edits that I 
> think could clarify; apologies for the delay.
> 
> On May 6, 2014, at 11:14 AM, Mike O'Neill 
> <michael.oneill@baycloud.com> wrote:
> 
>> A party MUST provide information in its privacy policy listing the 
>> specific reasons for not honouring the user expression. The party's 
>> representation MUST be easy discoverable, clear and unambiguous.
> 
> I think this is intended to be "easily discoverable" (a phrase already 
> being used) rather than "easy discoverable". Does "unambiguous" add 
> anything that "clear" doesn't already cover?
> 
> To match with the rest of the document I would also make what I think 
> would be purely editorial changes (matching with a version of the 
> existing text so that it makes sense.
> 
> [Nick's proposed update:]
> 
>> A party to a given user action that disregards a DNT signal MUST 
>> indicate so to the user agent, using the response mechanism defined 
>> in the [TRACKING-DNT] recommendation. The party MUST provide 
>> information in its privacy policy listing the specific reasons for 
>> not honoring the user's expressed preference. The party's 
>> representation MUST be clear and easily discoverable.
> 
> And for the non-normative paragraph:
> 
>> Non normative: In the interests of transparency, and especially if 
>> there are more than a single such reason listed, it is recommended 
>> that servers implement the [TRACKING-DNT] “status-id” mechanism so 
>> that the particular reason for not honouring the user expression is 
>> provided. The _TK_ response header can contain a _status-id_ field 
>> identifying the relevant Tracking Status Resource whose _qualifiers_ 
>> property contains a short token representing the particular reason. 
>> The User Agent can parse this and communicate the reason to the user.
> 
> As discussed, "recommended" is actually a normative term we typically 
> use. As Roy has pointed out, the qualifiers might be used even if the 
> tracking status is site-wide. So one way to rephrase this would be:
> 
> [Nick's proposed update:]
> 
>> In the interest of transparency, especially where multiple reasons 
>> are listed, a server might use the [TRACKING-DNT] *qualifiers* or
>> *config* properties to indicate a particular reason for disregarding 
>> or steps to address the issue. A user agent can parse this response 
>> to communicate the reason to the user or direct the user to the 
>> relevant section of a privacy policy. This document does not define 
>> specific qualifiers for different reasons servers might have for 
>> disregarding signals.
> 
> Hope this helps,
> Nick

Received on Wednesday, 14 May 2014 14:24:07 UTC