- 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