See also: IRC log
<aleecia_> Who is fanboynz? :-)
<aleecia_> Shouldn't be hard to pick a scribe… 12.5% chance :-)
<schunter> http://www.lotuslive.com/join?schedid=7248329
<npdoty> schunter, what's that link for?
<aleecia_> going to start in 1 minute
<schunter> We may later use it for shared browsing in the spec.
<schunter> If you like, you can try it. If you like it, we can use it.
<npdoty> scribenick: johnsimpson
<npdoty> (justin has volunteered to scribe for the other doc)
<aleecia_> http://www.w3.org/2012/02/08-dnt-minutes
<johnsimpson_> john simpson scribing for compliance
<tl> Do we have a super-smart Jeopardy-robot on the call?
minutes are approved
<andyzei> what conferences?
<rigo> yes
<rigo> sent to mailing list
rigo: have completed compliance proposals
<npdoty> action-47?
<trackbot> ACTION-47 -- Jonathan Mayer to write discussion on best practices for 3.6.1.2.1 -- due 2012-02-09 -- OPEN
<trackbot> http://www.w3.org/2011/tracking-protection/track/actions/47
jmayer: haven't made progress on best practices
... is question of what good practices for passively vs, actively collected info.
aleecia: still valuable but not get into next poublication
<npdoty> action-47 due 3/10
<trackbot> ACTION-47 Write discussion on best practices for 3.6.1.2.1 due date now 3/10
<npdoty> action-68?
<trackbot> ACTION-68 -- Justin Brookman to provide text on ISSUE-54 -- due 2012-02-01 -- OPEN
<trackbot> http://www.w3.org/2011/tracking-protection/track/actions/68
<npdoty> issue-54?
<trackbot> ISSUE-54 -- Can first party provide targeting based on registration information even while sending DNT -- open
<trackbot> http://www.w3.org/2011/tracking-protection/track/issues/54
issue 68?
<aleecia_> https://www.w3.org/2011/tracking-protection/track/actions/overdue
issue-68 changed to pending review
<WileyS> Registration information would be considered "out of band consent"
Tom takes action item to work on it
<npdoty> I didn't interpret Justin's proposal as out-of-band consent for tracking
<npdoty> ACTION: lowenthal to draft alternate proposal on first-party targeting based on registration information [recorded in http://www.w3.org/2012/02/29-dnt-minutes.html#action01]
<trackbot> Created ACTION-137 - Draft alternate proposal on first-party targeting based on registration information [on Thomas Lowenthal - due 2012-03-07].
<npdoty> action-137 due 3/10
<trackbot> ACTION-137 Draft alternate proposal on first-party targeting based on registration information due date now 3/10
<npdoty> action-101?
<trackbot> ACTION-101 -- John Simpson to revise Issue-6 based on feedback on the mailing list -- due 2012-02-22 -- OPEN
<trackbot> http://www.w3.org/2011/tracking-protection/track/actions/101
<WileyS> Tom and Justin, could you please loop me into the registration data conversation (obviously a big issue for Yahoo!)
<WileyS> ?
johnsimpson: yes, sent out some text on this
<justin> Correct npdoty --- first-party data is to me outside the scope of DNT, so I'm OK with parties using it in a third-party context
johnsimpson: but Dave Singer suggested cutting down the goals/introductions for both documents
... not put my text in the Compliance doc and cut down the TPE introduction
<WileyS> I'm open to it - I'll write the privacy interests paragraph
<aleecia_> Roy is saying he wants something in
Roy: opposed to removing the why we are doing this
<WileyS> Agree we should have "something" there - but smaller text that attempts to avoid controversial elements in that description
one paragraph from shane
<WileyS> Roy, Fair?
one from john
<fielding> I said that I want to keep the introduction because people who are not in this WG haven't the faintest clue what we are doing and why, as is abundantly clear from the latest PR flash. I am happy to edit it to reflect the group's goals.
<WileyS> Roy, great - then I believe we're all on the same page - simply editting/cutting down the current text.
<rigo> Shane, the intention of my democracy para was just of explanatory nature. I have no issue whatsoever if this is going into an explanatory notice
<aleecia_> thanks for offering Roy, but it looks like we have this covered
<jmayer> roy, we don't need agreement on "the group's goals," we need agreement on a standard
<fielding> we need agreement on what "do not track" means in the TPE spec.
do it for the com pliance document
<rigo> Roy, it is already unclear what meaning means here
<rigo> so I'm not really enthusiastic about your requirement
<npdoty> aleecia: start with the compliance doc, and if it works, we can use something similar in the TPE doc
<rigo> we could try a "meaning" definition on a explanatory note without normative value
action 104 won't make it
<npdoty> action-109?
<trackbot> ACTION-109 -- Adrian Bateman to draft text for issue-54: Can first party provide targeting based on registration information even while sending DNT -- due 2012-02-13 -- OPEN
<trackbot> http://www.w3.org/2011/tracking-protection/track/actions/109
<npdoty> andyzei, info on adrian?
action-109
<npdoty> action-120?
<trackbot> ACTION-120 -- Shane Wiley to write a proposal on web-wide exception API (for ISSUE-113) (with npdoty) -- due 2012-02-15 -- OPEN
<trackbot> http://www.w3.org/2011/tracking-protection/track/actions/120
action-120
<alex> I am interested
<WileyS> Thank you Alex!
probably won't make it into draft
<npdoty> alex, can I re-assign this action to you?
<WileyS> You did this!
<WileyS> Aleecia - you already wrote the text. :-)
Action-121: assigned now to Aleecia
<alex> Please do
<WileyS> Thank you!
<tl> action-121?
<trackbot> ACTION-121 -- Shane Wiley to re-write language on issue-57 proposal to avoid "opt out" language -- due 2012-02-15 -- OPEN
<trackbot> http://www.w3.org/2011/tracking-protection/track/actions/121
<andyzei> npdoty, i'll try to track him down
<andyzei> npdoty, he may be DNT:1 right now
Action-126: Clean up TPE on site-specific sections. not sure what to be cleaned up. Close..
<npdoty> fielding, it was your suggestion to clean it up / re-write
<fielding> it just needs editorial work in terms of writing
<dsinger> yes, we'll keep cleaning up...
assume that David and Roy will do necessary
<fielding> and I think npdoty was going to add more to the javascript?
<npdoty> with Tom and Andy I think we'll send out updates to the JS API proposal later today
Turning to discuss compliance document
<aleecia_> http://www.w3.org/2011/tracking-protection/drafts/tracking-compliance.html
aleecia: Does not necessarily have text from every issue yet
... if you've written text and it isn't in here, please help by sending a note to us / the list
... will have doodle poll n who has contributed text. list name as you want it for credit
<aleecia_> 1. Introduction
<aleecia_> This specification defines the meaning of a Do Not Track preference and sets out practices for websites and other online companies to comply with this preference.
objections to intro?
<WileyS> Agreed
holding off on 2.1 for this week
<fielding> This would be objections to WD publication, right? Not a consensus call on the text?
<fielding> thanks
aleecia: can we live here with these options?
3.2 are fair representation of options
<aleecia_> 3.3.1 Definitions
<aleecia_> A "first party" is any party, in a specific network interaction, that can infer with high probability that the user knowingly and intentionally communicated with it. Otherwise, a party is a third party.
<aleecia_> A "third party" is any party, in a specific network interaction, that cannot infer with high probability that the user knowingly and intentionally communicated with it.
<WileyS> Incorrect status - there is an alternate definition that Amy and I put together
<fielding> no objection to publish, but 3.3.1 cannot be implemented
<aleecia_> 3.3.1 -- draft text from Amy on dlist
shane: 3.3.1 is still under duscussion
<rigo> why don't we mark that in the Specification?
<aleecia_> Roy ok to publish as-is, but thinks it cannot be implemented
roy: don't think it can be implemented
looks like we don't have consensus
<aleecia_> 3.3.2.1 Overview
<npdoty> WileyS, is this the alternate definition for 3.3.1? http://www.w3.org/mid/81152EDFE766CB4692EA39AECD2AA5B60F5D330E@TK5EX14MBXC296.redmond.corp.microsoft.com
tom: asks if there are any other options
<ninjamarnau> maybe we could mark it as an option?
<aleecia_> 3.3.2.2 Common Examples and Use Cases
is an option and needs a box
<aleecia_> 3.3.2.3 Multiple First Parties
<aleecia_> There will almost always be only one party that the average user would expect to communicate with: the provider of the website the user has visited. But, in rare cases, users may expect that a website is provided by more than one party. For example, suppose Example Sports, a well known sports league, collaborates with Example Streaming, a well known streaming video website, to provide content at www.examplesportsonexamplestreaming.com. The website is prominent
<aleecia_> advertised and branded as being provided by both Example Sports and Example Streaming. An ordinary user who visits the website may recognize that it is operated by both Example Sports and Example Streaming.
<aleecia_> Note: non-controv but still open?
<fielding> which section?
<WileyS> Depends on the ultimate defintion of 1st party
aleecia: heard no objections to multiple first parties
<WileyS> Co-branded Web Site
<aleecia_> not branding related
<WileyS> This site brought to you by Company X and Company Y - with links to both party's privacy policies and TOS
need to have interacted with the site before it can be first party
aleecia: can't close but low controversy
<aleecia_> 3.3.2.4.1 Examples and Use Cases
aleecia: operator of domain makes sens as 1st party
<fielding> yep, close
aleecia: general direction seems noncontrovesial, working on details
<aleecia_> General direction seems fairly non-contra but details oaround edges still to agree
<aleecia_> co-branded websites, microsite: example to add
<dsriedel> We call this "Advertorial"
<justin> +justin
<aleecia_> Justin, could you type in which example you're disagreeing on?
shane: point out other valid use case, co-branded websites, microsite often in a contest
... often carry links to both parties privacy policy and TOS
<WileyS> Will do
alex: joint ventures may need to be considered
<WileyS> Not easy
<justin> This is a different take on branding.
justin: seems like trying to cater to nonexistence use case..
<aleecia_> 3.4 Network Interaction
<aleecia_> 3.4.1 Definition
<aleecia_> A "network interaction" is an HTTP request and response, or any other set of logically related network traffic.
<aleecia_> 3.4.2 Non-Normative Discussion
<aleecia_> Determination of a party's status is limited to a single interaction because a party's status may be affected by time, context, or any other factor that influences user expectations.
<laurengelman> but these are all related. how broadly you decide pepsi or doritos might affect how people feel about this.
<aleecia_> note: concern with sequence of actions to load a page.
<WileyS> Aleecia, sent multi-first party example to your email
<tl> What did Roy just say?
roy: concerned that should be a "se quence"
aleecia: might need to reopen
<fielding> The problem is that each interaction has a separate first-party unless you discuss all the interactions as a group.
<aleecia_> 3.5 Transactional data
<aleecia_> Transactional data is information about the user's interactions with various websites, services, or widgets which could be used to create a record of a user’s system information, online communications, transactions and other activities, including websites visited, pages and ads viewed, purchases made, etc.
no concerns raisd
<aleecia_> 3.6 Data collection, retention, use, and sharing
<aleecia_> A party "collects" data if the data comes within its control.
<aleecia_> A party "retains" data if data remains within a party's control.
<aleecia_> A party "uses" data if the party processes the data for any purpose other than storage.
<aleecia_> A party "shares" data if the party enables another party to collect the data.
<aleecia_> The definitions of collection, retention, use, and sharing are drafted expansively so as to comprehensively cover a party's user-information practices. These definitions do not require a party's intent; a party may inadvertently collect, retain, use, or share data. The definition of collection includes information that a party did not cause to be transmitted, such as protocol headers.
<npdoty> I think we've been using these definitions pretty successfully in discussion
<aleecia_> 3.7 Tracking
<aleecia_> Tracking is the collection or use of user data via either a unique identifier or a correlated set of data points being used to approximate a unique identifier, in a context other than "first party" as defined in this document. This includes:
<aleecia_> a party collecting data across multiple websites, even if it is a first party in one or more (but not all) of the multiple contexts
<aleecia_> a third party collecting data on a given website
<aleecia_> a first party sharing user data collected from a DNT-on user with third parties "after the fact".
<aleecia_> Examples of tracking use cases include:
<aleecia_> personalized advertising
<aleecia_> cross-site analytics or market research that has not been de-identified
<aleecia_> automatic preference sharing by social applications
<dsinger> 3.7 uses the undefined term "user data" which is a problem
<justin> Or whether we need a definition of tracking or x-site tracking AT ALL
<aleecia_> notes: user data not defined, tracking or cross-site tracking?
<aleecia_> or need at all?
<npdoty> scribenick: npdoty
<fielding> FWIW, I am fine not using cross-site tracking if we have a decent definition of tracking
<aleecia_> 3.8 Consent
<aleecia_> The term “affirmative, informed consent” is used throughout this document. While this terminology may ultimately be modified, some options for explaining the underlying idea are presented below:
<aleecia_> Option:
<aleecia_> "Affirmative, Informed Consent to be Tracked" means consent given by an affirmative action such as clicking a consent box in response to a clear and prominent request to ignore a "Do Not Track" setting that is distinct and separate from any other notifications or requested permissions.
<aleecia_> "Affirmative, Informed Consent to be Tracked" has been obtained when a mechanism to provide for or facilitate the acquisition and storage of permission to ignore the header has been made available to the user and the user has meaningfully interacted with the mechanism in a way that makes clear her intent to grant this permission.
aleecia: anything else needed for 3.7? (nothing raised)
<aleecia_> No definition, leaving the definition of consent to local rules.
<aleecia_> box in blue for options
aleecia: need to box these for options, but are there other options beyond these three?
<aleecia_> 3.9 Meaningful Interaction
<aleecia_> "Meaningful Interaction" with a widget or window initially presented on a third-party basis means affirmatively clicking on such content (except to stop, close, silence, or otherwise impair the rendering of such content) or otherwise engaging with the content in a manner that would reasonably be interpreted to express an intention to interact with that party. A user merely moving her cursor across the widget or window does not constitute "meaningful interactio
<johnsimpson> I cannot get back into call!!
<fielding> hoping that 3.8 is consistent with EU policies
<fielding> just a hope, please
<aleecia_> note on 3.8 that EU matters
<ninjamarnau> not 100 %
<npdoty_> I think the first option would address issue-69
<aleecia_> issue-69 Should the spec say anything about minimal notice? (ie. don't bury in a privacy policy)
<npdoty_> "informed consent" often brings those two points (notice and consent) together
<justin> Option 1 says "yes" to 69, Option 3 says "no"
aleecia: anything in particular on 3.9? "meaningful interaction"
<aleecia_> note as low contra and not closed
aleecia: propose as low-controversy
"affirmatively clicking" vs "clicking"
<tl> No.
<fielding> what does it mean?
<fielding> intentional?
tl: an affirmative interaction, rather than a dismissal or removal
<WileyS> Vote for just "clicking"
<fielding> and "clicking" is UI specific
<rigo> we need a user originated trigger-event
<johnsimpson> Tom: keep affirmatively, not a dismissive interaction, like it in there somewhere
<justin> I drafted it, I'm fine taking out affirmative.
<justin> ly
<dsinger> 'clicking' is an issue. Voice input gets a free pass?
<fielding> but no objection to publish
<rigo> as opposed to script triggered actions
<scribe> scribenick: johnsimpson
<aleecia_> affirmatively interacting with content?
<rigo> user input is good!
<justin> You could move "affirmatively" to right in front of "engaging" if you like
<fielding> I suggest we just note this as "in progress" for now
<justin> That would I think solve everyone's problems.
<aleecia_> note: wording not firm, but direction is non-contro
<npdoty> dsinger: could look at HTML and their definitions of what counts as "user input"
aleecia: note wording is not final, direction is good
<rigo> dsinger: why don't we go looking into the HTML5 Specification looking what they say about "user interaction"
<aleecia_> 3.10 User
<aleecia_> A user is an individual human. When user-agent software accesses online resources, whether or not the user understands or has specific knowledge of a particular request, that request is made "by" the user.
aleecia: looking quickly at othjer specs would be good
<npdoty> dsinger, are you volunteering for that action?
<dsinger> dang. I should keep my mouth shut. yes.
<aleecia_> 3.11 User Agent
<aleecia_> This specification uses the term user agent to refer to any of the various client programs capable of initiating HTTP requests, including but not limited to browsers, spiders (web-based robots), command-line tools, native applications, and mobile apps [HTTP11].
<aleecia_> 3.10, 3.11 closed and happy
<npdoty> ACTION: singer to investigate definitions of user action/input in HTML5 or similar specs [recorded in http://www.w3.org/2012/02/29-dnt-minutes.html#action02]
<trackbot> Created ACTION-138 - Investigate definitions of user action/input in HTML5 or similar specs [on David Singer - due 2012-03-07].
<npdoty> scribenick: justin
<tl> ACTION: lowenthal to Improve wording of 3.9 "Meaningful Interaction" to avoid "affirmatively clicking" and make sure that "clicking" is replaced with something more general. [recorded in http://www.w3.org/2012/02/29-dnt-minutes.html#action03]
<trackbot> Created ACTION-139 - Improve wording of 3.9 "Meaningful Interaction" to avoid "affirmatively clicking" and make sure that "clicking" is replaced with something more general. [on Thomas Lowenthal - due 2012-03-07].
<npdoty> http://www.w3.org/2011/tracking-protection/drafts/tracking-dnt.html
matthias: we're going through the TPE spec to make sure everyone's cool with its going out as SPWD
<johnsimpson> lost call again
<johnsimpson> i think somebody's working on put damn phone lines
dsinger: outlining recent changes
<npdoty> overview of the changes is in email here http://www.w3.org/mid/4F4E36EA.7020909@zurich.ibm.com
<jchester2> Can we discuss how the Community Group's input will be addressed as this is published?
<fielding> looks much nicer
matthias: happy the draft is stabilizing, less questions, big question is whether we have response header, well-known URI, or both
<dsinger> http://www.w3.org/2011/tracking-protection/drafts/tracking-dnt.html
matthias: if we don't get much input, we're putting this out on Thursday, and we'll keep discussing response header and/or URI issue
<dsinger> Dave is volunteering on the intro
<aleecia_> (we'll be publishing the two docs together)
matthias: tweaked intro to make less industry-centric.
<aleecia_> (so not tomorrow :-)
<jchester2> plus incorporate what the community group suggested
dsinger: I'm working to shorten and mesh with new compliance intro
<npdoty> +1 on publishing them together
aleecia: complaince won't be ready until next week, and we should wait to put them both out together
justin: agree we need to publish them together
<fielding> jchester2, perhaps you could paste the community group input specific to the intro directly in the WG mailing list?
<aleecia_> This reminds me: I need to add a note at the start of the Compliance doc that we have feedback we have not responded to from the WG. Ideally that's in both docs as a note.
<npdoty> ACTION: singer to work on updates to TPE introduction (harmonize with Shane/John) [recorded in http://www.w3.org/2012/02/29-dnt-minutes.html#action04]
<trackbot> Created ACTION-140 - Work on updates to TPE introduction (harmonize with Shane/John) [on David Singer - due 2012-03-07].
<Zakim> npdoty, you wanted to ask about "cross-site"
<fielding> actually, cross-site was removed since the last WD
jchester2: agree that intro needs to be more balanced than it is now
<aleecia_> and may go back in at some point
<aleecia_> I'd be happy with a note to that effect
<npdoty> fielding, removed from the text but then added in the introduction? (and now we have an explicit issue noted)
<aleecia_> That it's a live discussion
<rigo> roy, it's still in the introduction
<rigo> +1 to let David try
<aleecia_> +1
dsinger: intro should just say what the spec does
<fielding> it was in the FPWD
<aleecia_> argue about text when it exists
jchester: agreed
<rigo> +1 to write a companion report
dsinger: we could add a companion report which would be a lot of work
<fielding> The spec is supposed to be readable by people not in the WG
<npdoty> +1 on companion doc, potentially
<aleecia_> let's see David's text next week
<aleecia_> 3. Determining User Preference
<aleecia_> The goal of this protocol is to allow a user to express their personal preference regarding tracking to each server and web application that they communicate with via HTTP, thereby allowing each service to either adjust their behavior to meet the user's expectations or reach a separate agreement with the user to satisfy all parties.
<aleecia_> Key to that notion of expression is that it must reflect the user's preference, not the preference of some institutional or network-imposed mechanism outside the user's control. Although some controlled network environments, such as public access terminals or managed corporate intranets, might impose restrictions on the use or configuration of installed user agents, such that a user might only have access to user agents with a predetermined preference enabled,
<aleecia_> user is at least able to choose whether to make use of those user agents. In contrast, if a user brings their own Web-enabled device to a library or cafe with wireless Internet access, the expectation will be that their chosen user agent and personal preferences regarding Web site behavior will not be altered by the network environment, aside from blanket limitations on what sites can or cannot be accessed through that network.
<justin_> rigo and npdoty, I don't think dsinger actually wanted a companion report :)
<aleecia_> The remainder of this specification defines the protocol in terms of whether a tracking preference is enabled or not enabled. We do not specify how that preference is enabled: each implementation is responsible for determining the user experience by which this preference is enabled.
<aleecia_> For example, a user might select a check-box in their user agent's configuration, install a plug-in or extension that is specifically designed to add a tracking preference expression, or make a choice for privacy that then implicitly includes a tracking preference (e.g., Privacy settings: high). Likewise, a user might install or configure a proxy to add the expression to their own outgoing requests. For each of these cases, we say that a tracking preference is
<aleecia_> enabled.
<aleecia_> can we note we don't do UI here?
<aleecia_> please?
<johnsimpson> are we considering David's text to replace current into?
<aleecia_> next week, yes
<aleecia_> David's still editing
<WileyS> Should we note the open issue on site-specific exception header value?
<fielding> aleecia_, where?
<aleecia_> section 3, para starts: "For example, a user might select a check-box in their user agent's configuration, ..."
tl: concerns about statement that user isn't expressing preference [but he faded out so I missed the middle]
<aleecia_> I'd like to end that with a note that we don't do UI, as per charter.
<fielding> but that's just an example
tl: second bullet of Section 4 is wrong
<npdoty> you're suggesting add another bullet: "the user is not expressing a preference"
<dsinger> the user agent does implement the protocol but there is no user preference expressed.
<aleecia_> I have no problem with the text as it is for 3 - would just like to add a quick "don't shoot!" :-)
<tl> at this time.
<aleecia_> we're discussing:
<aleecia_> If a tracking preference is not enabled, then no preference is expressed by this protocol. This means that no expression is sent for each of the following cases:
<aleecia_> the user agent does not implement this protocol; or
<aleecia_> the user agent does implement the protocol but the user has not yet enabled a preference.
<rigo> I wonder about the legal difference between both wordings
<aleecia_> why is that, Tom?
<aleecia_> not following
<aleecia_> That would be good to make explicit!
<aleecia_> …meh?
<aleecia_> (not sure a Y!-specific don't express a pref is interesting)
discussion about how specific the expression of preference needs to be (I think)
<rigo> you're talking the wrong horizon, It is not the user, but what the server understands
<dsinger> the user agent does implement the protocol but the user does not wish to indicate a preference
<aleecia_> Tom, could you type some text here of what you'd like?
<aleecia_> lovely
agreement on new third bullet to be added
<aleecia_> different section.
wileyS: can we note that there is open discussion around different header value for exceptions
<npdoty> WileyS is referring to ISSUE-111, which is included below
everybody_else: move it below
<aleecia_> "see section 6"?
<aleecia_> x-ref to it?
<aleecia_> If it's hard to read, that's a good reason to x-ref but not duplicate
<dsinger> but we're talking here about the cases when nothing is sent...
<fielding> there was an issue marker there a couple days ago
<aleecia_> putting issue in sounds good
<fielding> was it commented out?
consensus on just adding an issue/x-ref
<aleecia_> thanks, Shane!
<schunter> I´´ll take this action
<background meowing>
<npdoty> issue-111
<dsinger> issue-111?
<trackbot> ISSUE-111 -- Different DNT value to signify existence of site-specific exception -- pending review
<trackbot> http://www.w3.org/2011/tracking-protection/track/issues/111
<aleecia_> so section 4: add link to issue-111, add 3rd bullet with David's text plus "at this time"
<aleecia_> ?
<npdoty> dsinger: will edit doc so all text is in a subsection or in a section without subsections
rigo: concerned about adding third bullet from a legal perspective
<fielding> actually, these are instructions to user agent implementers
<aleecia_> disagree
<tl> 'Zactly. +1 fielding.
rigo: need to be clear that signal comes from service instead of focus on user intent
<tl> aleecia_, we define what it looks like at the user end, and that inherently defines what the server can understand?
<aleecia_> DNT is a user preference at core
<aleecia_> that's what makes DNT different
<tl> Exactly, and we're making clear *what* preference we're seeing?
<ninjamarnau> the two bullets list cases in non-normative text
<aleecia_> oh: Rigo's *only* talking about the null case
<aleecia_> then I agree with him, but think the text is fine
<aleecia_> …and there I disagree again
fielding: we had a long discussion about this, these bullets are to give needed guidance to implementers
<aleecia_> ;-)
rigo: then make clear what this is supposed to be doing
<rigo> make clear that you now are talking about user agent guidance
<npdoty> rigo, do you want to draft some text that would address your concern and make it clear that this is for user agents rather than servers?
rigo tasked with adding language to address his concerns
aleecia: we need this text and we need more of it to give needed guidance
<npdoty> ACTION: rigo to draft text on clarity that this is for user agents (addressing his concern) [recorded in http://www.w3.org/2012/02/29-dnt-minutes.html#action05]
<trackbot> Created ACTION-141 - Draft text on clarity that this is for user agents (addressing his concern) [on Rigo Wenning - due 2012-03-07].
<aleecia_> Now discussing: 4.1 DNT Header Field for HTTP Requests
<npdoty> backlash?
<fielding> just to avoid conflict with JSON embedding
<fielding> typo, thanks nick
<aleecia_> of note: Jonathan believes "A user agent must not send the DNT header field if a tracking preference is not enabled" is not closed
schunter: looking for comments on 4.1
<aleecia_> (I'm not sure if he is correct or not, but he raised issues)
npdoty: can we just close this and exclude the JSON characters?
<aleecia_> +1 on closing JSON
<dsinger> (issue 111 is marked here as open, but in the issue database as pending review. which is right?)
<tl> +1
<aleecia_> close issue-126?
consensus on closing 126
<npdoty> close issue-126
<trackbot> ISSUE-126 DNT-extension syntax includes characters not safe to embed in JSON closed
dsinger: one issue is marked as pending review here and open elsewhere . . . which is right?
<aleecia_> perhaps we could add the 2 different proposals?
<aleecia_> +1 to Nick
npdoty: perhaps we can option-box these
<WileyS> T-minus 4 minutes to end of meeting. Should someone review work to be completed between now and next meeting?
<aleecia_> Shane: I'll send to the mailing list
<WileyS> Thank you Aleecia!
<aleecia_> And I'm sorry this hasn't been as organized as I would have liked. We've all been a bit busy for some reason...
schunter: leaving issue-84 and others as open
<npdoty> +1 on "We've all been a bit busy for some reason..."
<aleecia_> 4.3 Plug-In APIs
<aleecia_> User agents often include user-installable component parts, commonly known as plug-ins or browser extensions, that are capable of making their own network requests. From the user's perspective, these components are considered part of the user agent and thus ought to respect the user's configuration of a tracking preference. However, plug-ins do not normally have read access to the browser configuration. Therefore, we will define here various mechanisms for
<aleecia_> communicating the tracking preference via common plug-in APIs.
4.3 --- no comments from group
<aleecia_> 4.4 Tracking Preference Expressed in Other Protocols
<aleecia_> A user's tracking preference is intended to apply in general, regardless of the protocols being used for Internet communication. The protocol expressed here is specific to HTTP communication; however, the semantics are not restricted to use in HTTP; the same semantics may be carried by other protocols, either in future revisions of this specification, or in other specifications.
<aleecia_> When it is known that the user's preference is for no tracking, compliant services are still required to honor that preference, even if other protocols are used. For example, re-directing to another protocol in order to avoid receipt of the header is not compliant.
<aleecia_> could add, though not sure where off hand
<npdoty> looks good to me, dsinger
<rigo> +1 to 4.4
<aleecia_> David, we could add though off hand i'm not sure where
<tl> +1
<aleecia_> out of time.
dsinger: second para for 4.4 should be in compliance
<fielding> does that mean we close the issue 108?
<justin_> FWIW, we have a similar para in compliance already, but we should probably make sure they are precisely in accord
<aleecia_> +1 on both
<npdoty> +1 for publish both and ask for feedback on both from implementers
<aleecia_> and then we're out of time
<WileyS> Great meeting - thank you everyone - have a great day!
schunter: looking for feedback if anyone objects to waiting to publish together
<johnsimpson> +1 publish both
<aleecia_> after we publish
<dsinger> notes that I re-ordered the text in 5.2, and Tom is checking I didn't break anything
<aleecia_> we'll need to do timelines after we get things out, but we're not there yet
<aleecia_> call over time
<flashes lights on and off>
<fielding> aleecia_, yes
<aleecia_> <3
schunter: looking for feedback on header/URI issue
<schunter> q
<fielding> I think we closed 108
<npdoty> thanks, good progress!