Re: ACTION-326 and ACTION-327 BLOCKED on ISSUE-5

Roy.  I just don't understand what this means. Your point about an open web relying on servers having some flexibility to reject misconfigured headers was well taken.  But isn't the point of any spec to displace semantics? 

Whether a **server** and a **UA** are accurately communicating with each other only depends on whether each knows what signals to send and what actions to take in response. The spec should describe that.

Whether a UA accurately describes to **users** what a **feature** does is a problem we know how to address using messaging and where that fails, legally under misrepresentation.   This group should pass on that.

Please, someone.  Do a find/replace "tracking" with "froobalicious" in the documents.  Make sure all the actors affected by the doc will know what to do in the absence of any reliance on shared semantics about privacy or the meaning of the word tracking.  Even add a sentence to the intro that explicitly states "Tracking means many things to many people and this spec does not attempt to define it.  Instead, it describes a technique for users to express a limited preference for how certain data about them is used, a mechanism for recipients to respect that preference, and exceptions that permit certain business functions to continue even if the preference is activated." 

Lauren Gelman
@laurengelman
BlurryEdge Strategies
415-627-8512

On Nov 15, 2012, at 4:20 PM, Roy T. Fielding wrote:

> On Nov 15, 2012, at 3:58 PM, David Singer wrote:
>> On Nov 14, 2012, at 14:18 , Roy T. Fielding <fielding@gbiv.com> wrote:
>>> On Nov 14, 2012, at 9:47 AM, Thomas Roessler wrote:
>>>> On 2012-11-14, at 18:30 +0100, Shane Wiley <wileys@yahoo-inc.com> wrote:
>>>> 
>>>>> Thomas,
>>>>> 
>>>>> To this statement: “tracking" (a term which doesn't show up in the current normative language…“
>>>>>  
>>>>> Please note the title of both documents.  J  To me that is clearly “normative” in context.  Fair?
>>>> 
>>>> Actually, no -- the title of a specification isn't normative.  Sometimes, the title of a document is even just some acronym, like "HTML."
>>> 
>>> The charter uses the term tracking.  The browsers use the terms
>>> tracking or "to track" or "do not track".  TPE cannot avoid using
>>> the term tracking as that is the user expression that is being
>>> expressed by the protocol.  The Compliance specification is a
>>> charter deliverable to define tracking and related terms.
>>> 
>>> In short, I am extremely annoyed that I have to explain this again
>>> and again and again...  THIS working group will not successfully
>>> pretend to define the DNT header field without a definition of
>>> tracking.  
>> 
>> You know, I used to believe this.  It frustrated me as well.  I have even offered a definition (which met with little opposition as I recall).
>> 
>> But I think the opposite view actually is tenable.
>> 
>> For example, if I tell you "on my property, you are required to be froobalicious" you might reasonably ask "what do you mean by froobalicious?".  I might be able to give you a simple definitional answer ('froobalicios means that your socks are always color-coordinated with your tie') but it may be that I hand you a multiple page document that says "froobalicious people must do X, must not do Y, should do Z when Q happens, may do R if an only if T is true, ..." and so on.  That document is as much of a 'definition' of froobalicious as anything else.  It may not be pretty, it may not be terse, it may not be quotable, it may not have a sentence anywhere that says "froobalicious is defined as …" -- but if you abide by my rules, you can say (with pride, I hope) "on Dave's property, I am always froobalicious!" and be confident that you are.
>> 
>> I might even agree.
> 
> DNT does not just describe attributes of the sender.  It describes
> a user preference for adherence by the recipient.  Hence, both
> establishing the user's preference and adherence to those
> preferences are subject to shared semantics, not just a list of
> requirements in a spec.  We all know that most users will not read
> the spec.
> 
> HTTP header fields have a defined set of semantics.  When a header
> field describes attributes of the sender, the semantics are checked
> against the context of the sender to know whether the protocol is
> correctly implemented.  When a valid header field is received by a
> recipient, the expectations defined by those semantics are met by
> adhering to a set of protocol requirements on the recipient.
> Hence, the semantics are crucial to both determining the validity
> of the signal and the validity of our compliance document in
> defining the associated requirements.
> 
> ....Roy
>