14:08:57 RRSAgent has joined #dap 14:08:57 logging to http://www.w3.org/2012/12/05-dap-irc 14:08:58 RRSAgent, make logs world 14:08:58 Zakim has joined #dap 14:09:00 Zakim, this will be DAP 14:09:00 ok, trackbot; I see UW_DAP()10:00AM scheduled to start in 51 minutes 14:09:01 Meeting: Device APIs Working Group Teleconference 14:09:02 Date: 05 December 2012 14:09:40 Agenda: http://lists.w3.org/Archives/Public/public-device-apis/2012Dec/0002.html 14:10:01 fjh has changed the topic to: dap 3279 ; agenda http://lists.w3.org/Archives/Public/public-device-apis/2012Dec/0002.html 14:10:22 Chair: Frederick_Hirsch 14:10:34 Present + Frederick_Hirsch 14:10:48 s/Present + Frederick_Hirsch// 14:10:53 Present+ Frederick_Hirsch 14:11:17 Regrets+ Dominique_Hazael-Massieux 14:46:19 igarashi has joined #dap 14:48:06 Regrets+ Josh_Soref 14:48:52 Topic: Welcome, agenda review, scribe selection, announcements 14:49:39 richt has joined #dap 14:52:49 igarashi has joined #dap 14:57:41 UW_DAP()10:00AM has now started 14:57:48 +[IPcaller] 14:57:56 zakim, [IPcaller] is me 14:57:56 +fjh; got it 14:58:19 dtran has joined #dap 14:58:47 ccourtney has joined #dap 14:58:54 Present+ Colin_Courtney 14:59:28 + +1.757.825.aaaa 14:59:52 + +1.289.261.aabb 14:59:53 zakim, aaaa is ccourtney 14:59:54 +ccourtney; got it 14:59:56 +??P31 15:00:04 Zakim, aabb is Josh_Soref 15:00:04 +Josh_Soref; got it 15:00:14 Present+ Dzung_Tran 15:00:30 + +81.80.655.7.aacc 15:00:36 Regrets- Josh_Soref 15:00:39 lgombos has joined #dap 15:00:40 Jungkee has joined #dap 15:00:40 Clarke has joined #dap 15:00:42 scribe: Josh_Soref 15:00:43 regrets that I cannot attend the call today. 15:00:51 Present+ Tatsuya_Igarashi 15:00:52 Milan_Patel has joined #dap 15:00:53 Regrets+ richt 15:00:57 Present+ Jungkee_Song 15:00:59 + +25686aadd 15:01:00 RRSAgent, draft minutes 15:01:00 I have made the request to generate http://www.w3.org/2012/12/05-dap-minutes.html Josh_Soref 15:01:06 zakim, who is here? 15:01:06 On the phone I see fjh, ccourtney, Josh_Soref, ??P31, +81.80.655.7.aacc, +25686aadd 15:01:08 On IRC I see Milan_Patel, Clarke, Jungkee, lgombos, ccourtney, dtran, igarashi, richt, Zakim, RRSAgent, fjh, darobin, trackbot, slightlyoff, tobie, dom, timeless, Josh_Soref, 15:01:08 ... mounir 15:01:08 Present +Milan_Patel 15:01:18 sato has joined #dap 15:01:33 RRSAgent, make logs public 15:01:43 RRSAgent, draft minutes 15:01:43 I have made the request to generate http://www.w3.org/2012/12/05-dap-minutes.html Josh_Soref 15:01:55 + +1.781.534.aaee 15:01:58 AnssiK has joined #dap 15:02:10 Present+ naoyuki_sato 15:02:11 zakim, 534.aaee is me 15:02:12 sorry, lgombos, I do not recognize a party named '534.aaee' 15:02:22 zakim, aaee is lgombos 15:02:22 +lgombos; got it 15:02:28 + +1.858.651.aaff 15:02:28 Present+ Laszlo_Gombos 15:02:29 gmandyam has joined #dap 15:02:29 bryan has joined #dap 15:02:54 + +1.503.542.aagg 15:02:55 + +1.720.934.aahh 15:03:22 Zakim, where is +256? 15:03:22 country code 256 is Uganda 15:03:26 zakim, aagg is dtran 15:03:26 +dtran; got it 15:03:49 zakim, aadd is Milan_Patel 15:03:49 +Milan_Patel; got it 15:04:01 zakim +??P31 is igarashi 15:04:42 Zakim, aahh is me 15:04:42 +Clarke; got it 15:04:47 + +1.425.214.aaii 15:05:02 zakim, where is 425? 15:05:02 North American dialing code 1.425 is Washington 15:05:04 Zakim, where is +1425? 15:05:04 North American dialing code 1.425 is Washington 15:05:06 aacc is sato 15:05:11 zakim, aaii is bryan 15:05:11 +bryan; got it 15:05:30 Network Information API updated draft published: http://www.w3.org/News/2012#entry-9640 15:05:30 Proximity API Last Call publication planned for tomorrow. 15:05:30 Please complete F2F questionnaire for date of next F2F: https://www.w3.org/2002/09/wbs/43696/f2fQ12013/ 15:05:30 Reminder - no teleconference 19 December, 26 December, 2 January. 15:05:31 s/regrets that I cannot attend the call today.// 15:05:33 nkic has joined #dap 15:05:55 thanks Mounir for last minute updates to get the Network Information API published 15:06:27 gmandyam: I sent an issue for the network information 15:06:38 +??P41 15:06:40 fjh: i'll add an agenda item for it at the end 15:07:00 fjh: XXX 15:07:24 s/XXX/Network Information API/ 15:07:35 Topic: Minutes Approval 15:07:43 17 October - http://lists.w3.org/Archives/Public/public-device-apis/2012Oct/att-0042/minutes-2012-10-17.html 15:07:59 RESOLUTION: Minutes from 17 October are approved 15:08:02 F2F 1-2 November 2012 15:08:03 http://www.w3.org/2009/dap/materials/minutes-2012-11-01.html 15:08:03 http://www.w3.org/2009/dap/materials/minutes-2012-11-02.html 15:08:16 RESOLUTION: Minutes from F2F 1-2 November are approved 15:08:23 + +46.1.07.15.aajj 15:08:27 fjh: Josh_Soref just sent the minutes from last week 15:08:42 28 November 2012 http://lists.w3.org/Archives/Public/public-device-apis/2012Dec/att-0005/minutes-2012-11-28.html 15:08:43 +??P43 15:08:47 lets approve these next week 15:08:53 s/lets/let's/ 15:09:00 Topic: HTML Media Capture 15:09:01 nwidell has joined #dap 15:09:09 nwidell_ has joined #dap 15:09:16 Proposal with boolean - http://lists.w3.org/Archives/Public/public-device-apis/2012Nov/0097.html 15:09:42 I sent some comments http://lists.w3.org/Archives/Public/public-device-apis/2012Dec/0003.html 15:11:59 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 15:12:57 -bryan 15:13:15 anssi would you like to say anything about the update? 15:13:16 fjh: AnssiK, thanks for the new proposal 15:13:16 ... i think that was very helpful 15:13:16 ... i think your approach of making an unofficial draft was helpful 15:13:17 ... I sent some comments, I think they're editorial 15:13:20 +bryan 15:13:57 fjh: AnssiK, is there anything you want to add? 15:14:03 AnssiK: i'm looking for people to review the proposal 15:14:06 ... and +1 it 15:14:15 ... we should very quickly pick the approach we want to push 15:14:20 fjh: one comment i had 15:14:24 ... most were editorial 15:14:29 ... i think we can get rid of the note 15:14:40 ... and make it clear there's no precedence issue 15:14:54 ... and there was something about clarifying file v. media capture 15:15:01 ... i think the new examples are great 15:15:07 +q 15:15:24 ... i think it might be helpful to make it clear that it's a camera and not a generic file upload 15:15:33 AnssiK: are you referring to get getUserMedia? 15:15:51 fjh: I didn't see the element with the accept= and capture= attributes 15:15:56 AnssiK: they're basically continued 15:15:59 ... i'll make it clearer 15:16:05 fjh: i suspected that, but... 15:16:16 AnssiK: in order to not repeat stuff, i split it into a couple of example blocks 15:16:36 fjh: in each example, you should say which other previous blocks are relevant 15:16:47 AnssiK: the highlighter doesn't XXX 15:17:02 Present+ Niklas_Widell 15:17:12 fjh: examples build on eachother, and you don't want to replicate everything 15:17:29 ... but i think you should include some text indicating which things you're continuing 15:17:37 AnssiK: the reason i split scripts out of the html was 15:17:39 ... YYY 15:17:42 s/eachother/each other/ 15:17:51 q? 15:18:09 fjh: i didn't understand how you'd do a scanner with this approach 15:18:19 the reason for splitting examples: highlighter does not work if you have both HTML and JavaScript in the same example block 15:18:36 AnssiK: you just specify the mime type you want in the accept type 15:18:41 Josh_Soref: like image/tiff 15:18:49 AnssiK: and then have the capture= attribute 15:18:50 ack gmanyam 15:18:56 ack gmandyam 15:19:13 gmandyam: question for AnssiK 15:19:17 ... when we talk about precedence 15:19:21 ... accept over capture 15:19:27 ... how will that be done in practice? 15:19:32 I have proposal in my email for dealing with this 15:19:32 ... if there's capture=true 15:19:39 ... and accept=image/png 15:19:42 ignore capture if not possible 15:19:43 ... and there's no camera attached 15:19:51 AnssiK: probably we should remove that text all together 15:19:57 ... i forgot about that text 15:19:58 ... i'll remove it 15:20:04 ... i think fjh 's review covered that 15:20:08 fjh: yeah, i had a proposal for that 15:20:13 ... it's no longer precedence 15:20:25 ... it's "if the device doesn't have a means for capturing that mime type" 15:20:34 ... then it's effectively as if you don't have the boolean 15:20:37 gmandyam: that's fine 15:20:49 ... and we're ok with a web site being able to fingerprint with that? 15:20:57 ... it could detect the absence of capture devices? 15:21:01 AnssiK: actually, you can't 15:21:04 ... it's just an attribute 15:21:14 ... it won't increase the fingerprinting surface 15:21:14 in new version fingerprinting surface seems less, only a boolean 15:21:23 ... i don't see how this could be worse than the previous proposal 15:21:26 ... this is an improvement 15:21:36 fjh: i'd argue using a boolean gives much less information 15:21:43 wouldn't the user need to interact with the input to enable any fingerprinting data collection? 15:21:45 ... i'm not sure how you could figure it out 15:21:57 ... you don't have the specificity 15:22:04 ... we'll have to review all this stuff for privacy 15:22:11 ... but we have to get a draft in place first 15:22:16 ... i think the next step 15:22:20 any fingerprinting that depends upon user interaction would likely not scale 15:22:32 ... what i'd like to do is agree to make the unofficial draft the new editor's draft 15:22:40 ... we need to decide to adopt this new approach 15:22:47 ... and make a decision to publish a new WD 15:22:50 ... next week 15:22:55 ... because there's still edits to be done 15:23:04 ... i'd like to decide to go forward with this approach 15:23:09 ... too bad dom isn't on the call 15:23:18 +1 to the new approach 15:23:19 ... does anyone object to adopt the approach of using the boolean? 15:23:20 +1 to go forward with the new proposal 15:23:23 Josh_Soref: +1 to the new approach 15:23:44 RESOLUTION: WG agrees to adopt the approach taken in the new proposal of using the boolean for HTML Media Capture 15:23:54 fjh: please update the draft and make it the editor's draft 15:24:05 ... and then on next week's call, let's make a decision to publish a new WD 15:24:13 AnssiK: can we decide on the Publication Date? 15:24:21 fjh: let me check my calendar 15:24:23 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. 15:24:37 ... but you may need to update the ED if you get feedback 15:24:43 ... we're running close to the Pub deadline 15:24:49 ... i'd suggest we try to publish on the 18th 15:25:00 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. 15:25:19 AnssiK: please action me to give me the deadline in tracker 15:25:37 action: anssiK to update editors draft for HTML Media Capture using proposal and incorporating changes based on comments 15:25:37 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]. 15:26:11 RRSAgent, draft minutes 15:26:11 I have made the request to generate http://www.w3.org/2012/12/05-dap-minutes.html Josh_Soref 15:26:31 action: anssik to prepare updated WD of HTML Media Capture in preparation for publication on 18 December (assuming WG agreement 12 Dec) 15:26:31 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]. 15:26:46 fjh: thanks everyone, this is a major step forward 15:26:48 ... thanks AnssiK 15:27:02 ... does anyone have anything more on HTML Media Capture? 15:27:14 ... and AnssiK, please send out a message to the list that you've updated this 15:27:21 Topic: Network Service Discovery 15:27:34 fjh: there was discussion on the list 15:27:35 service name resolution? http://lists.w3.org/Archives/Public/public-device-apis/2012Nov/0098.html 15:27:42 zakim, who is here? 15:27:42 On the phone I see fjh, ccourtney, Josh_Soref, ??P31, +81.80.655.7.aacc, Milan_Patel, lgombos, +1.858.651.aaff, Clarke, dtran (muted), ??P41, +46.1.07.15.aajj, ??P43, bryan 15:27:45 On IRC I see nwidell_, nwidell, nkic, bryan, gmandyam, AnssiK, sato, Milan_Patel, Jungkee, lgombos, ccourtney, dtran, igarashi, richt, Zakim, RRSAgent, fjh, darobin, trackbot, 15:27:45 ... slightlyoff, tobie, dom, timeless, Josh_Soref, mounir 15:28:04 fjh: my take on it is that that has been resolved 15:28:10 Josh_Soref: I think cathy did resolve it 15:28:16 fjh: we might have a fingerprinting issue 15:28:22 zakim, aajj is nwidell 15:28:23 +nwidell; got it 15:28:31 ... there's an assumption that cathy made that reduces the risk of fingerprinting 15:28:31 s/printing issue/printing issue to review/ 15:28:37 ... but we should review that at some point 15:28:45 ... richt had comments 15:28:54 Naoyuki Review comments - http://lists.w3.org/Archives/Public/public-device-apis/2012Nov/0101.html 15:29:12 s/richt had comments// 15:29:20 fjh: we'll take this to the list 15:29:28 We need to review these comments and discuss on list, seeking comment from Cathy and Rich 15:29:38 Topic: Ambient Light 15:29:46 fjh: we had a CfC 15:29:48 ... but i had trouble getting in touch w/ dougt 15:29:53 ... but i wanted to include him 15:29:59 ... is anyone in touch with him? 15:30:11 ... is mounir on the call? 15:30:41 Topic: Network Information 15:30:45 fjh: we published an updated draft 15:31:05 ... gmandyam, is this a new issue? 15:31:17 Josh_Soref: this is the issue that we had discussed before 15:31:22 ... but which hadn't been raised into tracker 15:31:28 gmandyam: this is bandwidth estimation 15:31:46 ISSUE-128? 15:31:46 ISSUE-128 -- Need more description on how bandwidth should be estimated -- raised 15:31:46 http://www.w3.org/2009/dap/track/issues/128 15:31:47 [ fjh has issues with the issue tracker's raised status ] 15:32:13 -Clarke 15:32:32 fjh: i heard that it was highly implementation dependent 15:32:40 gmandyam: my suggestion is to just remove it 15:32:42 ... i don't think you can get it 15:32:50 ... my guess is one of two things will happen 15:32:59 ... there will be so much variability in how it is implemented 15:33:04 ... that developers won't rely on it 15:33:07 spec has note on metered, not bandwidth, http://www.w3.org/TR/2012/WD-netinfo-api-20121129/ 15:33:12 ... or developers can try to calculate it their own way 15:33:24 ... Navigation Timing has its own api 15:34:08 fjh: if implementations can figure it out, they can 15:34:15 ... if not, they provide infinity 15:34:20 s/they can/they can provide it, / 15:34:25 gmandyam: i don't see the point in standardizing something 15:34:37 ... that useragents claim they can provide, but which won't be accurate 15:34:46 ... he has a couple of notes 15:35:25 fjh: there's no note on bandwidth, because you can provide it, or give infinity 15:35:30 gmandyam: it isn't good enough to provide it if it's bad 15:35:42 ... or every browser has its own algorithm which yields different resluts 15:35:49 s/resluts/results/ 15:36:02 ... i'm confident that browsers won't provide consistent/reasonable values 15:36:17 gmandyam: how would you file a bug against browsers? 15:36:23 Zakim, who is making noise? 15:36:29 ok, concern is noted in section 1.2 outstanding issues 15:36:32 bryan: the accuracy of values can be tested 15:36:34 Josh_Soref, listening for 10 seconds I heard sound from the following: +1.858.651.aaff (27%), bryan (22%), ??P41 (18%) 15:36:46 Zakim, mute ??P41 15:36:46 ??P41 should now be muted 15:37:01 Zakim, who is on the call? 15:37:01 On the phone I see fjh, ccourtney, Josh_Soref, ??P31, +81.80.655.7.aacc, Milan_Patel, lgombos, +1.858.651.aaff, dtran (muted), ??P41 (muted), nwidell, ??P43, bryan 15:37:07 Zakim, aaff is gmandyam 15:37:07 +gmandyam; got it 15:37:18 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. 15:37:18 ISSUE-128 Need more description on how bandwidth should be estimated notes added 15:37:18 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." 15:37:26 gmandyam: if it's done in the UA, i don't think it's going to be accurate no matter what 15:37:56 ... if there's value, we can see how they do / how it's used 15:38:01 ISSUE-128: see http://dvcs.w3.org/hg/dap/raw-file/tip/network-api/Overview.html#outstanding-issues 15:38:01 ISSUE-128 Need more description on how bandwidth should be estimated notes added 15:38:02 bryan: as wireless technologies get better 15:38:12 ... i think you'll find much more stability (in LTE, LTE Advanced) 15:38:19 ... variability will become less of an issue 15:38:32 darobin has left #dap 15:38:32 gmandyam: mobility always screws up bandwidth estimation 15:38:44 ... you could go to wider bandwidth or narrower bandwidth systems 15:39:08 ... i think the way bandwidth is estimated should be discussed in the spec 15:39:18 ... if you say that, we have something to test against 15:39:26 fjh: there's an issue in the spec in 1.2 15:39:48 ... it is noted in the spec 15:40:14 gmandyam: the issue i raised is to specify how it's estimated 15:40:29 ... i don't think it should be left up to implementations alone 15:40:34 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. 15:40:34 fjh: adrianba made it clear 15:40:37 q+ 15:40:45 in the meantime I agree with adding some guidelines on estimation to the spec 15:40:46 ... If you're relying on the underlying platforms 15:41:06 gmandyam: what Qualcomm provides today 15:41:14 ... isn't always making its way to the high level OS 15:41:35 ... I don't think the HO OS takes advantage of what the modem provides 15:41:43 ... I think his point is valid to an extent 15:41:44 q+ 15:41:54 ... but I think it forces the UA to do its own estimation 15:42:06 fjh: would this problem be resolved if you treated the number as an estimated value 15:42:15 ... and an estimated error-precision 15:42:28 ... it seems what you're getting at is that we don't know what the precision is 15:42:33 ... a single number isn't good enough 15:42:46 gmandyam: having a single number isn't good enough 15:42:51 ... you have to understand how it's estimated 15:43:02 ... you're saying how it's estimated affects the number returned 15:43:14 ... maybe providing a software indicator of confidence 15:43:23 possible proposal - provide bandwidth + accuracy/precision estimate 15:43:25 ... my feeling is the way the spec is written 15:43:28 q? 15:43:35 ... it allows for a lot of variability 15:43:40 ack nwidell 15:43:41 ... and developers won't rely on it 15:43:47 ... and they'll go to Navigation Timing 15:43:59 q+ to say I'd like people to use Navigation Timing 15:44:07 nwidell: at TPAC we discussed this 15:44:20 ... bandwidth may not be addressing the right problem 15:44:30 ... what developers want to know is how good the connection is behaving 15:44:35 ... so they can adapt their content 15:44:41 ... that was mentioned by adrianba 15:44:50 ... many developers need some value they can handle 15:45:01 I thought Adrian suggested we need more thought on this 15:45:01 ... something that's useful 15:45:04 ... i spoke to people inside Ericsson 15:45:22 ... maybe this is something we should ask "developers" what kind of information would be useful to have 15:45:29 ... before we try to define something 15:45:40 ... potentially, what was raised by a colleague of mine 15:45:44 ... is maybe not bandwidth 15:45:53 ... but estimated bandwidth on the last leg 15:46:13 ... maybe that's something the native platform can handle efficiently 15:46:21 fjh: i assume you're assuming the last leg is the problem 15:46:31 q- 15:46:34 nwidell: i'm assuming the problem is often the last leg 15:46:46 s/the problem/the bottleneck and that is why it is interesting, otherwise not sure I understand why/ 15:47:04 do we need to clarify the use cae 15:47:10 nwidell: there was a Web Performance workshop 15:47:11 s/cae/case?/ 15:47:16 ... there may be stuff coming there that may be useful 15:47:53 - +81.80.655.7.aacc 15:48:05 lgombos: the browser isn't always on the same OS 15:48:17 ... the modem may not be easily accessible to the browser 15:48:34 fjh: it seems we need to define it in a way that isn't defined 15:48:51 ... either we don't provide bandwidth at all 15:48:58 ... we provide a standard way to categorize it 15:49:06 ... or provide a way to express error range 15:49:22 ... you shouldn't have to make assumptions about what's underneath 15:49:29 gmandyam: or recommend in the spec how the UA should estimate bandwidth 15:49:34 q? 15:49:38 ... so we'd have something to test 15:49:48 ... right now we don't know when a browser is compliant or not 15:49:50 ack Josh_Soref 15:49:50 Josh_Soref, you wanted to say I'd like people to use Navigation Timing 15:49:52 fjh: we need to test this 15:50:06 s/test this/test this, so need to think ahead how this might be done/ 15:50:35 josh_soref: at home using cell phone with uplink and wifi hotspot, laptop talks to phone to the internet, a common use case 15:50:49 ... last leg is wrong leg to test 15:51:10 ... assumption that there is a last leg that is useful is wrong 15:51:19 ... should use Navigation Timing 15:51:45 ... should see actual use cases, discussed and learned media streaming already has way to do this 15:51:58 +1 to need of clear use cases 15:52:22 josh_soref: use cases can be solved by Navigation Timing 15:52:26 -dtran 15:52:29 s/use cases can/most use cases/ 15:52:41 ... XXX? underflow and overflow 15:53:04 ... could have API asking if site is made available offline 15:53:50 ... ie. provide user an alternative to bandwidth estimation, by providing direct means to addressing use case 15:54:07 s/XXX?/video frame/ 15:54:14 fjh: if bandwidth isn't good enough 15:54:22 ... you probably want a way to address the overall problem 15:54:29 ... we should look at navigation timing 15:54:33 ... and we need UCs 15:54:46 ... i think we should take this discussion to the list 15:54:50 ... i'll kick it off 15:55:01 action: fjh to send summary and query to the list to start Network Information discussion 15:55:02 Created ACTION-602 - Send summary and query to the list to start Network Information discussion [on Frederick Hirsch - due 2012-12-12]. 15:55:45