[![W3C][1]][2]

# Device APIs Working Group Teleconference

## 06 Mar 2013

[Agenda][3]

See also: [IRC log][4]

## Attendees

Present

    Anssi_Kostiainen, Cathy_Chan, Clarke_Stevens, Diana_Cheng, Dzung_Tran,
Frederick_Hirsch, Giri_Mandyam, Josh_Soref, Richard_Tibbet, dom,
Mounir_Lamouri

Regrets

    Milan_Patel, Bryan_Sullivan

Chair

    Frederick_Hirsch

Scribe

    Josh_Soref

## Contents

  * [Topics][5]

    1. [Administrative][6]

    2. [Minutes Approval][7]

    3. [F2F Planning][8]

    4. [Network Service Discovery][9]

    5. [Contacts][10]

    6. [HTML Media Capture][11]

    7. [Transition Request process][12]

    8. [Vibration test progress][13]

    9. [OMA Liaison][14]

    10. [Privacy][15]

    11. [Action Review][16]

    12. [Other Business][17]

    13. [Adjourn][18]

  * [Summary of Action Items][19]

* * *

<trackbot> Date: 06 March 2013

<scribe> Scribe: Josh_Soref

### Administrative

<fjh> Please use this link to update phone number mapping for zakim
[https://www.w3.org/1998/12/bridge/info/name.php3][20]

<fjh> Note: Next meeting is regular ET time; this makes it an hour earlier in
Europe due to different in daylight savings time, see
[https://lists.w3.org/Archives/Member/member-device-
apis/2013Mar/0001.html][21]

Josh_Soref: i'm unlikely to call in on the 27th (Passover)

### Minutes Approval

<fjh> Approve minutes from 27 February 2013

<fjh> [http://lists.w3.org/Archives/Public/public-device-
apis/2013Feb/att-0093/minutes-2013-02-27.html][22]

<fjh> Approve (revised) minutes from 20 February 2013

<fjh> [http://lists.w3.org/Archives/Public/public-device-
apis/2013Feb/att-0098/minutes-2013-02-20.html][23]

<fjh> proposed RESOLUTION: Minutes from 20 Feb (revised) and 27 February 2013
are approved

**RESOLUTION: Minutes from 20 Feb (revised) and 27 February 2013 are
approved**

### F2F Planning

<fjh> Questionnaire completes 12 March,
[https://www.w3.org/2002/09/wbs/43696/2013-06-f2f/][24]

<fjh> [https://www.w3.org/2002/09/wbs/43696/2013-06-f2f/results][25]

dcheng3: i still have both reserved

<fjh> Deadline for deciding on TPAC 2013? ( Nov 18-22 in Shenzhen -
[http://lists.w3.org/Archives/Public/public-device-apis/2013Jan/0095.html][26]
)

fjh: i think we need to know way in advance to decide, because of Visas

dom: usually WGs are asked in March/April if they want to participate in TPAC

fjh: the June F2F was questionable, i think we can lock that down

... if we don't progress on Web Intents, we might not need TPAC

dom: i don't know that there's a schedule on this question

... but it would probably be asked in April

... intending to meet isn't necessarily a strong commitment

... we could cancel later

fjh: i mentioned that the Intents/Activity people were supposed to discuss
shortly

... i'd assume we'll know by the first week of April if we'd want to meet

... i'm assuming Dusseldorf will work out well

### Network Service Discovery

<fjh> Status on updates and publication of WD?

<fjh> additional discussion:

<fjh> [http://lists.w3.org/Archives/Public/public-device-
apis/2013Feb/0097.html][27]

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

richt: i'm traveling until Friday

... back Monday

... i have a backlog of changes

Cathy: re: Guisseppi comments earlier

... discovering UPnP device types v. Service types

... w/ device types, controllers typically are more interested in devices as
opposed to services

... but that would be a significant change to the UPnP mechanism in the spec

... we need to consider implications

richt: i agree

... Cathy, based on your experience, it might be a good idea for you to edit
that in

Cathy: i'll work with you on that

richt: it'd be cool to get you involved in editing

fjh: the change offers simplifications/solves problems

... Cathy, there's no need for you to get extra permissions, since we're using
git

richt: we're using overview-src.

fjh: Cathy, do you need an action?

Cathy: no

richt: i'd prefer discussing on list before we make changes?

Cathy: sure

<fjh> +1 to proposal on list before editing document, thanks Cathy for
volunteering

fjh: Cathy will make progress on device-types/service-types

<richt> I think you captured it well, Josh_Soref.

fjh: and richt will work on the backlog

### Contacts

<fjh> Sys Apps draft - [http://www.w3.org/2012/sysapps/drafts/contacts-
manager-api/][29]

<fjh> Pick Contacts Implementation status, original DAP Contacts
implementation status?

fjh: marcos asked about implementation

dom: afaik it was never implemented by anyone

Josh_Soref: it's implemented in the original form by Cordova

<dom> [http://www.w3.org/2009/dap/wiki/ImplementationStatus#Contacts_API][30]

fjh: we don't have any record of this

dom: we do, thanks to AnssiK

<fjh> ok, thanks Dom for the pointer, and AnssiK for the wiki work

richt: which are we talking about?

... we have a mozilla implementation

dom: but that was an addon

[ Josh_Soref summarizes concerns about SysApps doc ]

Josh_Soref: thanks fjh for getting them to rename their spec

fjh: i'm not sure if we can give feedback

Josh_Soref: some WGs will be asked to give feedback

... but all WGs can give unsolicited feedback

### HTML Media Capture

<fjh> resolving LC comments, [http://lists.w3.org/Archives/Public/public-
device-apis/2013Mar/0002.html][31]

fjh: i gave shepazu a 2 week time window this time, i should have done that
last time

dom: yes, that's good

AnssiK: thanks fjh for pushing Tracker

... i'll update the draft after we close shepazu's issues

... i'll add a status section about Exit criteria

... i'll give shepazu a couple of days

<mounir> Josh_Soref: actually, if the user must have to use a capture device,
that could work too (i guess) but a common behaviour would be better. I'm not
sure what is the specification wording regarding this.

<mounir> Regarding the HTML Media Capture, there is a problem regarding the
ability for the user to opt-out from the capture device and use its stored
pictures instead. I believe that should be allowed but I'm not sure how much
we should make this a requirement for specifications.

Josh_Soref: mounir: i thought that we designed the spec to specifically allow
for that!

### Transition Request process

fjh: i think we made a mistake in our publications in not including Exit
Criteria/At Risk in our documents

... i don't think we need to update the status retroactively

... we won't go back to CR, we'll just go to PR

AnssiK: you gave Mar 18 as the deadline to shepazu

... i won't touch it before then

fjh: dom, can go to PR w/o having that section in the document, as it's
documented elsewhere

dom: that shouldn't be a problem

... you're mixing Battery and Vibration

... but AnssiK is talking about HTML Media Capture

fjh: when we do transitions

... we need to include status/at risk

... we need to guess when we're done w/ LC comments

... we need to add Exit Criteria to the Status section

... and then having seen that, we publish as CR w/ transition request

... i just wanted to confirm w/ dom that we don't need to republish

... going forward, every doc should have status when we go to CR

dom: that's correct

... do we have any visibility on who is going to implement the spec?

... i know chrome has an impl based on the old spec

... i'm unclear about BlackBerry

... i know Firefox does accept attribute as well

AnssiK: we have discussion in the html bug tracker

... mounir doesn't say they will implement

... but says that the spec is simple and efficient and they like it

... Josh_Soref could comment on BlackBerry

Josh_Soref: need to check with our implementers

dom: anyone know about Chromium/Opera ?

AnssiK: i think Tizen implements

fjh: i thought I saw that as well

<AnssiK>
[http://www.w3.org/2009/dap/wiki/ImplementationStatus#HTML_Media_Capture][32]

fjh: AnssiK, how hard would it be to indicate if it's an implementation

... or just a note

AnssiK: yeah yeah

... when i notice someone is mentioning it, i try to include

... perhaps this should be more like caniuse.com

fjh: when i look at the list, i don't know if we're good to go

... maybe you can add text to the wiki

AnssiK: i haven't always looked at the source code

... and without the product in my hand, it's hard to know what is the level

... i'll try to dig deeper

fjh: just trying to understand what the wiki is saying

AnssiK: the wiki is pointers to implementations that claim to support these
specs

... but levels and spec version is missing

fjh: so this isn't a list of vetted implementations

... it's a list where somewhere someone mentioned they might

<AnssiK> "Implementations cited in this document may or may not implement the
latest version of the related specification."

fjh: when you have more details, it'd be helpful if you add them to the wiki

AnssiK: Josh_Soref, what is the status of BlackBerry on Media Capture

... I received a BB10 device

<Zakim> dom, you wanted to ask about testing

Josh_Soref: i'm hoping to talk to devrel guys tomorrow

dom: for that spec, we probably want to do some testing

... has anyone done any work on testing?

... are there existing testcases?

AnssiK: i'm going to use the BlackBerry Dev Alpha device to see if it has
anything

... i have the Vibration test suite to do

... dom, do you have ideas for the interactive tests?

... how to craft interactive tests for these specs

... there are implementation details that you're unable to test

dom: i see two kinds of tests

... IDL level

... parsing/handling

... interaction between Accept and Capture

... and then there's an interactive part

... i'd simply say in the test itself

... when you press the button, you should be offered to get a picture from
your camera

... and then maybe testing the file type

AnssiK: thanks, that matches what i was thinking about

... the idl is simple, so idlharness or manual tests

... and for interactive, something like you described

dom: i think separate actions for separate test suites is more actionable

<fjh> **ACTION:** anssik to create test cases for battery and vibration
[recorded in [http://www.w3.org/2013/03/06-dap-minutes.html#action01][33]]

<trackbot> Created ACTION-620 - Create test cases for battery and vibration
[on Anssi Kostiainen - due 2013-03-13].

AnssiK: let's do another action

<fjh> close ACTION-620

<trackbot> Closed ACTION-620 Create test cases for battery and vibration.

<AnssiK> **ACTION:** AnssiK to create test cases for HTML Media Capture
[recorded in [http://www.w3.org/2013/03/06-dap-minutes.html#action02][34]]

<trackbot> Created ACTION-621 - Create test cases for HTML Media Capture [on
Anssi Kostiainen - due 2013-03-13].

dom: the HTML WG is making a change to their test suite

... giving up the submitted/approved structure

... have we discussed migrating this group's tests?

fjh: i was thinking of wait-and-see

dom: i think it's working reasonably well for them

### Vibration test progress

Josh_Soref: vibration is stuck because it's submitted but not accepted

<fjh> would like to see focus on actual work rather than logistics unless it
is low effort to make the changes

Josh_Soref: AnssiK now has a bb10 with it

AnssiK: i'm testing it, but it seems to indeed be implemented

... it is buzzing

... good work guys

### OMA Liaison

<fjh> ACTION-613?

<trackbot> ACTION-613 -- Frederick Hirsch to draft proposed OMA liaison
response -- due 2013-02-13 -- OPEN

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

fjh: dom reminded me that it might be appropriate to respond formally

... i'll draft a response

### Privacy

<fjh> PING feedback : [http://lists.w3.org/Archives/Public/public-device-
apis/2013Feb/0095.html][36]

<fjh> Possible updates to Proximity and Ambient Light Event specs

fjh: i believe this message captures their feedback accurately

... specs aren't used in isolation

... npdoty offered to help

... The ability to fingerprint based on timing might not be the easiest way

Josh_Soref: there is another advantage re privacy timings

... if an application is written to a single implementation

... it could break if another implementation has different timings

... if the spec encouraged a single timing behavior

... then an application could be less likely to break when it interacts with a
different implementation

fjh: in GeoLocation there's an idea of lying

... that might also apply to these other apis

Josh_Soref: it should apply to these apis as well

... capture being an example

... -- letting the user select an already available object

fjh: the other concept from GeoLocation is Fuzzing

... giving a less accurate value

... we did that with ambient light

<fjh> in HTML Media Capture you could opt out by defaulting to file picker
instead of using camera device

<AnssiK> "When the capture attribute is specified, the user agent SHOULD
invoke a file picker of the specific capture control type."

Josh_Soref: note that it's a "File Picker" of a "Capture Type"

... certainly BlackBerry systems where the file picker gives access to both
Gallery and Camera/Mic does this :)

fjh: we received Feedback from PING about Proximity/Ambient light

... with specific approaches we should take

... should we try to take a pass through the spec to see if we can incorporate
that before moving forward?

<fjh> "there should be an indication to the user when the sensors are used"

Josh_Soref: Ambient could have been designed as a Media Query

... but you can certainly detect Media Query states

<fjh> "disable sharing proximity information"

Josh_Soref: browsers have spent 20 years trying to design the lock icon

... and some low level specs have UI requirements which were *never*
implemented

dom: we generally avoid putting normative text in about UI

fjh: but we put in consideration sections?

dom: do we put an indication in to suggest to the user that it's in use?

... we claim that these are generally QoI

Josh_Soref: we could point to implementations which have done something for
indications

<fjh> I suggest we should take the PING input and see what changes we should
make to the specs, such as the privacy considerations

Josh_Soref: e.g. the current Chrome (Canary) shows you what's allowed/has been
used if you click the Lock Icon

<fjh> also need to follow up with nick on general considerations

<fjh> **ACTION:** fjh to follow up on concrete actions based on PING input
[recorded in [http://www.w3.org/2013/03/06-dap-minutes.html#action03][37]]

<trackbot> Created ACTION-622 - Follow up on concrete actions based on PING
input [on Frederick Hirsch - due 2013-03-13].

<dom> [Chrome permissions][38]

AnssiK: i think we should be concrete

fjh: i'd appreciate if people could respond to the message on the list

### Action Review

<fjh> ACTION-617: [https://www.w3.org/2002/09/wbs/43696/2013-06-f2f/][24]

<trackbot> Notes added to ACTION-617 Set up f2f questionnaire.

<fjh> close ACTION-617

<trackbot> Closed ACTION-617 Set up f2f questionnaire.

<fjh> ACTION-618: [http://lists.w3.org/Archives/Public/public-device-
apis/2013Mar/0001.html][39]

<trackbot> Notes added to ACTION-618 Provide sotd text for battery, vibration
status updates.

<fjh> close ACTION-618

<trackbot> Closed ACTION-618 Provide sotd text for battery, vibration status
updates.

<fjh> ACTION-619: [http://lists.w3.org/Archives/Public/public-device-
apis/2013Mar/0002.html][31]

<trackbot> Notes added to ACTION-619 Follow up with Doug re closing HTML Media
Capture LC Comments.

<fjh> close ACTION-619

<trackbot> Closed ACTION-619 Follow up with Doug re closing HTML Media Capture
LC Comments.

### Other Business

<fjh> none

### Adjourn

trackbot, end meeting

## Summary of Action Items

**[NEW]** **ACTION:** anssik to create test cases for battery and vibration
[recorded in [http://www.w3.org/2013/03/06-dap-minutes.html#action01][33]]

**[NEW]** **ACTION:** AnssiK to create test cases for HTML Media Capture
[recorded in [http://www.w3.org/2013/03/06-dap-minutes.html#action02][34]]

**[NEW]** **ACTION:** fjh to follow up on concrete actions based on PING input
[recorded in [http://www.w3.org/2013/03/06-dap-minutes.html#action03][37]]


[End of minutes]

* * *

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

$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/2013Mar/0004.html

   [4]: http://www.w3.org/2013/03/06-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]: #item12

   [18]: #item13

   [19]: #ActionSummary

   [20]: https://www.w3.org/1998/12/bridge/info/name.php3

   [21]: https://lists.w3.org/Archives/Member/member-device-
apis/2013Mar/0001.html

   [22]: http://lists.w3.org/Archives/Public/public-device-
apis/2013Feb/att-0093/minutes-2013-02-27.html

   [23]: http://lists.w3.org/Archives/Public/public-device-
apis/2013Feb/att-0098/minutes-2013-02-20.html

   [24]: https://www.w3.org/2002/09/wbs/43696/2013-06-f2f/

   [25]: https://www.w3.org/2002/09/wbs/43696/2013-06-f2f/results

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

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

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

   [29]: http://www.w3.org/2012/sysapps/drafts/contacts-manager-api/

   [30]: http://www.w3.org/2009/dap/wiki/ImplementationStatus#Contacts_API

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

   [32]:
http://www.w3.org/2009/dap/wiki/ImplementationStatus#HTML_Media_Capture

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

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

   [35]: http://www.w3.org/2009/dap/track/actions/613

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

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

   [38]: http://www.digitallanding.com/wp-content/uploads/2012/12/Chrome-
Permissions.jpg

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

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

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