Re: Issue-207

Hi Roy,

Thanks for your response.

Please further explain how the TSR would be used as a dynamic, per user response.  

My understanding of the TSR as specified in Section 6.4 of the TPE is that the TSR is a static JSON representation on the server that contains information about either the potential tracking behavior of resources on that server or can be used to represent multiple, request specific tracking polices (also static JSON format) on the server that can be identified by a status-id value returned in the Tk header.

Also, my understanding is that the JSON representation will be updatable but normally static.  If that is true then isn’t it also true that the only possibility for a dynamic response would be through the choice (by the server) of appending a particular status-id to the Tk header based on information in the request?

Best regards,

Jack

Jack L. Hobaugh Jr
Network Advertising Initiative | Counsel
1620 Eye St. NW, Suite 210 Washington, DC 20006
P: 202-347-5341 | jack@networkadvertising.org

The information contained in this e-mail is confidential and intended for the named recipient(s) only. However, it is not intended as legal advice nor should you consider it as such. You should contact a lawyer for any legal advice. If you are not an intended recipient of this email you must not copy, distribute or take any further action in reliance on it and you should delete it and notify the sender immediately.





On May 8, 2014, at 9:47 PM, Roy T. Fielding <fielding@gbiv.com> wrote:

> The TSR is a potentially dynamic, per user response. The only reason that status-id would be used is if the response is different per resource on the same site, not per user or per user agent. Hence, status-id has nothing to do with signaling a reason for "D", and is not necessary for the functionality you seek.
> 
> ....Roy
> 
> 
>> On May 8, 2014, at 1:12 PM, "Mike O'Neill" <michael.oneill@baycloud.com> wrote:
>> 
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>> 
>> The status-id exists so a server can signal in-transaction a particular TSR out of a tree of them. That and the qualifiers property is the only way to differentiate between reasons for a particular D response. If the only reason for a D is “we do not believe your browser sends valid DNT signals” then we do not need the qualifier. If there is more than one,  or an unlimited set of them, then for the sake of transparency and clarity for the user there has to be a way to identify the specific one, and the status-id will do it (albeit with another transaction to get the TSR).
>> 
>> If the D response lets third-parties claim compliance with DNT without offering a reason for ignoring the signal, then D should be abolished.
>> 
>> 
>> From: Roy T. Fielding [mailto:fielding@gbiv.com]
>> Sent: 08 May 2014 19:39
>> To: Mike O'Neill
>> Cc: public-tracking@w3.org; 'Justin Brookman'; rob@blaeu.com; 'Jack Hobaugh'
>> Subject: Re: Issue-207
>> 
>> On May 6, 2014, at 11:14 AM, Mike O'Neill wrote:
>> 
>> Hi Justin,
>> 
>> Here is our agreed amended text, with reasons now in the plural as suggested, and also saying they should be listed in the privacy policy. The non-normative text is expanded to describe the TPE mechanism for signalling the particular reason (if there are several listed).
>> 
>> 
>> 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.
>> 
>> That last sentence is non-testable and cannot be a MUST.
>> An "ought to be easily discoverable, ..." would be fine.
>> 
>> 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.
>> 
>> "it is recommended ..." is a normative statement, but this is not how
>> the status-id is specified by the protocol.  Yes, a compliance document
>> can specify normative requirements on when qualifiers must be present,
>> but status-id is only used for resource-specific status.
>> 
>> We do not need to mention status-id here; we can just require certain
>> qualifiers to be present in the TSR (whether or not a resource-specific
>> TSR is necessary is already determined by the protocol requirements and
>> independent of any need for qualifiers).
>> 
>> ....Roy
>> 
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.13 (MingW32)
>> Comment: Using gpg4o v3.2.42.4591 - http://www.gpg4o.de/
>> Charset: utf-8
>> 
>> iQEcBAEBAgAGBQJTa+UbAAoJEHMxUy4uXm2JzdcH/jzp+8kWrUWarUYVTPXqj9Is
>> sHtJ7WwM4ezDMQETuKDsr0svpn40I+liGm6YlhXAvrwSLxp0oo6ijHvzy6S+AHi9
>> e6fRsp9z5KF8WAF3AX1sQPmcLItbmJ9ig+QRgDRx8AbfphL9Z2KCDEw/rhls/sHu
>> DLdfz+Zl2fPWQEm8D+Q/66yW84jmXJWC7e5day47KoXnyqRzSOCABXzoxpa+GLpm
>> 7nE0ZYhlekiTL+HMROJSzfNdqCJusGtxwCHYOGepFeB5gbor1Oo/Ng2jee8YDNSi
>> aouoHrvGB2Jp/zNEVhIaT5oUKdj7Xuo1TMJMxi3lP3kzg9qyg6P/Txwlsrb2kt4=
>> =kzCN
>> -----END PGP SIGNATURE-----
>> <PGPexch.htm>
>> <PGPexch.htm.sig>