<trackbot> Date: 02 April 2014

<Chris_IAB> I just joined

<justin> ninja, do we have a scribe yet?

<Chris_IAB> I'm on a private #

<walter> am on Skype, can try

<walter> but it will not necessarily be pretty

<justin> Yeah, this will be a tough one to scribe --- high margin of error will be tolerated.

<walter> justin: and if not you may take over :-P

<walter> justin: we're moving to last call

<walter> there is a request to let Roy walk us through

<walter> we will watch the queue for questions

<marc> 202 265-2736 is Marc

<walter> people may interupt

<walter> but for the most part Roy will walk us through the document

<walter> in the coming week we will have time to ask questions

<walter> and Roy will have an opportunity to incorporate clarifications

<walter> after next week we will go into a two week period

<walter> in which folks can come forward to object

<walter> wseltzer: I just want to echo Justin's call to remind people that the last call is that the group consensus is documented for wider review

<walter> If there is a new technical issue that we haven't addressed

<Chris_IAB> so the standard is consensus from the group?

<walter> That should block this document

<walter> before going out for last call

<fielding> Following the diff : http://www.w3.org/2011/tracking-protection/drafts/diffs/TPE-WD6-to-20140402.html

TPE Walkthrough

<ninja> http://www.w3.org/2011/tracking-protection/drafts/diffs/TPE-WD6-to-20140402.html diff

<walter> fielding: As you all know I am excited about a walkthrough of a document you can read

<walter> I will quickly describe the changes since January

<marc> I think a section-by-section review would be helpful.

<walter> Carl_Cargill: Would you prefer to know specific issues?

<walter> fielding: I am not going to read the document and open up for comments afterwards

<Ari> +1 to marc, a section by section would be helpful

<walter> who is speaking now?

<walter> oh, justin I suppose

<wseltzer> Chris_IAB, the chairs will call for consensus that the document is ready to publish

<walter> justin: there are people below your technical expertise so it would helpful if you were to describe in more detail

<walter> fielding: we'll start with the introduction

<walter> now it is a fairly broad introduction

<walter> my preference would be to replace that with the terminology section

<walter> for the most part it has been a placeholder

<walter> at this point I should be rethinking the introduction

<walter> it is clearly editorial now

<walter> it is not affected by the last call status so much

<walter> justin: are you going to change it during last call?

<walter> fielding: it should be editorial and it could go after last call

<walter> so that's the purpose of the introduction

<walter> the notational concepts section is usually a reference to IETF documents, but now that the HBP stuff is approved

<walter> which means that there will be a new set of RFCs about HTTP coming up

<walter> which will be more specific

<walter> I did make a number of changes to support that in this draft

<marc> Does the new RFCs change the substance or requirements in any way? I didn't follow that.

<walter> the terminology section is the unusual bit here

<walter> there are some small changes

<JC> Does he mean definitions?

<walter> section 2.3 has added the definitions of tracking and context

<walter> network interaction and user action

<justin> JC, yes definitions. It's called "terminology in the doc"

<walter> [inaudible]

<walter> justin: marc asked whether the RFC's changed the substance of the requirements

<walter> is there something magic about those?

<walter> fielding: no, DNT is pretty much self-contained

<walter> it is more editorial style

<walter> it is just easier to specify the requirements

<walter> [piano music]

<walter> we added the definitions of party

<walter> fielding: you're breaking up

<walter> the use of the word context in the definition of first party

<walter> yes, very much

we had a postponed question to satisfy the QA Framework: Specification Guidelines, which is also about specifying conformance for particular product types

<walter> editorially I'd prefer it to be in the introduction, but for the working group it is fine now

I think it might be that fielding's change already fixes that for us; I suspect the guidelines are similar

http://www.w3.org/TR/qaframe-spec/#specifying-conformance

<marc> Roy, why would you prefer the terminology to be in the introduction?

<walter> What requirements are going to be on the user agents

<walter> fielding: because it reads better

<walter> purely for editorial reasonds

<walter> reasons

<walter> I have changed a number of things that are editorial from my perspective

<walter> with the exception of plug-in

<walter> I am not sure how I should describe this other than to have a look at the diffs

<walter> I have mostly moved things around

<walter> It is important to read through this section

<marc> Please specify the section again. Thanks.

<walter> Because it was the most spaghetti of the post-WG review

<walter> Section 4 is about expressing a tracking preference

<walter> there are three different ways

<marc> What is the section with the "most speghetti?"

marc, fielding was referring to 3. Determining the User Preference; now Section 4

<walter> marc: 4

<walter> [inaudible]

<walter> I made changes to simplify it

<walter> Section 4.2

<walter> The DNT header field for HTTP requests

fielding: would prefer not to have separate language in the table, but instead refer directly to definitions from terminology

