Initial feedback on the well-known URI Proposal

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