See also: IRC log
<trackbot> Date: 20 March 2014
<scribe> ScribeNick: fjh
Alpha pubrules checker: http://lists.w3.org/Archives/Public/public-device-apis/2014Mar/0004.html
RESOLUTION: Cancel 3 April 2014 teleconference
Approve minutes from 27 February 2014
http://lists.w3.org/Archives/Public/public-device-apis/2014Feb/att-0058/minutes-2014-02-27.html
RESOLUTION: Minutes from 27 February 2014 are approved
CfC concluded, will shelve Network Information API specification, http://lists.w3.org/Archives/Public/public-device-apis/2014Mar/0003.html
Planning publication for 27 March - publication draft preparation needed
fjh: might delay this publication for a week so that we can properly reference the use cases document being published as a W3C Note on 27 March
... simpler than working on simultaneous publication, no rush here
Test pull request proposal, http://lists.w3.org/Archives/Public/public-device-apis/2014Mar/0005.html
Review Security and Privacy considerations section - how to handle generally in test reports/tool
http://www.w3.org/TR/2013/CR-html-media-capture-20130509/
fjh: the tests look reasonable as noted in my email, the issue is with the nature of security/privacy considerations due to need for flexibility with regards to implementations and some higher level or non testable guidance
... Here is extract from document
[[ The user agent should not enable any device for media capture, such as a microphone or camera, until a user interaction giving implicit consent is completed. A user agent should also provide an indication when such an input device is enabled and make it possible to terminate such capture. Similarly, the user agent should allow the user:
to select the exact media capture device to be used if there exists multiple devices of the same type (e.g. a front-facing camera in addition to a primary camera).
to disable sound capture when in the video capture mode.
This specification builds upon the security and privacy protections provided by the <input type="file"> [HTML5] and the [FILE-API] specifications; in particular, it is expected that any offer to start capturing content from the user’s device would require a specific user interaction on an HTML element that is entirely controlled by the user agent.
Implementors should take care of additional leakage of privacy-sensitive data from captured media. For instance, embedding the user’s location in a captured media metadata (e.g. EXIF) might transmit more private data than the user might be expecting.]]
fjh: perhaps we should add sentence to conformance section regarding fact that security/privacy considerations are hard to test, special case etc
<scribe> ACTION: fjh to draft proposal for conformance and testing related to security and privacy [recorded in http://www.w3.org/2014/03/20-dap-minutes.html#action01]
<trackbot> Created ACTION-683 - Draft proposal for conformance and testing related to security and privacy [on Frederick Hirsch - due 2014-03-27].
cathy: not an issue in other tests
fjh: right, light and proximity do not have any SHOULDs in security,privacy section and vibration has no security, privacy section
... similar issue appears to be in network service discovery
cathy: suggest we update implementation report rather than conformance section
... should check geolocation
fjh: yes, looking at geolocation they have musts in the security,privacy considerations section
... also tests, but some pass by referencing the web site privacy policy it seems
http://www.w3.org/2008/geolocation/drafts/API/Implementation-Report.html
http://www.w3.org/TR/geolocation-API/
fjh: so it looks like it is possible to go to REC with security and privacy normative requirements
... we need to review the language in the spec some more, I'll take another look
... geolocation also had conformance targets, web site and user agent
... we might need for review roles as well (note will update action to include looking more closely at geolocation approach etc)
Updated test links on home page, http://lists.w3.org/Archives/Public/public-device-apis/2014Mar/0006.html
Pull request status summary : http://lists.w3.org/Archives/Public/public-device-apis/2014Feb/0049.html
cathy: pull request from Lisa for battery status, comments from intel
... that file is testing battery interface, so not right place for that test
... so we should close that pull without accepting, and can say done with battery
... that pull was a duplicate
<scribe> ACTION: dom to help close pull request #376 on battery, duplicate so does not need to be incorporate [recorded in http://www.w3.org/2014/03/20-dap-minutes.html#action02]
<trackbot> Created ACTION-684 - Help close pull request #376 on battery, duplicate so does not need to be incorporate [on Dominique Hazaël-Massieux - due 2014-03-27].
Cordova update, http://lists.w3.org/Archives/Public/public-device-apis/2014Feb/0059.html
fjh: what should this group do with regards to Cordova
lisa: we could use help knowing what needs to be done to align specs, jira issues say that they need to be aligned
note - we need to determine who can help with reviewing the various issues to note the differences
lisa: need to prioritize and work through the list
<scribe> ACTION: fjh to review priorities of cordova alignment [recorded in http://www.w3.org/2014/03/20-dap-minutes.html#action03]
<trackbot> Created ACTION-685 - Review priorities of cordova alignment [on Frederick Hirsch - due 2014-03-27].
lisa: we could arrange another call if needed
fjh: defer until we have Rich
Update to alternative week schedule, see http://lists.w3.org/Archives/Public/public-device-apis/2014Mar/0007.html
fjh: I believe someone asked about keeping weekly schedule as place holder but with small group we can adjust if needed, but we haven't needed weekly call for some time so I think it is better to go to alternate weeks now.
<mats> it was, but I'm fine with the change to alternate weeks
RESOLUTION: adopt meeting schedule in http://lists.w3.org/Archives/Public/public-device-apis/2014Mar/0007.html
fjh: we probably should work through one spec with a draft implementation report etc even though all testing isn't done, so we can test out the approach and make sure we are on track, then we can apply to others, hopefully ease process of getting to REC.