Device APIs Working Group Teleconference -- 03 Oct 2013

<trackbot> Date: 03 October 2013

<Josh_Soref> scribe: Josh_Soref

Welcome, agenda review, scribe selection, announcements

fjh: welcome everyone

<fjh> CR drafts of Ambient Light Events and Proximity Events published 1 Oct, http://lists.w3.org/Archives/Public/public-device-apis/2013Oct/0001.html

fjh: thanks to anssik for working on
... i wonder if we should cancel the call the week of TPAC

<dom> +1 to cancel call during TPAC week

anssik: i think we should cancel

<fjh> RESOLUTION: Cancel DAP teleconference 14 November

<fjh> (week of TPAC)

Minutes Approval

<fjh> Approve minutes from 26 September 2013

<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2013Sep/att-0060/minutes-2013-09-26.html

RESOLUTION: Minutes from 26 September 2013 are approved

Proximity and Light

<fjh> CR drafts published 1 Oct,

<fjh> http://www.w3.org/TR/2013/CR-ambient-light-20131001/

<fjh> http://www.w3.org/TR/2013/CR-proximity-20131001/

<fjh> ISSUE-153?

<trackbot> ISSUE-153 -- Would interface and event name change be possible and clearer -- pending review

<trackbot> http://www.w3.org/2009/dap/track/issues/153

fjh: we got feedback asking about changing the name
... but we had feedback from Mozilla that they have shipped it and aren't willing to change

anssik: Mozilla has a point
... this is about naming (bike-shedding), not functionality
... I wonder if the person w/ the feedback had a proposal

fjh: i proposed an alternative
... the feedback was just that the name didn't match functionality
... but it isn't worth cycling around on this given Mozilla's feedback

anssik: regardless of the name, someone will be unhappy
... we have Device-prefix and User-prefix
... we have getUserMedia
... we have DeviceOrientation
... i agree they don't clearly match what the api is about but...

fjh: i agree
... i'd suggest we close the issue out

Josh_Soref: +1

fjh: i'll send a response

<fjh> ISSUE-153: feedback on list from Mozilla that too late to change naming for implementation, WG agrees to close issue with no change

<trackbot> Notes added to ISSUE-153 Would interface and event name change be possible and clearer.

<fjh> close ISSUE-153

<trackbot> Closed ISSUE-153.

