See also: IRC log
<trackbot> Date: 05 June 2013
i can scribe
<npdoty> scribenick: kulick
schunter: brad is too quick
... main goals to go over all main goals to close them or make progress on them
... end call with associated actions for all issues
... listed issues in agenda which could benefit for discussion
... next item open actions, overdue action
schunter: next item 312... Justin
<npdoty> note we have several quite old actions that I didn't close during cleanup because I wasn't sure about the status
<trackbot> ACTION-312 -- Justin Brookman to merge financial logging language -- due 2013-04-01 -- OPEN
schunter: due April 1st
<npdoty> I think Justin might have actually done this already :)
justin: superceded by conversation
schunter: closing this
... adrian on call?
... action 365
<rigo> trackbot, close action-312
<trackbot> Closed ACTION-312 Merge financial logging language.
<justin> Superseded or done, either way it can be closed.
<trackbot> ACTION-368 -- Chris Pedigo to work on updated "service provider"/"processor" definition (with vinay) -- due 2013-02-27 -- OPEN
<rigo> trackbot, close Action-365 overtaken by events
<trackbot> Sorry, rigo, I don't understand 'trackbot, close Action-365 overtaken by events'. Please refer to <http://www.w3.org/2005/06/tracker/irc> for help.
schunter: <which item?
... will send reminder to associated folks
<Chapell> Shane is only on IRC
<npdoty> skipping 368, 369, 375, 376, 377 for absent
<WileyS> Thank you Alan
<npdoty> rigo, are you on the call?
schunter: nick, can you send
... would like clean up
who is speaking?
<rachel_n_thomas> folks, the DAA Summit is taking place in DC today, so I know that a lot of folks are tied up there at the moment.
scribe: action 405
rigo: 405 is same as <>...
susan is getting decision on audience measurement.
... once feedback, need to provide text and see if addresses Jeff's FAQ
... please keep open... i will set date to next week
schunter: next action about AU OBA guidelines
... can be closed
<npdoty> close action-383
<trackbot> Closed ACTION-383 Ask Malcom Crompton about the Australian OBA guidelines.
not OBA guidelines in AU at the moment
schunter: done with overdue
... nick can you send reminder
<vinay> Rigo - aren't the ADAA best practice guidelines here: http://www.youronlinechoices.com.au/wp-content/uploads/2011/03/Australian%20Best%20Practice%20Guideline%2014%20March.pdf
npdoty: yes, i sent some and i will continue to send. also for those we dont know if we can close.
schunter: would appreciate
delivery dates for associated open action items
... issues in 3 cats
scribe: issue 137, whether need service provider flag
singer: I am in process of
finding my previous write ups
... conclusion: can sail without the flag if we need to
... yes, we can express what we want to thru each of the cases
schunter: you want discussion with aleecia and jonathan
singer: yes, let's reopen the discussion
schunter: instead of separate call, you will discuss on the list and then call, if need be
<fielding> dsinger, was that http://www.w3.org/mid/7AC4D9F6-C8AB-417F-A244-0FF5080D898B@apple.com
schunter: next issue... <mnissed>
<trackbot> ISSUE-200 -- Transitive exceptions -- open
scribe: trasitive exception
rigo: is 1st party recv site wide
... <behind, sorry>
... would have transitory perms for eveyone in the auction, but w/o adding to profile
<Brooks> aacc is Brooks
rigo: shane mentioned that if i
have webside exception, i want to be able to add to my
... only on this edge case do we have disagreement
... the text reflects the main thing that with web wide exception allows for adding tp profiles but is not inline with our proposal
... i will work on text
... about some with web wide exception can add to profile
schunter: why cant you?
... seems reasonable to do this
... why does it not work in auction
<WileyS> If we equate a WW UGE to equate to OOBC then I don't see an issue here
rigo: b/c if you have user granted exc, if you have real estate on the page, transitory dont apply
<WileyS> WW UGE (Web-Wide User Granted Exception) - OOBC (Out of Band Consent)
rigo: only applies if you dont
have direct access to the browser
... question is who is paying for the doubt, user or company
... shane wants user to pay, i want company to pay
schunter: there are multiple
issues intermingled here
... 1 issue (missed)
... 2 what extent are you allow to store permissions
schunter: other opionions?
nick: clrifiying question
... this case seems about where user doesnt interact with user directly
... server to server
... I thot <missed>
<npdoty> one relevant email: http://lists.w3.org/Archives/Public/public-tracking/2013Jun/0004.html
rigo: you can indirect
... we want to avoid reprogramming all auction systems to be rewired to work for redirects
<schunter> issue 1: Storage of transaction data (if you get an exception that has been transferred)
rigo: we were trying to provied a kind of container
schunter: propose that we see rigo and shane's proposals
rigo: cant do before june 26
schunter: assigning to shane, then
npdoty: this is for action item 203
schunter: correct, please update accordingly
npdoty: what is the work
schunter: spell out agreements and alternatives accordingly
<dsinger> do we need to remember the 'acting as a service provider to a 3rd party with consent'?
schunter: add a comment and push deadline by a week
singer: tech poss to say i am a site acting as a 3rd party with consent
<npdoty> yes, thanks for clarifying for me
rigo: problem is you need prior
... auction works on post bid agreement
schunter: btw - i opened issue
200, which was closed
... in an old issue
<npdoty> re-opened action-203, with notes
schunter: should action 396 be associated with this issue
schunter: nick, can you report on the progress on this
npdoty: daivd put in text for
transitive redirect case, but not server to server case
... C for consent, but need to add new qualifier key
schunter: david will add to the text
<npdoty> use "C" for consent, and a new qualifier "t" for transferred
schunter: this closes 168 ?
<fielding> why don't you just use a different TSV, like T
siger: yes will cover the 2 cases
<who is speaking>
no reason to respond with 'C'... <missed>... why not just create a new status of 't'
fielding: they may have consent,
but also have trasferred consent
... you want them to be diff signals instead of adding 't' as a qualifier
... i'll update mailing list with that alt
schunter: anything else on the
issues we wanted to discuss?
... moving on to where status is unclear
<trackbot> ISSUE-153 -- What are the implications on software that changes requests but does not necessarily initiate them? -- pending review
schunter: issue 153
<npdoty> I think fielding is right, that better handles distinguishing between the transferred case and the independently-having-user-granted-exception case
<npdoty> open action-396
schunter: there shouldnt be mods
between UA and server
... i would close this issue
... did i overlook something?
<fielding> So, create a new TSV (perhaps "T") to indicate the the third party does not have consent directly from the user but does have transferred permission from the transitive permission.
schunter: issue 153
<npdoty> action-396: provide an update, as suggested by Fielding, to use a different tracking status value
<trackbot> Notes added to ACTION-396 Provide pending review text for signal of transferred/redirected exception (issue 168).
rigo: related to open action ???
npdoty: it is in pending review as of October
npdoty: jonathan has proposed
... but there are other alts
<npdoty> with David Singer, I suggested that we add a requirement that any software that modifies also follow the consent requirements as defined in Section 3
<fielding> I think this is tied up with the compliance issue?
rigo: as soon as alt nick mentioned is in the spec we can close the issue
<Chapell> agree with roy
<Chapell> there is a key dependency here
schunter: need a volunteer
rigo: add to 285? and open with new due date ?
<Chapell> assuming that the group finds consensus re: the de-identification proposal
<dsinger> I added Nick's text to the notes of the action.
chapell: no opinion on this lang so long as group has some info on de-id... however it that doesnt move forward, we need more on this
<justin> I think it's tied up with *other* compliance issues than deidentification . . .
<think I messed up alan's comments>
<justin> But still tied up with other ongoing issues.
<npdoty> my proposal with dsinger was a MUST, rather than a best practice, but Jonathan proposed this alternative
<Chapell> +1 to justin
<npdoty> I agree, I don't see the particular connection to de-identification, except for deidentification being an important issue
chapell: not sure what this
... de-id is a recognition that there would be invalid DNT signals... we dont know if we can distinguish btw them and that would be built into the sighanl
... dwhat does it add
rigo: the scenario is related to
a transparent proxy
... this is a clear req that software can circumvent
... what are valid toekns
... need to send a header that you are dismissing if you believe invalid
chapell: why is this a must if called as a best practice
<dsinger> …and we add to that the consent requirements must be held to
schunter: should be a must if
... another use case
<npdoty> my proposal from last July: http://lists.w3.org/Archives/Public/public-tracking/2012Aug/0001.html
<npdoty> "> Software outside of the user agent that causes a DNT header to be sent (or modifies existing headers) MUST NOT do so without following the requirements of this section; such software is responsible for assuring the expressed preference reflects the user's intent."
schunter: any intermediatary needs to make sure if support user choice the same as broswer <right?>
chapell: i would move to make must
<npdoty> Chapell, you can see my "MUST" proposal in IRC above, or in link above
singer: it must follow reqs for setting DNT header
schunter: can it delegate to
... as a whole it should happen, some could be by UA and some by extensions
<justin> Whatever we decide here, it needs to be mapped to whatever we decide on UA requirements in Compliance: http://www.w3.org/2011/tracking-protection/drafts/tracking-compliance.html#user-agent-compliance
schunter: end product must satisfy reqs
<npdoty> I proposed text in July 2012, pasted above
chapell to provide requirements
chapell: singer's lang better
schunter: nick, p[ls mod existing action and assign to alan?
<aleecia> listen only mode
schunter: welcome aleecia
<aleecia> (Zakim dropped me multiple times this morning already)
schunter: issue 195
<npdoty> ACTION: chapell to propose new text regarding other software (perhaps building off of npdoty, dsinger) [recorded in http://www.w3.org/2013/06/05-dnt-minutes.html#action01]
<trackbot> Created ACTION-414 - Propose new text regarding other software (perhaps building off of npdoty, dsinger) [on Alan Chapell - due 2013-06-12].
schunter: proposal from
... handling OOB consent
<npdoty> action-414: issue-153
<trackbot> Notes added to ACTION-414 Propose new text regarding other software (perhaps building off of npdoty, dsinger).
schunter: 'p' potential
... accpt, reject, oither?
... not clear if people are convinced
singer: leaky hole
<aleecia> I'm 408
<rigo> agrees with dsinger that this is a leaky hole
<aleecia> Or rather, was, until joining via work phone
singer: dont think any users will do this... it seems dangerous
schunter: site needs more than 2
secs to get consent
... so w/o delaying we need another way
singer: user should be able to find from control link
schunter: I would support this lang
<hefferjr> the information does not necessarily exist at that point in time (as discussed previously)
schunter: we should not go into details of timing for retrieval
schunter: at control link user can retrienve this but no speak to timing
ronan: did discuss timing
<justin> Where is this language?
ronan: 24-48 hrs?
ronan: data may not be collected in time
schunter: exact hours creates debate
<aleecia> (this sounds exactly like what a SHOULD is for)
schunter: therefore we should leave it out and explain why you need more time at the link
<dsinger> ….I fear that any 'come-back-later' is a gaping hole that the nefarious will drive trucks of bad behavior through
<justin> I had proposed two amendments: can't be used for personalization and can't subsequently reject consent as invalid. I don't think those are adequately reflected in that text.
singer: i dont think it is a gapping hole
<fielding> There was a question about short term data retention permission being sufficient to make this TSV no longer needed. Did we confirm that or not?
singer: bad sites will abuse this
<npdoty> justin, if you can remind us with a text proposal, that would be great
coorrect: singer: I think IS a gapping hole
npdoty: understand the concern, would be bad if 'p' was over used
<justin> I can take an action to update this. hefferjr had agreed in concept with the amendments, but not sure it was ever put into text.
npdoty: meant for exceptional
... we could update to say "in this exceptional case..." and see if over used and come back to this
rigo: service could send 'p' to
... and then say we find out later who we have for
<npdoty> yes, rigo is right, the "P" would be used by any such service in all of its responses
<schunter> I disagree.
rigo: brtowser is unable to determine if data collection is propotionate
<npdoty> ACTION: brookman to provide text proposal regarding limitations on using a Potential Consent signal [recorded in http://www.w3.org/2013/06/05-dnt-minutes.html#action02]
<trackbot> Created ACTION-415 - Provide text proposal regarding limitations on using a Potential Consent signal [on Justin Brookman - due 2013-06-12].
rigo: <gist is will be abused>
<schunter> The "P" does not give any extra permissions. It just is a relaxation of the information requirement.
rigo: "p" opens too much
<npdoty> rigo: "P" signal would be sent for everyone
schunter: our understanding might
be diff then
... "p" doesnt give extra perms
... it just says i cannot tell you at this point
... it doesnt allow you to do anything with the data
... you must be on safe side
<dsinger> I really fear 'P' is an invitation for sites to be lazy. If it's any amount of work to do the check that 'C' requires to work at the control link, sites will say 'P' to everyone all the time.
<npdoty> I think schunter is right that this does not create a new permitted use or new retention possibility, it's just a different signal back to the user
<dsinger> There *is* a short-term storage permitted use already.
schunter: doesnt give extra
perms, but delays cheking for consent
... alt discussed is just declare '1' or '3'. as '3' you still have perms to say if I have consent to use the data
... if find out that I can consent then I can keep your data
fielding: same point as
... other alt
<aleecia> DNT fails.
fielding: to the dangerous loophole concern:
no danger implied by holding danger for time to identify consent, here we are making it more explicit
scribe: danger notion doesnt match
<npdoty> I think the danger might be that signals will stop losing their meaning if "P" is always returned and the user never knows if they are being tracked with consent
schunter: if add under '3', people dont understand if stored long term
<dsinger> …agree with Roy that the short-term raw data retention is there and OK. The question is whether the use will know whether there is retention and tracking beyond that. P makes it effectively impossible for the user to know, and it's too attractive for sites to say P all the time.
ronan: echo matthias
... no permited use... it is permitted retention
... text also has should determine in real time
... 'p' prtovides more transparency
... '3' works but is less transparent to users
singer: i dont agree
<fielding> dsinger, but that is still better than receiving 3 (and actually keeping data if there is consent) or not being able to send any response because we forbid these systems from complying with DNT
<rigo> Roy, I think you assume that the browser is not reacting while I assume that the browser reacts, thus my different opinion. Under your assumption, Roy, I would agree with you...
singer: alot of sites will read this as i dont need to create ctonrol link <?>
<justin> This only applies to market research companies, not OBA companies (assuming my amendment goes through).
singer: 3 times to check for
... 1. as user interaction
... 2. user visits control link
... you hav minutes at this point
<npdoty> justin, but users have an interest in knowing what's going on whether the business practice is OBA or market research, yeah?
singer: 3. 24-48 hours later after data agg
<schunter> Suggested way forward: "say that the control link provides information "as soon as technically possible"" and try to add the extensions of Justin
singer: okay with 1 and 2, but feel 3 is too big a hole
schunter: control link should provide as technically possible
<fielding> justin, yes -- I am assuming this excludes personalization
<justin> npdoty, Yes, I have concerns either way. I don't love this rule, just trying to make it as palatable as possible.
singer: but you cannot find out
... need to say that control link will tell you whether you have consent or not
<npdoty> fielding, justin, as this doesn't add new permitted uses, I think it necessarily excludes using the data for personalization before consent is determined
schunter: justin mention some
... i suggest moving forward with control link text w/o time
<trackbot> ACTION-414 -- Alan Chapell to propose new text regarding other software (perhaps building off of npdoty, dsinger) -- due 2013-06-12 -- OPEN
<justin> singer, I have an action to provide text, will circulate to list.
<trackbot> ACTION-415 -- Justin Brookman to provide text proposal regarding limitations on using a Potential Consent signal -- due 2013-06-12 -- OPEN
schunter: then wew ill review revised text
<npdoty> action-415: dsinger can add this new text to the spec, and allow group review
<trackbot> Notes added to ACTION-415 Provide text proposal regarding limitations on using a Potential Consent signal.
schunter: should add explict that 'p' does not provide usage of the data
<trackbot> ACTION-415 -- Justin Brookman to provide text proposal regarding limitations on using a Potential Consent signal -- due 2013-06-12 -- OPEN
ronan: find with no time
... still gives us 72 hours
<justin> npdoty, You might be right about that. Still want to make clear that you can't reject DNT:1 signal later.
ronan: how about outer bound
schunter: outer bound means you have to delete data if regardless if you know if you have consent or not
ronan: outer bound is privacy enhancing
<npdoty> is the outer bound implied as an outer bound for retention? or outer bound for returning a signal back to the user?
rigo: 1 question, 1 remark
... when have 72 hours outer bound... should say up to 72 hours
... roy's remark made me rethink my pos
... do browser intend to have reaction on response
<schunter> The outer bound for retention is the maximum time you may need to determine consent. If you need longer, you may be forced to answer "I was unable to find out whether I had consent from you in a timely fashion, therefore I did not keep your data."
<missed.... sorry rigo, you are hard to scribe>
<aleecia> Rigo - there is more to life than browsers
<npdoty> I don't think there is any scenario where after an amount of time a service will have a definite answer on consent because it's always possible that for new requests the consent may have received in the meantime
npdoty: 1 concern
<WileyS> As with other items, I believe we should avoid arbitrary timeframes in normative text but could offer thoughts in non-normative
schunter: wait and look at text then move forward
<rigo> NP: if p would be predominant the browser couldn't inform the user anymore in time
<fielding> well, the sender of P still needs to obtain that consent -- I have a hard time understanding what the problem would be that browsers can't mess up the UI.
npdoty: david to work with ronan
... in david's hands
... <what number>
<npdoty> ACTION: singer to review potential consent proposal (including updates from justin), may provide alternative regarding control link [recorded in http://www.w3.org/2013/06/05-dnt-minutes.html#action03]
<trackbot> Created ACTION-416 - Review potential consent proposal (including updates from justin), may provide alternative regarding control link [on David Singer - due 2013-06-12].
<trackbot> ISSUE-151 -- User Agent Requirement: Be able to handle an exception request -- open
schunter: on 151...
<rigo> RW: only concerned if the browser reacts on DNT signals by e.g. sending less chatter or personal data, then p is dangerous as it mainly requires the browser to open up as a reaction. So the browser would have to block things in p as the state is unclear
schunter: not a must, but a should... some say it doesnt matter
<fielding> rigo, no more than it would have to do so for sites that don't support DNT at all.
npdoty: the must req is just
having a section in the spec
... do we have alt text for proposal
<rigo> fielding: right, but then P won't by Ronan anything anyway
schunter: do we need alt text?
singer: spoke about this in
... would be redundant to add
... want to see must inserted to avoiud abuse
<fielding> well, that effectively means we should remove UGE from the spec.
<npdoty> might have missed that last point, dsinger -- you want to add an explicit "MUST" here
chapell: how is this significanntly diff from discussion 30 mins ago
<npdoty> ... or you want to *not* say "MUST"?
... why is this diff?
<trackbot> ACTION-151 -- JC Cannon to write up personalization-without-tracking on loggedinness (with David and Shane) -- due 2012-03-28 -- CLOSED
<trackbot> ISSUE-151 -- User Agent Requirement: Be able to handle an exception request -- open
chapell: isnt this just an exaqmple of software changing signal
npdoty: this is related to browser,
schunter: all UA must have exception APIs
<dsinger> the other practical point is that there is no functional difference between a UA that doesn't implement and a UA that always says 'no'.
<dsinger> I am completely opposed to a MUST
schunter: convergin to a must
<adrianba> does the spec say that the api is optional?
<npdoty> the current text in the spec does not include a MUST or indication that it's optional
singer: if will be abuse, i am against must
chapell: not sure how we address that
<npdoty> singer: if sites will use this as a reason to ignore the user's signal, then I am against adding a MUST
rigo: biggest dang for DNT are
people not here just imp to spawn dnt headers
... kills our ecosystem
<Chapell> WileyS may want to weigh in on this
rigo: my aim was to protect the eco system
<dsinger> Also, we heard in Cambridge that sites would make no practical difference to the users, whether DNT is set or not; under those circumstances, why would sites ask, and why would users grant, an exception?
rigo: by those investing and have
exception, you cannot ignore them
... and claim compliance
<dsinger> The issue of equipment/software that randomly injects DNT signals is real, and will exist whether or not we write this into the spec. We need a serious discussion on how to handle this.
<adrianba> in the end everything is optional for implementers but unless the spec says the feature is optional you can't claim to comply with 100% of the requirements in the spec if you do not implement all the non-optional pieces
rigo: if other better way to exclude bad routers and killers of ecosystem, i can drop issue 151
singer: i dont have intermediate evildoer problem
<Chapell> I propose we table this discussion
singer: needs seriously discussion... must in text doesnt matter
<npdoty> I believe we have already rejected the idea of orphaning legacy agents by changing DNT: 1 to a different value later
singer: changing from dnt:1 to dnt:something might be good idea
<not scribing jokes>
scribe: suggest not tying with extra musts
<Chapell> +1 to Roy
<adrianba> writing MUST in spec doesn't change if it gets implemented
<rigo> IMHO this is why I raised the issue, so we have to ponder and noodle on it
fielding: sites have to imp OOB consent mech
<justin> Two browsers have said they don't want it, and I know other advocates (and Ed Felten) have expressed concerns about putting a MUST in here. Not sure there is consensus.
<npdoty> dsinger: adrian has indicated that he is working on implementing it; other companies are unable to comment
fielding: only reason to justify in the spec and this everyone <missed> ... if in spec should be must, if not remove from spec altogher
<npdoty> we could mark it as risk, but I agree with adrian that adding more MUSTs doesn't seem to make it *more* likely to be implemented
singer: if adding musts on UA, we need more musts on sites
<fielding> MUST implement the WKL is a huge requirement on sites
schunter: i believe sites already
have quite a few musts
... how to move forward
... must or not must... that is the question
<justin> Chair's decision seems to be right approach here.
<npdoty> we can postpone this discussion, I was just asking whether we need alternatives from the current text
<dsinger> yes, I am saying that
<schunter> "to MUST or not to MUST" ;-)
<fielding> we could make it conditional : browsers that block on the basis of TSV responses MUST implement the UGE?
<schunter> Way forward: "SHOULD" and wait for last call
rigo: if leave open in lastr call and have in cr exit criteria, then make exception api a should and how it works how bad the ambient header noise is
singer: seeing experience is good
schunter: add as should and evaluate at last call
<fielding> SHOULD is fine
<Chapell> I'm not sure we have the right folks on the call --- we should leave open for now
rigo: SHOULD now
<npdoty> we would mark it in the ISSUE, and then include text in our last call/cr announcements
<dsinger> we should insert the 'UAs should implement the exception API" and we add a NOTE saying "under consideration, for last call, to be a MUST"
<Chapell> If memory serves, WileyS had a strong opinion on this issue - and he is not on the call
rigo: and issue 151, resolved or postponed with comment we have this resolution we want to test and if need be, this can become a MUST
<npdoty> Chapell, I don't think we're closing the issue right now (matthias would send around email about it), just a possible way forward
<Chapell> npdoty sounds good. thanks
schunter: we have a way
forward... action in singer to add a should
<hefferjr> sorry about that, this technology is beyond me
<npdoty> ACTION: singer to provide proposal regarding SHOULD and last call / CR notes regarding implementing exceptions API [recorded in http://www.w3.org/2013/06/05-dnt-minutes.html#action04]
<trackbot> Created ACTION-417 - Provide proposal regarding SHOULD and last call / CR notes regarding implementing exceptions API [on David Singer - due 2013-06-12].
rigo: progress. yah
<npdoty> action-417 due 06-19
<trackbot> Set ACTION-417 Provide proposal regarding SHOULD and last call / CR notes regarding implementing exceptions API due date to 06-19.
schunter: issue 164
<trackbot> ISSUE-164 -- To what extent should the "same-party" attribute of tracking status resource be required -- open
schunter: 3 alts
... 1. completely optional
... 2. mulitple domains should declare
3. UA may assume you are diff parties if you dont declare
scribe: 3. UA may assume you are
diff parties if you dont declare
... my fav is 3
<rigo> my suggested text: http://lists.w3.org/Archives/Public/public-tracking/2013Jun/0016.html
<npdoty> do we have text proposals for the alternatives?
<moneill2> +1 for C
<rigo> npdoty, see end of my email
scribe: any other points
<fielding> I said above (missed) that sites already have to implement OOB consent. The premise for having UGE in the spec is that sites will eventually be able to use it when all browsers implement UGE -- otherwise, sites have to keep using OOB consent forever. That is why the spec needs to require implementation of UGE, or remove the functionality from the spec because it is redundant.
<dsinger> yes, UAs may question why you claim '1' status when you appear unrelated to the first party
scribe: unless objection... option C (3 in scribe notes... doh!)
<rigo> schunter: accept that text and put in the spec: http://lists.w3.org/Archives/Public/public-tracking/2013Jun/0016.html
<fielding> okay, not sure I am happy with exact wording
<schunter> we can fine-tune the wording.
<npdoty> I think rigo is proposing no new requirements, but the recommendation, with Roy clarifying wording
schunter: actio to Roy to put in
... 1 more item
<rigo> npdoty, yep no new requirements, just non-normtive text
schunter: issue 161
<trackbot> ISSUE-161 -- Do we need a tracking status value for partial compliance or rejecting DNT? -- pending review
<npdoty> ACTION: fielding to add text to spec regarding conditions where it would be useful to indicate same-party member [recorded in http://www.w3.org/2013/06/05-dnt-minutes.html#action05]
<trackbot> Created ACTION-418 - Add text to spec regarding conditions where it would be useful to indicate same-party member [on Roy Fielding - due 2013-06-12].
schunter: jonathan is okay with
'!' but has concerns with 'd'
... '!' is accepted
<npdoty> action-418: can work off of http://lists.w3.org/Archives/Public/public-tracking/2013Jun/0016.html, but Rigo certainly accepts any improvements in language
<trackbot> Notes added to ACTION-418 Add text to spec regarding conditions where it would be useful to indicate same-party member.
schunter: 'D' means i disregard your signal
<dsinger> The point is that IF they are going to disregard you, at least tell the user
singer: concern is more suttle...
disregard is compliant... need add to text that compliance is
indetermine in this case
... if 'D' at least tell why
rigo: from legal, '!' and 'D' is the same
<dsinger> so, I want to add to 5.2.8 "The compliance of the Disregard signal is indeterminate; it may be compliant or not compliant, depending on the reasons or circumstances."
<schunter> + explain why somewhere
<Zakim> npdoty, you wanted to ask indeterminate or non-compliant
rigo: i understand concern, but abuse would be highlighted soon
npdoty: i thot '!' doesnt mean compliance... <???missed>
<dsinger> I also want a required "why" somewhere in the WKR
schunter: might need to postpone due to time.
<npdoty> npdoty: I thought "!" indicated non-compliance and must not be used in compliance; we could do the same with "D", to say that it's never compatible with complying with a user's preference
singer: want to see why is disregarded and user can act upon that
adrian: agreed with david
adrian: i think signal should be 'D' disregard the signal b/c upon reason I dont think i should follow it b/c it is believe the source is not compliant or not readable
<rigo> because I'm not able to honor, so +1 to adrianba
<dsinger> …maybe I am under a court order to keep complete records of my visitors because I did something bad in the past. Under those circumstances, I have to disregard you...
schunter: action item to update text?
<schunter> "D should be used in exceptional cases and policy should explain when it is used"
fielding: should add info as to
non-compliance in policy
... i dont want in spearate field
<dsinger> totally fine if the policy has to explain when 'D' may be used. As long as we require the explanation somewhere, that's fine.
<npdoty> might be hard to get agreement on "in exceptional cases" if implementers believe they will use it predominantly
schunter: 'D' in exceptional cases, but policy says why/when not respected
schunter: update text and see if
jonathan's concern is mitigated
... roy is taking action item
<npdoty> ACTION: fielding to update Disregard signal with conditions (rarely and indeterminate) [recorded in http://www.w3.org/2013/06/05-dnt-minutes.html#action06]
<trackbot> Created ACTION-419 - Update Disregard signal with conditions (rarely and indeterminate) [on Roy Fielding - due 2013-06-12].
schunter: for 1 and 2 of singer's comment above
<trackbot> Notes added to ACTION-419 Update Disregard signal with conditions (rarely and indeterminate).
<dsinger> yes, Rigo, that's the point of 'rarely' used
rigo: concern is where you claim something you do not do
schunter: give rigo action for text
<npdoty> ACTION: rigo to propose non-normative text on use of Disregard signal [recorded in http://www.w3.org/2013/06/05-dnt-minutes.html#action07]
<trackbot> Created ACTION-420 - Propose non-normative text on use of Disregard signal [on Rigo Wenning - due 2013-06-12].
schunter: 137 is big concern
<fielding> actually, one problem with "rarely" is what that means: MSIE 10 will be disregarded whether it is rare or not
<scribe needs to leave> bye
<npdoty> thanks to kulick for scribing!
This is scribe.perl Revision: 1.138 of Date: 2013-04-25 13:59:11 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/thomas/schunter/ Succeeded: s/The *is*/There *is*/ Succeeded: s/not UA// Succeeded: s/???101???/151/ Succeeded: s/sites/browsers/ Found ScribeNick: kulick Inferring Scribes: kulick WARNING: No "Topic:" lines found. Default Present: eberkower, +1.202.347.aaaa, jackhobaugh, Fielding, moneill2, WaltMichel_Comcast, Rigo, [CDT], [Adobe], npdoty, +1.650.595.aabb, kulick, Aleecia, schunter, adrianba, Peder_Magee, [DAA], [Microsoft], Yianni, David_MacMillan, chapell, +1.678.492.aacc, ninjamarnau, JeffWilson, hefferjr, +1.650.595.aadd, +1.678.492.aaee, Brooks, dsinger, +1.650.595.aaff, +1.323.253.aagg, +1.650.723.aahh Present: eberkower +1.202.347.aaaa jackhobaugh Fielding moneill2 WaltMichel_Comcast Rigo [CDT] [Adobe] npdoty +1.650.595.aabb kulick Aleecia schunter adrianba Peder_Magee [DAA] [Microsoft] Yianni David_MacMillan chapell +1.678.492.aacc ninjamarnau JeffWilson hefferjr +1.650.595.aadd +1.678.492.aaee Brooks dsinger +1.650.595.aaff +1.323.253.aagg +1.650.723.aahh Regrets: johnsimpson aleecia jmayer peterswire chris_iab susanisrael Found Date: 05 Jun 2013 Guessing minutes URL: http://www.w3.org/2013/06/05-dnt-minutes.html People with action items: brookman chapell fielding rigo singer 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]