- From: Matthias Schunter (Intel Corporation) <mts-std@schunter.org>
- Date: Wed, 25 Jan 2017 09:29:51 +0100
- To: David Singer <singer@mac.com>, Mike O'Neill <michael.oneill@baycloud.com>
- Cc: public-tracking@w3.org
Hi Folks, I suggest we try to do the best technical solution to solve our challenge to simplify EU compliance. 1. We analyze the problem to understand and dervice our requirements. 2. We optimize the spec to address the requirements 3. We provide sufficient implementations (some sites, the EFF badger, Mike's plugin, potentially others) 4. We demonstrate interop and push to rec If this plan is viable, then only features are dropped if we realize that they do not make sense for our implementation: The implementors are part of our team and will update their implementations whenever reasonable and helpful. Finally, we are done and celebrate! If our prediction that market pull in EU increases due to regulations then the standard will be widely adopted. If we follow this process, then the questions are (a) what are the new requirements that emerge? (b) what is a good enough plan to demonstrate sufficient implementations and interop to get to rec? David: Would you agree? Any feedback/comments? Regards, mathtias On 25.01.2017 09:15, David Singer wrote: > Hi Mike > > I guess I am finding it hard to get enthusiastic about fixing a feature that’s very likely to be marked as “at risk of removal” in the CR and removed through lack of interoperable support in the PR. > > >> On Jan 25, 2017, at 9:03 , Mike O'Neill <michael.oneill@baycloud.com> wrote: >> >> I don't think changing the API to return a promise changes much, it only >> affects the IE implementation which already does not comply with the rec >> anyway (does not support navigator.doNotTrack for a start). Bouncer will be >> fixed to comply with whatever we agree in a jiffy. >> >> But we may want other changes anyway so why don't we schedule a drop dead >> date for all the TPE changes we agree on, say june/july, giving us a couple >> months or so for the transition request. >> >> -----Original Message----- >> From: Matthias Schunter (Intel Corporation) [mailto:mts-std@schunter.org] >> Sent: Tuesday, January 24, 2017 8:31 PM >> To: public-tracking@w3.org >> Subject: Re: Issue 12: Javascript API to return promises instead of nothing. >> >> Hi TPWW, >> >> >> BERT: this is very useful information. >> >> Here are two process suggestions. >> >> ------------- >> ANOTHER TRANSITION? >> >> We should try to balance efficiency/speed and a useful outcome. >> For me, being required to issue another transition request would not be a >> show-stopper. >> I guess it also would not cause huge delay (say more than 1 month), won't >> it? >> >> What we could do is triage changes according to two criteria: >> >> (a) Are they essential to reach our goal or nice to have? >> (b) Are they substantial or editorial? >> >> If we do not have essential changes that are substantial, we will not need >> to take the burden of another transition. >> We we do, there is no way around it. >> >> ----- >> IMPLEMENTATION/INTEROP >> >> We should soon document our implementation / interop test plans and discuss >> them in the group and then with the director. >> Once we all have a joint understanding of the plans and informal OK that the >> plans are likely to meet the W3C requirements, then we are good to go., >> >> >> What do you think? Any other feedback? >> >> >> Regards, >> >> matthias >> >> >> >> On 24.01.2017 14:45, Bert Bos wrote: >>> On Tuesday, January 24, 2017 8:45:56 AM CET Schunter, Matthias wrote: >>>> Hi Roy, >>>> >>>> PS: As far as I know, W3C now allows to change the spec while >>>> iterating in the candidate recommendation state. I.e. no need to go >>>> back to WD even if we introduce changes to the API. >>> Yes, but the exact process depends on the kind of changes: >>> >>> Republishing a CR with only editorial changes simply requires a WG >>> decision and can be done as often as the WG wishes. It needs the >>> Webmaster's help, so only on Tuesdays and Thursdays, but otherwise no >>> need to talk to anybody. >>> >>> The same holds for republishing a CR after removing features that were >>> already marked explicitly as "at risk". >>> >>> The WG can also decide at any time to republish the CR as a WD. >>> >>> But republishing a CR with "substantive changes" requires writing a >>> new Transition Request (with all the usual things that go into such a >>> request) and waiting for Director's approval. If the changes are >>> small, such approval is likely to be quick, though. >>> >>> "Substantive changes" are changes that affect conformance or add new >>> features: i.e., any changes that can make an implementation that used >>> to >>> be conforming now non-conforming, or vice-versa. >>> >>> >>> I haven't looked at the change itself, but based on Roy's e-mail >>> below, it seems to be a change that affects conformance. And so it >>> requires writing a new Transition Request if we want the updated spec to >> be a CR. >>> I can help writing such a Transition Request, but I can't do it on my >>> own. I don't know enough about the history of the spec and its >>> implementations yet. >>> >>>> -----Original Message----- >>>> From: Roy T. Fielding [mailto:fielding@gbiv.com] >>>> Sent: Tuesday, January 24, 2017 9:15 AM >>>> To: Matthias Schunter (Intel Corporation) <mts-std@schunter.org> >>>> Cc: public-tracking@w3.org (public-tracking@w3.org) >>>> <public-tracking@w3.org> Subject: Re: Issue 12: Javascript API to >>>> return promises instead of nothing. >>>> >>>> Umm, the downside is that it is a normative change to the API, which >>>> means we go back to WD status and have zero implementations. >>>> >>>> I want commitments from browsers to implement this change before we >>>> make it. Right now we should assume the entire API will be removed. >>>> >>>> ....Roy >>>> >>>>> On Jan 24, 2017, at 3:20 AM, Matthias Schunter (Intel Corporation) >>>>> <mts-std@schunter.org> wrote: >>>>> >>>>> Hi Folks, >>>>> >>>>> >>>>> Sites can use our javascript API to register site-wide and web-wide >>>>> exceptions. Currently the corresponding calls do not return any >>>>> results. >>>>> >>>>> Mike proposed to return promises. These would allow the engine to >>>>> call-back to a site once it has processed a javascript request. >>>>> This renders our API more asynchronous. >>>>> >>>>> IMHO there does not be a downside to this proposal. Mike posted the >>>>> changed javascript API here: https://github.com/w3c/dnt/issues/12 >>>>> >>>>> >>>>> Unless somebody objects before our next call, I suggest to introduce >>>>> this change to our API. >>>>> >>>>> >>>>> Regards, >>>>> >>>>> matthias >>>> Intel Deutschland GmbH >>>> Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany >>>> Tel: +49 89 99 8853-0, www.intel.de >>>> Managing Directors: Christin Eisenschmid, Christian Lamprechter >>>> Chairperson of the Supervisory Board: Nicole Lau Registered Office: >>>> Munich Commercial Register: Amtsgericht Muenchen HRB 186928 >>> >>> Bert >> >> >> > Dave Singer > > singer@mac.com >
Received on Wednesday, 25 January 2017 08:30:27 UTC