23:33:14 RRSAgent has joined #webrtc 23:33:14 logging to http://www.w3.org/2015/10/29-webrtc-irc 23:33:31 RRSAgent, this meeting spans midnight 23:33:54 Meeting: WebRTC TPAC 2015 F2F Day 2 23:34:26 Agenda: https://www.w3.org/2011/04/webrtc/wiki/October_29_-_30_2015#Friday_October_30 23:34:47 Chair: Harald & Stefan 23:37:52 burn has joined #webrtc 23:39:11 kpfleming has joined #webrtc 23:39:46 yuwei has joined #webrtc 23:44:08 toddg has joined #webrtc 23:46:44 wonsuk has joined #webrtc 23:59:22 alan_iida has joined #webrtc 23:59:40 jxck has joined #webrtc 00:00:02 ekr has joined #webrtc 00:01:35 tomoyuki has joined #webrtc 00:02:20 toddg has joined #webrtc 00:08:42 juberti has joined #webrtc 00:08:48 iwashi has joined #webrtc 00:08:55 dom has joined #webrtc 00:09:11 scribenick: dom 00:09:29 [agenda bash] 00:09:34 Topic: Placement: Resolution of issues from Thursday's Transceiver preso 00:09:47 -> https://www.w3.org/2011/04/webrtc/wiki/images/7/75/Transceivers_Part_2.pdf Transceiver Part 2 slides from Peter 00:09:59 I have made the request to generate http://www.w3.org/2015/10/29-webrtc-minutes.html vivien 00:10:05 igarashi has joined #webrtc 00:11:26 Present+ Maire_Reavy 00:14:34 Remote people - yell if you can't hear. 00:14:48 Peter: coming back on a couple of new options for rollback 00:14:58 ... Option I is a refinement of the F from yesterday 00:15:01 what's the url for the webex? i'm having trouble connecting. 00:15:13 ... [description on slide 2] 00:15:22 juberti: https://mit.webex.com/mit/j.php?MTID=m128c5164edf8e2d747c34f2bc6cb3235 00:15:30 oonishi has joined #webrtc 00:15:51 mreavy: thanks 00:16:14 Martin: there is 2 things that create a transceiver: adding a track and receiving a remote description 00:16:24 ... when you do a rollback, you rollback only those created by the remote description 00:16:41 hta: I'm having a little trouble hearing Peter. I can follow, but if Peter could get closer to the mic, that'd be helpful. (In contrast, I can hear Martin quite well.) 00:16:43 juberti: np 00:16:47 ... if you have one that was created by the combination of these 2 things, you only reset the one created by the remote side of things 00:17:38 Present+ Dominique_Hazaël-Massieux, Shijun_Suny Peter_Thatcher, Varun_Singh, Eric_Rescorla, Martin_Thomson, Cullen_Jennings, Mathieu_Hofman, Alexandre_Gouaillard, Andrew_Hutton, VIiven_Lacourba, Dan_Burnett, Stefan_Håkansson, Harald_Alvestrand, Taylor_Brandstetter 00:17:46 I have made the request to generate http://www.w3.org/2015/10/29-webrtc-minutes.html vivien 00:18:20 lags has joined #webrtc 00:18:26 ekr: the ordinary rollback behavior is to return the state you were before 00:18:37 ... here, it's only half way backtracking 00:18:58 martin: we discussed this yesterday and had an option to rollback everything since the last stable state 00:19:12 ... but that includes things that were done even before reaching stable state 00:20:43 present+ Erik_Lagerway 00:20:49 cullen: when we said rolling back to 0 time, there are different states that need to be rolled back 00:21:00 ... some states are linked to the offer/answer, others aren't 00:21:17 ... rollback should be only about the former 00:21:42 ... things that haven't been applied to the offer/answer state machine shouldn't be impacted 00:22:08 jib has joined #webrtc 00:22:51 martin: the problem of doing otherwise is that a rollback rewrites history even further back to stable state 00:22:56 present+ Bernard_Aboba 00:23:24 ekr: with such an approach, do we actually need rollback? 00:23:39 martin: we need it, and we implement it that way 00:23:53 present+ Jan-Ivar_Bruaroey 00:24:02 cullen: [missed comment about pranswer] 00:24:05 present+ Randell_Jesup 00:24:14 martin: we're unlikely to implement pranswer 00:24:31 peter: we have it now, but we haven't implemented transceiver yet 00:24:47 mishizaw has joined #webrtc 00:24:59 cullen: I think we're at the point where we need to discuss whether to remove it 00:25:22 peter: I'd love to remove it 00:25:39 Bernard has joined #webrtc 00:25:52 cullen: if we're going to reopen these discussions, there are other decisions that would need to be revisited 00:26:07 peter: that probably needs to be discussed separately in any case 00:26:18 ... presenting the 2nd option, option J 00:26:55 ... which is forbidding rollback after setting description and calling addTrack after 00:27:38 ekr: the main reason of rollback is that sometimes you need to apply a description before you can decide whether it's good for you 00:27:54 hta: we discussed other cases yesterday beyond that 00:28:05 juberti has joined #webrtc 00:28:23 ... if we don't support rollback before or after addtrack (a "no return" point), it means that some error cases will have to be handled by tearing down the connection 00:28:27 ekr: which error cases? 00:29:13 hta: setRD is async, so things can happen between the call and the promise resolution that makes you think "I shouldn't have done that" 00:29:29 ekr: the Transceiver is created at the moment of the promise resolution of setRD 00:30:19 present+ Adam_Roach 00:30:40 hta: the question is whether you can get in trouble between addTrack and setLD 00:30:53 ekr: I'd like to see a concrete set of events 00:31:06 juberti: if there is no compelling use case, I think option J is nice and simple 00:31:23 ... we could always come back to this if there are use cases that require a more complex approach 00:32:00 ekr: do setRD, make sanity checks, do addTrack 00:32:14 martin: but sanity checks can be long and thus addTrack might need to be queued 00:33:43 cullen: the simplest scenario is: I send an offer, I add a track, the answerer doesn't understand my offer for any reason, and we need to rollback 00:33:53 ekr: but that's for setLD, not RD 00:34:23 juberti: I think for RD, you'll want to do your sanity checks before addTrack 00:34:44 hta: option J is looking good because it leaves us room for adding more stuff later if needed 00:35:35 cullen: this is deprecating rollback in a bunch of use cases 00:35:48 adamR: but we haven't identified any such use case 00:36:47 ekr: in the trivial case where I have an outsdanding offer with voice and I add video, and the audio call gets accepted, I'm now in onnegotiationneeded because it doesn't match the negotiation state 00:36:56 ... the question is what should I do if the offer is rejected? 00:37:10 ... how would you rollback? 00:37:18 mishizaw has joined #webrtc 00:38:01 ekr: [describing an example on the whiteboard] 00:38:16 ... A creates a datachannel, we exchange an offer/answer and get back to stable state 00:38:30 ... then I add track audio, send an offer 00:38:42 ... and then I add an video track 00:39:21 ... if instead of an answer, I'm getting a rollback, it would be have to get to negotiationneeded state 00:39:48 ... and this is addressed by option J 00:40:45 ... but the other case of stuff happening after setRD and addTrack doesn't seem very plausible 00:41:30 ... but even if the plausible case I described, it's not even clear how you can react 00:41:48 ... stepping back a little, I'm not even sure what rollback is useful for 00:41:57 adamR has joined #webrtc 00:42:10 cullen: adding/removing rejected streams is easy, modifying them is much harder 00:42:51 ekr: but recovering from a stream change will take a lot of logic 00:43:00 martin: the remote rollback case is harder to make 00:43:23 ekr: so we have a complex system to signal situations that are complex to recover from 00:43:50 present+ Justin_Uberti 00:43:50 ... not sure how useful that is 00:44:05 juberti: rollback is a way to reject things that we immediately realize we don't want 00:44:06 I have made the request to generate http://www.w3.org/2015/10/29-webrtc-minutes.html vivien 00:44:18 ... it's not clear that there is a value to use it for things lower down in the chain 00:46:04 ekr: one way of dealing with avoiding loops of negotiations is to freeze the latest stable session in a super-stable / immutable state 00:46:25 peter: we need to distinguish remote and local rollback 00:46:39 cullen: I think we all agree we need local rollback 00:47:00 martin: local is (mostly) useful for apply and reject 00:47:34 martin: option J will be enough if we deal with activateSender and look at other state changes (at least removeTrack) 00:48:05 cullen: the only thing that rollback affects is what is part of the negotiation 00:48:16 ekr: jesus what a mess 00:49:21 adamR: either the app is in charge of keeping track of state changes, or the browser gives affordance to it 00:49:26 martin: option I was for the latter 00:49:41 juberti: but option J gives us more freedom to evolve on this 00:49:49 martin: it's a cop-out 00:51:17 martin: option I was rolling back just the receivers 00:52:28 hta: my suggestion is let's adopt J, and someone wanting to propose something else will need to provide a use case 00:53:40 martin: I don't think only handling addTrack is enough 00:54:24 peter: any other modification (e.g. activate or remove) is not surprising 00:54:53 cullen: another way to put it is: if you modify the transceiver created by the remote description and do a rollback, you'll get surprises 00:58:27 peter: the only thing that can change a transceiver is addTrack 00:58:40 martin: not if I addTrack before setRD, and then do a removeTrack 00:58:57 peter: this would not connect the two transceivers 00:59:10 martin: I think JSEP say they would 00:59:39 ... when you create an answer, you go through the m-lines in the offer and find one that matches your track and reuse that transceiver 01:00:03 ekr: it would be very surprising otherwise 01:00:08 peter: not to me 01:00:16 juberti: it would not be that surprising 01:01:09 ... it's not clear that the browser can make useful matching up based on track types 01:01:24 martin: so you're backtracking on track matching in JSEP 01:01:36 juberti: we can move stuff from JSEP to the application layer 01:01:53 ... JSEP has some very complicated logic that is not necessarily full enumerated 01:02:31 cullen: this matters a lot of legacy interop 01:02:45 adamR: this is revisiting multiple years of history and discussion 01:03:07 http://rtcweb-wg.github.io/jsep/#rfc.section.5.3.1 01:03:13 juberti: I can tell you from experience that the matching up algorithm is extremely complex and the browser is not always in a good position to know what was meant 01:03:20 paragraph 5, http://rtcweb-wg.github.io/jsep/#rfc.section.5.3.1 01:04:47 juberti: we can maybe simply consider peter's case for the matching 01:05:02 fluffy has joined #webrtc 01:05:11 martin: I suggest we simply stick to JSEP's rules 01:05:14 wonsuk has joined #webrtc 01:05:27 vr000m has joined #webrtc 01:06:05 martin: but that argues that option I is a better match to the JSEP model 01:07:15 hta: so are we converging on getting a pull request for Option I 01:07:43 ... Peter will provide a pull request, and martin will review/contribute 01:08:14 Slide 4 Can we change MIDs on an m-line 01:08:15 Peter: looking at the other issue we discussed: changing MIDs on an m-line 01:08:40 ... Justin said making mids immutable would make JSEP much simpler 01:09:26 cullen: this sounds good, but we have to deal with the mid exposed in candidates 01:09:48 ... we should have a note to that effect 01:09:54 Candidates should get GCed when m= section is cleared 01:10:01 peter: this has only effect on JSEP 01:10:48 juberti: I think JSEP probably needs to understand the concept of transceiver to do the matching to SDP 01:12:11 Topic: Changing dictionaries to interfaces 01:12:58 martin: we have a bunch of dictionaries returned by getParameters, and setParameters accept these dictionaries 01:13:58 ... when looking at setCodecPreferences, having to deal with dictionaries being wrong vs requiring an interface, the latter is much better 01:14:27 ... since interfaces guarantees that the object is built by the browser, you get much better control 01:14:50 ... in general, domain objects are recommended to be built from interfaces rather than dictionaries to avoid this type of issume 01:15:34 -> https://github.com/w3c/webrtc-pc/pull/350 RTCRtpSender support objects -> interfaces #350 01:15:51 (now looking at file modifications) 01:16:14 ... in my pull request 350, I distinguished between dictionaries that are under control of the application, and interfaces that the browser need to control to restrict input from the app 01:17:11 ... going through the various existing usage in getParameters / setParameters, most were cases where the browser should not leave access to the developer 01:17:37 ... going through this, it wasn't clear whether making ssrc changeable is a good idea 01:18:06 ... it was important beforehand, not sure it is useful 01:18:20 peter: I meant to be mark it as readonly 01:18:40 ... there are use cases where it would be useful, but there was no consensus to do so 01:20:06 martin: I only focused on setParameters, but this probably affects other parts of the spec, especially stats 01:21:08 jan-ivar: we should not make too much generalization either; the case for setParameters is clear because you're getting objects from the browser before resending it to it 01:21:22 ... it's not clear that the same applies to stats 01:22:48 dom: I think the case is quite clear for get/setParameters 01:22:57 ... we would have to look at a proposal to evaluate stats 01:23:19 hta: speaking as stats editor, it's important to have serialization — but we can get that for interfaces too 01:23:48 ... I wonder how that would play with ids 01:24:03 The question is whether interfaces will paint us into a corner - where the entire API will be unextendable. 01:25:17 These changes are being made based on the assumption that attributes that are readonly in exisrting objects will remain that way... or that this will be consistent between objects. That is not true in general. 01:26:30 Capability objects and Parameter objects are the similar or in some cases identical... dictionaries can serve both purposes but interfaces with restrictions cannot. 01:26:53 So effectively imterfaces are poisoning the object space in a way that will require massive changes later on... for no useful purpose. 01:26:57 shijun: dictionaries can vary, where interfaces can't 01:27:17 martin: if there are capabilities that browsers can or can't do, we should change the interfaces accordingly 01:27:43 varun: but for stats, there is data the browser may not be able to provide at some point 01:27:48 But the interface can't do multipile things at once.... 01:28:04 The same attribute cannot be readonly and readwrite, for example.... 01:28:14 shijun: I think we need to think more about this; at least the comparison with stats gives me pause 01:28:30 Yet that is exactly what is required in many cases if the same dictonary is used differently in different methods. 01:28:45 martin: I agree that the timing aspect of stats makes a good argument as to why to use dictionaries instead of interfaces 01:29:27 peter: if later one we decide to make ssrc writable? 01:29:34 martin: ... we add it to the dictionary 01:29:42 peter: so it would be fairly simple? 01:30:13 You'd have to change the attribute from readonly to readwrite - whereas with a dictionary you would not have to make that kind of change. 01:30:54 martin: yes; there are more complicated examples, e.g. when we want to change a sequence of interfaces to something else 01:31:16 jan-ivar: you could deal with that by making the attribute writable instead of readable (and still need to use setParameters) 01:34:09 There are cases where attributes are readonly within some methods and writeable in others. Interfaces cannot deal with this. 01:38:03 Yes. 01:38:30 dom: so this PR makes choices about things we would need to evolve later — are we comfortable with those? 01:38:40 maehama has joined #webrtc 01:39:00 kinjim has joined #webrtc 01:39:26 martin: from my reading, the only constraints it creates are on things that are firmly under the browser creates 01:40:21 s/creates/control/ 01:40:43 peter: looking at the example, does this change requires this "copy(params)" call? 01:40:49 martin: yes 01:43:00 toddg has joined #webrtc 01:44:47 ama_ has joined #webrtc 01:45:25 [discussion as to why the getParameters returns an immutable object] 01:47:31 wonsuk has joined #webrtc 01:47:32 martin: my assumption had been that setParameters only needed partial application 01:48:16 shijun has joined #webrtc 01:48:42 ekr: I'm still not sure what's the point of having the readonly fields 01:50:27 ... I'm confused 01:50:45 hta: I think it's clear that is no consensus on #350 01:51:55 martin: I think we're close to making progress 01:52:29 hta: I don't understand the claim that getting an object from an interface with non read-only parameters, you could not change them 01:52:55 martin: the issue is that there are expectations that tweaking values from a platform objects should have side effects 01:54:03 ... in my model getParameters returns the browser view of its state 01:54:09 ... and then you have to provide your own view 01:54:26 ekr: but how does this help? 01:55:44 martin: I'm open to adopting the model of a modifiable platform object for setParameters 01:56:50 [consensus this would be better] 01:57:20 martin: I'll revise the pull request accordingly 02:01:53 frodek has joined #webrtc 02:14:52 adamR has joined #webrtc 02:16:38 Topic: Bug Bash for WebRTC-1.0 02:16:49 -> https://www.w3.org/2011/04/webrtc/wiki/images/5/5d/Bug_Bash_for_WebRTC-1.0.pdf Bug Bash for WebRTC-1.0 slides 02:16:52 DrAlexG has joined #webrtc 02:16:56 02:17:00 scribe: DrAlexG 02:17:02 bug status 02:17:36 there are still 52 bugs, (152 were closed) 02:17:47 and the oldest bug is around 1 year old 02:17:58 if you look at the categories of bugs 02:18:14 s/bug status/harald: bug status/ 02:18:22 you will find many (see slide) but we want to fix all of them, except the functionality wishes 02:18:43 s/there are still/... there are still/ 02:19:00 s/and the oldest/... and the oldest/ 02:19:13 s/if you look/... if you look/ 02:19:30 s/you will find many/... you will find many/ 02:19:43 harald: of course, we might not deal with all of them today ..... 02:20:18 ... as we did for media capture and stream, we first remove all the editorial stuff 02:20:44 ... first bug: #150 and #151: closing a peerconnection 02:21:53 ... there is a question regarding what is the best practice for promises? return error / failing, or not? 02:22:07 justin: I thought we had already decided that we would fail them. 02:22:35 jesup: there were a couple a question regarding what happen after you close the peer connection 02:22:52 mishizaw has joined #webrtc 02:22:58 ... we don t really care anymore after a close. because anything produced would not be usable. 02:23:29 fluffy: i do not say it s right, but right now we are collecting errors, and making statistics on them, so I am in favor of failing it. 02:23:41 martin: but you re calling close first, so you re biasing your stats 02:23:50 fluffy: right, i m just describing what we do right now. 02:23:58 kinjim has joined #webrtc 02:24:53 mathieu: if we have an error, the application then get the option to deal with it or not. 02:25:06 ekr: can we make the promises cancelable? 02:25:44 martin: there are only two states right now, not a third cancelable state. 02:26:01 harald: our options are either fail or not fail. no cancel option 02:26:05 ekr: ok 02:26:08 martin: that s my rea 02:26:59 xxx: the general consensus is that in cases where you shutdown or refresh, you don t want JS activity 02:27:06 s/xxx/jan-ivar/ 02:27:22 justin: I think it s a different use case. I think failing would be nicer, if you want to do things like UI cleaning. 02:27:42 jib: 02:28:31 ekr: if we don t fail, there is no option at all for the app. It seems to be a pretty strong argument in favor of resolving the promise. Of course, app can screw up, but hey, c est la vie. Plus it s already in the specs. 02:28:50 adam: bad user code is bad user code, we can t control it. 02:29:10 harald: plus PC will be closed at that time, so they can t shoot themselves in the foot anymore, really. 02:30:14 +1 to leave it 02:30:26 jib: it looks like there is no case where close would be called by the browser. so I m ok with resolving the promise. 02:30:39 harald: show of hand? 02:30:48 all in favor or abstening 02:30:49 Hey guys - I've lost all audio from the room it appears - I'll try rejoining 02:31:00 harald: ok , next problem 02:31:10 ... #337 and #338: webrtc vs JSEP 02:31:54 ... the suggested guideline are: if it s about what the SDP looks like, defer to JSEP, if it s about the JS API, write it in webrtc 02:32:11 yes 02:32:20 s/yes// 02:32:29 rejoinnig fixed it...but now it's gone again 02:32:42 and it's back 02:33:12 ... specific issues: how to reference JSEP in webrtc specs, how to reach agreement between teams, and what are the permitted changed to SDP in JS (between CreateOffer and SetLocalDescription) 02:33:38 peter: there is a sync issue, and sometimes we need to reference things that are not there yet. 02:34:27 fluffy: yes, like any sync problem, we'll deal with it. Eventually we will converge, it's ok. I'm happy to do whatever is needed here [as chair of IETF rtcweb group] 02:34:45 ekr: is there any reason why we can cross reference symbols between webrtc and jeep? 02:34:54 s/jeep/JSEP/ 02:37:42 ekr: I'm happy to help 02:37:51 dom: i'm happy to help too 02:38:11 fluffy: i don tthink we need to work too much on JSEP => WEBRTC, those are rarely needed 02:38:40 dom: one of the difficulty when i started to review the spec, there is the question of maintenaining referencing, but there are also implicit references 02:38:47 ... like handling ICE candidates 02:39:09 fluffy & dom: a scrum is in order 02:39:21 harald: dom and eke are in charge of dealing with the leakage 02:39:21 lost audio again... 02:39:28 ... 02:39:32 last bug 02:39:33 same here 02:39:42 ... #334 consider using the stream API 02:39:53 can anyone hear the room? 02:40:23 I can, but I'm in the room :) 02:40:44 no, I lost audio too around the same time as juberti 02:40:45 no 02:40:46 ... back when we made the original decision, DC were modeled after web sockets, 02:40:50 rejoinging 02:40:55 ... however, streams API was not ready. 02:41:01 rejoined and have audio 02:41:07 ... revisiting it now, it seems that streams API is still quite not ready 02:41:07 ... proposing to leave it for later (close it now, mark it "LATER") 02:41:16 ... everybody OK with that? 02:41:20 all: OK 02:41:26 harald: next 02:41:29 magically recovered 02:41:35 for me too 02:41:39 ... #257 ICE candidate should have accessors 02:41:41 it's done that for me before too 02:41:50 ... solved by . Closed 02:42:19 ... #263 Overriding default ICE servers 02:43:30 kinjim has joined #webrtc 02:44:44 02:45:23 ekr: let's separate the use cases. Here we are speaking about ICE servers, which are provided by the app. return, which behaves more like a proxy, that the application do not have access to today, is different. 02:45:53 mathieu: I'm not ok with browser overriding ICE servers (STUN, turn) provided by the app. 02:46:43 jeff_ has joined #webrtc 02:46:51 fluffy: I think this bug was about to decide wether JS can decide to let the browser get control over ICE servers. 02:47:11 fluffy: wether it is overriding one list (app) by another (browser), or merge both lists. 02:47:23 ... but this bug is only about overriding. 02:48:20 dom: what downside is there to use user provided server? 02:48:38 justin: if you use non-app-provided ICE server, you might bust th app. 02:49:46 adam: we can propose default servers, but make it explicit to the app with a GiveMeTheDefaultServersYouKnowAboutPlease() api available. 02:50:05 harald: here is a matrix of all the possible cases. 02:50:12 ... 02:53:04 justin: so where are we with this? 02:53:22 fluffy: summarizing: return and proxy are not available to the app 02:53:38 I have made the request to generate http://www.w3.org/2015/10/29-webrtc-minutes.html vivien 02:53:56 ... however in this bug, we propose an API that allows the app to query the browser for known ICE servers, and do whatever they want with it. 02:54:30 ekr: in terms of security, this is the same surface. 02:54:37 harald: so ... we do not override? 02:54:43 mathieu: yes, do not override. 02:54:52 dan: do not AUTOMATICALLY, silently, override. 02:55:36 harald: so we all agree on this? 02:55:42 martin: I have a pull request :-D 02:56:05 Harald: I feel ekr and martin are in favor ... ? 02:56:15 ekr: i m in favor of everything that close this conversation faster. 02:56:34 fluffy: it s something we wanted to do for a long time, we just never came around to decide HOW to do it 02:56:41 justin: I disagree. 02:56:58 [to clarify for my later self, the reason having this as a list of STUN servers rather than a a-priori-less-fingerprintable boolean "use configured stun" is that these STUN servers can be trivially exposed via stats after ICE gathering, without any user involvement] 02:57:07 harald: so we rejected the idea of letting the browser to inject ICE servers just because they feel like it. 02:57:37 adam: the other use case is return, and we do not need a JS API for that. 02:57:40 fluffy: agreed. 02:58:27 justin: in the case where you have multiple level of NAT, it s not clear people can handle it with ICE servers. 02:58:49 fluffy: someone report yesterday that the amount of <...> is pretty low 02:58:57 justin: i said that, right 02:59:26 ekr: you are misunderstanding return. It does not involve a normal TURN server, and in spirit it should be seen as a proxy. 02:59:42 fluffy: I mean this could work without return. 02:59:58 martin: the pull request is done, we could merge this right now. 03:00:23 harald: which interface shall we put it on 03:00:43 martin: PeerConnection (and it s static, which will also been fun to implement, but hey, my happy life) 03:00:58 harald: everybody satisfied with this? 03:01:02 fluffy: yes 03:01:06 justin: yes 03:01:10 ekr: fine 03:01:20 haralrd: ok, merged 03:02:39 ... #265 add privacy/security review questions 03:02:55 ... need volunteer for review and text proposals 03:03:56 ekr: is the rule obvious from this document, or will need further input from IETF docs? 03:04:00 harald: obvious. 03:04:22 ekr: hum, oh, uh ..... I guess I can do it ....... 03:04:36 fluffy: why? it's an insane amount of work! 03:04:47 ekr: well, really? well, .. i'm not going to do it then :D 03:05:07 fluffy: the AI for you should be: read the document and decide if you want to do it. 03:05:11 ekr: agreed. 03:05:33 fluffy: we should close that bug anyway 03:05:59 alex: ekr reads it, decides, and if he decides NOT to do it, we reopen it. 03:06:06 ekr, fluffy, harald: OK 03:06:10 (break time for lunch bat at 13:00 (ie in 55 minutes)) 03:06:18 03:06:20 s/bat/back/ 03:06:24 frodek has joined #webrtc 03:06:27 I have made the request to generate http://www.w3.org/2015/10/29-webrtc-minutes.html vivien 03:16:57 ekr has joined #webrtc 03:35:57 frodek has joined #webrtc 03:53:49 hta has joined #webrtc 04:03:02 tomoyuki has joined #webrtc 04:04:28 kpfleming has joined #webrtc 04:05:17 burn has joined #webrtc 04:06:12 adamR has joined #webrtc 04:06:56 jxck has joined #webrtc 04:07:03 iwashi has joined #webrtc 04:09:50 oonishi has joined #webrtc 04:10:39 DrAlexG has joined #webrtc 04:10:43 (meeting resumes) 04:10:47 04:11:07 04:11:13 kinjim has joined #webrtc 04:11:23