14:35:21 <RRSAgent> RRSAgent has joined #mediacap
14:35:21 <RRSAgent> logging to http://www.w3.org/2014/10/02-mediacap-irc
14:35:23 <trackbot> RRSAgent, make logs public
14:35:23 <Zakim> Zakim has joined #mediacap
14:35:25 <trackbot> Zakim, this will be MCAP
14:35:25 <Zakim> ok, trackbot; I see UW_MdCap()11:00AM scheduled to start in 25 minutes
14:35:26 <trackbot> Meeting: Media Capture Task Force Teleconference
14:35:26 <trackbot> Date: 02 October 2014
14:38:51 <Cow_woC> Cow_woC has joined #mediacap
14:49:17 <burn> burn has joined #mediacap
14:50:26 <fluffy> fluffy has joined #mediacap
14:50:52 <Zakim> UW_MdCap()11:00AM has now started
14:50:59 <Zakim> + +1.408.902.aaaa
14:52:22 <fluffy> Zakim, aaaa is me
14:52:22 <Zakim> +fluffy; got it
14:54:21 <Zakim> + +1.407.421.aabb
14:54:41 <burn> zakim, I am aabb
14:54:41 <Zakim> +burn; got it
14:56:00 <stefanh> stefanh has joined #mediacap
14:56:14 <annevk_> annevk_ has joined #mediacap
14:57:09 <Zakim> +[IPcaller]
14:57:19 <annevk> Zakim, [IP is me
14:57:19 <Zakim> +annevk; got it
14:57:36 <jib> jib has joined #mediacap
14:58:57 <Zakim> + +1.267.934.aacc
14:59:09 <jib> zakim aacc is me
14:59:26 <jib> Zakim, I’m aacc
14:59:26 <Zakim> I don't understand 'I’m aacc', jib
14:59:29 <Zakim> +stefanh
14:59:33 <jib> Zakim, I am aacc
14:59:33 <Zakim> +jib; got it
14:59:35 <adambe> adambe has joined #mediacap
14:59:39 <Zakim> +gmandyam
14:59:41 <adam> adam has joined #mediacap
15:00:39 <Jim_Barnett> Jim_Barnett has joined #mediacap
15:00:42 <dom> Zakim, code?
15:00:43 <Zakim> the conference code is 6227 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), dom
15:00:55 <mt_> mt_ has joined #mediacap
15:01:03 <ShijunSun> ShijunSun has joined #mediacap
15:01:20 <Zakim> +??P20
15:01:22 <dom> Zakim, ??P20 is me
15:01:22 <Zakim> +dom; got it
15:01:29 <Zakim> + +1.617.564.aadd
15:01:40 <Zakim> + +46.1.07.14.aaee
15:02:07 <stefanh> details for this call: http://lists.w3.org/Archives/Public/public-media-capture/2014Oct/0000.html
15:02:10 <dom> Zakim, who's on the call?
15:02:10 <Zakim> On the phone I see fluffy, burn, annevk, jib, stefanh, gmandyam, dom, +1.617.564.aadd, +46.1.07.14.aaee
15:02:15 <Zakim> +[Mozilla]
15:02:33 <Zakim> +[Microsoft]
15:03:43 <ShijunSun> Zakim, [Microsoft] is me
15:03:43 <Zakim> +ShijunSun; got it
15:03:54 <Zakim> + +1.214.343.aaff
15:04:00 <adam> zakim, aaff is me
15:04:01 <Zakim> +adam; got it
15:04:25 <mt_> mt_ has joined #mediacap
15:04:31 <Zakim> +??P46
15:04:38 <ekr> ekr has joined #mediacap
15:04:47 <fluffy> scribenick: fluffy
15:05:10 <fluffy> Topic: Agenda & minutes
15:05:18 <stefanh> minutes to approve: http://lists.w3.org/Archives/Public/public-media-capture/2014Aug/0049.html
15:05:29 <fluffy> Call is being recorded
15:05:48 <fluffy> Resolution: minutes aproved
15:06:39 <Zakim> +??P5
15:06:58 <juberti> juberti has joined #mediacap
15:07:31 <dom> -> http://lists.w3.org/Archives/Public/public-media-capture/2014Sep/att-0171/ModernizegUM.pdf JIB slides
15:07:39 <fluffy> No changes to agenda
15:08:15 <fluffy> Topic: Slides on why to use Promises
15:08:36 <fluffy> jib presenting slides
15:10:15 <hta1> hta1 has joined #mediacap
15:10:46 <hta1> zakim, who is here?
15:10:46 <Zakim> On the phone I see fluffy, burn, annevk, jib, stefanh, gmandyam, dom, +1.617.564.aadd, +46.1.07.14.aaee, [Mozilla], ShijunSun, adam, ??P46, ??P5
15:10:49 <Zakim> On IRC I see hta1, juberti, ekr, mt_, ShijunSun, Jim_Barnett, adam, adambe, jib, annevk, stefanh, fluffy, burn, Cow_woC, Zakim, RRSAgent, anssik, fjh, dom, slightlyoff, timeless,
15:10:49 <Zakim> ... derf, Josh_Soref___, richt, trackbot
15:10:59 <hta1> zakim, aadd is me
15:11:00 <Zakim> +hta1; got it
15:11:13 <Zakim> + +1.602.380.aagg
15:11:16 <hta1> zakim, hta1 is hta
15:11:16 <Zakim> +hta; got it
15:11:56 <juberti> Zakim, aadd is juberti
15:11:56 <Zakim> sorry, juberti, I do not recognize a party named 'aadd'
15:12:15 <juberti> Zakim, .aadd is juberti
15:12:15 <Zakim> sorry, juberti, I do not recognize a party named '.aadd'
15:12:35 <juberti> Zakim, +1.617.564.aadd is juberti
15:12:36 <Zakim> sorry, juberti, I do not recognize a party named '+1.617.564.aadd'
15:16:02 <burn> q+
15:17:46 <fluffy> EKR argued that current stuff is not broken and promises are at best modelstly better. JIB argued that web world had moved to promises as a better way.
15:19:08 <annevk> The main reason we want promises now is so that when synchronous async/await syntax lands in JavaScript WebRTC can use it and we don't need to keep hacking around with callbacks.
15:20:00 <mt_> mt_ has joined #mediacap
15:20:01 <annevk> Also, given that we want promises and getUserMedia is still prefixed, I don't really understand what the pushback is here. This can be done, it's trivial.
15:20:21 <hta1> annevk: if your argument depends on a future feature, we're in trouble.
15:20:57 <hta1> q+
15:21:00 <burn> ack burn
15:21:07 <annevk> hta1: I guess in this group I will refrain from that argument then
15:21:12 <ekr> Shipping is a feature.
15:21:33 <annevk> Yes, shipping something coherent is too and you've had a year now to adapt.
15:21:39 <annevk> And you still haven't shipped
15:21:44 <hta1> ack hta
15:21:50 <annevk> It's not like this is the problem
15:21:52 <fluffy> jutin asked if we still need to catch expceptions even if uses Promises. JIB pointed out some error catching could be done in Promises
15:23:21 <ekr> Yes, we still haven't shipped. The idea is to do so without more bikeshedding
15:23:53 <annevk> The more you resist change and clinge to old habits, the more of that you'll get
15:24:39 <ekr> Yes, I realize you see it that way
15:25:33 <annevk> It's happening now, no?
15:26:30 <ekr> It's cute how you think that if we just take this PR that will be the end of the bikeshedding, not the beginning
15:27:32 <annevk> Are you always so condescending to your peers?
15:28:55 <burn> annevk, you were the first one to get personal.  Feel free to stop anytime.
15:29:47 <annevk> burn: you was meant to refer to the WG, not ekr
15:30:37 <mt_> I just love the collegial attitude here
15:30:49 <hta1> annevk, language that is regarded as insulting when applied to a single person is no less insulting when applied to a whole group.
15:32:27 <annevk> Fair, sorry for that
15:34:31 <juberti> https://docs.google.com/presentation/d/1mokzOqRrZIFDigQFonEhPm5kdHmRVrrB8CZ6-jSJ2bw/edit?usp=sharing
15:34:35 <fluffy> Topic: Slides on why not use Promises
15:34:51 <fluffy> Justin presenting slides
15:35:26 <dom> -> http://lists.w3.org/Archives/Public/public-media-capture/2014Oct/att-0003/Thoughts_on_Promises__Public_.pdf Archived version of Justin's slides
15:35:54 <annevk> I think at Mozilla we think we can deprecate callbacks and remove them over time. We've been successful with that for other features.
15:36:24 <annevk> XMLHttpRequest gets replaced by fetch()
15:36:40 <annevk> (which will handle more use cases, etc.)
15:36:47 <adam> annevk: If you're going to show contempt for the standards process, I'd advise at least avoiding the exceptionally poor form of doing so on the W3C IRC server.
15:37:12 <annevk> adam: what specifically are you referring to?
15:37:31 <adam> "I think at Mozilla…" -- I think at Mozilla, we can implement whatever is speced.
15:37:58 <annevk> adam: how is that contempt for the standards process to share experience on what is possible?
15:38:13 <annevk> adam: we have removed features before that have been specced, because we realized that would be better for the web
15:38:24 <annevk> adam: and are still planning on doing so, e.g. with showModalDialog()
15:38:32 <annevk> adam: that's not contempt, that's how we do standards...
15:39:31 <jib> q+
15:40:26 <fluffy> jib argues that moving to promises would not break people (by using polyfills etc)
15:40:44 <ekr> q+
15:40:53 <fluffy> jib points out XHR does not really have the options we have
15:41:25 <gmandyam> gmandyam has joined #mediacap
15:41:34 <fluffy> jlb points out we may have other issues around errors in last call if we do not use promiases
15:42:23 <fluffy> jlb points out that if we tell people we are doing it one way in 1.0 and changing in 1.1, that might actualy slow down adption of webrtc
15:42:33 <juberti> Q+
15:42:37 <dom> ack jib
15:42:38 <dom> ack ekr
15:43:32 <Zakim> -dom
15:43:32 <fluffy> ekr does not think error handling is an issue that developers are complaining about
15:43:46 <Zakim> +??P12
15:43:51 <dom> Zakim, ??P12 is me
15:43:51 <Zakim> +dom; got it
15:44:33 <fluffy> jlb argue we could be done quickly - ekr does not feel this is obvios - jlb argue will take some time to fix existing error handling
15:44:53 <hta1> q+
15:44:55 <fluffy> justin - agree we would want to to update error objects so we can add promises later
15:45:28 <fluffy> justin - dubios that the pull request to move to promises would be the end of the conversation on this
15:45:43 <Zakim> -hta
15:45:48 <fluffy> justin feels doing this now would push out the tmeline to be done
15:46:08 <annevk> Android is the wrong example. They can change APIs. We can't on the web.
15:46:12 <stefanh> q?
15:46:30 <annevk> Sometimes we're lucky we can. But now would be a good time to get it right, before we ship.
15:46:59 <jib> q+
15:47:07 <annevk> Also, this person is ignoring the point jib brought up with regards to the current setup being wrong
15:47:13 <dom> ack juberti
15:47:20 <juberti> how can Android now change APIs?
15:47:23 <dom> ack hta
15:47:23 <juberti> now=not
15:47:25 <juberti> q-
15:47:45 <juberti> Android needs to be able to ensure apps continue to work.
15:48:04 <fluffy> hta - the reasons we don't inherit from Error is we don't have a stable spec for it. We need a real ref to use this.
15:48:07 <Zakim> -dom
15:48:07 <ekr> annevk: that's an odd argument to be making at the same time as you're arguing for breaking changes to the permissions model about, say, geo
15:48:14 <mt_> https://w3.org/TR/WebIDL ?
15:48:19 <Zakim> +??P12
15:48:24 <dom> Zakim, ??P12 is me
15:48:24 <Zakim> +dom; got it
15:48:25 <annevk> ekr: yes, sometimes we're lucky as I said, but it's a painful process
15:48:39 <annevk> ekr: it's better to be right from the start then try to make changes later
15:48:40 <stefanh> q?
15:48:46 <annevk> ekr: especially if it's known we need to make changes
15:48:49 <fluffy> some existing specs have normative ref to private moz repo for error specifiction
15:49:40 <fluffy> q?
15:49:52 <dom> ack jib
15:50:43 <fluffy> Justin as when promises would be usable in FF
15:50:49 <annevk> Promises is shipping in stable
15:50:58 <dom> ["how soon would Firefox Hello switch to a promise version?" might be another way to phrase juberti question]
15:50:58 <fluffy> jib - Firefox already has a version of FF that  supports promises for gum in private branch
15:51:25 <ekr> q+
15:51:38 <annevk> If we agree to promises now, we can do that for the next version
15:51:48 <ekr> well, when the next version is in 18 weeks
15:52:03 <annevk> Yeah, sorry
15:52:22 <annevk> q?
15:52:28 <annevk> q+
15:53:38 <adam> q+
15:53:57 <fluffy> Jusitn - does not think it will be free to swtich to this. If it is so simple, we can add it simply later
15:54:10 <dom> ack ekr
15:54:12 <mt_> cost[now] < cost[later]
15:54:13 <fluffy> JIB - does not really change underlying implmentations
15:54:41 <jib> Working promise patch for mediaDevices.getUserMedia: https://bugzilla.mozilla.org/page.cgi?id=splinter.html&bug=1033885&attachment=8492555
15:55:00 <annevk> The vendor prefix negates that argument imo
15:55:16 <fluffy> ekr - argue that this would delay doc 18 weeks as we need to wait for implemetiotns before moving doc forward
15:56:23 <gmandyam> q+
15:56:24 <fluffy> anne - Promises are shipping in all browses now. They are stable. True that ecma 6 script is hosted on moz servers since the official spec is PDF. You can just ref webidl.
15:57:11 <fluffy> ... if we change now, in the futre we can move to a version of the API that has one way to do it not two
15:57:46 <fluffy> ... seems weird that people agree we want to move to promises eventuall but don't understand resitance to doing it now
15:58:05 <ekr> I will say that the prefix change is trivial
15:58:07 <dom> ack anne
15:58:13 <fluffy> ... ther will library impact from prefix change so better to do now rather than to it in multiple steps later
15:58:15 <dom> ack adam
15:58:26 <annevk> ekr: we have found that unprefixing often breaks things
15:58:29 <jib> Oh, I forgot, most of my patch is actually adding the mediaDevices interface itself, so the actual code is much less
15:58:31 <annevk> ekr: especially with APIs
15:59:01 <ekr> annevk: that's fair. but we already have polyfills that handle Chrome vs. Firefox, so I have some confidence we can get this done
15:59:11 <jib> q+
15:59:18 <annevk> ekr: we have those for Fullscreen too
15:59:21 <annevk> ekr: it's terrible :-(
15:59:38 <fluffy> adam - These aproach are funcitonal isomoric. So this is an asthetic decisions. So agree shipping is a feature. We know what we have now works. The argumrent we can polyfill cuts both ways
15:59:43 <gmandyam> Question for jib:  What about functions hanging off of EventTargets (e.g. addTrack(), getTrackById())?
15:59:46 <ekr> annevk: yeah, I know it's pretty bad
16:00:07 <ekr> annevk: especially, since we have to also bridge small API differences
16:00:13 <mt_> q?
16:00:16 <mt_> q+
16:01:56 <dom> ack gmandyam
16:02:12 <dom> ack jib
16:02:30 <fluffy> gmandyam - would the event targets in webrtc be moved to targets ? JIB - it depends. Things that can fire multiple times proabbly best for events. Some other things probabbly not. Things like addTrack need to move to async so will brak backwards compat already
16:02:54 <dom> ack mt_
16:03:29 <jib> q-
16:03:38 <mt_> q-
16:03:41 <gmandyam> Clarification:  I wasn't asking jib about event targets themselves (e.g. MediaStream), but the asynch. functions that hang off of the event targets (MediaStream.someFunc()).
16:03:43 <fluffy> mt - This is being set up in very adverserial way. We are attacking it in way that makes me very uncofortbale. Its hard to convince people to pay down technical debt which is what you are doing.
16:04:17 <fluffy> ... the callbacks and error stuff are technical debt. It is spec technical debt. What concenrs him the most is API usability.
16:04:55 <fluffy> ... Promises are a win (not big win) from API usabilyt point of view
16:05:36 <dom> q+
16:05:50 <mt_> Promises won't hold anything up inherently
16:05:51 <burn> fluffy asked whether use or lack of use of promises will slow us down in the W3C Last Call process.
16:05:56 <annevk> You will certainly get one formal objection less if you adopt promises
16:06:12 <fluffy> dom - think it is clear that TAG will send comments on this if we don't use promises
16:06:29 <fluffy> ... we would probbaly argure we have enough deployment we think this is best
16:06:41 <fluffy> ... gut feel is promises would be smother
16:06:53 <stefanh> q?
16:06:57 <dom> ack me
16:06:58 <fluffy> ... but we should make decisiosn based on what would make the web the best, not what would make our lives easy
16:07:12 <burn> s/smother/smoother/ in fluffy's minutes :)
16:08:20 <fluffy> Topic: chairs schedule impact ?
16:08:35 <fluffy> chairs - could be easy but might be lots of things hiding in details so hard to know right now
16:08:44 <fluffy> Topic: Decision Tree
16:08:59 <dom> -> http://www.w3.org/mid/542A62A4.2090606@alvestrand.no Harald's decision tree
16:09:24 <fluffy> chairs: discussing the set of questions
16:10:03 <fluffy> ... on first question feel people want yes
16:10:12 <fluffy> ... on seond question feel people sharply divided
16:10:59 <ekr> yes, I think I understand
16:11:18 <fluffy> chairs: proposal to group is we have a YES on 1
16:11:28 <dom> [despite my longstanding push to finalize this damn spec, I have to come to a personal conclusion that moving to promise now (i.e. before LC) would be the better option]
16:11:37 <fluffy> resolution: consenssus is yes on we want promises eventually
16:11:55 <gmandyam> Qualcomm Innovation Center votes in favor of Level 2
16:12:11 <gmandyam> q+
16:12:20 <fluffy> q+
16:12:27 <Cow_woC> For what it's worth, I'm +1 for Promises before LC.
16:13:48 <Cow_woC2> Cow_woC2 has joined #mediacap
16:14:31 <fluffy> gmandyam - can we get a colective view from each organization ?
16:14:41 <gmandyam> q-
16:15:22 <Zakim> -burn
16:15:55 <Zakim> -dom
16:15:58 <fluffy> fluffy: quetion about if we did this later would we later depricate callbacks
16:16:09 <Zakim> +??P6
16:16:10 <dom> Zakim, ??P6 is me
16:16:10 <Zakim> +dom; got it
16:16:14 <fluffy> jib: future spec  would doc both in spec if we do it later
16:16:40 <jib> q+
16:16:41 <fluffy> justin: could have callback in 1.0 then in 1.1 we could add Promises and say callbacks were complicated
16:17:25 <fluffy> dom: the two browsers that have not shipped may only want to do speced version not callbacks in this case
16:19:41 <fluffy> jib - whats not clear in decisons tree is how we deal callbacks over time
16:19:52 <ShijunSun> q+
16:20:02 <fluffy> q -
16:20:32 <annevk> I strongly disagree; we've managed to remove many APIs over time
16:20:38 <fluffy> ekr: dont' see world wehre we remove these APIs
16:20:43 <dom> q- fluffy
16:20:52 <dom> ack jib
16:21:01 <fluffy> jib: seem prefixes deal with this and several of the API are not implemented yet i
16:21:24 <fluffy> ekr: argue that exisitn PAI need to continu to have callbacks
16:21:26 <ekr> q+
16:21:30 <annevk> q+
16:21:46 <annevk> ekr: are you suggesting we'd keep supporting mozGetUserMedia() forever too, then?
16:21:53 <dom> ack ShijunSun
16:22:02 <ShijunSun> q-
16:22:05 <fluffy>  ShijunSun: lets keep focused on gum - webrtc is a seperate issue
16:22:32 <dom> ack ekr
16:22:47 <dom> ack annevk
16:23:14 <jib> q+
16:23:20 <fluffy> anne: If callbacks don't disapear, do the prefx disapear?
16:23:38 <ShijunSun> q+
16:24:00 <fluffy> ekr: having prefix disapear is differnt than this. Chrome has depricated many webkit api
16:24:26 <dom> q- jib later
16:24:29 <dom> ack ShijunSun
16:24:35 <ekr> q+
16:25:46 <jib> q+
16:25:51 <fluffy> ShijunSun: for promises think it is a good coding style. Good idea to adopt. But what is imeplemented is also important. We don't want to break interop - that is important for developers.
16:25:59 <dom> ack ekr
16:26:20 <jib> q-
16:26:24 <fluffy> ekr: wants to never have this dicsuions again.
16:26:58 <Cow_woC> :)
16:27:25 <fluffy> ekr: propose we have promise version of all API and agree not to depricated callback based apraoches for stuff that is in use today
16:27:26 <Cow_woC> ekr: I can promise you that if Promises are not adopted it will come up again :)
16:27:58 <fluffy> ... not willing to abandon existing callbacks in next few years because people use them
16:28:20 <jib> q+
16:29:03 <annevk> People also use mozGetUserMedia(); I doubt there would be consensus on not deprecating that after we ship something unprefixed within the Mozilla community
16:29:21 <ekr> annevk: I'm fine with discussing deprecating mozgetusermedia
16:29:23 <annevk> Or within the Chrome community for that matter
16:29:27 <ekr> I'm solely talking about the api calling style
16:29:56 <annevk> If you have to change one of those things anyway, it seems fairly trivial to have both adjusted.
16:30:14 <ekr> annevk: well, I think I've explained why I don't think that's true.
16:30:23 <annevk> Just post a page online that outlines the transition you need to do.
16:30:39 <annevk> I don't think your experience matches what I've seen for many other platform APIs
16:31:01 <ekr> Well, you don't have to agree.
16:31:09 <fluffy> chairs propose consensus of
16:31:13 <annevk> I don't
16:31:20 <ekr> Yes, I'd gathered that.
16:31:20 <fluffy> 1) we add promises to version for LC
16:31:34 <fluffy> 2) we keep callbacks for things that use them
16:31:35 <mt_> I'll note that our decision to make error callbacks mandatory might have to be revisited
16:31:43 <mt_> but that's a small point only
16:31:48 <ekr> q+
16:31:56 <Cow_woC> ekr: What about the "our callbacks our broken" slide? Don't we need to modify error handling in callbacks either way?
16:31:58 <mt_> q+
16:32:02 <jib> both versions of what? getUserMedia and enumeratDevices and applyConstraints? Does anyone implement the latter?
16:32:03 <fluffy> chairs: will find someone to write up this proposal and bring to group
16:32:07 <fluffy> q?
16:32:09 <ekr> q+
16:32:12 <dom> ack jib
16:32:18 <annevk> I think a number of people said that they didn't want both, no?
16:32:25 <ekr> annevk: yes, I tink they did.
16:32:37 <dom> ack ekr
16:32:39 <fluffy> jib: aks ehin ones have callbacsk
16:32:41 <jib> q-
16:32:53 <fluffy> chairs: juse userMedia
16:33:16 <fluffy> ekr: ask if we going to hear people asking for remove getusermedia
16:34:25 <fluffy> ekr: the one on getusermedia can be just promises but navigator need to have callbacks
16:34:28 <jib> q+
16:35:26 <dom> ack jib
16:35:29 <mt_> q-
16:36:07 <Zakim> -[Mozilla]
16:36:08 <jib> q-
16:36:11 <Zakim> -dom
16:36:15 <Zakim> -??P5
16:36:17 <Zakim> -gmandyam
16:36:17 <Zakim> -jib
16:36:18 <Zakim> -stefanh
16:36:18 <Zakim> - +46.1.07.14.aaee
16:36:19 <fluffy> end fo call
16:36:19 <Zakim> -??P46
16:36:20 <Zakim> -adam
16:36:22 <Zakim> -fluffy
16:36:24 <Zakim> -annevk
16:36:25 <Zakim> - +1.602.380.aagg
16:36:28 <dom> Zakim, list attendees
16:36:28 <Zakim> As of this point the attendees have been +1.408.902.aaaa, fluffy, +1.407.421.aabb, burn, [IPcaller], annevk, +1.267.934.aacc, stefanh, jib, gmandyam, dom, +1.617.564.aadd,
16:36:31 <Zakim> ... +46.1.07.14.aaee, [Mozilla], ShijunSun, +1.214.343.aaff, adam, +1.602.380.aagg, hta
16:36:32 <dom> Chair: HTA, stefanh
16:36:53 <dom> Agenda: http://lists.w3.org/Archives/Public/public-media-capture/2014Oct/0000.html
16:36:59 <dom> RRSAgent, draft minutes
16:36:59 <RRSAgent> I have made the request to generate http://www.w3.org/2014/10/02-mediacap-minutes.html dom
16:37:39 <dom> Zakim, who's on the phone?
16:37:39 <Zakim> On the phone I see ShijunSun
16:37:49 <dom> Zakim, drop Shijunsun
16:37:49 <Zakim> ShijunSun is being disconnected
16:37:51 <Zakim> UW_MdCap()11:00AM has ended
16:37:51 <Zakim> Attendees were +1.408.902.aaaa, fluffy, +1.407.421.aabb, burn, [IPcaller], annevk, +1.267.934.aacc, stefanh, jib, gmandyam, dom, +1.617.564.aadd, +46.1.07.14.aaee, [Mozilla],
16:37:51 <Zakim> ... ShijunSun, +1.214.343.aaff, adam, +1.602.380.aagg, hta
16:37:58 <dom> RRSAgent, bye
16:37:58 <RRSAgent> I see no action items