Re: Revised Response Header

You don't get to invent exceptions, but you may have complex practices 
that you want to explain, or you may want to provide other information 
relevant to this specific transaction, such as a way to revoke the 
out-of-band opt-in permission already granted by the user.

Perhaps we should start talking about what the explanations documents 
should look like? We may want to require/suggest that there's some sort 
of machine-readable exception enumeration in the explanation document. 
This is probably a good place for a "should", but I'm open to 
suggestions.

On Wed 25 Jan 2012 06:49:03 PM CET, David Singer wrote:
> Oh, and a separate point.
>
> It's by no means clear to me why the *site* should be giving a reason code.  We don't allow anyone to invent exceptions on the outside, do we?  So the exceptions  can all have reason codes in *our* specification, and indeed we can promise that the single-letter anchors will always index into the spec. to explain a reason-code.
>
> So, http://www.w3.org/<where it is>/tpe.html#3
>
> will explain what reason 3 is, to anyone who cares.
>
>
> On Jan 25, 2012, at 17:11 , Tom Lowenthal wrote:
>
>> ACTION-90 ACTION-87
>> ISSUE-48 ISSUE-76 ISSUE-90 ISSUE-105 ISSUE-106 ISSUE-107
>>
>> Behold, the bikeshed has been re-painted.
>>
>>   ---
>>
>> Non-normative Discussion
>> ------------------------
>>
>> This response header has the following features:
>>
>> - Servers state whether they think that they are a first or third party.
>> - Servers may state that they think that a user has explicitly opted
>> back in to data collection by that site (not catchable).
>> - There is a response for catchable, static, or otherwise
>> not-relevant-to-tracking objects.
>>
>> Everything fits within two characters: one for status and one for
>> explanations. With the exception of "you have opted in" almost any
>> logical server should only ever exist in one of these states, so dynamic
>> generation is not needed. The user also has a way to query a server to
>> discover that server's tracking policies, without that request causing
>> tracking.
>>
>>
>> Normative Text
>> --------------
>>
>> If a server receives a request with a DNT header, the response to that
>> request MUST include a DNT-response header. If a server receives a
>> request without a DNT header, the response to that request MAY include a
>> DNT-response header. If sent, a DNT-response header MUST be accurate.
>> The DNT-response header is as follows:
>>
>>> DNT-Response = "Tk:" [CFWS] DNT-Status [CFWS] [ reason-code ]
>>> DNT-Status = no-dnt / full-dnt-1 / full-dnt-3 / except-dnt-1 /
>> except-dnt-3 / opt-dnt-1 / opt-dnt-3 / dnt-cached
>>> no-dnt = 0
>>> not-tracking = 1
>>> static-untracked = u
>>> first-party = f
>>> third-party = 3
>>> service-provider = s
>>> first-party-opt = c
>>> third-part-opt = p
>>> reason-code: 1*alphanum
>>> alphanum = ALPHA / DIGIT
>>
>> If a reason code is specified, an *explanation* MUST exist at
>> /.well-known/dnt?r=reason-code . Whether or not a reason code is
>> specified, a *general policy* regarding Do Not Track SHOULD exist at
>> /.well-known/dnt . The structure and requirements for *explanations* and
>> *general-policies* is described in section $FIXME of this document.
>>
>> *no-dnt* indicates that this party does not comply with [Tracking
>> Definitions and Compliance](). Servers MUST NOT use this response.
>>
>> *not-tracking* indicates that:
>> - this party complies with [Tracking Definitions and Compliance](),
>> - does not engage in tracking, and
>> - that any information gathered by the party as a result of this request
>> will be treated as if this party is a third party.
>>
>> *static-untracked* indicates that:
>> - this a resource -- such as a cached resource -- on which tracking does
>> not occur, and
>> - that any information gathered by the party through requests to this
>> resource will be treated as if the server is a third party.
>>
>> *first-party* indicates that:
>> - this party complies with [Tracking Definitions and Compliance]() and
>> - believes it is acting as a first party in responding to this request.
>>
>> *third-party* indicates that:
>> - this party complies with [Tracking Definitions and Compliance]() and
>> - believes it is acting as a third party in responding to this request.
>>
>> *service-provider* indicates that:
>> - this party complies with [Tracking Definitions and Compliance]() and
>> - believes it is acting as an outsourced third party service provider
>> under section [3.6.1.2]() of [Tracking Definitions and Compliance]().
>>
>> *first-party-opt* indicates that:
>> - this party complies with [Tracking Definitions and Compliance](),
>> - believes it is acting as a first party in responding to this request,
>> - believes that the user has affirmatively consented to allow this site
>> additional permission to track them, and
>> - the appropriate *explanation* describes these additional permissions
>> and allows the user to revoke or modify them.
>> All responses with this state must be marked as uncacheable.
>>
>> *third-part-opt* indicates that:
>> - this party complies with [Tracking Definitions and Compliance](),
>> - believes it is acting as a first party in responding to this request,
>> - believes that the user has affirmatively consented to allow this site
>> additional permission to track them, and
>> - the appropriate *explanation* describes these additional permissions
>> and allows the user to revoke or modify them.
>> All responses with this state must be marked as uncacheable.
>>
>
> David Singer
> Multimedia and Software Standards, Apple Inc.
>