20:36:24 RRSAgent has joined #webrtc 20:36:24 logging to http://www.w3.org/2012/02/01-webrtc-irc 20:36:25 RRSAgent, make logs world 20:36:27 Zakim has joined #webrtc 20:36:29 Zakim, this will be 20:36:29 I don't understand 'this will be', trackbot 20:36:32 Meeting: Web Real-Time Communications Working Group Teleconference 20:36:34 Date: 01 February 2012 20:38:00 Meeting: Web Real-Time Communications Working Group F2F in Mountain View, CA, USA 20:50:51 Agenda: http://www.w3.org/2011/04/webrtc/wiki/February_1_2012 20:50:56 Chairs: Stefan, Harald 21:00:30 stefanh has joined #webrtc 21:05:57 richt_ has joined #webrtc 21:06:42 derf has joined #webrtc 21:11:08 burn has joined #webrtc 21:11:20 nstratford has joined #webrtc 21:11:29 dom: how do I set the scribe? 21:11:36 ScribeNick: anant 21:11:42 s/dom:/dom,/ 21:11:42 thanks 21:11:53 fluffy has joined #webrtc 21:12:42 First topic: publish new WD 21:12:50 JonathanLennox has joined #webrtc 21:13:12 stefanh: the first draft is continuously updates, are there any objections to publishing the current version of the ED as a WD? 21:13:23 s/First // 21:13:24 no objections noted 21:13:53 harald: we should push a new version of the WD when we have JSEP documented in the editor's draft 21:14:01 Ted_Hardie has joined #webrtc 21:14:20 topic: Incoming Notifications by Dan Druta 21:14:36 Just as a reminder for those used to WEBRTC methods, all the decisions from the RTCWEB meeting will need to be confirmed on the list. 21:14:49 adambe has joined #webrtc 21:15:18 DanD: there was an informal discussion around notifications at w3c, following which I sent out a paper to the mailing list detailing the problem 21:15:33 s/w3c/TPAC 21:16:39 DanD: the main idea with this is to allow unsolicited notifications for incoming connection requests in WebRTC clients 21:17:03 DanD: To make notifications available without user visible UI, and in a variety of different clients(and browsers) 21:18:14 DanD: Presenting 2 use cases. 1) Bob uses Ringo's webrtc service on a mobile phone, calls alice and leaves a voice mail; Alice calls Bob later (and Bob, on a different webrtc-enabled client is able to receive it via a notification) 21:18:25 2nd use on slide, missed the transcription 21:19:24 DanD: Factors to consider while designing a notification system: multiple connection on battery constrained devices, web development effort to use them should be minimal, webapps working group has an API for server-sent events which could be extended 21:20:18 DanD: discussing client scenarios. simplest one in which the user is available, online with the app in front (easy). second one is which the user is online and available but the app is in the background 21:21:00 jesup|laptop has joined #webrtc 21:21:04 mreavy has joined #webrtc 21:21:21 DanD: third one is when the user is available, but the app is closed. by available, it means the user has expressed an intent to receive incoming notificaions 21:23:09 anant_ has joined #webrtc 21:23:16 jesup_ has joined #webrtc 21:23:19 richt has joined #webrtc 21:23:23 mreavy_ has joined #webrtc 21:23:44 2nd option is to use an existing solution, not particularly preferable by members in the past 21:24:01 derf has joined #webrtc 21:24:25 3rd option is to define a notifications spec and define a basic structure for notifications 21:25:04 DanD: proposal is to register a URI scheme or data format (MIME) and associate the browser as the handler 21:25:41 DanD: Create an API to parse this notification structure and for applications to attach themselves to certain notification events 21:26:03 DanD: proposal was also sent to the webapps WG, members are requested to read it 21:27:11 DanD: Could we implement the API as headless browser? No, because you would need to create a new browser for every notification service and it doesn't tie it well to the PeerConnection API 21:27:59 DanD: Can we use sendMessage so that it isn't tied to the browser 21:28:05 opening up for questions 21:28:36 juberti: we have an asynchronous channel via websockets, signaling is an application provide issue. what are we trying to solve here? 21:29:00 s/provide/provider 21:29:13 DanD: Websocket solutions assume that the browser is running, not applicable to devices where the app is not running 21:29:39 juberti: there are already solutions to run web pages in the background, why not use that? 21:30:06 DanD: but those assume that the app is running on the client, which may not be true, especially on mobile? 21:30:15 juberti: it's what desktop clients do 21:30:27 DanD: Each individual connection on mobile costs battery 21:31:08 stefanh: you suggested that the incoming notification should be connected to the PeerConnection, should it not tie in to other parts of the API? 21:32:56 nstratford has joined #webrtc 21:32:57 Cullen: I think the most important part about this is aggregating connections, we can copy the iOS model by making one connection to each aggregation source which pushes down blobs from the app (signed) and use webintents model to then dispatch them to apps. this allows flexibility in allowing apps to register themselves for particular intents 21:33:12 Adam: is this a webrtc problem or is this is a problem in general? 21:33:22 Adam: Chat applications could use something like this to 21:33:25 s/to/too 21:34:03 Adam: this feels a bit like the JavaME push registry 21:34:29 DanD: if we look at the two use cases there is definitely a gap regarding notification 21:35:03 burn has joined #webrtc 21:35:14 DanD: the keyword in the proposal is connection-less push, there are ways today to achieve this in efficient manners 21:36:22 DanD: there still has to be a way for user A to notify user B that they are available 21:36:39 DanD: the problem space is larger, webrtc is a subset that can benefit and is the primary beneficiary of notifications 21:37:14 juberti: I agree with Adam that there are many other applications that can use this and agree with Cullen that we can use many of the existing solutions for this 21:38:12 juberti: I don't understand why we are in the business of defining a notification service, when there are already ways for apps to do this using existing technology 21:39:08 juberti: contents of the notification should be a blob, structure need not be defined 21:39:18 DanD: defining the specific structure doesn't mean it has to be a laborious one 21:39:28 DanD: it's the gluing piece that's most important 21:40:20 ???: I agree this is a generic problem of how to allow webapps to use a generic notification service, what is the level of standardization that we can achieve? most existing system are proprietary anyway 21:41:09 DanD: I agree that this is a broader scope problem, but it also can be focused on particular requirements 21:41:27 DanD: That's one of the reasons I was looking into what the specific structure we need 21:42:20 DanD: is there a benefit of sending the offer blob, something to consider 21:42:49 ???: existing systems let you push blobs around, we don't need to specify what exactly the structure is, it could be application specific 21:43:40 DanD: what are the elements that are neccesary, and having a consistent behavior for what happens when someone is calling me would be nice to standardize 21:44:43 Ashish: can we handle the use-case where I want to get a notification from mom, doesn't matter what provider, some way of establishing an identity; only ring if she calls 21:45:09 stefanh: this group's core competence is not that; DanD: to my understanding, no 21:46:07 Adam: if you are running the webapp on your phone there has to be some level of trust 21:47:07 ekr: It is reasonable to have a system dispatch events to an app, and you have app-level permissions 21:47:22 juberti: do we know what the status is on bryan sullivan's proposal on sms events? 21:47:37 DanD: it was submitted at the last TPAC, do not know what the status is 21:47:47 juberti: it seems like that's the kind of place to work out this problem 21:48:37 rillian has joined #webrtc 21:48:48 hey, look at all the people 21:48:50 DanD: I was trying to recommend in the paper is to use webrtc use cases to accelerate that work, and if there are any specific elements of that spec to be captured (if need be) 21:49:10 DanD: let's piggy back on that proposal, do we need to do anything specific? and support that work in webapps WG 21:49:34 harald: conclusion from the chairs: there is generic work that needs to be done which is done elsewhere in the w3c, and we need to link there when it is done 21:50:14 cullen: that work is about sms, harald: no sms is just one channel 21:50:25 cullen: is the aggregation part being done elsewhere in the w3c? 21:50:38 harald: we will continue to monitor and figure stuff out 21:51:21 topic: JSEP 21:51:44 harald: we had a pretty clear decision at the IETF that the next version of the API draft be based on JSEP 21:52:14 ted: decisions at the IETF required confirmation on the mailing list 21:53:01 harald: we also need confirmation at w3c whether we accept IETF's recommendation or not 21:53:34 cullen: if we are moving away from 3264, myself and matthew kaufman have an alternative proposal that we would like to bring up 21:53:55 adam: do we have a recommendation for API? or is it a protocol? 21:54:33 harald: speaking as myself, we should sit down tomorrow and modify the spec, and experiment to see if it works 21:54:55 adam: is it necessary to put it in the spec to see if it works out? 21:55:30 juberti: things don't get implemented in chrome unless they are in a written spec that we can point at. we would like to see if jsep works, working build of chrome by Paris 21:56:16 harald: roap could be implemented without changes to webkit API, jsep is not like that 21:57:14 Mauro has joined #webrtc 21:57:15 derf: one of the things that the current API lacks (that roap brought clarity to) is the state machine from 3264, helps browser implementers figure out. JSEP as currently specced lacks a lot of those things, and I would like to see that fleshing out done before it is added to the draft 21:57:28 juberti: I would also like that fleshing out! 21:57:47 juberti: that will occur between now & paris but it doesn't need to block inclusion in spec 21:58:08 juberti: given the benefit of getting implementation experience, still worth doing 21:58:56 cullen: did not suggest that jsep not be iterated on and experimented in code, but we also have alternative proposals which need to be considered 21:59:55 stefanh: for larger changes to spec we need a consensus, I would like to see jsep fleshed out before inclusion 22:00:44 anant: does spec need to be in w3c for it to be in chrome? 22:01:08 anant: is there a req that the spec in w3c space or not (for the webkit people) 22:01:28 justin: don't know really 22:02:07 juberti: what do we gain by that instead of just reving the ED? 22:02:50 dom: I don't have a strong opinion on this, but there is a fair amount of work to put it in the editor's draft 22:04:11 juberti: we've already thrown away a lot of implementation in chrome already, additional proposal become available; but we should try what we have now and was recommended yesterday and move forward 22:04:26 dom: you're right but we don't have consensus on what the API looks like 22:05:17 dom: editor's draft must also look like what the group has consented to 22:05:42 cullen: I do not get why having this text in the ED is important, other than just having a document for implementors to look at 22:06:18 cullen: it's very difficult to evaluate if the spec is incomplete, what happens when setLocalDescription is called? 22:06:47 harald: how much time do you need for the alternative proposals? 22:07:17 cullen: lesser time than what it took for JSEP to form since the last interim (-3 weeks for Christmas!) 22:07:45 cullen: we shouldn't rule out a whole class of proposals based on that 22:08:15 cullen: it will be healthy to explore the range of possibilities 22:09:06 harald: im looking for a drop-date by which if we have no alternative proposals that we go forward with implementing JSEP 22:10:02 harald; we don't want to be in a situation like in december where we couldn't do anything while waiting for a proposal 22:11:19 tim: my fear (for putting the API in the spec) is that it's easy to put the API calls themselves but specifying the behavior is hard and will end up being whatever chrome implements 22:14:17 anant: need to have implementation first to demonstrate that it works. We need multiple implementations before we put into the draft. 22:14:34 anant: when we put it in a document it does not have to be the ED 22:15:45 juberti: the original version of the spec was something that didn't work, and that's why we had to make ROAP 22:17:25 cullen: matter of taste, how big things are before moving to the draft. there are exceptions to the spec but the history of the spec is that it was from the WhatWG 22:18:15 ted: one of the things i've heard in terms of this spec is that we want to get implementation experience, it would be nice to show what particular use cases an implementation tackles 22:19:24 ???: comment on JSEP/ROAP - IETF/W3C. I think they are an evolution for SDP and I think the IETF should define how the data flows but the W3C is defining the API there is overlap which is causing this debate 22:19:41 harald: a lot of the back and forth is exactly that process, I don't see any clear answer 22:20:52 ???2: we have made decision yesterday to move away from 3264, but isn't JSEP just an extension to offer/answer? independent of whether it's O/A there's a question of whether it's actually SDP that we used to define the paramters 22:21:19 Speaker is Christer 22:21:55 s/???2:/Christer:/ 22:22:36 s/???:/Mathieu:/ 22:24:25 harald: trying to get to some degree of conclusion. clearly we have some amount of work to do on the current jsep spec, we have to find a timeline for other proposals and criteria by which we judge whether they are better/worse than JSEP 22:24:38 harald: take it to the list! we'll get implementations and try it out somehow 22:26:37 looking at code samples for jsep 22:31:35 -> http://lists.w3.org/Archives/Public/public-webrtc/2012Jan/0093.html Code samples for JSEP/ROAP 22:36:48 Zakim has left #webrtc 22:38:25 If later on we a chance to discuss congestion interaction apis, this is the document to use: http://lists.w3.org/Archives/Public/public-webrtc/2012Feb/0000.html 22:48:45 discussion on getUserMedia vs. HW reservation of camera 22:49:39 what happens if several tabs have right to use camera, and suddenly many wants to use it 22:52:10 -> http://dev.w3.org/2009/dap/api-perms/ Permissions for Device API Access Editors draft 22:52:45 sorry, I meant: 22:52:54 -> http://dev.w3.org/2009/dap/perms/FeaturePermissions.html Feature Permissions "This document defines APIs for web pages to request permission to use privileged user agent features. " 23:11:27 Mauro has joined #webrtc 23:14:48 RRSAgent, draft minutes 23:14:48 I have made the request to generate http://www.w3.org/2012/02/01-webrtc-minutes.html dom 23:25:42 scribing 23:25:57 eric: to late for me to change my mind about scribing 23:26:02 ScribeNick: adambe 23:26:29 eric: hope you remember what happend before lunch 23:27:04 stefanh has joined #webrtc 23:27:35 eric: There may be times where a page want permanent, long term or short term access to input devices. 23:27:51 eric: We need an API to solve this. 23:29:26 eric: We need to be able to start setting up the call without revealing your IP address 23:29:52 eric: The server has your IP address 23:31:23 eric: I want to gather without staring ICE 23:31:50 oscar: The web server doesn't know your private address 23:33:56 eric: No ietf hum about identity 23:34:23 Mauro has joined #webrtc 23:34:46 eric: Want to make a plea for a structured PeerConnection configuration parameter 23:35:03 eric: That's all 23:36:07 -> http://www.w3.org/2011/04/webrtc/wiki/File:Rtcweb-security-w3c.pdf Eric's slides on WebRTC Security 23:36:31 -> http://www.w3.org/2011/04/webrtc/wiki/File:MediaStream_Security_1.pdf Randell Jesup's slides on MediaStream Security 23:36:50 jesup: We talked in the ietf about the bits on the wire 23:37:10 jesup: Who can access MediaStreams 23:37:20 jesup: We don't trust JS 23:38:12 -> http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/0464.html A very recent thread on trusted "installable" apps on public-webeapps 23:38:19 jesup: It doesn't help to secure the transport if the app can access your media and send it off to another location 23:39:37 jesup: MediaStream processing proposal will be affected by the ability to access local streams 23:39:52 jesup: Using Poker Stars as an example 23:40:27 jesup: Two players may want to have a private conversation 23:42:07 jesup: Media security adds value even if source of app is untrusten (e.g. distributen via USB stick) 23:43:01 -> http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/0466.html Jonas Sicking on installable Web apps and trust 23:43:01 jesup: Untrusten apps will be blocked from processing data from local media streams 23:43:41 jesup: Cross-origin can be used to limit the problem 23:44:18 jesup: Sandbox access to media streams 23:45:07 jesup: What level of MediaStream security is needed? 23:45:18 jesup: How to handle trusten vs. untrusted apps? 23:45:36 jesup: How does this key into the encryption model? 23:46:05 jesup: How much security are we loosing by letting the application access the keys 23:46:43 jesup: How does MediaStream security affect local processing 23:46:44 [I think with SDES, we probably have lost security against attacker, but I would still protect the MediaStream to avoid blunder from careless developers] 23:46:50 stefanh has joined #webrtc 23:49:44 cullen: I would prefer if an app had to request access to process local media 23:51:54 cullen: A common application is desktop/application sharing 23:52:54 cullen: Such an application could be restricted from accessing the data in a stream 23:53:06 harald: rhm.mmm.. 23:53:32 harald: We can't ask the users permission every time (it stinks) 23:55:10 harald: My impression is that it's not impossible to come up with an API that lets an app say that I'm not going to read the data from local streams 23:56:11 harald: There are limits on how energy we should spend on locks for paper doors. 23:59:25 oscar: What would be possible with a secure iframe in a unsecure page? 23:59:43 oscar: (the iframe handling MediaStreams)