Re: status of Tracking Preference Expression (DNT) Editor's Draft

Hi Roy,

thanks a lot for this impressive amount of work!
You moved the spec to where it should be for CR.

Unless there are any final editorial changes, I suggest to stick to our
goal of moving to CR. The reason is that I believe that this move is
more likely to encourage implementation.

If we then find major problems (which is always possible), we may need
to iterate once more on CR. If we are lucky (which is also possible), we
can proceed to Req as planned ;-)

We can discuss some more during our call.


Regards,
matthias


On 02.07.2017 16:24, Roy T. Fielding wrote:
> I spent the week trying to ensure that all of the changes the WG has
> made or resolved since CR have been correctly added to the draft and
> that the overall spec is readable and consistent.  I also revisited
> some of the old last call input to see what we could improve now that
> we decided to change the API.  This resulted in a significant number
> of editorial changes (mostly terminology fixes) and a few normative
> changes (API names and adjustments to the text of a couple of the
> resolved issue that were committed while I was in Europe).
> 
> The current ED is at
> 
>   https://w3c.github.io/dnt/drafts/tracking-dnt.html#rep.controller
> 
> a complete side-by-side diff of the changes since CR is at
> 
>   https://w3c.github.io/dnt/diffs/diff_tpe_CR_to_ED_20170702.html
> 
> and the blow-by-blow history can be seen at
> 
>   https://github.com/w3c/dnt/commits/master/drafts/tracking-dnt.html
> 
> 
> The following are significant changes worth reviewing first:
> 
> 0) I updated the SOTD section and removed DNT-extension from the formal
>    "at risk" category (since the new W3C process doesn't seem to care
>    about removing things after CR).
> 
> 1) I did a global replace of "user-granted exception" with
>    "user-granted permission" (and assorted other variants)
>    and adjusted the descriptions accordingly.
> 
> 2) I replaced the target and top-level origin terminology of the API
>    descriptions with terms that are defined by HTML5 or new terms
>    defined using the terms in HTML5. This was necessary because we depend
>    on the domain model for some defaults and the matching algorithm.
> 
> 3) I added a Note to 5.1 to describe why no signal is the default
>    and why mandating a preconfigured DNT:1 is a bad idea.  Given the
>    number of misunderstandings from the prior last call comments,
>    I think it is worth the attempt. YMMV.
> 
> 4) I explicitly defined how the TSV and TSR properties are extended by
>    compliance regimes and required that the compliance array contain
>    identifiers for each such extension used. See 6.2.11, 6.5.3, and 6.5.10.
> 
> 5) I clarified the policy property in accordance with issue #35 but
>    removed the examples because they used real names and assumed the
>    policy link referenced only a tracking policy and not the site's
>    entire privacy policy. See 6.5.8.
> 
> 6) I reverted part of the "WG consensus" decision on issue #21 which
>    added a requirement to the JavaScript API section that redefined
>    what is a valid TSR and required the presence of controller and policy
>    properties be present, in spite of the fact that both are defined
>    as having a default when not present (which accomplishes exactly
>    the same thing without sending any extra bytes).
> 
> 7) After updating the terminology in section 7.* (User Granted Permissions),
>    I found so many severe problems with the description that I decided
>    to rearrange the order in which it is presented and rewrite some of the
>    introductory paragraphs. It is still terrible, but at least now we can
>    see some of the glaring omissions. All prior requirements and useful text
>    should still be present (but in different sections and using different
>    terms to describe the domains). You can compare them in the diff, but
>    it is probably more useful at this point to just give a careful read of
>    the entire section and suggest the additional text that it needs to
>    help people implement the thing.
> 
> 8) I added some notes in section 7 where I think the API still has some
>    serious shortcomings.  I would like to remove those notes before CR.
> 
> Unfortunately, my personal conclusion remains that the API and the API
> descriptions are not ready for a push to CR.  They need serious work,
> actual implementation experience, and review by the Web Platform folks.
> If we want to publish something right now, publish it as a WD instead
> so that we don't bother the team with premature process.
> 
> I have already overspent the time I had available.  I won't be able
> to work on it again until July 10th at the earliest, and will go on
> sabbatical on July 24th through September 5.  I will be happy to resign
> as editor of TPE if the WG can find anyone with experience specifying
> Web Platform promise APIs to carry it the rest of the way.
> 
> My suggestion is that folks in the WG who aren't on vacation this week
> should do a thorough read-through of the ED and raise new issues on github
> for anything you think should be changed, even if it is just a request to
> revert something I described above (after you have reviewed the ED).
> That will make it far easier for us to track things that need to be
> addressed or brought to a formal CfC.
> 
> 
> Cheers,
> 
> Roy T. Fielding                     <http://roy.gbiv.com/>
> Senior Principal Scientist, Adobe   <https://www.adobe.com/>
> 
>

Received on Monday, 3 July 2017 15:39:09 UTC