See also: IRC log
anyone scribing?
<fielding> scribe: aleecia
(thanks!)
schunter: call for
objections
... holiday in some parts of EU but going through text
proposals. Mike proposed
<schunter> https://github.com/w3c/dnt/milestone/2
schunter: in this we have two issues basically done, one is 22 is under call for objections
mikeoneill: edited the draft, in github. promises are in there.
<schunter> https://github.com/w3c/dnt/blob/master/drafts/tracking-dnt.html
mikeoneill: amended to fix a bug
to return array for site-wide consent
... browser can decide to only support site-wide consent,
return it in an object
schunter: can we look at it?
mikeoneill: up on the list,
... also support Aleecia’s view on “should” for policy link,
that’s the thread, and continue to site-wide exceptions
<fielding> https://github.com/w3c/dnt/commit/803e40b370dfc7e7b986f8cf8936a6a346744d2b
(scribe plugs in laptop while others hunt for text to discuss)
(thanks, Roy!)
<fielding> https://github.com/w3c/dnt/commit/445d5a9a98f2808a0d72e978713e8f33630b00f5
mikeoneill: needs to return a
value, resolves to an object, trackingprotectionresults.
... also did same thing for confirm to make it the same
:-)
... confirm & restore return: bools site wide, exists
... before was just the promise with a bool, now both are an
object so it’s the same and you don’t have to implement two
things
... resolves to an object or returns a syntax error.
... site-wide set to true if the exception is site-wide
fielding: normally would require
API name if you change the API
... still using the same API names for the published prior —
change the names
mikeoneill: good idea
... shorter names would be good
fielding: just need to decide to change them
mikeoneill: sure, will come up with short names by next week
schunter: agrees on shorter new names
mikeoneill: used to be derived
from common object, now sep
... some disadvantages put a link up, like David Singer
suggested consent in batches.
... wouldn’t have to match them with the confirm if you don’t
have the same objects
... there’s no explaination string and site name
fielding: saw the thread, wasn’t
sure
... there was one where the store tracking exception was
responding with -
mikeoneill: the dictionary, the
property bag, they’re just sep but before, on the main list,
it’s derived from a common property bag with common properties.
before they all had a site name, property string, detail URI
and all that
... just pointing that out. not wrong to do it this way, but
affects what David Singer was saying on batches of
exceptions
... might be better to have it the old way
aleecia: David’s point could be really important with dynamic partnerships on ads
mikeoneill: could also say “these
are analytics” and batch by purpose
... user could revoke by purpose
... better granularity
... if we don’t have detail URI & explaination string,
can’t match them up
fielding: understand you could theoretically do that but there’s nothing in the spec that mentions this
mikeoneill: don’t have the fields any more
fielding: right, because it
didn’t make any sense. if we want them in, we need to add text
to say what they’re for, and use them
... fine to have it but needs explaination
mikeoneill: could use Dave Singer in this discussion
schunter: please send email to David
mikeoneill: will do
schunter: new topic
... 2nd topic, must have a TSR
mikeoneill: did that, done
schunter: everyone’s fine with the update and we’re done?
fielding: change granted to requested?
mikeoneill: yes
<fielding> https://github.com/w3c/dnt/commit/803e40b370dfc7e7b986f8cf8936a6a346744d2b
https://github.com/w3c/dnt/commit/803e40b370dfc7e7b986f8cf8936a6a346744d2b
(appears to literally change the word “granted” to “requested”)
schunter: seems done, now we’re
waiting for comments on call for objection. once done, ready to
publish CR
... any other steps we need?
fielding: we’re changing the API, so have to go to working draft or last call, then request a new CR
schunter: believe that has changed now
fielding: ok, process is changed, not sure
schunter: anything else?
... how about a diff or wait until the end
... will be on holiday in june, so want to push it out so we
don’t lose a month
fielding: last diff is basically it
schunter: appreciate after the API changes, then another diff
mikeoneill: site-specific tracking isn’t as pretty so something’s not right, will work on formatting too
fielding: will look at it, but going to London & Paris. might have time in transit
schunter: thanks a lot!
... all from me, will ask W3C staff for any final actions, will
wait for Roy’s link for next version
... will look for call for objections comments
<fielding> resent+ mikeoneill, aleecia
<fielding> trackbot, end meeting
This is scribe.perl Revision: 1.152 of Date: 2017/02/06 11:04:15 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00) Default Present: fielding, schunter, mikeoneill, aleecia Present: fielding schunter mikeoneill aleecia Found Scribe: aleecia Inferring ScribeNick: aleecia WARNING: No "Topic:" lines found. Found Date: 05 Jun 2017 Guessing minutes URL: http://www.w3.org/2017/06/05-dnt-minutes.html People with action items: WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option. WARNING: No "Topic: ..." lines found! Resulting HTML may have an empty (invalid) <ol>...</ol>. Explanation: "Topic: ..." lines are used to indicate the start of new discussion topics or agenda items, such as: <dbooth> Topic: Review of Amy's report[End of scribe.perl diagnostic output]