# Device APIs Working Group Teleconference

## 03 Oct 2013

[Agenda][3]

See also: [IRC log][4]

## Attendees

Present

    Frederick_Hirsch, Lisa_DeLuca, Anssi_Kostiainen, JeanClaude_Dufourd,
Dominique_Hazael-Massieux, Cathy_Chan, Josh_Soref, Tatsuya_Igarashi

Regrets

    Giri_Mandyam

Chair

    Frederick_Hirsch

Scribe

    Josh_Soref, fjh

## Contents

  * [Topics][5]

    1. [Welcome, agenda review, scribe selection, announcements][6]

    2. [Minutes Approval][7]

    3. [Proximity and Light][8]

    4. [Vibration][9]

    5. [Network Service Discovery][10]

    6. [Network Information API][11]

    7. [Roadmap/Charter review][12]

    8. [Action Review][13]

    9. [Other Business][14]

    10. [Adjourn][15]

  * [Summary of Action Items][16]

* * *

<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][17]

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][18]

**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/][19]

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

<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][21]

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][22]]

<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][23]

anssik: i think they're informed

... QA follows the list

<dom> [Pull Request for ambient light events][24]

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][25]

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

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][27]

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

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][29]

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

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][30]

<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][31]

fjh: i think i can just close this

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

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][33]

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

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][34]]

<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][35]

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][36]

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][37]

ISSUE-131?

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

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

ISSUE-133?

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

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

ISSUE-134?

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

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

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][41]

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][42]

ISSUE-151?

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

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

ISSUE-154?

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

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

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][44]

Walk through test case status, review plans.

charter: [http://www.w3.org/2011/07/DeviceAPICharter][45]

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][46]

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

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

<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

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

<anssik> ... but I assume your impl is not following the latest 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][49]

jcdufourd: will have some time to work on it shortly

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][50]

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][27]

close ACTION-652

<trackbot> Closed ACTION-652.

close ACTION-661

<trackbot> Closed ACTION-661.

close ACTION-662

<trackbot> Closed ACTION-662.

### Other Business

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

### Adjourn

## Summary of Action Items

**[NEW]** **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][34]]


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


[End of minutes]

* * *

Minutes formatted by David Booth's [scribe.perl][51] version 1.135 ([CVS
log][52])

$Date: 2009-03-02 03:52:20 $

   [1]: http://www.w3.org/Icons/w3c_home

   [2]: http://www.w3.org/

   [3]: http://lists.w3.org/Archives/Public/public-device-
apis/2013Oct/0009.html

   [4]: http://www.w3.org/2013/10/03-dap-irc

   [5]: #agenda

   [6]: #item01

   [7]: #item02

   [8]: #item03

   [9]: #item04

   [10]: #item05

   [11]: #item06

   [12]: #item07

   [13]: #item08

   [14]: #item09

   [15]: #item10

   [16]: #ActionSummary

   [17]: http://lists.w3.org/Archives/Public/public-device-
apis/2013Oct/0001.html

   [18]: http://lists.w3.org/Archives/Public/public-device-
apis/2013Sep/att-0060/minutes-2013-09-26.html

   [19]: http://www.w3.org/TR/2013/CR-ambient-light-20131001/

   [20]: http://www.w3.org/TR/2013/CR-proximity-20131001/

   [21]: http://www.w3.org/2009/dap/track/issues/153

   [22]: http://www.w3.org/2013/10/03-dap-minutes.html#action01

   [23]: https://github.com/dontcallmedom/web-platform-tests/pull/2

   [24]: https://github.com/dontcallmedom/web-platform-tests/pull/1

   [25]: http://www.w3.org/2009/dap/track/issues/146

   [26]: http://lists.w3.org/Archives/Public/public-device-
apis/2013Oct/0019.html

   [27]: http://www.w3.org/2009/dap/track/issues/149

   [28]: http://lists.w3.org/Archives/Public/public-device-
apis/2013Oct/0012.html

   [29]: http://www.w3.org/2009/dap/track/issues/150

   [30]: http://lists.w3.org/Archives/Public/public-device-
apis/2013Oct/0003.html

   [31]: http://www.w3.org/2009/dap/track/issues/152

   [32]: http://lists.w3.org/Archives/Public/public-device-
apis/2013Oct/0004.html

   [33]: http://lists.w3.org/Archives/Public/public-device-
apis/2012Nov/0015.html

   [34]: http://www.w3.org/2013/10/03-dap-minutes.html#action02

   [35]: http://www.w3.org/2009/dap/track/issues/154

   [36]: http://lists.w3.org/Archives/Public/public-device-
apis/2013Oct/0014.html

   [37]: http://www.w3.org/2009/dap/track/issues/130

   [38]: http://www.w3.org/2009/dap/track/issues/131

   [39]: http://www.w3.org/2009/dap/track/issues/133

   [40]: http://www.w3.org/2009/dap/track/issues/134

   [41]: http://www.w3.org/2009/dap/track/issues/147

   [42]: http://www.w3.org/2009/dap/track/issues/148

   [43]: http://www.w3.org/2009/dap/track/issues/151

   [44]: http://www.w3.org/2009/dap/#roadmap

   [45]: http://www.w3.org/2011/07/DeviceAPICharter

   [46]: https://github.com/w3c/web-platform-tests/pull/306

   [47]: http://cordova.apache.org/docs/en/edge/cordova_events_events.md.html#
batterystatus

   [48]: https://github.com/w3c/web-platform-tests/tree/master/battery-status

   [49]: http://www.w3.org/2009/dap/track/actions/654

   [50]: http://www.w3.org/2009/dap/track/actions/658

   [51]: http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm

   [52]: http://dev.w3.org/cvsweb/2002/scribe/