Re: Issue-207

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>

Received on Friday, 9 May 2014 01:47:51 UTC