<fjh> ACTION: fjh to respond regarding ISSUE-153 that it is closed [recorded in http://www.w3.org/2013/10/03-dap-minutes.html#action01]

<trackbot> Created ACTION-663 - Respond regarding issue-153 that it is closed [on Frederick Hirsch - due 2013-10-10].

fjh: we need to figure out our next steps for Proximity and Light
... later in the agenda, we can do test plan
... anything else to talk about now?

anssik: wrt Tests, iirc i've asked our QA to review them
... i'll need to refer back to the repo to find out what has been done

dom: there was a review of the existing TCs
... and i reviewed them before merging
... the existing TCs match the spec
... but they don't completely cover it
... there's very little about semantics of the event
... that there is/isn't an object
... that there is/isn't a level of light
... I understand that you guys were going to look into contributing test cases
... but i don't know if there are specific plans

anssik: i'm trying to find the initial pull-request where the comments were

fjh: i assume your team knows it's in CR now
... and i think they should review the plans

<dom> Pull Request for proximity events

anssik: i think they're informed
... QA follows the list

<dom> Pull Request for ambient light events

anssik: those are the changes
... our QA looked at them
... to look for gaps
... i tasked them to fill in the gaps

dom: i can't recall if there was a private thread or a thread on the main repo issues list

anssik: i'll follow
... up
... our QA guy said he'd like to add new tests
... let's leave this open
... we'll come back w/ more tests

fjh: any idea when that will happen?

anssik: there's a holiday period this week in China
... but definitely by the end of the year
... i'd assume w/in a couple of weeks
... i'll follow up on the thread

fjh: it'd be helpful if you could share where we're at

Vibration

<fjh> ISSUE-146?

<trackbot> ISSUE-146 -- Add vibration strength control -- open

<trackbot> http://www.w3.org/2009/dap/track/issues/146

<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2013Oct/0019.html

LisaDeLuca_IBM: There was feedback in cordova that iOS doesn't support vibration strength

fjh: so you support deferring it

LisaDeLuca_IBM: yes

fjh: and anssik, you were the same?

Josh_Soref: i also support deferring

fjh: and anssik was asking for other feedback

<fjh> proposed RESOLUTION: defer strength until future version

Josh_Soref: +1

RESOLUTION: defer strength until future version

<fjh> ISSUE-149?

<trackbot> ISSUE-149 -- handling of long vibration list - truncate or no vibration at all -- open

<trackbot> http://www.w3.org/2009/dap/track/issues/149

<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2013Oct/0012.html

fjh: i think we should put this in the spec

<fjh> defer until next week, but proposal is to adopt resolution provided by anssi

Josh_Soref: i wonder if someone does something like: [1, 2, 3, 4, 1000, 2, 1000]
... if all you get is 1,2,3,4 then you might totally miss the goal of the thing

<fjh> ISSUE-150?

<trackbot> ISSUE-150 -- Should vibration be additive when multiple instances, e.g. iframes -- open

<trackbot> http://www.w3.org/2009/dap/track/issues/150

<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2013Oct/0003.html

anssik: back to Josh_Soref 's question

<fjh> ISSUE-150: proposal related to ACTION-652 http://lists.w3.org/Archives/Public/public-device-apis/2013Oct/0003.html

<trackbot> Notes added to ISSUE-150 Should vibration be additive when multiple instances, e.g. iframes.

anssik: i don't have a position

Josh_Soref: on additive

anssik: i was still thinking about 149

fjh: let's move on to 150

Josh_Soref: on additive ... my concern is that the timing is fairly random

<fjh> this one makes sense to me, please review ,we will decide next week for ISSUE-150

Josh_Soref: so yes, i think i support anssik 's proposal

anssik: iOS is probably the most limited

Josh_Soref: i don't think the underlying system matters so much
... as long as the underlying system has a stop and insert replacement
... you can always emulate this
... but the timing of the overlapping things will be fairly inconsistent
... and impossible for a user to recognize

fjh: where you layer it might have an effect
... os/browser-engine/browser
... i think the proposal is good

Josh_Soref: me too

<fjh> ISSUE-152?

<trackbot> ISSUE-152 -- Vibration API events start/pause/resume/cancel and status listener start/pause/resume/cancel/finish -- pending review

<trackbot> http://www.w3.org/2009/dap/track/issues/152

fjh: i think i can just close this

<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2013Oct/0004.html

Josh_Soref: would it tell the app when it's not-currently-vibrating-but-will-shortly

fjh: it isn't speced out

<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2012Nov/0015.html

<anssik> earlier similar feedback: http://lists.w3.org/Archives/Public/public-device-apis/2012Nov/0015.html

fjh: i think we could ask for a more detailed proposal

Josh_Soref: i think we'd need UCs

fjh: do we have accurate enough timings to be able to do anything?

Josh_Soref: i doubt we could
... my guess is that you won't be able to respond fast enough to do something useful

<anssik> +1 for deferring to v2

Josh_Soref: +1 for deferring

fjh: it seems the UC would have to be specifically spelled out
... proposing a change could result in more complexity without solving the problem

RESOLUTION: Defer ISSUE-152

<fjh> ACTION: fjh to respond indicating ISSUE-152 deferred, suggesting more detailed use case/requriements for v.next [recorded in http://www.w3.org/2013/10/03-dap-minutes.html#action02]

<trackbot> Created ACTION-664 - Respond indicating issue-152 deferred, suggesting more detailed use case/requriements for v.next [on Frederick Hirsch - due 2013-10-10].

Network Service Discovery

fjh: Cathy is here, richt is not

<fjh> ISSUE-154?

<trackbot> ISSUE-154 -- Security approach -- open

<trackbot> http://www.w3.org/2009/dap/track/issues/154

fjh: i added a new issue
... i'm trying to capture what we've raised and what we've resolved
... it starts w/ a good message by Youenn Fablet

<fjh> Youenn Fablet sent good summary linking to external implementer discussions

fjh: we're having the discussion on the list
... there are two conclusions that i'm drawing
... one is deciding what to do on CORS
... richt has a proposal that came out just before the call

<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2013Oct/0014.html

fjh: the second topic is how much requirement do we have to support legacy devices

jcdufourd: if we don't support legacy devices
... when NSD comes up in browser
... if there are no supported devices
... no one will be interested in using it
... we need to design a standard that would be adopted

fjh: that's a question the implementers raised
... questions about security
... there's also a question about usefulness
... i sent a question about
... what if i have a router which is insecure, it supports Router and Media
... and you attack the media bit, take over the router
... and then control DNS and attack other things
... it seems to be a real case
... there's a uPNP link pointing to papers identifying insecurities
... i'm not sure CORS helps
... i'm not sure it prevents an attack post discovery phase
... maybe whitelist-blacklist will work
... i dunno

jcdufourd: the UCs i see that are useful for bootstrapping

<scribe> scribe: fjh

jcdufourd: only need to discovery services specific to your need

… permission to discover by user limits what can be discovered

… whitelist should only allow discovery of these two services by one webapp

… this could be more of a requirement for more UI

… this could be totally safe

fjh: there's the possibility that a malicious web site could pretend to be friendly
... get permission for a reasonable service
... attack the buggy part of the reasonable service
... and then having taken over the device
... abuse the more valuable services (router)

dom: we should re-use web technologies such as CORS as much as possible and also consider whitelisting to enable legacy to the extent possible

… also we cannot address all security issues ,e.g. regarding the router issue, but we can note in security considerations

fjh: agree we must address the implementer concerns re security in the security considerations section

… even if to only highlight and describe the issue and outline potential mitigations

Josh_Soref: we could propose banning all services from devices which advertise scary services

<igarashi> +q

fjh: a number of issues related to network service discovery are open, we should attempt to resolve on the list

igarashi: CORS specific to web applications due to HTTP header usage

… so CORS helps

ISSUE-130?

<trackbot> ISSUE-130 -- Enable variety of protocols (e.g. UPnP, Bonour) with protocol independent developer code -- open

<trackbot> http://www.w3.org/2009/dap/track/issues/130

ISSUE-131?

<trackbot> ISSUE-131 -- Support UPnP device discovery by Device Type? -- open

<trackbot> http://www.w3.org/2009/dap/track/issues/131

ISSUE-133?

<trackbot> ISSUE-133 -- Fix UPnP events subscription and unsubscription -- open

<trackbot> http://www.w3.org/2009/dap/track/issues/133

ISSUE-134?

<trackbot> ISSUE-134 -- Rename NetworkServices and NetworkService events -- open

<trackbot> http://www.w3.org/2009/dap/track/issues/134

close ISSUE-134

<trackbot> Closed ISSUE-134.

ISSUE-147?

<trackbot> ISSUE-147 -- Reference 'Requirements for Home Networking Scenarios' in Introduction -- open

<trackbot> http://www.w3.org/2009/dap/track/issues/147

ISSUE-148?

<trackbot> ISSUE-148 -- NetworkService.name definition in 8.2.2.4 incoherent with definition in 7.1 (a human-readable title for the service) -- open

<trackbot> http://www.w3.org/2009/dap/track/issues/148

ISSUE-151?

<trackbot> ISSUE-151 -- USN should not be used as device identifier -- open

<trackbot> http://www.w3.org/2009/dap/track/issues/151

ISSUE-154?

<trackbot> ISSUE-154 -- Security approach -- open

<trackbot> http://www.w3.org/2009/dap/track/issues/154

fjh: web and TV IG is cc'd on security discussion
... waiting on PING and Web & TV formal review given the large number of open issues, potential changes
... can ask PING informally about the Nov slot
... this spec is in WD, eventually LC and CR, not ready to consider given state of change
... can expect this draft will not go into LC until next year
... would like to see LC this year if we can

dom: need to check with Rich but would like to take advantage of current momentum

Network Information API

fjh: still discussing with Mounir re Mozilla offline

<anssik> we're looking at this internally and will try come back with feedback

Roadmap/Charter review

Review plans for progressing work through year-end.

All active non-task-force specifications are in CR (Battery Status, HTML Media Capture, Ambient Light Events, Proximity Events, Vibration API) apart from Network Service Discovery (WD)

http://www.w3.org/2009/dap/#roadmap

Walk through test case status, review plans.

charter: http://www.w3.org/2011/07/DeviceAPICharter

Additional work on permissions API, privacy?

fjh: need to link to test case to HTML Media Capture from DAP home page, not sure of status

<anssik> https://github.com/w3c/web-platform-tests/pull/306

<LisaDeLuca_IBM_> FYI, here is the Apache Cordova battery events (batterycritical, batterylow, batterystatus) http://cordova.apache.org/docs/en/edge/cordova_events_events.md.html#batterystatus

dom: can anssik check the status of HTML Media Capture test cases and share status on the list

fjh: how do we get the pull request for HTML Media Capture approved, who is reviewing it?

dom: bring attention to the pull request on the DAP list

… seek reviewers

… then we can go from there

… I'll put the link on the home page

<anssik> Lisa, those events are as per an earlier version of the spec

Action Review

ACTION-654?

<trackbot> ACTION-654 -- Jean-Claude Dufourd to Propose text for network service discovery to define wildcard api and feature detection -- due 2013-09-11 -- OPEN

<trackbot> http://www.w3.org/2009/dap/track/actions/654

jcdufourd: will have some time to work on it shortly

<LisaDeLuca_IBM_> @anssik, can you email me to see how I can help you with action-523 ... even if it's just testing. ldeluca@us.ibm.com

ACTION-658?

<trackbot> ACTION-658 -- Dominique Hazaël-Massieux to Review issue-149 get input on tradeoff of either failing or offering partial result (not all of request) -- due 2013-10-03 -- OPEN

<trackbot> http://www.w3.org/2009/dap/track/actions/658

ISSUE-149?

<trackbot> ISSUE-149 -- handling of long vibration list - truncate or no vibration at all -- open

<trackbot> http://www.w3.org/2009/dap/track/issues/149

close ACTION-652

<trackbot> Closed ACTION-652.

close ACTION-661

<trackbot> Closed ACTION-661.

close ACTION-662

<trackbot> Closed ACTION-662.

Other Business

<anssik> Lisa, the tests are here: https://github.com/w3c/web-platform-tests/tree/master/battery-status

<anssik> ... but I assume your impl is not following the latest spec

none

fjh: please review the issues we discussed today (as well as other open issues) so we can resolve on list and close next week if possible

… also any help reviewing or working on test cases or implementation to progress CR drafts would be helpful

… thanks

- DRAFT -

Device APIs Working Group Teleconference

03 Oct 2013

Attendees

Contents