- From: David Singer <singer@apple.com>
- Date: Mon, 11 Sep 2017 13:14:21 -0700
- To: "Roy T. Fielding" <fielding@gbiv.com>
- Cc: Matthias Schunter <mts-std@schunter.org>, "public-tracking@w3.org (public-tracking@w3.org)" <public-tracking@w3.org>
> On Sep 11, 2017, at 12:56 , Roy T. Fielding <fielding@gbiv.com> wrote: > >> On Sep 11, 2017, at 9:36 AM, Matthias Schunter (Intel Corporation) <mts-std@schunter.org> wrote: >> >> Dear TPWG, >> >> thanks a lot for all then hard work you put into the CR proposal of the >> TPE. >> >> As you know, a CR needs to satisfy certain criteria: >> - List of features at risk (if any) >> - Wide review >> - Implementation reports (test suite as a plus) >> >> Despite the fact that most parts are unchanged, the feedback received is >> that we should preferably repeat these steps and re-compile this package >> for each subsequent CR release. >> >> As a consequence, my suggested next steps are: >> 1 - We mark two features as at risk (changes to the CR draft): >> - Extensibility of the DNT header (unchanged from first CR) >> - Exception API (also to emphasize that we need more implementations) > > Why? We had that discussion on one of the calls and it was felt > that we did not have any pieces that would be removed prior to REC. > That is, either the document succeeds as a whole or it should stop > progression to REC. The "at risk" category is only for stuff > that can be removed at REC without going back to the WG. > > I could re-introduce the bits about DNT being extensible at risk, > but that seems to be a waste of time. > I think it’s way easier to leave the at-risk marking in than to justify its removal, and it’s hard not to see a newly-redesigned API as at-risk. There may be one implementation, no test suite, and and so on. I am prepared to argue at PR that the feature should nonetheless be retained, as I think removing it would take the chances of DNT adoption from small, down to minuscule. >> 2 - Bert asks again for a wide review (PING, security, Art29, >> accessibility / internationalization, ...) within 2 weeks. >> Points to make: >> - Exception API has been redesigned >> - Otherwise, the spec largely unchanged >> - It does not have any user interface (machine2machine) >> >> 3 - We call for implementations and implementation reports (also within >> 2 weeks): >> - Mike suggested he should be able to update his implementation >> - For the signals, we can re-use existing reports. >> - Other implementations of the API? >> >> 4- If we receive no blocking feedback in these 2 weeks, we can then >> submit the full CR package around end of September. >> >> If you agree, then no action is required ;-) > > Well, someone has to send mail for (2) and update the wiki page for (3). > > ....Roy > > David Singer Manager, Software Standards, Apple Inc.
Received on Monday, 11 September 2017 20:14:47 UTC