- From: Roy T. Fielding <fielding@gbiv.com>
- Date: Fri, 2 Nov 2012 02:24:20 -0700
- To: David Singer <singer@apple.com>
- Cc: "public-tracking@w3.org Group WG" <public-tracking@w3.org>
On Nov 2, 2012, at 1:01 AM, David Singer wrote: > I agree. No matter what you do, be clear and communicate what you are doing. > > Another important principle is that each end behaves 'better' than the other. If you truly believe that the other end is non-compliant, or has made a mistake, then the correct response is to notify them, so that the responsibility both for advising the rest of the system or the user (or the tool author) of the error now lies clearly at that end -- both the error (if it is one) and the notification now belong clearly at the UA end. > > We agreed in principle to have a tracking value "other reason for being tracked" which would require a URL to explain the reason (at least, I don't recall any push-back). (It's theoretically possible, for example, that the server is under a court order to keep detailed records, and must 'track' according to our definitions.) > > Whether the response is, itself, compliant, would have to be indeterminate (it depends on how good your reason is, whether it conflicts with the spec., how well explained, and so on). > > Should we take an action to add to the response values "tracking for other reason explained at <this url>"? I think this is a separate issue. Telling a UA that the signal will be disregarded as invalid does not imply that the server is tracking. It might very well disregard the signal and fall back to regional defaults, or it might do no tracking at all. ....Roy
Received on Friday, 2 November 2012 09:24:57 UTC