01:05:23 RRSAgent has joined #dap 01:05:23 logging to http://www.w3.org/2012/03/21-dap-irc 01:05:32 RRSAgent, this meeting spans midnight 01:05:36 dsr has joined #dap 01:06:00 Deepanshu has joined #dap 01:06:09 ping 01:06:17 Present+ Deepanshu_Gautam 01:06:18 shan has joined #dap 01:06:19 RRSAgent, pointer? 01:06:19 See http://www.w3.org/2012/03/21-dap-irc#T01-06-19 01:06:30 RRSAgent, make minutes public 01:06:30 I'm logging. I don't understand 'make minutes public', darobin. Try /msg RRSAgent help 01:06:36 xingxin has joined #DAP 01:06:37 RRSAgent, make logs public 01:07:09 bryan_sullivan has joined #dap 01:07:16 Present+ dsr 01:07:17 Agenda: http://www.w3.org/2009/dap/wiki/F2F_Agenda_20-22_March_2012,_Shenzhen,_China 01:07:19 Samarth has joined #dap 01:07:31 Chair: Robin_Berjon, Frederick_Hirsch 01:07:33 present+ Bryan_Sullivan 01:07:33 Jungkee has joined #dap 01:07:40 Present+ Robin_Berjon, Frederick_Hirsch 01:07:40 Present+ Wonsuk_Lee 01:07:42 gao has joined #dap 01:07:46 Stephan_Steglich has joined #DAP 01:07:59 Present+ Jungkee 01:08:11 rrsagent, generate minutes 01:08:11 I have made the request to generate http://www.w3.org/2012/03/21-dap-minutes.html fjh 01:08:53 Present+ Soonbo_Han 01:08:54 aizu has joined #dap 01:08:54 gbillock has joined #dap 01:09:12 OliverD has joined #dap 01:09:29 Claes has joined #dap 01:09:32 zakim, this will be dap 01:09:33 Present+ Cathy_Chan 01:09:56 Present+ Claes_Nilsson 01:10:58 ray has joined #dap 01:11:04 present+ Stephan_Steglich 01:12:00 Scribe: Josh_Soref 01:12:01 Present+ Youngsun_Ryu 01:12:29 Topic: Media Capture 01:12:39 rrsagent, generate minutes 01:12:39 I have made the request to generate http://www.w3.org/2012/03/21-dap-minutes.html fjh 01:12:44 http://dev.w3.org/2011/webrtc/editor/getusermedia.html 01:13:07 http://www.w3.org/TR/capture-scenarios/ 01:13:49 http://www.w3.org/TR/html-media-capture/ 01:13:53 Meeting: DAP F2F Day 2 01:13:59 rrsagent, generate minutes 01:13:59 I have made the request to generate http://www.w3.org/2012/03/21-dap-minutes.html fjh 01:15:02 http://dvcs.w3.org/hg/dap/raw-file/tip/media-stream-capture/scenarios.html 01:17:44 gao has joined #dap 01:17:52 we will start with taking a look at MediaStream Capture Scenarios 01:18:11 then getusermedia, then html media capture 01:18:58 Bo_Chen has joined #dap 01:19:20 [ Bryan projects the MediaStream Capture Scenarios ] 01:19:41 Yuan has joined #dap 01:20:52 Darobin: Scenario 1 is photo upload 01:21:17 Bryan: I reviewed this document, and it's pretty good 01:21:59 richt has joined #dap 01:22:07 ... If we focus on the specific capabilities described in this document 01:22:12 Qiuling has joined #DAP 01:22:21 I'm in the bridge, but I can't hear anything. 01:22:29 ... I think we can go forward pretty quickly 01:22:33 dsr has joined #dap 01:22:34 Deepanshu, Could you open the bridge? 01:22:39 Present+ Rich_Tibbett 01:23:20 Present+ Oliver_Don 01:24:43 Fjh: this document is for the joint WebRTC. + DAP Task Force 01:25:11 ... The "Media Capture TF" 01:25:41 shunan has joined #dap 01:26:06 Fjh: WebRTC is working on streaming 01:26:36 ... This document was initially created to focus on DAP scenarios 01:27:16 Bryan: The design section (#5) 01:27:29 ... We'll need to make some decisions 01:28:07 ... Some of the items cover dependencies to HTML5 01:28:53 I'm in. Thanks:) 01:28:58 Darobin: Using the issues in the document to drive discussion seems to be the way to go 01:30:03 s/I'm in. Thanks:)// 01:30:05 Ok, I did. 01:30:57 s/Ok, I did.// 01:31:02 Bryan: there are levels of access that are granted 01:31:24 ... Initially you can't see anything 01:31:41 Richt: there's a proposal from Voxio 01:31:48 ... For capabilities 01:32:19 s/Voxio/Voxeo/ 01:32:24 ... Which is going to make fingerprinting too easy 01:33:10 Capabilities API proposal: http://lists.w3.org/Archives/Public/public-webrtc/2012Jan/0041.html 01:33:22 fjh: there appears to be a concern of fingerprinting related to the capability document being discussed in the task force 01:33:30 fjh: this is a concern 01:33:51 Darobin: we have serious concerns about the capabilities document and its implications on privacy 01:34:00 Device selection and capabilities discovery/setting are privacy-sensitive functions - as long as the user is in control of the initial access permission, I think those concerns are mitigated. 01:34:03 nwidell has joined #dap 01:34:05 fjh: what is the source of requirements for the capabilities API and document 01:36:04 darobin: capabilities API should not be exposed to untrusted sources 01:36:35 Darobin: so the WebRTC starting point is where DAP was two years ago? 01:36:43 Josh_Soref: yes 01:37:46 Richt: it's best to start from nothing and expose as little as possible, slowly adding 01:37:48 .. 01:38:00 s/..// 01:38:23 discussing 5.1.2 Issues related to privacy 01:38:53 Bryan: it's better to have the UA ask the user if it wants to expose cameras 01:38:54 WU has joined #DAP 01:38:57 mindong has joined #dap 01:39:10 ... And once you do, then you can provide some information 01:39:26 issue: capabilities API compatibility with web privacy and security, assuming untrusted, fingerprinting risk 01:39:27 Created ISSUE-125 - Capabilities API compatibility with web privacy and security, assuming untrusted, fingerprinting risk ; please complete additional details at http://www.w3.org/2009/dap/track/issues/125/edit . 01:39:36 ... If we recommend that there's a step by step process 01:39:58 Richt: I think that's a given 01:40:25 ... We have a build that has this, it's in Opera Mobile 12 01:40:26 .. 01:40:35 s/..// 01:40:43 Stephan_Steglich has left #DAP 01:40:47 ... And in a labs desktop build 01:41:09 ... The UI problem is understood by all browser vendors 01:41:19 ... It's a hard problem 01:41:27 fyi: http://dev.opera.com/articles/view/getusermedia-access-camera-privacy-ui/ 01:41:56 Bryan: I read the API and scenarios document at the same time 01:42:21 ... And thought about how we discussed pickers 01:42:40 Fjh: let's look at the conference call scenario 01:42:56 [ fjh reads section 2.5 ] 01:44:28 Fjh: it's talking about automatically selecting video based on who's speaking 01:44:55 Stephan_Steglich has joined #DAP 01:44:55 Josh_Soref: this is quite doable, Zakim can already tell us who's making noise 01:45:19 ... Selecting the video is a logical extension 01:45:56 Fjh: she (scribe) does what Josh does, pausing / rewinding 01:46:25 ... It would be interesting to analyze this from a privacy perspective 01:46:53 ... This document attempts to outline the capabilities needed to implement this 01:47:05 Most of this is app-specific and has no impact on the API AFAICT. 01:47:10 Jack has joined #dap 01:47:17 ... There's a whole bunch of stuff in this use case 01:48:24 Bryan: obviously when she receives the streams, she could save / record / etc. 01:48:58 Fjh: Harold sent an email to the list explaining that Streaming isn't so simple 01:49:56 ... The capabilities document is not this document, but it isn't documented outside the TF 01:50:35 s/documented/publicised/ 01:51:34 [ Preview ] 01:51:53 Bryan: I just reviewed the documents 01:52:03 ... I haven't sent comments yet 01:52:38 Thanks to the task force and Travis for a great job with the scenarios document 01:52:53 the DAP WG should review and comment on the issues, preferably on the task force mailing list 01:53:23 [ Pre-Processing ] 01:53:53 Richt: I have a demo 01:55:29 ... This issue quick demo 01:55:39 ... Nothing normative 01:56:21 [ getUserMedia ] 01:56:57 Richt: all browsers are experimenting with UIs 01:57:05 I have some comments I will send to the list. Overall I think the document is a useful overview of the capabilities/issues and if we focus on key capabilities the API can be very useful, without being initially too complex. 01:57:12 mindong_ has joined #dap 01:57:41 ... Mozilla demonstrated their UI, and it was very similar to our's 01:58:04 "hair check" - show still from camera in ok dialog, so you can decide on permission including this information in the decision 01:58:37 Webcam Toy demo: http://neave.com/webcam/html5/ 01:58:45 ... Although they included a "hair check" - a preview to see if your hair is out if place 01:59:04 e.g. re Pre-processing (monitoring of the input signal for various purposes, e.g. audio end-pointing, volume leveling/AGC, face/gesture recognition) - this is key to many of the use cases and usability of apps. Initially it should include boolean options (capture auto-start/pause and AGC). 01:59:12 ... The first visit to the page requests permission 01:59:31 ... And we're making permissions persistent 01:59:37 ... Per domain 01:59:55 input level events (e.g. threshold passing) or some realtime-updated attribute (input signal level) are very useful as well but perhaps advanced capabilities that can be deferred. 02:00:17 ... We're looking into domains that have user generated content 02:00:45 [ demo of live post-processing ] 02:01:33 Jack has joined #dap 02:03:43 Darobin: capturing a video from canvas will give you camera quality from 5 years ago 02:04:09 ... You want to use canvas as a view-finder 02:04:37 ... And capture from the underlying stream 02:04:57 ... We need something similar for audio 02:05:15 ... There are two apiece proposals 02:05:54 s/apiece/APIs/ 02:06:21 shows capture of video frame and post--processing on canvas, also ability to capture as photo 02:07:36 richt: face recognition demo - recognize specific face and add mustache automatically 02:11:03 I was thinking about platform support to find faces and extract video for them for use in conferencing apps. 02:12:25 * 9-something 02:12:46 bryan and rich note that simple api appropriate, as javascript and current standards can be used for this work, hardware should evolve to enable faster javascript processing for face recognition, robin notes certain opencl hardware should enable better performance as well 02:12:57 Do you need me to check his room number ? 02:14:46 ... The first visit to the page requests permission 02:14:46 ... And we're making permissions persistent 02:14:46 Darobin: capturing a video from canvas will give you camera quality from 5 years ago 02:14:46 ... You want to use canvas as a view-finder 02:15:17 s/Do you need me to check his room number ?// 02:15:57 ... And capture from the underlying stream 02:15:57 ... We need something similar for audio 02:15:57 ... There are two apiece proposals 02:15:57 Dsr: for the conferencing case 02:17:22 Apps may need to know and set the image capture options, so the section on Capture method selection is important (e.g. determining if the camera/device can capture RAW format for HDR postprocessing, or only JPEG), and to set the options via MediaStreamOptions) 02:17:34 ... Facial recognition? 02:17:58 ... Can you do that? 02:17:58 Richt: we have a demo of putting a mustache on people 02:17:58 Darobin: Mozilla had a demo, they cheated by looking at shirt color 02:17:58 Darobin: would you have been helped by Simd or OpenCL? 02:18:33 [ Scribe was disconnected ] 02:18:50 The options described in "Format detection" are important to reach consensus on, to support that capability-awareness for apps. 02:39:17 aizu has joined #dap 02:43:30 Topic: WoPhone OS 02:44:16 a12u has joined #dap 02:45:14 Qiuling has joined #DAP 02:46:18 Wonsuk has joined #dap 02:46:50 ping 02:46:53 s/ping// 02:48:17 [ Jing_Wu presents WoPhone OS - China Unicom ] 02:48:32 shunan has joined #dap 02:49:12 Jing_Wu: questions? 02:49:36 Richt: how do you run your Web applications? 02:49:38 . 02:49:49 s/.// 02:50:14 ... Are web applications trusted? 02:50:27 gbillock has joined #dap 02:50:31 ... Do you install with trust? 02:51:05 Jing_Wu: I think we're going with the installed model 02:51:52 http://www.w3.org/community/coremob/ 02:52:05 Darobin: The Core Mobile Platform CG is looking into which APIs should be supported first 02:52:08 fjh: thanks for presentation on WoPhone; questions regarding status of DAP specs should be discussed as part of the DAP F2F agenda, so that shouldhelp 02:52:14 s/shouldhelp/should help/ 02:52:37 fjh: if you have any remaining questions please ask tomorrow during the F2F 02:52:57 ... We have data on the most commonly installed applications for most platforms 02:53:26 ... We're going to define a level 0 and a level 1 02:54:10 Darobin: thanks 02:54:38 RB: in the CoreMob CG we will have level 0 which gives us a large majority of the most popular applications, and level 1 which gives us all of them 02:54:47 ... you are all encouraged to join 02:54:58 Topic: WebIntents Demonstration 02:55:21 Derek has joined #dap 02:55:29 gao has joined #dap 02:55:37 [ Class presenting ]] 02:55:57 s/]// 02:56:01 c/Class/Claes/ 02:58:28 s/Class/Claes/ 02:58:44 s!c/Class/Claes/!! 03:00:43 Claes: the client page sends postMessage commands 03:01:21 ... And the service uses UPnP to talk to the light 03:01:46 question: ack messages from the light ? answer is yes 03:02:46 Richt: is the message from the client a well known format? 03:04:20 Claes: it's speaking JSON and the service converts that to UPnP 03:04:44 ... Abstracting away the UPnP 03:05:05 gao has joined #dap 03:05:18 ... So you could speak to some non-UPnP thing 03:06:11 Richt: Could I use this to talk to my TV? 03:06:21 Claes: yes 03:06:49 Cathy: can you do UPnP eventing? 03:07:05 Claes: yes 03:07:54 Bryan: so do you have some native code? 03:08:10 Claes: yes 03:08:43 Bryan: can you do it in pure javascript! 03:09:06 Jack has joined #dap 03:09:09 q+ to talk about multicast discovery as restricted api 03:09:45 Claes: no 03:10:04 s/!/?/ 03:10:19 q? 03:10:31 fjh has joined #dap 03:10:34 Richt: it looks like this needs standardization 03:11:04 ... And integration with the Intents specification 03:11:42 ... We need a way to reach an address 03:11:49 http://people.opera.com/richt/release/specs/discovery/Overview.html -> Opera's Discovery Proposal 03:11:52 q? 03:12:01 Zakim has joined #dap 03:12:06 q+ dsr 03:12:22 ... And then you could speak to it directly 03:12:56 Bryan: could you do this with an internal web server? 03:13:27 Claes: of course, but we consider this more efficient 03:13:53 ack dsr 03:14:25 Dsr: a generic mechanism allows access to Bluetooth, Zigby, UPnP /ZeroConf 03:15:10 s/Zigby/Zigbee 03:15:11 Richt: why not allow low level access? 03:15:49 Dsr: do you want access to packet sniffing? 03:17:01 Richt: of course not 03:17:51 Josh_Soref: we decided yesterday that there would be a WebIntents compendium for UPnP 03:18:33 ... We could have similar for Bluetooth and others 03:18:56 Dsr: which forum for follow up? 03:19:12 Richt: WebIntents 03:20:26 Topic: Unknown 03:21:15 Won_Suk: tomorrow we'll talk about Tizen web API 03:21:44 Fjh: can we talk about html medi capture? 03:21:58 hints?? 03:22:29 s/medi/media/ 03:22:55 Darobin: Mozilla has implemented their own thing 03:23:00 dsr noted earlier that restricted API for multicast might be useful APIs 03:23:10 s/medi /media / 03:24:10 ... We noted that whomever implements first gets to pick names 03:25:22 ACTION: Robin to kill Media Capture API 03:25:23 Created ACTION-517 - Kill Media Capture API [on Robin Berjon - due 2012-03-28]. 03:27:06 i/can we/Topic: HTML Media Capture/ 03:29:22 Topic: Device orientation feedback to Geolocation.w3.org WG 03:30:04 [ Bryan presents dzung team's email ] 03:30:20 q+ to ask about QoI 03:30:59 s/team/tran 03:31:21 Re Sensor API feedback to GeoLoc (http://lists.w3.org/Archives/Public/public-device-apis/2012Mar/0097.html) 03:31:58 We need ability to integrate events from sensors to prevent event overload and processing overhead of doing this in Javascript. 03:32:10 q? 03:32:14 q+ 03:32:25 q+ fjh 03:32:40 Some simple type of controls would be IMO essential for an effective sensor API. 03:33:23 Fjh: part of this thread was impact on battery life and whether sensor is on it 03:33:33 ... But this seems implementation dependent 03:34:21 Bryan: for the part we give to the geolocation WG 03:34:28 ... What's missing 03:35:27 ack Josh_Soref 03:35:27 Josh_Soref, you wanted to ask about QoI 03:35:33 ack fjh 03:35:55 ... If an implementer is firing events into the application, isn't that more expensive than filtering earlier 03:36:20 josh_soref: yes, want browers to filter earlier, but more work, simpler to pass what is from OS 03:36:42 josh_soref: react to feeback as approach is often taken 03:37:29 josh_soref: app asks for something, implemented, then discover getting too much information then ask for simpler API 03:37:46 ... analogy to drown then ask for less, so point is to start with less in API, not more 03:38:30 ... don't micromanage a firehose 03:39:46 Richt: the android system lets you manage flow by application class 03:40:14 ... Is sensors a wolf in sheep's clothing? 03:40:37 Darobin: and are we losing sense of security 03:41:03 The Sensors API is simply a rebranding of Systems Information API without addressing the problems of that approach. 03:41:06 Fjh: there was a request for generic API 03:41:19 i.e. losing focus on use cases for the individual sensors. 03:41:25 that enabled extension to new as yet unidentified sensors 03:41:41 ... So you have an api for when you don't know how it will be used 03:41:56 does understanding threat model depends on specifics or can it be generic to sensors 03:42:10 q+ 03:42:14 ack richt 03:42:17 Darobin: we should have a collection box for when people ask for a generic 03:42:33 ack fjh 03:42:47 ack fjh 03:43:05 Bryan: on the one hand, postMessage is generic 03:43:16 some sensors read, some act 03:43:24 ... But we don't like sensors as generic 03:43:31 s/some sensors read, some act// 03:43:38 q+ 03:43:47 ack Claes 03:44:20 Darobin: there's a difference between geolocation and temperature 03:45:03 Claes: discovering sensors using technology Intents, model makes sense to me 03:45:45 Bryan: you'll have middle ware on the device 03:45:58 ... Which will be used 03:46:18 ... If we don't facilitate sensor access 03:48:09 Bryan: I'm good with not rehashing old ground 03:48:13 ack richt 03:48:51 josh_soref: look how we simplified network info, likely to need to simplify sensors as well 03:49:01 bryan: agree, need prototyping 03:49:11 richt: need to see implementations 03:51:06 Richt: Josh_Soref is right, we need to shred apis and rebuild to address use cases instead of apiece requests 03:51:31 s/apiece/apis 03:51:39 ... We accept documents to CVS 03:52:14 ... It's really hard to get rid of them 03:53:01 Darobin: the point Josh_Soref made about network information 03:53:25 ... Is that we aren't reviewing things 03:54:05 ... When we do, tell output is better, but doesn't look like the initial input 03:54:21 jerry has joined #DAP 03:54:33 ACTION: Frederick to send a CfC about changing the design of Sensors 03:54:34 Created ACTION-518 - Send a CfC about changing the design of Sensors [on Frederick Hirsch - due 2012-03-28]. 03:54:49 Fjh: we need a CfC to explain why the proposed approach is the wrong way 03:55:20 s/tell/the/ 03:56:16 Richt: should something based on discovery be suggested? 03:56:19 Stephan_Steglich has joined #DAP 03:56:47 Claes: yes, maybe based on Intents 03:57:33 Bryan: once you get it, how do you talk to 03:57:50 you treat a generic sensor as a service. 03:58:06 Josh: my hope is that we deal with this via intents. 03:58:08 s/explain why the proposed approach is the wrong way/obtain agreement to discontinue work on current Sensor API spec as-is, review different cases, refactoring use of webintents etc 03:58:13 I can agree in principle that to progress work on sensors that if the only way is to work on individual specs, we should do that at least. 03:58:28 we do not want WG members to devote resources on work that might no progress or be implemented as is 03:59:05 Josh: for example a get temperature intent, and each individual sensor ends up with its own intent. 04:00:39 I would recommend though that if we have consensus on the usefulness of discovering what sensors are accessible (e.g. via Web Intents), then that work should also proceed. Accessing the specific sensors then could be individual spec work. 04:01:07 http://lists.w3.org/Archives/Public/public-web-intents/2011Nov/0011.html - example B\ 04:01:26 Bryan: for each sensor, how would you implement it as a service, as a XHR, or what? 04:01:32 ^-- Josh's example for exposing temperature sensor via Intents. 04:01:43 s/B\/B/ 04:01:59 scribenick: dsr 04:02:36 dsr: it depends, you could use XHR, websockets, or whatever is appropriate. 04:03:40 Josh talks through an email with thermometer as an example of a web intent. 04:04:34 q+ 04:04:46 q+ 04:05:07 This is an email from 21 Nov 2011. 04:05:24 close ACTION-517 04:05:25 ACTION-517 Kill Media Capture API closed 04:05:42 This can be realized with a real sensor, or with a service exposed by a website. 04:05:59 close ACTION-297 04:05:59 ACTION-297 Draft up TZDate closed 04:06:38 Oliver: using web intents could result in exposing users to choices which aren't really important to them. 04:07:19 Bryan: if we can use a consistent model for web intents for sensors, that would be fine. 04:07:24 http://lists.w3.org/Archives/Public/public-web-intents/2011Nov/author.html 04:08:09 Josh: I sent off 5 parts via email to introduce the concepts involved in web intents. 04:08:10 close ACTION-397 04:08:10 ACTION-397 Coordinate with HTML WG chairs about Capture, include the HCG closed 04:08:18 http://lists.w3.org/Archives/Public/public-web-intents/2011Nov/0000.html 04:08:27 close ACTION-425 04:08:27 ACTION-425 Incorporate feedback for NetInfo, draft use cases and requirements section closed 04:08:59 close ACTION-479 04:08:59 ACTION-479 Take FeatPerms to ScriptLib to see if this is something that devs would be interested in, taking caveats from implementers into account closed 04:09:18 close ACTION-492 04:09:18 ACTION-492 Prod DavidA and Shane about feedback on Activities/Intents closed 04:09:22 Some suggestions for likely common intents, e.g. save, send, print, share, call, chat. Some of these are similar. 04:09:26 close ACTION-509 04:09:26 ACTION-509 Prepare gUM scenarios for publication closed 04:09:49 kensaku has joined #dap 04:10:06 I can end up printing to a file, where the result is like a share. 04:11:15 Josh talks about the sensor examples, e.g. get temperature, get orientation. 04:11:49 We will need multiple deliverables, including a best practices note. 04:12:38 http://lists.w3.org/Archives/Public/public-web-intents/2011Nov/0012.html 04:12:54 http://lists.w3.org/Archives/Public/public-web-intents/2011Nov/0011.html 04:13:54 web apps shouldn't know how/where the data was obtained. 04:14:48 We need a way for persistent user defined names. 04:16:15 Josh uses the term "hub" for assemblies of devices/services, e.g. a thermometer which knows where it is. 04:17:26 Users should be able to change the provider of a service without the application becoming aware of the change. 04:17:51 richt: RPC doesn't lend itself to hot swapping. 04:18:23 josh: consider example of a keyboard, the app only needs the key stroke stream. 04:18:47 swapping keyboards between keystrokes shouldn't effect the app. 04:18:54 Present+ Anssi_Kostiainen 04:20:17 the user agent may register services as it finds them in the background, but apps only become aware when requesting a particular intent. 04:20:18 http://lists.w3.org/Archives/Public/public-web-intents/2011Nov/0039.html 04:20:32 http://lists.w3.org/Archives/Public/public-web-intents/2011Nov/0038.html 04:20:42