<walter> which defines the header field that the user would send

<walter> So it defines the syntax of the header field

fielding: but that change would't change the technology

<walter> What I changed is that I moved parts to the end

<walter> There used to be a general requirement

<walter> and then specific requirements for UAs

<walter> I split that into three paragraphfs

<walter> that are disjointed

<walter> only one is going to be true at a time

<walter> and after that I tried to clarifiy

<walter> So it is just a way of phrasing it

thanks, I think that does make it easier for implementers to read/understand

<walter> [silence]

<walter> Section 4.3 is a Javascript property

<walter> The purpose is that a script can determine what the current DNT value would be sent to the document origin of the page or the script

<walter> it is a method for making it known to scripts that they should not do things that are tantamount to tracking

<walter> I do not think there is anything new here

<walter> There was a section 4.4. on plug-in APIs

<walter> We decided that there is no way to standardise them

<walter> I decided to remove that and move it to the section on user preferences

<walter> Section 4.4 now is the protocols

<walter> It is simply the statement that DNT is meant for all protocols

but when you moved that Plugin section, you also created a new requirement, rather than leaving it unspecified as before (per email)

<walter> but we only do HTTP for now

<walter> I did simplify the 5. overview

<walter> summarizing all requirements in a single sentence was a bad plan

<walter> I did move it to the summary of requirements

<walter> 1

<walter> In 5.2 we described what should be included or not

<walter> We removed the option setting for issue boxes

<walter> [breaking up again]

<walter> [silence]

<walter> npdoty: if you would be so kind to take over...

<scribe> scribenick: npdoty

<walter> ninja: We are not absolutely clear what 'you' means, could you give a use case?

ninja: discussing with chairs, not sure about the use of tracking status value "U"

<walter> fielding: there is a use case furthert in the document

<walter> npdoty: please do, yes

fielding: there is a use case, the user accesses the site and sees that they've previously given prior consent

<walter> fielding: it is for the user to retract the status

fielding: but then the user changes that permission

<justin> scribenick: npdoty

fielding: the site, in responding to the form request, can send Tk: U to indicate that the UA should clear its cache of the tracking status

ninja: should we add use case text to the spec?

fielding: we could do that for all values, but requires writing new text

<fielding> sec 5.3.3

fielding: 5.3.3 Indicating an Interactive Status Change already describes it, but in a separate section
... we could define the Tk header field or resource first, and then the status values
... it would mix up the diffs a lot, but wouldn't change content, just ordering

<justin> Not necessary in my opinion, but others may disagree.

fielding: so could do at the end, but not earlier because it might confuse people following my changes
... 5.2.1 has a list of the current values, doesn't allow for extensions (beyond writing new versions of the standard)
... if people are aware that this list of categories would increase in the future, we could proactively add extensionality

<JackHobaugh> Yes, we might want to add an “R” value :-)

fielding: "!" for under construction, don't rely on the claims
... "?" dynamic, indicates to the user agent that the tracking status is resource specific, in the Tk header or resource-specific tracking status
... expect this to be uncommon
... "N" means not tracking, referring to the definition of tracking; "T" means tracking
... "C" indicates that the server believes it has the user's consent
... a link to find out more; changed the name from "edit" to "config" to be more consistent with other link relations
... "P" the server doesn't know if it has consent, but won't do any tracking unless it has that consent
... "D" server unable to unwilling to respect the tracking preference
... ... for example, if user agents or intermediaries are non-conforming or compelled for some reason to disregard

<walter> who is speaking now?

WileyS: note on 5.2.8, was that part of Call for Objection?

fielding: yes.
... probably not a cut/paste because of an editorial change

<walter> oh, it's probably Shane

fielding: don't remember the exact change, but don't expect it's large

<ninja> "Note: This specification was written assuming that the D tracking status value would only be used in situations that can be adequately described to users as an exception to normal behavior. If this turns out not to be the case, either the logic that is leading to the D signal may need re-examination, or this specification, or both."

WileyS: the language seems stronger than I remembered; "misleading", for example

<ninja> from ISSUE 197

<fielding> issue-197?

<trackbot> issue-197 -- How do we notify the user why a Disregard signal is received? -- pending review

<trackbot> http://www.w3.org/2011/tracking-protection/track/issues/197

WileyS: will go back and review

<sidstamm> WileyS: are you thinking of this result? http://lists.w3.org/Archives/Public/public-tracking/2014Jan/0099.html

fielding refers to commit logs.

<fielding> This specification was written assuming that the D tracking status value would only be used in situations that can be adequately described to users as an exception to normal behavior. If this turns out not to be the case, either the logic that is leading to the D signal may need re-examination, or this specification, or both.

<justin> I don't see the word misleading.

