Re: Options for the future of the TPWG - Discussion needed

I thought Roy resolved this at the last meeting.  We've already submitted
the current (non-purpose supported) version for CR.  Case closed.

Any work the group is doing now is on version 1.1 and net new CR.

I'm supportive of moving forward as quickly as possible to get to a new CR
while pushing v1.0 CR to REC in parallel.  There won't be time for browsers
to build anything in the next ~5 weeks before the end of the year anyway
(removing 2.5 weeks for holidays).

As we now have an emerging view on ePR would it be possible to spin up the
extension process now ahead of the end of the year in parallel as well?  If
yes, then we have the following tracks:

- Move v1.0 RC to REC
- Develop Purposes for v1.1 RC (then move to REC in early 2018)
- Submit extension request for TPWG through mid-2018 (if not the full year
as ePR becomes more real for the tech industry)

Fair?  Thoughts?

- Shane

On Sat, Nov 4, 2017 at 7:33 AM, Mike O'Neill <michael.oneill@baycloud.com>
wrote:

> I agree with all that, i.e. we go with what we have for Rec 1.0, and in
> parallel carry on with Rec 1.1 (with Rec 1.0 getting precedence if there is
> a conflict).
>
> There seems to be some interest in pursuing the DNT extension which could
> help getting other companies to get involved, or re-engage, so the 2 paths
> are complementary. I see nothing that needs to be removed from Rec 1.0, we
> are just talking about adding detail to the extensible feature already
> defined e.g. the TSR,  the DNT header extension and a new parameter for the
> API.
>
> Mike
>
>
> -----Original Message-----
> From: Matthias Schunter (Intel Corporation) [mailto:mts-std@schunter.org]
> Sent: 04 November 2017 13:23
> To: public-tracking@w3.org (public-tracking@w3.org) <
> public-tracking@w3.org>
> Subject: Options for the future of the TPWG - Discussion needed
>
> Dear TPWG,
>
>
> just as a context, here are my current believes on the politics around
> our WG.
>
> Some points to consider:
> - We got an extension of our charter until end of 2017
> - W3C may not be willing to extend again unless there is strong evidence
> of renewed interest (e.g. new members joining)
> - We should barely be able to push the current spec into the REC final
> state
> - If we address new issues, it will cause a delay that will put the REC
> at risk.
> - If we do not address the new issues, the standard may not be adopted
> anyway.
> - While we may try an educated guess on best practices for the EU (e.g.
> adding purposes),
>   the true best practices in the EU will evolve in 2018 (or even later).
>   [i.e. whatever we produce now may or may not be future-proof]
>
> The ideal scenario I see is:
> - We publish the current version as REC 1.0 to put a stake in the ground
> and meet the deadlines in our charter
> - We get new members on board to convince W3C that there is renewed
> interest
> - We continue to improve our standard and shape the EU best practices
> - We work towards a REC 1.1 in 2018 where we are confident
>   that the emerging EU best practices are optimally supported.
>
> This requires us to find a sufficient number of members and implementers
> who re-engage
> and say "yes, we believe that the TPE is a great technical means to help
> compliance in the EU".
>
> Other options (less favourable options) are:
> - We publish the current draft as REC and stop/pause
> - We add the purposes ASAP, publish another CR, and try to survive
>   long enough to get the corresponding REC out.
>
> In any case, pushing the current release out as-is seems to be the
> preferred choice. Based on this version, we can then implement/design
> extensions and evolve best practices. Once they get stable, we have
> confidence how exactly an update should look like.
>
> What do you think? Any input/feedback is welcome!
>
>
> Regards,
> matthias
>
>
>
>
>
>
>
>


-- 
- Shane

Shane Wiley
VP, Privacy
Oath: A Verizon Company