The API with three instead of six functions for Tracking Exceptions, which Roy asked for and Mike worked out, seems to be what we want. Given the scarcity of implementations so far (after the addition of the JavaScript Promises feature), changing the API like this should be possible. But it needs review. Mike and Roy will try to update the editors' draft this week, so that next week we can start a new two-week review.
That was also the opportunity for other, smaller changes, such as dropping the redundant ‘expires’ property and some wording changes for clarity: what the purpose of the doNotTrack property in JavaScript is; dropping the last, redundant sentence in ‘Checking an exception’; and rephrasing the note about DNT-extension being ‘at-risk’.
How to get implementations remains the big question. It seems browsers don't want to spend much effort on the API and a UI when it is not clear how many servers will implement DNT.
The old WebEx reservation disappeared. There is now a new one:
mikeoneill: I reduced the API calls from 6 to 3 and all return the same response type.
… Now has a new property in the Bag to distinguish webWide from site-specific.
<fielding> Mike is talking about the pull request at https://github.com/w3c/dnt/pull/45
<fielding> Right, ednotes are not published by CR
mikeoneill: Roy put in a note about not understanding a sentence.
fielding: Maybe just remove that sentence. It doesn't seem to matter.
shane: Like David, I'd need more time to review the changes.
fielding: It's not in the document yet, it's mike's propoasl.
bert: is an API chnage possible at all at this point?
<wileys> In the promise structure it appears the UGEs have been collapsed with a boolean for web-wide or not, correct?
bert: roy, your opinion on mike's API?
fielding: my goal is to get implementation commitments.
<fielding> I haven't had a chance to go through it in detail, but my preference remains to get an indication by browsers first and then go to CR. But I will defer to the WG.
bert: what does the ed. note in 7.3 mean?
fielding: Not really explained in the spec.
mikeoneill: There is something in the wiki. Could maybe copy that.
fielding: Anything, from wiki or mail.
… need more detail than the current one sentence at the start.
<fielding> earlier, Mike pointed out the comment on https://w3c.github.io/dnt/drafts/tracking-dnt.html#exception-checking
mikeoneill: I can find text.
<fielding> ... about none of us knowing what the last sentence means in that section.
mikeoneill: Section 7.6, doNotTrack property is not redundant. Just keep it.
fielding: I remember now why the remark is there.
mikeoneill: I have implemented it, it is not hard.
fielding: property is generated dynamically for each navigator window.
mikeoneill: Every context has its own property.
… E.g., an iframe. Have to be able to find the value without bouncing a request to a server.
fielding: I think the need is reasonable, but the spec doesn't reflect that.
mikeoneill: I could make some text.
fielding: If you can describe it.
Action: mikeoneill: describe doNotTrack property purpose and implementation
<trackbot> Error finding 'mikeoneill'. You can review and register nicknames at <http://www.w3.org/2011/tracking-protection/track/users>.
mikeoneill: "Expires" property: roy says it should be removed, but it is still in HTTP.
fielding: Yes, for legacy reasons. But if we have maxAge, expires is not needed.
mikeoneill: It is not much cost to implement.
fielding: Date parsing is actually expensive.
mikeoneill: Yes, but that code is there already.
fielding: No implems yet, we can decide. But we need more than 2 people with an opinion.
mikeoneill: There are implems.
shane: Expires is clearly understood, but maxAge serves the same pupose.
mikeoneill: The removal of expires is an easier chnage than the change to Promises was.
Resolved: remove "expires"
Action: fielding to remove Expires from API in favor of just using maxAge
<trackbot> Created ACTION-474 - Remove expires from api in favor of just using maxage [on Roy Fielding - due 2017-07-24].
bert: Do we need to mention DNT-extension as at risk (issue 48)?
Action: fielding to rephrase "at risk" on DNT-extensions
<trackbot> Created ACTION-475 - Rephrase "at risk" on dnt-extensions [on Roy Fielding - due 2017-07-24].
fielding: We can republish the CR instead. But there seems no reason to mark it at risk at present.
mikeoneill: Back to API:
… Re the duplets, I made a variable domain.
fielding: Will have a look, haven't had time to read it.
mikeoneill: [Something about resolving a Promise]
fielding: Probably editorial. Web Platforms specs typically specify an algorithm for Promises.
mikeoneill: I can make a pull request for next week.
bert: how much time do we need for review & editing?
mikeoneill: Most seems to be editorial.
<rvaneijk> Q: what is the consequence of a revision to the API for the process?
shane: browsers want to know that servers will implement before they spend resources. Move to Promises is big.
… I don't have enough feedback.
mikeoneill: Promises are in the spec.
fielding: yes, that was already decided,
shane: OK, so I'll need to talk to my team.
bert: How many weeks do we want for review?
shane: We first need the editorial changes in the spec. And then about 2 weeks after that.
… And if no comments in those two weeks, that implies acceptance.
fielding: I can do work this week only.
mikeoneill: I can do my text next Monday.
<rvaneijk> sorry, soundcard problem
<rvaneijk> would it require new implementations?
<fielding> I think further changes would be bound by existing implementations. Right now we are not bound because the Promises changes.
<rvaneijk> ok, tnx
No scribenick or scribe found. Guessed: bert