<sidstamm> WileyS: right, right hand side

<mecallahan> zakim mecallahan is 213239

WileyS: we're good, I was reading the old text on the left-hand side; the text on the right-hand side is what I expected

<fielding> now it says: This specification is written with an assumption that the D tracking status value would only be used in situations that can be adequately described to users as an exception to normal behavior. If this turns out not to be the case, either the server's decision to send the D signal needs re-examination, or this specification, or both.

"with an assumption" rather than the active participle

fielding: the Tk header field, if the server wants to response separately on every request, or if the value changes request-by-request
... can give a status ID, so that the user can then look up the full tracking-status representation
... 5.3.3 was the "U" flag interactively; not sure if this will be used in practice
... 5.4 describes the tracking status resource
... no response indicates that the server does not implement the protocol
... site-wide vs. request-specific
... server has space to provide different/individual responses

JC: do we define a specific well-known location, or do servers do that themselves?

<sidstamm> .well-known is the path

fielding: 5.4.1 uses "/.well-known/"

<sidstamm> http://foo.com/.well-known/dnt/

http://tools.ietf.org/html/rfc5785

JC: isn't "well-known" going to be replaced per company? or would we use "w3c"?

<JackHobaugh> For 5.4.1, the removal of “MUST” seems like more than an editorial change. Or is that captured someplace else?

fielding: per rfc 5785, we use the actual path ".well-known"

<WileyS> I believe there is a typo in 5.2.9 - this appears to be a dangling sentence " An origin server MUST NOT send U as a tracking status value anywhere other". Is there something missing on "other 'than....'" or should "other" be "else"?

"MUST send either a successful response containing a machine-readable representation of the site-wide tracking status, as defined below, or a sequence of redirects that leads to such a representation."

<justin> wileys, I think that's just a problem in the diff.

<justin> Doc reads: An origin server MUST NOT send U as a tracking status value anywhere other than a Tk header field that is in response to a state-changing request.

JackHobaugh: the old version had a MUST in 5.4.1, is that removed in the new version?

<justin> http://www.w3.org/2011/tracking-protection/drafts/tracking-dnt.html#TSV-U

<sidstamm> WileyS, that's just cut off, the side-by-side is not showing the whole document

<rvaneijk> it is in the diff: An origin server that receives a valid GET request targeting its site-wide result in either a successful response containing a machine-readable tracking status resource MUST send

fielding: rephrased because origin servers always have resources in REST, but the valid response is what is necessary
... technically it's more accurate, but has the same intended effect

<JackHobaugh> I need to evaluate Roy’s response.

<justin> jackhobaugh, Hopefully that addresses your concern, but if not, please bring to the list for further discussion.

<fielding> 5.4.1: An origin server that receives a valid GET request targeting its site-wide tracking status resource MUST send either a successful response containing a machine-readable representation of the site-wide tracking status, as defined below, or a sequence of redirects that leads to such a representation. Failure to provide access to such a representation implies that the target origin server does not implement this protocol.

fielding: 5.4.3 that tracking status resource checks are not tracked
... 5.4.4 has requirements about caching, behavior has to be consistent with tracking status from the previous 24 hours
... one open comment on this section about phrasing, not integrated

<marc> I'm sorry, I didn't follow that comment Roy.

fielding: chairs, please post to mailing list

<marc> What comment do the Chairs still need to post?

<wseltzer> marc, he was saying there was a chairs' comment not yet integrated

fielding: 5.5 defines the fields in the tracking status representation

<wseltzer> that chairs should re-send if they wanted discussion

fielding: only change is "edit" to "config"
... removed issue boxes regarding compliance and qualifier arrays

[going through properties in the tracking status resource representation]

fielding: compliance indicates an array, but no requirement that the array be present, or particular values
... just a mechanism for carrying that information, for future documents
... qualifiers value, characters are not defined, but could be in a compliance regime

<ninja> marc, the chairs' comment was to rephrase the language in section 5.4.4 It is overly detailed with the 7 days text. http://www.w3.org/2011/tracking-protection/track/actions/446

fielding: controller property an array of URIs, not necessarily to be referenced

<JackHobaugh> For the controller property, why was the MUST replaced with “ought to”?

fielding: same party is a list of domains that are the same as "me" (the responding server)
... changed from MUST to "ought to" because not an interoperability requirement that can be tied to a particular party
... audit property, hasn't changed in some time
... policy property, link to a privacy policy
... config property, a resource that allows the user to change settings themselves
... extensions: additional properties could be added to the JSON object, they shouldn't cause parse failures
... updated to the latest RFC regarding JSON
... rfc7159

anecdote about a whole new RFC number to fix a typo

