jmayer: language is about personal preference, with is a value suggested by Mozilla, others by user expectation.
... key to that is user's preference, not set by institution. We talked about SHOULDs, and where institutions SHOULD NOT

<npdoty> +1, I'm not sure I like this institutional language, which I thought was covered by Issue 95

<fielding> The goal of this protocol is to allow a user to express their personal preference regarding cross-site tracking to each server and web application that they communicate with via HTTP, thereby allowing each server to either adjust their behavior to meet the user's expectations or reach a separate agreement with the user to satisfy both parties. Key to that notion of expression is that it must reflect the user's preference, not the preference of some institution

<fielding> network-imposed mechanism outside the user's control.

<fielding> The remainder of this specification defines the protocol in terms of whether DNT is enabled or not enabled. We do not specify how that preference is configured: the user agent is responsible for determining the user experience by which this preference is set.

<fielding> For example, a user might configure their own user agent to tell servers "do not track me cross-site", install a plug-in or extension that is specifically designed to add that expression, or make a choice for privacy that then implicitly includes a tracking preference (e.g., "Privacy settings: high"). For each of these cases, we say that DNT is enabled.

tl: text language in defaults in user agents was agreed on 26th, but may not be in WD. also discussed at f2f, with recommendations for non-user agents

matthias: should be user preference

<npdoty> I'm not sure the text concludes that there shouldn't be a default

<KevinT> point re: mobile apps I would like to raise

jmayer: language doesn't convey what I agree with: "conveys a user preference" isn't what I'd like. If you get DNT:1, you have to honor it regardless if set by institution. Then discussion of what institutions should & shouldn't do.
... you're taking a position of where it can be set

tl: Recall the institutional language is separate from the default language.

<schunter1> Aleecia: tri-value: yes/no/not set.

<npdoty> who wants to take on the action to re-draft that text?

Aleecia: Good discussion on this on mailing list. Suggestion was three-way setting: DNT-1, DNT-0, DNT-unset. Don't think that agreement is captured by language, is important. Would like it to be airtight. Suggest one more round of language edits.

jmayer: language should be one on user agents, and one on institution or proxy. Renaming these issues to be clearer.
... Want to make clear, for what it's worth, don't have my support on issue-4. Don't see it as necessarily about user expression
... without getting into that debate now, let's make that an explicit issue.

<sidstamm> +1 on jmayer's plan of action (though I may not agree with his position)

jmayer: What intermediaries get to do & not do should stay open, but closing issue-4 is ok

<npdoty> does issue-95 cover jmayer's concern on intermediaries?

jmayer: language in issue-4 conflates outcomes and motivation, let's have a section on what browsers can do by default and one section on intermediaries

schunter: closing issue-4

<fielding> I think the intermediary issue is 81

schunter: disagree user agent should set DNT on user preference?

<npdoty> fielding, 81 is the response header issue

jmayer: if user sets, of course. Debate is about defaults.
... if browser or network provider has it on by default, that's different; we should talk about that more

dsinger: If we say "it's a user preference," what can a service do if it knows it was set by an intermediary.

<fielding> If DNT is not a user preference then there is no reason to waste the bytes and time by adding it to the protocol -- we should just give up and rely on regulators to state the requirements on data sharing.

<dsinger> I cannot see how it is relevant what the name of the software the user uses is; 'browser', 'help viewer', 'application', etc...

jmayer: would suggest we add non-normative language on how this might apply elsewhere. We're focused on web context, but smart phones and tablets shouldn't be back to square one when what we do translates there.
... the spec is targeted to the web, but could be in a native environment; we might note that.

schunter: all we do relates to HTTP. issue-13 says doesn't apply if not HTTP. resist the idea of extending

<dsinger> yes, we're talking about HTTP user agents (at the user end)

schunter: can have different specs on different protocols

<sidstamm> +1 on dsinger's point -- lets focus on HTTP user agents (all software that speaks HTTP for the user)

jmayer: Suggests two things. First, note this applies to mobile more broadly than some read it, should clarify. Second, if we're scoping this to HTTP, would be a shame if a company said "fine, we'll use FTP"
... at minimum some non-normative language around SPDY. failing to future-proof

<npdoty> I think jmayer's point is that we could have a non-normative comment to suggest that this could apply to other protocols (which I could support)

<aleecia_> +1 personally

