[![W3C](http://www.w3.org/Icons/w3c_home)](http://www.w3.org/) # Device APIs Working Group Teleconference ## 05 Dec 2012 [Agenda](http://lists.w3.org/Archives/Public/public-device- apis/2012Dec/0002.html) See also: [IRC log](http://www.w3.org/2012/12/05-dap-irc) ## Attendees Present Anssi_Kostiainen, Bryan_Sullivan, Clarke, Colin_Courtney, Dzung_Tran, Frederick_Hirsch, Giri_Mandyam, Josh_Soref, Jungkee_Song, Laszlo_Gombos, Milan_Patel, Niklas_Widell, Tatsuya_Igarashi, naoyuki_sato Regrets Dominique_Hazael-Massieux, richt Chair Frederick_Hirsch Scribe Josh_Soref ## Contents * Topics 1. Welcome, agenda review, scribe selection, announcements 2. Minutes Approval 3. HTML Media Capture 4. Network Service Discovery 5. Ambient Light 6. Network Information 7. AOB * Summary of Action Items * * * Date: 05 December 2012 ### Welcome, agenda review, scribe selection, announcements scribe: Josh_Soref Network Information API updated draft published: [http://www.w3.org/News /2012#entry-9640](http://www.w3.org/News/2012#entry-9640) Proximity API Last Call publication planned for tomorrow. Please complete F2F questionnaire for date of next F2F: [https://www.w3. org/2002/09/wbs/43696/f2fQ12013/](https://www.w3.org/2002/09/wbs/43696/f2fQ120 13/) Reminder - no teleconference 19 December, 26 December, 2 January. thanks Mounir for last minute updates to get the Network Information API published gmandyam: I sent an issue for the network information fjh: i'll add an agenda item for it at the end ... Network Information API ### Minutes Approval 17 October - [http://lists.w3.org/Archives/Public/public-device-apis/201 2Oct/att-0042/minutes-2012-10-17.html](http://lists.w3.org/Archives/Public /public-device-apis/2012Oct/att-0042/minutes-2012-10-17.html) **RESOLUTION: Minutes from 17 October are approved** F2F 1-2 November 2012 [http://www.w3.org/2009/dap/materials/minutes-2012-11-01.html](http://ww w.w3.org/2009/dap/materials/minutes-2012-11-01.html) [http://www.w3.org/2009/dap/materials/minutes-2012-11-02.html](http://ww w.w3.org/2009/dap/materials/minutes-2012-11-02.html) **RESOLUTION: Minutes from F2F 1-2 November are approved** fjh: Josh_Soref just sent the minutes from last week 28 November 2012 [http://lists.w3.org/Archives/Public/public-device-apis /2012Dec/att-0005/minutes-2012-11-28.html](http://lists.w3.org/Archives/Public /public-device-apis/2012Dec/att-0005/minutes-2012-11-28.html) let's approve these next week ### HTML Media Capture Proposal with boolean - [http://lists.w3.org/Archives/Public/public- device-apis/2012Nov/0097.html](http://lists.w3.org/Archives/Public/public- device-apis/2012Nov/0097.html) I sent some comments [http://lists.w3.org/Archives/Public/public-device- apis/2012Dec/0003.html](http://lists.w3.org/Archives/Public/public-device- apis/2012Dec/0003.html) fjh: thanks very much for a good proposal Anssi, it is an improvement, thanks for making an unofficial version and redline, that was very helpful. I have some comments related to material from the old version that probably should be fixed in the revision anssi would you like to say anything about the update? fjh: AnssiK, thanks for the new proposal ... i think that was very helpful ... i think your approach of making an unofficial draft was helpful ... I sent some comments, I think they're editorial ... AnssiK, is there anything you want to add? AnssiK: i'm looking for people to review the proposal ... and +1 it ... we should very quickly pick the approach we want to push fjh: one comment i had ... most were editorial ... i think we can get rid of the note ... and make it clear there's no precedence issue ... and there was something about clarifying file v. media capture ... i think the new examples are great ... i think it might be helpful to make it clear that it's a camera and not a generic file upload AnssiK: are you referring to get getUserMedia? fjh: I didn't see the element with the accept= and capture= attributes AnssiK: they're basically continued ... i'll make it clearer fjh: i suspected that, but... AnssiK: in order to not repeat stuff, i split it into a couple of example blocks fjh: in each example, you should say which other previous blocks are relevant AnssiK: the highlighter doesn't XXX fjh: examples build on each other, and you don't want to replicate everything ... but i think you should include some text indicating which things you're continuing AnssiK: the reason i split scripts out of the html was ... YYY fjh: i didn't understand how you'd do a scanner with this approach the reason for splitting examples: highlighter does not work if you have both HTML and JavaScript in the same example block AnssiK: you just specify the mime type you want in the accept type Josh_Soref: like image/tiff AnssiK: and then have the capture= attribute gmandyam: question for AnssiK ... when we talk about precedence ... accept over capture ... how will that be done in practice? I have proposal in my email for dealing with this gmandyam: if there's capture=true ... and accept=image/png ignore capture if not possible gmandyam: and there's no camera attached AnssiK: probably we should remove that text all together ... i forgot about that text ... i'll remove it ... i think fjh 's review covered that fjh: yeah, i had a proposal for that ... it's no longer precedence ... it's "if the device doesn't have a means for capturing that mime type" ... then it's effectively as if you don't have the boolean gmandyam: that's fine ... and we're ok with a web site being able to fingerprint with that? ... it could detect the absence of capture devices? AnssiK: actually, you can't ... it's just an attribute ... it won't increase the fingerprinting surface in new version fingerprinting surface seems less, only a boolean AnssiK: i don't see how this could be worse than the previous proposal ... this is an improvement fjh: i'd argue using a boolean gives much less information wouldn't the user need to interact with the input to enable any fingerprinting data collection? fjh: i'm not sure how you could figure it out ... you don't have the specificity ... we'll have to review all this stuff for privacy ... but we have to get a draft in place first ... i think the next step any fingerprinting that depends upon user interaction would likely not scale fjh: what i'd like to do is agree to make the unofficial draft the new editor's draft ... we need to decide to adopt this new approach ... and make a decision to publish a new WD ... next week ... because there's still edits to be done ... i'd like to decide to go forward with this approach ... too bad dom isn't on the call +1 to the new approach fjh: does anyone object to adopt the approach of using the boolean? +1 to go forward with the new proposal Josh_Soref: +1 to the new approach **RESOLUTION: WG agrees to adopt the approach taken in the new proposal of using the boolean for HTML Media Capture** fjh: please update the draft and make it the editor's draft ... and then on next week's call, let's make a decision to publish a new WD AnssiK: can we decide on the Publication Date? fjh: let me check my calendar In terms of fingerprinting, I don't think Anssi's proposal makes thing worse than the previous version of HTML Media Capture. However, I don't see how it improves upon fingerprinting either. fjh: but you may need to update the ED if you get feedback ... we're running close to the Pub deadline ... i'd suggest we try to publish on the 18th I think it achieves what was the primary intention (based on my understanding) - resolving any conflicts between the accept and the old version of the capture attributes. AnssiK: please action me to give me the deadline in tracker **ACTION:** anssiK to update editors draft for HTML Media Capture using proposal and incorporating changes based on comments [recorded in [http://www.w3.org/2012/12/05-dap- minutes.html#action01](http://www.w3.org/2012/12/05-dap- minutes.html#action01)] Created ACTION-600 - Update editors draft for HTML Media Capture using proposal and incorporating changes based on comments [on Anssi Kostiainen - due 2012-12-12]. **ACTION:** anssik to prepare updated WD of HTML Media Capture in preparation for publication on 18 December (assuming WG agreement 12 Dec) [recorded in [http://www.w3.org/2012/12/05-dap- minutes.html#action02](http://www.w3.org/2012/12/05-dap- minutes.html#action02)] Created ACTION-601 - Prepare updated WD of HTML Media Capture in preparation for publication on 18 December (assuming WG agreement 12 Dec) [on Anssi Kostiainen - due 2012-12-12]. fjh: thanks everyone, this is a major step forward ... thanks AnssiK ... does anyone have anything more on HTML Media Capture? ... and AnssiK, please send out a message to the list that you've updated this ### Network Service Discovery fjh: there was discussion on the list service name resolution? [http://lists.w3.org/Archives/Public/public- device-apis/2012Nov/0098.html](http://lists.w3.org/Archives/Public/public- device-apis/2012Nov/0098.html) fjh: my take on it is that that has been resolved Josh_Soref: I think cathy did resolve it fjh: we might have a fingerprinting issue to review ... there's an assumption that cathy made that reduces the risk of fingerprinting ... but we should review that at some point ... Naoyuki Review comments - [http://lists.w3.org/Archives/Public/public- device-apis/2012Nov/0101.html](http://lists.w3.org/Archives/Public/public- device-apis/2012Nov/0101.html) fjh: we'll take this to the list We need to review these comments and discuss on list, seeking comment from Cathy and Rich ### Ambient Light fjh: we had a CfC ... but i had trouble getting in touch w/ dougt ... but i wanted to include him ... is anyone in touch with him? ... is mounir on the call? ### Network Information fjh: we published an updated draft ... gmandyam, is this a new issue? Josh_Soref: this is the issue that we had discussed before ... but which hadn't been raised into tracker gmandyam: this is bandwidth estimation ISSUE-128? ISSUE-128 -- Need more description on how bandwidth should be estimated -- raised [http://www.w3.org/2009/dap/track/issues/128](http://www.w3.org/200 9/dap/track/issues/128) [ fjh has issues with the issue tracker's raised status ] fjh: i heard that it was highly implementation dependent gmandyam: my suggestion is to just remove it ... i don't think you can get it ... my guess is one of two things will happen ... there will be so much variability in how it is implemented ... that developers won't rely on it spec has note on metered, not bandwidth, [http://www.w3.org/TR/2012/WD- netinfo-api-20121129/](http://www.w3.org/TR/2012/WD-netinfo-api-20121129/) gmandyam: or developers can try to calculate it their own way ... Navigation Timing has its own api fjh: if implementations can figure it out, they can provide it, ... if not, they provide infinity gmandyam: i don't see the point in standardizing something ... that useragents claim they can provide, but which won't be accurate ... he has a couple of notes fjh: there's no note on bandwidth, because you can provide it, or give infinity gmandyam: it isn't good enough to provide it if it's bad ... or every browser has its own algorithm which yields different results ... i'm confident that browsers won't provide consistent/reasonable values ... how would you file a bug against browsers? ok, concern is noted in section 1.2 outstanding issues bryan: the accuracy of values can be tested ISSUE-128: note in spec about issue is in section 1.2 Outstanding issues : "One concern is that bandwidth may be hard to implement, can be quite power- consuming to keep up-to-date and its value might be unrelated to the actual connection quality that could be affected by the server. ISSUE-128 Need more description on how bandwidth should be estimated notes added A solution to fix this would be to return non absolute values that couldn't be easily abused and would be more simple to produce for the user agent. For example, having a set of values like very-slow, slow, fast and very-fast. Another solution would be to have only values like very-slow, slow and the empty string." gmandyam: if it's done in the UA, i don't think it's going to be accurate no matter what ... if there's value, we can see how they do / how it's used ISSUE-128: see [http://dvcs.w3.org/hg/dap/raw-file/tip/network- api/Overview.html#outstanding-issues](http://dvcs.w3.org/hg/dap/raw-file/tip /network-api/Overview.html#outstanding-issues) ISSUE-128 Need more description on how bandwidth should be estimated notes added bryan: as wireless technologies get better ... i think you'll find much more stability (in LTE, LTE Advanced) ... variability will become less of an issue gmandyam: mobility always screws up bandwidth estimation ... you could go to wider bandwidth or narrower bandwidth systems ... i think the way bandwidth is estimated should be discussed in the spec ... if you say that, we have something to test against fjh: there's an issue in the spec in 1.2 ... it is noted in the spec gmandyam: the issue i raised is to specify how it's estimated ... i don't think it should be left up to implementations alone i would just suggest that we subject the implementations to testing, and if we have too much variability in the estimates, or bandwidth variability (over a short time) is determined to be a major limitation, we could drop it from the final spec. fjh: adrianba made it clear in the meantime I agree with adding some guidelines on estimation to the spec fjh: If you're relying on the underlying platforms gmandyam: what Qualcomm provides today ... isn't always making its way to the high level OS ... I don't think the HO OS takes advantage of what the modem provides ... I think his point is valid to an extent ... but I think it forces the UA to do its own estimation fjh: would this problem be resolved if you treated the number as an estimated value ... and an estimated error-precision ... it seems what you're getting at is that we don't know what the precision is ... a single number isn't good enough gmandyam: having a single number isn't good enough ... you have to understand how it's estimated ... you're saying how it's estimated affects the number returned ... maybe providing a software indicator of confidence possible proposal - provide bandwidth + accuracy/precision estimate gmandyam: my feeling is the way the spec is written ... it allows for a lot of variability ... and developers won't rely on it ... and they'll go to Navigation Timing nwidell: at TPAC we discussed this ... bandwidth may not be addressing the right problem ... what developers want to know is how good the connection is behaving ... so they can adapt their content ... that was mentioned by adrianba ... many developers need some value they can handle I thought Adrian suggested we need more thought on this nwidell: something that's useful ... i spoke to people inside Ericsson ... maybe this is something we should ask "developers" what kind of information would be useful to have ... before we try to define something ... potentially, what was raised by a colleague of mine ... is maybe not bandwidth ... but estimated bandwidth on the last leg ... maybe that's something the native platform can handle efficiently fjh: i assume you're assuming the last leg is the problem nwidell: i'm assuming the bottleneck and that is why it is interesting, otherwise not sure I understand why is often the last leg do we need to clarify the use case? nwidell: there was a Web Performance workshop ... there may be stuff coming there that may be useful lgombos: the browser isn't always on the same OS ... the modem may not be easily accessible to the browser fjh: it seems we need to define it in a way that isn't defined ... either we don't provide bandwidth at all ... we provide a standard way to categorize it ... or provide a way to express error range ... you shouldn't have to make assumptions about what's underneath gmandyam: or recommend in the spec how the UA should estimate bandwidth ... so we'd have something to test ... right now we don't know when a browser is compliant or not Josh_Soref, you wanted to say I'd like people to use Navigation Timing fjh: we need to test this, so need to think ahead how this might be done Josh_Soref: at home using cell phone with uplink and wifi hotspot, laptop talks to phone to the internet, a common use case ... last leg is wrong leg to test ... assumption that there is a last leg that is useful is wrong ... should use Navigation Timing ... should see actual use cases, discussed and learned media streaming already has way to do this +1 to need of clear use cases Josh_Soref: most use cases be solved by Navigation Timing ... video frame underflow and overflow ... could have API asking if site is made available offline ... ie. provide user an alternative to bandwidth estimation, by providing direct means to addressing use case fjh: if bandwidth isn't good enough ... you probably want a way to address the overall problem ... we should look at navigation timing ... and we need UCs ... i think we should take this discussion to the list ... i'll kick it off **ACTION:** fjh to send summary and query to the list to start Network Information discussion [recorded in [http://www.w3.org/2012/12/05-dap- minutes.html#action03](http://www.w3.org/2012/12/05-dap- minutes.html#action03)] Created ACTION-602 - Send summary and query to the list to start Network Information discussion [on Frederick Hirsch - due 2012-12-12]. ### AOB [http://dvcs.w3.org/hg/dap/raw- file/tip/proximity/LC.html](http://dvcs.w3.org/hg/dap/raw- file/tip/proximity/LC.html) are we on track to publish LC tomorrow? fjh: yes we're all set close ACTION-584 ACTION-584 Update F2F agenda for sensor next steps, network information, and to make invitations for mozilla participation closed fjh: i've done the submission ... it's all set to go ... i think we're done ... we'll meet again next week close ACTION-585 ACTION-585 Review Battery test and contribute more tests closed fjh: when hopefully we'll agree to publish an update to HTML Media Capture ... and we'll publish the update to Ambient Light ... thanks all close ACTION-589 ACTION-589 Send CfC for Last Call of Ambient Light Events closed close ACTION-593 ACTION-593 Build a survey for finding a week for DAP meeting March/April closed close ACTION-594 ACTION-594 Arrange publication of updated WD of Network Information API closed close ACTION-597 ACTION-597 Announce plans for LC publication to webapps, sys apps, ping closed Call scheduled for next week, 12 December 2012 trackbot, end meeting ## Summary of Action Items **[NEW]** **ACTION:** anssik to prepare updated WD of HTML Media Capture in preparation for publication on 18 December (assuming WG agreement 12 Dec) [recorded in [http://www.w3.org/2012/12/05-dap-minutes.html#action02](http://www.w3.org/2012/12/05-dap-minutes.html#action02)] **[NEW]** **ACTION:** anssiK to update editors draft for HTML Media Capture using proposal and incorporating changes based on comments [recorded in [http://www.w3.org/2012/12/05-dap-minutes.html#action01](http://www.w3.org/2012/12/05-dap-minutes.html#action01)] **[NEW]** **ACTION:** fjh to send summary and query to the list to start Network Information discussion [recorded in [http://www.w3.org/2012/12/05-dap-minutes.html#action03](http://www.w3.org/2012/12/05-dap-minutes.html#action03)] [End of minutes] * * * Minutes formatted by David Booth's [scribe.perl](http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm) version 1.137 ([CVS log](http://dev.w3.org/cvsweb/2002/scribe/)) $Date: 2012-09-20 20:19:01 $