- From: Matthias Schunter <mts@zurich.ibm.com>
- Date: Wed, 29 Feb 2012 11:11:18 +0100
- To: "Roy T. Fielding" <fielding@gbiv.com>, "public-tracking@w3.org" <public-tracking@w3.org>
Hi Roy, I now had a closer look at your proposal to transmit tracking status via well-known URI. I believe that both proposals, headers and URIs have benefits. I need to continue trying to understand their pros and cons. Here is some initial feedback on the proposal: 1. I like the URI proposal and I believe it has its merit. We need to understand whether URI/header or both are the avenue to go forward 2. A main goal of DNT (my perspective) is simplicity and ease of use/understanding. I believe that the overall scheme should be minimalistic to keep it as simple as possible. We spent time in Brussels slimming the headers to the minimal info that is essential. I'd like to do a similar exercise for your proposal. This means that I would omit all fields that are not essential to make the proposal slim and similar to the headers. - Fields I would remove are same-site, edits, partners, received (we agreed that it is not needed; it no longer exists in the headers either) - I am not sure about the options as a separate field since the policy may link to it, too. - I also would focus on fields that are usually static (e.g., not having a 'received' field) 3. I would fold 'tracking' and 'response' into a single field that has the same values as the headers (no-tracking, first-party, service-provider, tracking) 4. A new comment: While I understand the idea of the path field (scoping of status objects), I do not understand its semantics enough. E.g., I would not know what status object to apply if there are two objects Well-known URI Path in Object /sub / / /sub Some more questions: 1. Can there be multiple status-objects at one well-known URI? 2. We should attempt at finding a way to minimize the number of requests to the well-known URI. Regards, matthias
Received on Wednesday, 29 February 2012 10:11:54 UTC