# Device APIs Working Group Teleconference

## 04 Sep 2013

[Agenda][3]

See also: [IRC log][4]

## Attendees

Present

    Frederick_Hirsch, Clarke_Stevens, Anssi_Kostiainen, Jean-Claude_Dufourd,
Cathy_Chan, Josh_Soref, Igarashi_Tatsuya

Regrets

    Dominique_Hazael-Massieux, Giri_Mandyam

Chair

    Frederick_Hirsch

Scribe

    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 Discovery][10]

    6. [HTML Media Capture][11]

    7. [Teleconference schedule][12]

    8. [Action Review][13]

    9. [Issues Review][14]

    10. [Other Business][15]

    11. [Adjourn][16]

  * [Summary of Action Items][17]

* * *

<trackbot> Date: 04 September 2013

### Welcome, agenda review, scribe selection, announcements

<scribe> ScribeNick: fjh

Reminder: No DAP F2F at TPAC, but there will be the Media Capture TF meeting,
please attend that.

fjh: if you are attending TPAC please remember to register and make
arrangements soon

a new Working Draft of Media Capture and Streams has just been published:
[http://www.w3.org/TR/2013/WD-mediacapture-streams-20130903/][18] ;
[http://www.w3.org/TR/mediacapture-streams/][19]

### Minutes approval

Approve minutes from 21 August 2013

[http://lists.w3.org/Archives/Public/public-device-
apis/2013Aug/att-0048/minutes-2013-08-21.html][20]

**RESOLUTION: Minutes from 21 August 2013 are approved**

### Proximity and Light

LC-2739 [http://lists.w3.org/Archives/Public/public-device-
apis/2013Aug/0055.html][21]

Proximity CR CfC (5 Sept deadline) [http://lists.w3.org/Archives/Public
/public-device-apis/2013Aug/0054.html][22]

Light CR CfC (5 Sept deadline) [http://lists.w3.org/Archives/Public/public-
device-apis/2013Aug/0056.html][23]

using WebIDL's "conforming IDL fragment" conformance class (Barstow,
[http://lists.w3.org/Archives/Public/public-device-
apis/2013Aug/0059.html)][24]

fjh: CfC deadline is tomorrow, +1 on list would be useful

... dom responded to Art that what we are doing makes sense

anssik: will look at this

[http://lists.w3.org/Archives/Public/public-device-apis/2013Aug/0061.html][25]

### Vibration

Remaining questions/comments:

Question/Comment on CR draft: [http://lists.w3.org/Archives/Public/public-
device-apis/2013Jul/0050.html][26]

Question Vibration and iframes, [http://lists.w3.org/Archives/Public/public-
device-apis/2013Jul/0055.html][27]

Question: Vibration strength [http://lists.w3.org/Archives/Public/public-
device-apis/2013Aug/0040.html][28]

Supporting strength (Marcos) [http://lists.w3.org/Archives/Public/public-
device-apis/2013Aug/0062.html][29]

fjh: anssik, can you please review these and respond on the list.

... I think most are editorial

... I believe the WG is deciding to defer vibration sstrength

... I would think vibration would only be active for the active window

anssik: fix would be to say top level browsing context

fjh: that makes sense to me, thought you already made that change

anssik: did it for proximity

fjh: I think we should be consistent

anssik: this is a generic issue

fjh: I think we should make this change in the editors draft, pull it in in PR

anssik: walks through choices, looking at mail
[http://lists.w3.org/Archives/Public/public-device-apis/2013Jul/0055.html][27]

fjh: clarification needed

... would relate to the other strength issues

<scribe> **ACTION:** anssik to make proposal on list regarding multiple
vibration API invocations in frames for Vibration [recorded in
[http://www.w3.org/2013/09/04-dap-minutes.html#action01][30]]

<trackbot> Created ACTION-652 - Make proposal on list regarding multiple
vibration api invocations in frames for vibration [on Anssi Kostiainen - due
2013-09-11].

fjh: re vibration strength, Marcos suggested in next version,
[http://lists.w3.org/Archives/Public/public-device-apis/2013Aug/0062.html][29]

anssik: do we have a concrete proposal

fjh: no

**RESOLUTION: defer Vibration strength to next version of Vibration API**

anssik: ask for discussion on list, most implementations currently do not
support strength

another clarification issue [http://lists.w3.org/Archives/Public/public-
device-apis/2013Jul/0050.html][26]

<scribe> **ACTION:** fjh to create issues for Vibration questions [recorded in
[http://www.w3.org/2013/09/04-dap-minutes.html#action02][31]]

<trackbot> Created ACTION-653 - Create issues for vibration questions [on
Frederick Hirsch - due 2013-09-11].

### Network Discovery

fjh: WD for publication in progress, Rich created draft, I had some comments,
awaiting resolution before publication

Web & TV IG review, [http://lists.w3.org/Archives/Public/public-device-
apis/2013Aug/0063.html][32]

fjh: want to have published WD for review

... reopened issue, difficult to resolve without everyone on call

Re-Opened ISSUE-130, see [http://lists.w3.org/Archives/Public/public-device-
apis/2013Aug/0053.html][33] (discuss next week 4 Sept)

ISSUE-131 comment, [http://lists.w3.org/Archives/Public/public-device-
apis/2013Aug/0066.html][34] (Tatsuya Igarashi )

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) -- raised

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

jcdufound: regarding ISSUE-148, agreed between Jean-Claude and Cathy but Rich
might have missed part of this discussion

… service type for SDP is not human-readable at all

… agree with Cathy that should change to something with friendly name of the
device, believe Rich disagrees due to possible fingerprinting issue

… not a fingerprinting issue, since only exposed after authorization step

fjh: could still be fingerprinting despite authorization

jcdufourd: should make this change once we have agreement with Rich

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

jcdufourd: need answer to my argument on the list from richt

… need to determine what is appropriate in the use case I presented, which
would require large number of discovery requests

… I implemented current state of spec, others implemented services

… they didn't want to use complete name each time, wanted one search
regardless of the protocol

… didn't care about underlying discovery protocol

… so search with fragments

… requests from authors to simply API

… that is the main point to make it use simpler for authors

cathy: issue with doing that, web app might not be able to handle all the
responses that come back

… different types of media renderers

… so get everything and filter on what you can use versus ask for what you can
get

… I think it might make sense to ask what you can process

… I think rich agrees

… for media renders can have same service name with different domain and
protocol, so can get services you cannot handle

fjh: can this be done with a wrapper, convenience function?

jcdufourd: tried this first with adaptation layer, but could not do it

… however could modify my implementation to allow for it

… with small change

fjh: why not offer both options

jcdufourd: ok with me

cathy: first need to decide what we want

… if UA does not continuously monitor then problem

… UPnP does not allow wild card services

fjh: why didn't jclaude have this problem

cathy: monitors network, doesn't do search

fjh: issue search vs continues monitored

... wonder if we can allow support for implementation that can handle it but
not for implementation that cannot

... e.g. allow for usability where it makes sense and can be supported in
underlying implementation but otherwise not

<Cathy> [http://www.w3.org/2009/dap/track/issues/130][36]

fjh: this way we do not create an artificial limitation where not needed

cathy: might be hard to spec

jcdufourd: we could have an exception if implementation does not support it

<Josh_Soref> i'm not in favor of this

fjh: is it possible or necessary to have a different wildcard api method so
developer knows what to expect

... summary, trying to enable usability where implementation supports it yet
not get into difficulty where implementation does not

josh_soref: do not want same API used for both, will work in test environment
but not in another case, will have interop problem

fjh: have two APIs

josh_soref: would only use wildcard api if you know you really want to, have
fallback path

… so don't see this as a big problem for developers

jcdufourd: developer needs feature detection to see if can use wildcard api,
otherwise fallback

josh_soref: one way is to not have function present if not implemented

fjh: i think the next step is to draft some specification text and use that to
drive some more discussion

<scribe> **ACTION:** jcdufourd to propose text for Network Service Discovery
to define wildcard API and feature detection [recorded in
[http://www.w3.org/2013/09/04-dap-minutes.html#action03][37]]

<trackbot> Error finding 'jcdufourd'. You can review and register nicknames at
<[http://www.w3.org/2009/dap/track/users>.][38]

<scribe> **ACTION:** Dufourd to propose text for Network Service Discovery to
define wildcard API and feature detection [recorded in
[http://www.w3.org/2013/09/04-dap-minutes.html#action04][39]]

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

ISSUE-131?

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

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

email message [http://lists.w3.org/Archives/Public/public-device-
apis/2013Sep/0002.html][41]

cathy: general concern is about complexity added to spec

… if device string is UPnP specific so we lose generic aspec

igarashi: won't be too complicated, similar api

… device type is more important than service type

fjh: why more important

igarashi: based on UPnP architecture, first find by device then service type

fjh: seems to be another issue related to trying to make underlying discovery
mechanism transparent

igarashi: cannot be agnostic to underlying discovery mechanism, not a goal

clarke: one goal was to be agnostic, approach is to use parameters to allow UA
to deal with specifics, customization

fjh: what is the minimal set of changes we can make to the spec, then we can
discuss

cathy: it is in the issue text

fjh: not sure that is the minimum

igarashi: we can offer a proposal on the list

fjh: anything more on this topic?

### HTML Media Capture

Update on testing, [http://lists.w3.org/Archives/Public/public-device-
apis/2013Aug/0065.html][42]

thanks for this work to Intel

### Teleconference schedule

Proposal: Changing meeting time from Wed to Thur (same time),
[https://lists.w3.org/Archives/Member/member-device-
apis/2013Aug/0000.html][43]

<anssik> Thu is ok for me

<anssik> earlier is better

<anssik> conflict on Tue

fjh:

<Josh_Soref> thursday is good for me, i've already moved my schedule around
for it to fit

**RESOLUTION: Recurring meeting moved to Thursdays, same time (10 am ET)**

and also

**RESOLUTION: cancel 24 Oct, 28 Nov and 26 Dec**

### Action Review

<Josh_Soref> regrets for Thursday September 19 and September 26 :)

<Josh_Soref> ... Sukkot

ACTION-621?

<trackbot> ACTION-621 -- Anssi Kostiainen to Create test cases for HTML Media
Capture -- due 2013-03-13 -- PENDINGREVIEW

<trackbot> [http://www.w3.org/2009/dap/track/actions/621][44]

ACTION-621: resolved with [http://lists.w3.org/Archives/Public/public-device-
apis/2013Aug/0065.html][42]

<trackbot> Notes added to ACTION-621 Create test cases for HTML Media Capture.

close ACTION-621

<trackbot> Closed ACTION-621.

ACTION-643?

<trackbot> ACTION-643 -- Anssi Kostiainen to Review Ambient Light and
Proximity test cases by Sept -- due 2013-07-10 -- OPEN

<trackbot> [http://www.w3.org/2009/dap/track/actions/643][45]

anssik: done

close ACTION-643

<trackbot> Closed ACTION-643.

<anssik> [https://dvcs.w3.org/hg/dap/rev/916dbd5920d8][46]

<scribe> **ACTION:** anssik to update test for light
:[https://dvcs.w3.org/hg/dap/rev/916dbd5920d8][46] [recorded in
[http://www.w3.org/2013/09/04-dap-minutes.html#action05][47]]

<trackbot> Created ACTION-655 - Update test for light
:[https://dvcs.w3.org/hg/dap/rev/916dbd5920d8][46] [on Anssi Kostiainen - due
2013-09-11].

<anssik> [https://dvcs.w3.org/hg/dap/rev/a6ad49819c41][48]

<scribe> **ACTION:** anssik to update proximity test for
[https://dvcs.w3.org/hg/dap/rev/a6ad49819c41][48] [recorded in
[http://www.w3.org/2013/09/04-dap-minutes.html#action06][49]]

<trackbot> Created ACTION-656 - Update proximity test for
[https://dvcs.w3.org/hg/dap/rev/a6ad49819c41][48] [on Anssi Kostiainen - due
2013-09-11].

action-649?

<trackbot> action-649 -- Anssi Kostiainen to Review todo items associated with
battery test cases -- due 2013-08-21 -- OPEN

<trackbot> [http://www.w3.org/2009/dap/track/actions/649][50]

fjh: todo items were removed

close ACTION-649

<trackbot> Closed ACTION-649.

action-621?

<trackbot> action-621 -- Anssi Kostiainen to Create test cases for HTML Media
Capture -- due 2013-03-13 -- CLOSED

<trackbot> [http://www.w3.org/2009/dap/track/actions/621][44]

action-647?

<trackbot> action-647 -- Frederick Hirsch to Send cfc to progress light to cr,
two week cfc -- due 2013-08-21 -- PENDINGREVIEW

<trackbot> [http://www.w3.org/2009/dap/track/actions/647][51]

close ACTION-647

<trackbot> Closed ACTION-647.

close ACTION-648

<trackbot> Closed ACTION-648.

anssik: may need updates for IDLharness tests for battery

<scribe> **ACTION:** anssik to revise battery tests for IDLharness, find QA
person to help [recorded in [http://www.w3.org/2013/09/04-dap-
minutes.html#action07][52]]

<trackbot> Created ACTION-657 - Revise battery tests for idlharness, find qa
person to help [on Anssi Kostiainen - due 2013-09-11].

### Issues Review

reviewed network service discovery issues during call

### Other Business

<scribe> New editors draft of getUserMedia,
[http://dev.w3.org/2011/webrtc/editor/archives/20130824/getusermedia.html][53]

fjh: is there any relevant news from sys apps f2f relevant to dap

anssik: no dap relevant discussions

<Josh_Soref> SysApps asked to change their TPAC F2F dates

<Josh_Soref> ... because they were initially avoiding DAP

<Josh_Soref> ... but w/o DAP, they're now trying to avoid WebApps instead

<Josh_Soref> ... it's unclear if they'll succeed

Next week we will meet at new meeting day, Thursday, please remember to update
your calendars.

### Adjourn

## Summary of Action Items

**[NEW]** **ACTION:** anssik to make proposal on list regarding multiple
vibration API invocations in frames for Vibration [recorded in
[http://www.w3.org/2013/09/04-dap-minutes.html#action01][30]]

**[NEW]** **ACTION:** anssik to revise battery tests for IDLharness, find QA
person to help [recorded in [http://www.w3.org/2013/09/04-dap-
minutes.html#action07][52]]

**[NEW]** **ACTION:** anssik to update proximity test for
https://dvcs.w3.org/hg/dap/rev/a6ad49819c41 [recorded in
[http://www.w3.org/2013/09/04-dap-minutes.html#action06][49]]

**[NEW]** **ACTION:** anssik to update test for light
:https://dvcs.w3.org/hg/dap/rev/916dbd5920d8 [recorded in
[http://www.w3.org/2013/09/04-dap-minutes.html#action05][47]]

**[NEW]** **ACTION:** Dufourd to propose text for Network Service Discovery to
define wildcard API and feature detection [recorded in
[http://www.w3.org/2013/09/04-dap-minutes.html#action04][39]]

**[NEW]** **ACTION:** fjh to create issues for Vibration questions [recorded
in [http://www.w3.org/2013/09/04-dap-minutes.html#action02][31]]

**[NEW]** **ACTION:** jcdufourd to propose text for Network Service Discovery
to define wildcard API and feature detection [recorded in
[http://www.w3.org/2013/09/04-dap-minutes.html#action03][37]]


[End of minutes]

* * *

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

$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/2013Sep/0000.html

   [4]: http://www.w3.org/2013/09/04-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]: #item11

   [17]: #ActionSummary

   [18]: http://www.w3.org/TR/2013/WD-mediacapture-streams-20130903/

   [19]: http://www.w3.org/TR/mediacapture-streams/

   [20]: http://lists.w3.org/Archives/Public/public-device-
apis/2013Aug/att-0048/minutes-2013-08-21.html

   [21]: http://lists.w3.org/Archives/Public/public-device-
apis/2013Aug/0055.html

   [22]: http://lists.w3.org/Archives/Public/public-device-
apis/2013Aug/0054.html

   [23]: http://lists.w3.org/Archives/Public/public-device-
apis/2013Aug/0056.html

   [24]: http://lists.w3.org/Archives/Public/public-device-
apis/2013Aug/0059.html)

   [25]: http://lists.w3.org/Archives/Public/public-device-
apis/2013Aug/0061.html

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

   [27]: http://lists.w3.org/Archives/Public/public-device-
apis/2013Jul/0055.html

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

   [29]: http://lists.w3.org/Archives/Public/public-device-
apis/2013Aug/0062.html

   [30]: http://www.w3.org/2013/09/04-dap-minutes.html#action01

   [31]: http://www.w3.org/2013/09/04-dap-minutes.html#action02

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

   [33]: http://lists.w3.org/Archives/Public/public-device-
apis/2013Aug/0053.html

   [34]: http://lists.w3.org/Archives/Public/public-device-
apis/2013Aug/0066.html

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

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

   [37]: http://www.w3.org/2013/09/04-dap-minutes.html#action03

   [38]: http://www.w3.org/2009/dap/track/users>.

   [39]: http://www.w3.org/2013/09/04-dap-minutes.html#action04

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

   [41]: http://lists.w3.org/Archives/Public/public-device-
apis/2013Sep/0002.html

   [42]: http://lists.w3.org/Archives/Public/public-device-
apis/2013Aug/0065.html

   [43]: https://lists.w3.org/Archives/Member/member-device-
apis/2013Aug/0000.html

   [44]: http://www.w3.org/2009/dap/track/actions/621

   [45]: http://www.w3.org/2009/dap/track/actions/643

   [46]: https://dvcs.w3.org/hg/dap/rev/916dbd5920d8

   [47]: http://www.w3.org/2013/09/04-dap-minutes.html#action05

   [48]: https://dvcs.w3.org/hg/dap/rev/a6ad49819c41

   [49]: http://www.w3.org/2013/09/04-dap-minutes.html#action06

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

   [51]: http://www.w3.org/2009/dap/track/actions/647

   [52]: http://www.w3.org/2013/09/04-dap-minutes.html#action07

   [53]:
http://dev.w3.org/2011/webrtc/editor/archives/20130824/getusermedia.html

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

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