See also: IRC log
<scribe> ScribeNick: dom
<fjh> Approve minutes from 18 Feb 2016
<fjh> proposed RESOLUTION: Minutes from 18 Feb 2016 are approved, https://lists.w3.org/Archives/Public/public-device-apis/2016Feb/att-0065/minutes-2016-02-18.html
RESOLUTION: Minutes from 18 Feb 2016 are approved, https://lists.w3.org/Archives/Public/public-device-apis/2016Feb/att-0065/minutes-2016-02-18.html
<fjh> Steps for transition from CR to PR: https://lists.w3.org/Archives/Public/public-device-apis/2016Mar/0000.html
<fjh> Review of test case and implementation status, https://lists.w3.org/Archives/Public/public-device-apis/2016Feb/0073.html
FJH: we plan to go to PR, have been looking at the transition request
... we need an implementation report
... not sure what we have is suitable
<fjh> https://www.w3.org/2009/dap/wiki/ImplementationStatus
[https://w3c.github.io/test-results/battery-status/20160226.html is our Implementation report]
<fjh> https://zqzhang.github.io/blog/2016/02/18/testing-battery-status-api.html
[https://w3c.github.io/test-results/battery-status/20160226.html
<fjh> so we will use this as test report
Dom: I think we should start with https://w3c.github.io/test-results/battery-status/20160226.html as our implementation report
... it's linked from https://www.w3.org/2009/dap/wiki/ImplementationStatus
<fjh> for PR draft we should like to the results for implementation report, https://w3c.github.io/test-results/battery-status/20160226.html
Dom: we'll probably want to link to that specific document in our PR
<fjh> anssik, please make note that in PR draft we need to change link for implementation report, see above
<anssik> please open an issue for me
<fjh> anssik, any questions re preparing Battery PR
<fjh> ACTION: anssik to update PR draft to change link from implementation report to https://w3c.github.io/test-results/battery-status/20160226.html [recorded in http://www.w3.org/2016/03/03-dap-minutes.html#action01]
<trackbot> Created ACTION-746 - Update pr draft to change link from implementation report to https://w3c.github.io/test-results/battery-status/20160226.html [on Anssi Kostiainen - due 2016-03-10].
<fjh> ACTION: anssik to create PR publication draft, updating status section to note that there were no new issues since CR, that there were no features marked as at risk [recorded in http://www.w3.org/2016/03/03-dap-minutes.html#action02]
<trackbot> Created ACTION-747 - Create pr publication draft, updating status section to note that there were no new issues since cr, that there were no features marked as at risk [on Anssi Kostiainen - due 2016-03-10].
<fjh> ACTION: Anssik to put tentative date of 3 may 2016 in battery pr draft [recorded in http://www.w3.org/2016/03/03-dap-minutes.html#action03]
<trackbot> Created ACTION-748 - Put tentative date of 3 may 2016 in battery pr draft [on Anssi Kostiainen - due 2016-03-10].
<fjh> ACTION: fjh to send transition request [recorded in http://www.w3.org/2016/03/03-dap-minutes.html#action04]
<trackbot> Created ACTION-749 - Send transition request [on Frederick Hirsch - due 2016-03-10].
Tobie: I'm progressing towards a complete level 1 version of the spec
... I'm on the right track — I've found a model that fits the whole thing very well and lets me solve all but one issues
... the one remaining issue is around permissioning
... I've started rewriting ambient light based on generic sensor
... this I'll complete over the next couple of days
... my aim would be to have versions ready by mid next week for publication the week after
fjh: we would need a cfc
tobie: that makes sense for ambient light; I don't think we need it for generic sensor
... since we have agreement for automatic update of that doc
fjh: you're right
tobie: but yeah, we should do a cfc for ambient light
... the other thing I'm going to look at quickly is writing a spec for air pressure, altitude and barometer based on generic
fjh: we first have to determine if it's in scope of the charter
dom: not sure it would fit the charter as is
... could you comment about why that sensor in particular?
tobie: I understand Intel would be interested; it comes bundled with existing mobile devices
... it should be easy to expose on top of the generic sensor
... and would be a good showcase
dom: ok; I think you could develop a proposal, but would likely need some more cycles before we can adopt it formally as a wg
tobie: sure
... it should be fairly easy to get a first draft up
... there may be security or privacy issues I haven't thought of yet, but the technical aspects should be simple
fjh: first step is to create a draft, and when we get our new charter, we figure the right next process steps
tobie: in terms of implementations, riju has been hitting difficulties to a new layering system in chromium
... the basic idea of my new approach is that a given physical sensor will not give guarantees on the actual frequency of data gathering, for a combination of fingerprinting and cross-app usage
<fjh> tobie: one physical sensor shared across origins and applications
tobie: it also matches how these things are exposed in underlying platforms
... the last problem is the permission stuff, linked to the unresolved issue in the permission spec
... since I'm not getting traction, I'll keep it as a note in the spec
<fjh> PING teleconf discussion, https://lists.w3.org/Archives/Public/public-device-apis/2016Feb/0072.html
FJH: there was a PING call on that API
... Lukasz is working on a draft new section
... the plan is to work on a Proposed Edited Rec for the API
... the changes don't affect conformance, so we can use PER
... 3 changes: errata incorporation, addition of Privacy & Sec section, maybe some A11Y change
... actually, the A11Y aspect is part of the discussions around privacy & security, so that's only 2 changes
<fjh> https://lists.w3.org/Archives/Public/public-device-apis/2016Feb/0081.html
<fjh> Lukasz is creating draft security and privacy considerations section for Vibration API
<fjh> ACTION: lukasz to create draft security and privacy considerations section for Vibration API [recorded in http://www.w3.org/2016/03/03-dap-minutes.html#action05]
<trackbot> Created ACTION-750 - Create draft security and privacy considerations section for vibration api [on Lukasz Olejnik - due 2016-03-10].
<fjh> process - 1. new editors draft with errata folded in and added security and privacy considerations (2) informal review with PING and others (3) PER process
<fjh> ACTION: anssik to prepare new Vibration editors draft including errata and security and privacy consideration material from Lukasz and others [recorded in http://www.w3.org/2016/03/03-dap-minutes.html#action06]
<trackbot> Created ACTION-751 - Prepare new vibration editors draft including errata and security and privacy consideration material from lukasz and others [on Anssi Kostiainen - due 2016-03-10].
<fjh> https://lists.w3.org/Archives/Public/public-device-apis/2016Feb/att-0067/00-part
FJH: we have a WD, we want to go to CR
... so we should get wide review on our draft before asking transition to CR
Dom: https://lists.w3.org/Archives/Public/public-device-apis/2016Mar/0006.html
FJH: Andrey walked us through the issues and that the remaining ones are longer term
Andrey: yes; addressing these issues would require a significant change to the spec
... making these changes would invalidate the existing implementation in chromium
Dom: I would say it depends on how likely these changes would affect take up from implementors
fjh: I think we have decided to go with that version and get wide review from it
<fjh> privacy & security questionnaire: https://w3ctag.github.io/security-questionnaire/
fjh: Andrey, could look into the seucrity questionnaire?
Andrey: yes, I can
Dom: since issue 56 is about "book reader use case", we should probably also ask the Digital Publishing IG for review
<fjh> ACTION: Andrey_Logvinov to review wake lock with respect to privacy and security https://w3ctag.github.io/security-questionnaire/ [recorded in http://www.w3.org/2016/03/03-dap-minutes.html#action07]
<trackbot> Error finding 'Andrey_Logvinov'. You can review and register nicknames at <http://www.w3.org/2009/dap/track/users>.
<fjh> ACTION: andrey to review wake lock with respect to privacy and security https://w3ctag.github.io/security-questionnaire/ [recorded in http://www.w3.org/2016/03/03-dap-minutes.html#action08]
<trackbot> Created ACTION-752 - to review wake lock with respect to privacy and security https://w3ctag.github.io/security-questionnaire/ [on Andrey Logvinov - due 2016-03-10].
https://github.com/w3c/wake-lock/issues
<fjh> process (1) Andrey to review security privacy questionnaire, (2) any WD updates if needed (3) Dom, Frederick to send request for review
Andrey: will try to get that done in the upcoming week
<fjh> Upcoming meetings, https://www.w3.org/2009/dap/minutes.html#upcoming-teleconferences
FJH: I'll be out for the next 2 calls
... Dom will chair March 17
... and we will cancel March 31st
... we can do most of our work on the list in any case
RESOLUTION: no call on March 31st
Dom: still working on the objection we received; hopefully all will get done before our extension expires at the end of this month
<fjh> none