- From: Matthias Schunter (Intel Corporation) <mts-std@schunter.org>
- Date: Thu, 2 Feb 2017 09:24:46 +0100
- To: "public-tracking@w3.org (public-tracking@w3.org)" <public-tracking@w3.org>
- Message-ID: <cfe1f07d-3dee-7a2d-6737-6005d28e5b25@schunter.org>
Hi Folks,
thanks a lot for the lively and productive discussion on the mailing list.
Below info for our call on monday.
BTW: Should we return to weekly calls?
Matthias
FINDINGS
- We seem to have found consensus that the Tracking Status resource
should remain at the well-known resource.
We should not allow content-owners to ship some TSR-like-information via
http-equiv.
The reason was that a TSR at a well-known resource allows to ensure that
the server owner is indeed part of the
DNT support. Please object if you disagree.
AGENDA
I propose to discuss the following topics next week:
-----------
0. Should we return to weekly calls?
--------------
1. Should we allow transmission of TK headers within http-equiv.
PRO reasons I heard:
- Convenient;
- May simplify dynamic generation of Tk info along with dynamically
generated content;
- If content includes tracking mechanisms, then the content can also
include Tk signal
CONTRA
- May lead to ambiguities (header vs. http-equiv info) [would require
conflict resolution]
- Tracking (unlike CSP) are not a content property. Thus attaching it
breaks the logics of server design
- Headers are easy to set for content-owners (once the server owner
enabled it).
-------
2. Implementation/Validation Strategy
To reach REQ state, we have to demonstrate implmentation and
interoperability.
Question: What is a viable strategy for us.
Proposals I have seen so far:
- Use the existing browser implementations; retrofit the spec
PRO: No implementation effort
CONTRA: Minimal spec that we can no longer change (since browser
changes are unlikely)
- Use one or more plugins (e.g. Badger and Mike's plugin) and a number
of sites.
PRO: Allows us to evolve our spec
CONTRA: Implementation effort; We have to double-check that this
meets the requirements of W3C.
--------
3. Should the Javascript API return promises ?
PRO
- Allows call-back
- More developer friendly; User-agent is notified once call is completed
CONTRA
- Changes the API
- Unclear what the meaning of the callback is.
-----
4. Do we want to change our exception model
Mike to explain what he suggests to change.
------
5. Other issues from our tracker:
https://github.com/w3c/dnt/issues
UPDATED Webex Info
--
This is a placeholder for the biweekly TPWG Telco.
We agreed to calendar a placeholder and cancel if needed
CHAT: irc.w3.org channel #dnt
PHONE:
12:00 pm | Eastern Daylight Time (New York, GMT-04:00) | 1 hr
Meeting number: 642 521 085
Meeting password: dnt
Meeting link:
https://mit.webex.com/mit/j.php?MTID=m1e591a8d322ec7d4989b2dd6fbf11c35
Audio connection: +1-617-324-0000
Received on Thursday, 2 February 2017 08:25:26 UTC