See also: IRC log
<jmayer> Very excited about the 1P vs. 3P discussion on the list. Seems to me we're getting quite close.
<aleecia> Please mute
<jmayer> Tom and I proposed user expectations, Amy and Shane proposed branding or affiliation.
<vm> + [Nokia]
<vm> Vikram Malaiya
<jmayer> I think we could definitely achieve a compromise here on branding.
<aleecia> Reminder: face-to-face meeting dates are April 10, 11, 12 in Washington, DC.
schunter: face-to-face fixed for April 10-12, exact details of venue to come
... ideal goal is to clarify remaining open questions for TPE document and plan how to get the next release out the door
... remove all closed issues
... fairly clean, listing alternatives where we have them
<npdoty> scribenick: tedleung
<dsinger> ...and use the q+!!
<aleecia> Recent teleconferences:
<aleecia> thanks Nick!
<npdoty> note that I did get some extra notes on one days of Brussels minutes, that I'll add in
minutes from previous meetings approved
<npdoty> really close, but not quite finished yet
tom and andy are still working on a counter proposal
due by next wed
<npdoty> action-82 due 2/29
<trackbot> ACTION-91 -- Andy Zeigler to write text on fingerprinting risk (ISSUE-109, ISSUE-114), with Nick Doty -- due 2012-02-13 -- OPEN
<aleecia> (Andy speaking)
<npdoty> action-91 due 2/29
<trackbot> ACTION-91 Write text on fingerprinting risk (ISSUE-109, ISSUE-114), with Nick Doty due date now 2/29
andyzei: same date as action-82
<trackbot> ACTION-93 -- Jeffrey Chester to write suggestions for best practices for issue-115, assisted by Ninja, Alan, Jim -- due 2012-02-07 -- OPEN
<aleecia> 1 more week?
<aleecia> Or done?
jchester2: sent text this am. new due date fri to allow alan to comment
<aleecia> I like Friday better :-)
<npdoty> action-93: due 2/24
<trackbot> ACTION-93 write suggestions for best practices for issue-115, assisted by Ninja, Alan, Jim notes added
<aleecia> TL speaking?
tl: still have an action for 3rd parties not to represent themselves as 1st parties. holding off until response header issues are clarified
<npdoty> tl, new due date for action 116?
<aleecia> Responses via well-known URI:
<tl> npdoty, 14d please.
<npdoty> action-116 due 3/6
<trackbot> ACTION-116 Draft text prohibitng third parties from acting or representing themselves as first parties due date now 3/6
<trackbot> ACTION-124 -- Amy Colando to draft an alternate 1st/3rd proposal (with Shane and Ted) -- due 2012-02-22 -- OPEN
schunter: purpose is to give information to user agents about the tracking status
... tl (with help) proposed a response header in http
schunter: fielding proposed a well-known URI approach
<tl> dsinger, 5.1
fielding: summarizes the proposal for using the well known URI
<tl> aleecia, This works fine in that situation. JSON is just a data format.
<aleecia> thank you, Nick
<npdoty> schunter: don't need to discuss the particular fields at the moment (since they may change, say)
schunter: asks that we not discuss the specifics of the fields
... rather compare the use of headers vs well known uris
tl: like this proposal, would like to see a compromise btwn the two approaches
... does a site have to have a status resources for every object on it?
would like clarification that every resource must be covered by a status resource
<fielding> tl: incorporate 4.1.1 of compliance into list of reasons
would like a connection 4.1.1 of compliance ( the exceptions?)
<aleecia> when the compliance doc is baked, this gets easier
<aleecia> +1 to Matthias here
<npdoty> I think that's compliance doc section 4.4.1?
<dsinger> dave would like to spend time with both server and client folks here to tease out the pluses and minuses
tl: given this type of proposal, would be comfortable with response headers as May not Must
<WileyS> Why not both?
schunter: if we have well known uri, do we still need headers
<WileyS> Machine readable vs. human readable
tl: well known uri can give a lot more detail, headers can give simple low latency info for user agents
<aleecia> Is bootstrapping a problem here?
fielding: ua can request on the well known URI before doing anything real on the site, so harder to track
<WileyS> well known URI = MUST, response header = SHOULD
fielding: user agent should always ask the well known URI first. if the entire site is covered, then must query about individual resources
<Zakim> rigo, you wanted to tell that it reverts the direction of the protocol
rigo: this is similar to what p3p does and that we should look at p3p if we go this direction.
<tl> I do not have any of Rigo's confusion, and I didn't have any on my first read of Roy's proposal.
<rigo> because you haven't read the P3P Specification yet
<johnsimpson> which is easier to implement? header or well-known URI
<aleecia> P3P will cause confusion :-)
<tl> This is not P3P
tl & fielding: this is different from p3p in that it is not general purpose
<schunter> Rigo: Well-known location only works for simple sites.
<aleecia> Rigo: well-known location seems simple, but then we add more to it and it gets complicated.
<schunter> 99% of target sites were too complicated to properly model/express in a single location
it's not about the fields that you send, it's about the fixed location
<schunter> My take: Federated sites may have difficulties managing a well-known URI for all its pieces.
<tl> Completely disagree with Rigo's assertion.
<schunter> Easier for page-author to send a header, too?
<npdoty> probably depends on the page-author's particular infrastructure
<aleecia> ...but the content at the well-known lot can be dynamic, right? Not sure what Rigo means here?
rigo: sites cannot react to the DNT value and is therefore not dynamic [?]
<Zakim> npdoty, you wanted to comment on requesting before making a request
npdoty: querying the well known uri before retrieving a resource
... because of things like cookies
<aleecia> so P3P had a bootstrapping problem because P3P was used to block things. DNT is not envisioned that way. Does bootstrapping matter?
<rigo> is what Roy is currently tallking about
fielding: server must not track the well known uri space
<aleecia> the Referer piece here is actually interesting (re: safe zone)
<rigo> I think this is providing additional information and could convey the P3P semantics and also the additional compliance semantics if need be
npdoty: in the case of a bad server, sending cookies to it (even in the well known uri space) is what you don't want to do
aleecia: asks to walk through roy's proposal using facebook like button as example
<rigo> the protocol Roy suggests is here: http://www.w3.org/TR/P3P11/#Well_Known_Location
fielding: browser is in pre query mode. browser checks it's list of whether it has checked this uri before. query to wellknown uri of ny times returns a list of affiliated servers, facebook like button is not on the list
... and like button is then a 3rd party
aleecia: now click on like button
fielding: that's a new user initiated request, so now a 1st party, if client doesn't have tracking policy for facebook, then it will query facebook's well-known URI for policy.
<npdoty> clicking on the like button would likely have a different tracking status than when loading the like button, right?
fielding: tracking status resource specifies the scope of the covered uri
<aleecia> I wonder if this would be an instructive example to walk through for both proposals. My concern is that cache and sites that can be 1st or 3rd parties always works correctly, in both cases. Certainly the well known URI content can be dynamic
<aleecia> But does that work with multiple users read the same URI?
<dsinger> I think the problem only arises with resources that are sometimes 1st and sometimes 3rd party. do referer headers help?
tl: what about the effects of caching the tracking policy information obtained from the well known uris. concern is about objects like like button which switch back and forth between 1st and 3rd parties
<WileyS> bad actors will be bad actors - thought we agreed to overly build the standard to try to stop bad actors - they'll find ways around anything we build
<WileyS> "...agreed to NOT overly build..."
tl: if i am very nefarious, the js for the like button can call some other piece of code, like flash or java, which might not make an http request which could checked by querying the well known uri
<aleecia> Shane: I'm not concerned so much about malice as are we accidentally specifying how things work at a technical level
<aleecia> +1 for use cases
schunter: still looking for pros and cons vs headers; also would like to see a walkthrough of some more use cases, using both headers and the well known uri
<npdoty> yes, it seems like walking through details of some use cases will be important for us
<jchester2> +1 for use cases
+1 for use cases
<aleecia> Is that good use of group time, or one-on-one? (I'm not sure at all)
tl: want to have proposal / counter proposal with roy
schunter: want to build a matrix of pros cons between the various proposals, driven by use cases
<fielding> I'd love to have more use cases inside the TPE spec.
<schunter> 4 steps: 1: Use casese; 2: Implementation sketches using both technologies; 3: compare approaches using a table (possibly in wiki)
dsinger: about the privacy of querying the well known uri. is the goal that it is always safe to fetch this uri?
<aleecia> Use cases I'd find helpful for both implementations:
<aleecia> - first party that doesn't do any tracking whatsoever
<aleecia> - first party with dynamic third parties (e.g. ads)
johnsimpson is asking which method is easier to implement
<rigo> dsinger, look at http://www.w3.org/TR/P3P11/#safezone for requirements for fetching WKL
<aleecia> - first party with a third party promoted to first party (e.g. Like button)
<aleecia> anything else that would be helpful?
<dsinger> headers for sites that do no tracking is a simple change to the server config file, no?
fielding: well known uri is easier for sites to deploy because the implementation is external from the existing machinery of their sites
<npdoty> I think it may vary depending on your particular implementation
<schunter> I created ISSUE-127 to moderate this comparison...
<aleecia> David, I do think some of this is very simple -- I was trying to start with "hello world" for use cases there
fielding: header field is easier to implement on the user agent side, but it learns the tracking status after it actually makes the request
schunter: let's include both in draft, we should also ask for public input by including both proposals in the draft
<rigo> fielding, look at http://www.w3.org/2010/09/raggett-fresh-take-on-p3p/
<npdoty> (that is, +1 on asking for public input on these different proposals)
<dsinger> I think both proposals have the nature that the complexity of implementation is proportional to the complexity of tracking, which is good
<npdoty> I thought we were just looking at the more recent header proposal
<aleecia> roy: currently both in document
schunter: would also like a call with tl and fielding to synchronize on the fields
<aleecia> david, +1
<npdoty> yeah, the fields won't be completely identical, but the exceptions area in particular may be good to synchronize
<rigo> exactly what Roy is saying: Scope of the declaration
fielding: unsure the field synchronization is possible
<rigo> +1 to take offline
field synchronization discussion to go offline
alex: do we need to include language to address user-agent caching?
<tl> If only HTTP provided for detailed descriptions of cacheability?
<rigo> the scope of the statement is different. A response to a DNT is on the request
<rigo> the WKL is scoped on all requests
<sean> super robot!
<aleecia> everyone loves giant robots
schunter: plan is to publish both proposals in next WD, work out pros and cons matrix via use cases
<dsinger> I think we need to understand the uses cases, pluses and minuses before we even decide whether we want one winner, or ...
<npdoty> ACTION: schunter to collect use cases for well-known-uri/response-header [recorded in http://www.w3.org/2012/02/22-dnt-minutes.html#action01]
<trackbot> Created ACTION-128 - Collect use cases for well-known-uri/response-header [on Matthias Schunter - due 2012-02-29].
<aleecia> david, that seems right to me too
first round of use cases due by end of the week
<fielding> ACTION: fielding to remove old response header proposal from TPE so that there is just one header proposal [recorded in http://www.w3.org/2012/02/22-dnt-minutes.html#action02]
<trackbot> Created ACTION-129 - Remove old response header proposal from TPE so that there is just one header proposal [on Roy Fielding - due 2012-02-29].
<aleecia> - Details for site-specific exeptions:
<WileyS> I'd like to make the case for DNT:2 if possible
<jchester2> Issue 112 goes to heart of First and Third party issues, and requires indepth discussion
<tl> I'd like to make the case against DNT:2.
<trackbot> ISSUE-111 -- Different DNT value to signify existence of site-specific exception -- pending review
<jchester2> I have to sign off, unfortunately, due to conflict. I hope we can address 112 next week
<npdoty> it's the current proposal from WileyS, and it's mentioned as an open issue in the draft
<fielding> the issue is noted in both 4.1 and 6.5
<npdoty> do you want DNT:2 to be a promise that the user agent has persisted all the permissions that were requested the last time?
WileyS: argument for dnt:2 is to reduce the amount of polling for site-specific exceptions
<vincent_> npdoty, that's not what I understand, it's rather to know that at least one exception exist for this site
tl: constant polling allows user agent to make very robust choices about when it prompts users and how long to store exceptions
<npdoty> I agree, vincent_, but I'm not sure that's Shane's use case
<schunter> ACTION: schunter to collect use-cases for URI vs Response header [recorded in http://www.w3.org/2012/02/22-dnt-minutes.html#action03]
<trackbot> Created ACTION-130 - Collect use-cases for URI vs Response header [on Matthias Schunter - due 2012-02-29].
<schunter> ACTION: fielding to sketch use case implementation for URI [recorded in http://www.w3.org/2012/02/22-dnt-minutes.html#action04]
<trackbot> Created ACTION-131 - Sketch use case implementation for URI [on Roy Fielding - due 2012-02-29].
<rigo> I don't understand why the UA doesn't send DNT=0 if a site specific exception has been granted?
<schunter> ACTION: tl to sketch use case implementation for URI [recorded in http://www.w3.org/2012/02/22-dnt-minutes.html#action05]
<trackbot> Sorry, amibiguous username (more than one match) - tl
<trackbot> Try using a different identifier, such as family name or username (eg. tleung2, tlowenth)
<WileyS> Disagree - remember this will happen on every single page request from a DNT:1 user
<schunter> ACTION: tlowenth to sketch use case implementation for Response Headers [recorded in http://www.w3.org/2012/02/22-dnt-minutes.html#action06]
<trackbot> Created ACTION-132 - Sketch use case implementation for Response Headers [on Thomas Lowenthal - due 2012-02-29].
tl: overhead this polling is not any worse than some of the ajax style traffic that is used to provide a rich experience on the web today
<schunter> ACTION: schunter to collect comparison criteria and summarize comparison in URIvsHeaders table [recorded in http://www.w3.org/2012/02/22-dnt-minutes.html#action07]
<trackbot> Created ACTION-133 - Collect comparison criteria and summarize comparison in URIvsHeaders table [on Matthias Schunter - due 2012-02-29].
<rigo> roy, why aren't they sending DNT=0 after exception?
<rigo> and maintain state in the browser (client-side)
WileyS: DNT:2 is in addition to DNT:1 and would be a should not a must. Full user control is still present with DNT:1
fielding: isn't client going to be sent DNT:0 if there is a site specific exception?
WileyS: no, DNT:0 doesn't cover the site specific exception case
... the question is when do we poll for site specific exceptions
<npdoty> my understanding is that the first-party will continue to receive DNT:1 when some of the third-parties might be receiving exceptions
<rigo> the scope of DNT=2 is going far beyond the request and will create all sorts of complexities and issues IMHO
<npdoty> tl: one or more gets DNT:2, or when all of them?
WileyS: my conception of DNT:2 is that one or more of the first party's 3rd parties have been granted a site specific exception
<fielding> note that none of these details are present in the issue
<vincent_> wait, how do you know you polled me since you added your last third party if you can't track me?
<rigo> why doesn't the third party poll the user themselves?
<rigo> so the first party only wants to give content if the third party tracking is allowed and needs communications to know that
<schunter> It is information that tells the site ¨this guy sent DNT;1, have I received exceptions that continues my site to operate?¨
<rigo> in this case, DNT=2 means that requests are only allowed if all exceptions are granted
<schunter> I believe that ´does not my site still work´ is a valid question/concern.
npdoty: if the UA only grant exceptions for some of the 3rd parties, what DNT value is that?
<rigo> whatif the UA just does not request that content from the third party at all?
<aleecia> (5 minutes left on this call)
<npdoty> < 1ms, presumably, for a JS call, right?
<npdoty> we definitely have some confusion here :)
<schunter> Ideas how to clarify?
[make it hard to scribe]
<npdoty> WileyS: better if the user agent does it because it's faster
<WileyS> Suggest we take this offline
<fielding> I can see the desire, but given the fact that a user agent can change preferences at any time and that the server cannot trust the 2 being sent anyway if it depends on it, the DNT:2 proposal is not useful.
<WileyS> Versus polling and adding polling overhead on every single request
<aleecia> Sorry, hard stop for me today. Off I go.
<WileyS> Email is fine
<npdoty> I think we should wrap-up and continue in email
<schunter> Our goal must be to implement Shane´s requirement in the most efficient way
<WileyS> Let's document the full use case and we can come back to discuss after that
<WileyS> I have to jump - apologies - really want to stay. Look forward to the email chain! :-)
schunter: by next week, polish the document so it's presentable to the public
... take a quick look next week to make sure we're okay releasing the next draft to the public
... if the issues are closed, remove them, other issues remain in the doc
<tedleung_> npdoty: thanks for the help
<dsinger> ...regrets he is still behind-hand with the emails...
<dsinger> thx all
<npdoty> thanks to tedleung for scribing
<schunter> ACTION: fielding to cleanup document to produce next public version of TPE [recorded in http://www.w3.org/2012/02/22-dnt-minutes.html#action08]
<trackbot> Created ACTION-134 - Cleanup document to produce next public version of TPE [on Roy Fielding - due 2012-02-29].
<npdoty> Chair: schunter
<schunter> ACTION: wiley to detail use case for ISSUE-111 (DNT;2) [recorded in http://www.w3.org/2012/02/22-dnt-minutes.html#action09]
<trackbot> Created ACTION-135 - Detail use case for ISSUE-111 (DNT;2) [on Shane Wiley - due 2012-02-29].
<schunter> ACTION: Propose simplified set of fields for URI and response headers [recorded in http://www.w3.org/2012/02/22-dnt-minutes.html#action10]
<trackbot> Sorry, couldn't find user - Propose
<schunter> ACTION: Schunter to Propose simplified set of fields for URI and response headers [recorded in http://www.w3.org/2012/02/22-dnt-minutes.html#action11]
<trackbot> Created ACTION-136 - Propose simplified set of fields for URI and response headers [on Matthias Schunter - due 2012-02-29].
<npdoty> trackbot, bye