dsinger: We're defining an HTTP header. We don't need to say anything at all about other protocols
... can extend later, or others can

jmayer: don't agree. Don't see why saying things non-normative would be out of scope

dsinger: happy to read text you propose but don't see how you could do it

<sidstamm> I think this is a new issue

<npdoty> dsinger: I'm not sure how you'd do it, but I'm happy to read text you propose.

schunter: suggest closing this, but can perhaps take a new issue for non-normative

<npdoty> what would the new issue be called?

<sidstamm> "should the TPE be extended to other protocols?"

<aleecia> (Sid's title works for me)

<fielding> jmayer, sorry missed your q on IRC ... the reason for deliberately ignoring portions of the network that override user preferences is because we are trying to develop a protocol that behavioral advertising networks will be willing to adhere to as a reasonable cost of business. Sending a corporate preference or an ISP preference is not reasonable -- it means we just won't implement this protocol, and would instead go back to cookie-based, non-standard means of

<fielding> determining that preference which would less likely be gamed by intermediaries.

<schunter1> Unset means either that DNT is not enabled or that the user agent (maybe old) does not support DNT.

<aleecia> um.

<sidstamm> lack of header does not imply any value

<aleecia> +1 sid

<WileyS> +1

<JohnSimpson> +1

<npdoty> so should we move on beyond issue-78? (currently hearing silence)

<eberkower> I hear silence\

<aleecia> I'm not sure the text captures that, but perhaps it will when we have multiple issues all together in place?

<eberkower> ah - much better

<JC> +1 sid

matthias1: Would clarify - absence of a header means not enabled or not supported, don't say what 0 means.

<aleecia> jmayer: If you don't see a header, it's a different state.

<aleecia> ... not "unspecified or the same thing as DNT:0" which is not what we've agreed upon

<aleecia> ...it is a separate state of there's nothing here

<aleecia> That's a rather large suggestion. Frank, what do you have in mind?

fwagner: Unsure if we defined the default state. Default may vary by language or region.

matthias1: DNT: 1 and 0 are preferences. Otherwise, send nothing.

<fielding> That may be my mistake ... I could have sworn I added the text that Aleecia sent about no header meaning that no preference given (and other defaults may depend on region, other cookies, etc.) ... but now I can't find it in TPE

<aleecia> Ah! That's where Frank was going.

<aleecia> I'm pretty sure we didn't remove it at the f2f

roy: Thought I added text about no header = up to region, just no expressed preference.

<fielding> Section 5: If no DNT preference is received, it may indicate either that the user has chosen to allow cross-site tracking or that their user agent does not support this protocol for expressing DNT (e.g., user agents deployed prior to this protocol's existence). In the absence of regulatory, legal, or other requirements, servers are free to interpret the lack of a DNT header as they find most appropriate for the given user, particularly when considered in light

tl: No. This is a fundamental problem. HTTP perspective != DOM perspective, no solution for the problem.

jmayer: I agree with tl on the problems, per my slides from Princeton. One easy way to implement would be for the server to insert into its own JavaScript the status of DNT.
... for now avoid implementing a DOM API and just suggest to servers that this would be one easy way to do it

<aleecia> ...and that might help in the EU context where we cannot always have a global opt out / opt in

WileyS: Going to take a lot more discussion, but good progress.

tl: See web-wide exceptions as just a special case of a first party / third party pairing.
... Preserves the things I like about this approach.

npdoty: Yes, you can represent a web-wide exception the same way. You could do things much more complicated in the user agent, too. How much do we want to set in the spec? How much flexibility do we want to leave to user agents?

<aleecia> -1

<aleecia> (sorry - I should have jumped in and did not)

jmayer: We should say something about exceptions in browsers that don't support this exception API.

<aleecia> I'm in favor of moving this into the spec but leaving it open

schunter1: Suggestion that we put this into the spec, but more discussion necessary.

<aleecia> It's going to be easier to see things in one place, I think

npdoty: In spec language, should be able to import easily.

<npdoty> so I'll send this language to Roy to import into the draft

schunter1: Convert remaining Qs into new issues.

<npdoty> and then we'll also need to create new group ISSUES for the open issues we have in this proposal

schunter1: Next meeting 1/4.

<npdoty> including the issue that jmayer has raised about alternate opt-outs (perhaps scoped to when browsers have not implemented this yet)