fielding: status code 409 for tracking required
... just picking which of the status codes seemed most appropriate, generally don't create new ones for applications like DNT
... 5.7 collects use cases for using the tracking status
... ways browsers might use the tracking status, and describing how to do so

<WileyS> At some point someone had requested we move to "User Granted Permission" over "Exception" and I thought the Working Group had accepted that change. Have we not?

fielding: Deployment: since responding to that resource indicates deployment
... defines pre-flight checks, how a user agent might figure out before it accesses whether the protocol is deployed
... could be more use cases, just haven't had time to find them and define them
... can be added to even after Last Call
... but if actual users can write that down, that's even better

<ninja> WileyS: here is the pointer to Adrian's email http://lists.w3.org/Archives/Public/public-tracking/2014Mar/0027.html

fielding: any comments on the edited sections so far?

ninja: haven't updated acknowledgments for a long time, if you'd like your name added (or removed) please let us know

fielding: section 6 briefly as I haven't edited it much: User-Granted Exceptions

<WileyS> Thank you Ninja - I don't find that argument compelling so will raise this again during Last Call.

fielding: define the user-granted exceptions format

<ninja> Chairs have asked to mainly remove old Notes and issue boxes in section 6

fielding: discussion of changing the name, but had a response from Microsoft, happy to leave it as is

<WileyS> We've only had a single implementation so I don't believe we should hold up the standard to move to superior phrase for that reason.

fielding: removed some notes
... correction to refer to window.doNotTrack rather than navigator (per adrian)

ninja: thank you roy, for lots of work and for walking us through

<jeff> Roy++

<jeff> Roy++

<JackHobaugh> Will section 6 be further edited prior to Last Call?

<jeff> great job!!

fielding: any general comments for discussion on the call?

<WileyS> Thank you for the walk-through Roy!

<WileyS> +q

<moneill2> Thanks Roy

WileyS: on use cases, when a server encounters a user agent that doesn't support UGE, why suggest sending a 409 or a disregard response?

fielding: either is certainly acceptable, in that the server can do what it wants, these just define the responses

<walter> WileyS: I don't think that's the reason for the Disregard response

WileyS: can provide a recommended edit.
... think it would be better to do before Last Call

<walter> Also, there is no technical reason to send Disregard for lack of a UGE

<walter> that is a compliance reason

fielding: these sections are not about what the server should do, just what message the server can send back

<walter> for that reason I'd prefer Disregard over 409

WileyS: not sure anyone would ever redirect someone to an error page when sending DNT

fielding: NYT example regarding user-identification/authentication
... if you're *going* to send an error response, this is the one you should send

WileyS: can take to mailing list, hope it won't upset anyone, but could do it in Last Call comments if need be

<rvaneijk> WileyS: curious: if you would not accept a certain browser, would you send 409?

npdoty: in the paywall example, the server might send back 409 with the description of paywall and requirements, etc.

fielding: that was the example, happy to receive more text

<WileyS> Walter - disagree, I could definitely see supporting a server sending back disregard for a browser that isn't fully compliant - with includes supporting UGEs

ninja: any other comments?
... please send any other remarks, comments before the call next wednesday so that we have a chance to discuss

<WileyS> Rob - no, I would send Disregard and give the user other options

[adjourned.]

<jeff> Bye all

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/4.5.1/5./
Succeeded: s/that was/summarizing all requirements in a single sentence was/
Found ScribeNick: npdoty
Found ScribeNick: npdoty
Inferring Scribes: npdoty
Default Present: walter, +1.202.785.aaaa, JackHobaugh, Jeff, Ninja, Mike_Zaneis, hober, SusanIsrael, Peder_Magee, Brooks, Fielding, Joanne, kulick, +1.650.480.aabb, hefferjr, WileyS, MattHayes, Carl_Cargill, rvaneijk, ChrisPedigoOPA, moneill2, Ari, justin, Wendy, +1.917.934.aacc, vinay, [Microsoft], +1.202.265.aadd, npdoty, +1.202.370.aaee, robsherman, Chris_IAB, [Mozilla], marc, dwainberg, schunter, +1.213.239.aaff, mecallahan, vincent
Present: walter +1.202.785.aaaa JackHobaugh Jeff Ninja Mike_Zaneis hober SusanIsrael Peder_Magee Brooks Fielding Joanne kulick +1.650.480.aabb hefferjr WileyS MattHayes Carl_Cargill rvaneijk ChrisPedigoOPA moneill2 Ari justin Wendy +1.917.934.aacc vinay [Microsoft] +1.202.265.aadd npdoty +1.202.370.aaee robsherman Chris_IAB [Mozilla] marc dwainberg schunter +1.213.239.aaff mecallahan vincent

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Found Date: 02 Apr 2014
Guessing minutes URL: http://www.w3.org/2014/04/02-dnt-minutes.html
People with action items: