15:02:42 <RRSAgent> RRSAgent has joined #mediacap
15:02:42 <RRSAgent> logging to http://www.w3.org/2014/10/30-mediacap-irc
15:02:47 <dom> RRSAgent, this meeting spans midnight
15:03:11 <dom> RRSAgent, make log public
15:04:01 <stefanh> stefanh has joined #mediacap
15:04:33 <dom> Zakim, room for 8?
15:04:36 <Zakim> ok, dom; conference Team_(mediacap)15:04Z scheduled with code 26632 (CONF2) for 60 minutes until 1604Z; however, please note that capacity is now overbooked
15:04:44 <dom> Zakim, call portland
15:04:44 <Zakim> ok, dom; the call is being made
15:04:45 <Zakim> Team_(mediacap)15:04Z has now started
15:04:46 <Zakim> +Portland
15:05:14 <dom> Zakim, Portland is really TPAC
15:05:15 <Zakim> +TPAC; got it
15:07:05 <burn> burn has joined #mediacap
15:12:27 <xeoncore> lol wut
15:12:28 <xeoncore> :P
15:31:20 <Domenic> Domenic has joined #mediacap
15:31:29 <Domenic> Zakim, code?
15:31:30 <Zakim> the conference code is 26632 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), Domenic
15:32:21 <Domenic> Zakim, you lied to me
15:32:21 <Zakim> I don't understand 'you lied to me', Domenic
15:32:35 <Domenic> (hi everyone)
15:32:49 <dom> hi Domenic, thanks for joining! we're still getting set up here FWIW
15:32:58 <Domenic> ok, np.
15:33:54 <npdoty> npdoty has joined #mediacap
15:36:18 <dom> Topic: Welcome
15:36:32 <dom> hta: this is the media capture task force meeting as part of the WebRTC WG F2F
15:36:43 <dom> ... We're hoping to be at the stage where we stop making big changes to the document
15:36:55 <jib> jib has joined #mediacap
15:36:56 <dom> ... we need to review a last set of changes before we're sure we're done
15:37:13 <Zakim> +Domenic
15:37:32 <shinwoo_> shinwoo_ has joined #mediacap
15:38:14 <ShijunS> ShijunS has joined #mediacap
15:38:34 <stefanh> mom: http://lists.w3.org/Archives/Public/public-media-capture/2014Oct/0186.html
15:38:42 <shinwoo> shinwoo has joined #mediacap
15:38:48 <dom> stefanh: minutes approved
15:39:00 <hta> hta has joined #mediacap
15:39:10 <dom> Topic: Authenticated Origins
15:39:15 <dom> stefanh: this topic has been discussed in the task force before
15:39:20 <dom> ... it's been quite a heated debate
15:39:33 <dom> hta: we have a TAG representative on the phone
15:39:37 <dom> domenic: that would be me
15:40:18 <dom> ... work for Google, been elected to the TAG ~ a year ago
15:40:24 <alexG> alexG has joined #mediacap
15:40:36 <dom> hta: we wanted someone from the TAG to get some keywords on why imposing that restriction might be a good idea
15:40:55 <dom> domenic: the TAG has made a statement that we should move sensitive APIs to authenticated origins over time
15:41:06 <dom> ... i.e. a deprecation plan for using getUserMedia on plain http
15:41:42 <dom> ekr: I don't find that analysis is uncompelling
15:42:53 <dom> ... the attacker can detour you from an unsecure origin
15:43:26 <dom> domenic: a more interesting technical question is whether this provides protection to the user
15:43:34 <dom> .... we've seen that it does
15:43:50 <alexG> domenic: we think authenticated origin provide more protection against proven attacks.
15:43:59 <dom> scribenick: alexG
15:44:10 <adam_> adam_ has joined #mediacap
15:44:12 <dom> i/Toipc: Welcome/ScribeNick: dom
15:44:18 <dom> i/Topic: Welcome/ScribeNick: dom
15:44:37 <alexG> ekr: supposing that https is enough even if you connect to an attacker site is not going to work.
15:45:15 <Cyril> Cyril has joined #mediacap
15:45:23 <eric_carlson> eric_carlson has joined #mediacap
15:45:25 <alexG> ekr: the problem is not asking GUM access over https
15:46:01 <alexG> ekr: the problem is to know when you can trust, wether it is http / https
15:46:26 <alexG> dominic: at least with https we can have alittl ebit more control and add red flags in the address bar.
15:46:38 <npdoty> it sounds like ekr is arguing that the user doesn't have any reason to trust the origin on http-only, but that it should be allowed in that case anyway
15:47:18 <alexG> ekr: what is the way forward with this questions in the absence of specific use case one way or another?
15:47:28 <alexG> domenic: i just wanted to convey the position of TAG, thank you
15:47:47 <alexG> hta: this is a good overview of the disagreements today
15:47:52 <mdadas> mdadas has joined #mediacap
15:48:42 <alexG> domenic: .... The specs should be consistent or it is not going to work. We should make things better for user down the path. nobody is proposing anything crazy, really.
15:49:00 <alexG> hta: this is actually how the first message came across. that might be the reason of the ... strength .... of the reaction
15:49:08 <alexG> domenic: i m happy i clarified this thing then.
15:49:35 <alexG> adamR: justin, do you have comment on this conversation?
15:50:06 <eric_carlson_> eric_carlson_ has joined #mediacap
15:50:14 <npdoty> it sounded to me like TAG was not suggesting a "flag day"
15:50:15 <alexG> justin: chrome would like to move to more https in the future, but breaking existing content is not ok. We should have a multi year deprecation process, but having a flag day today is not going to happen.
15:50:34 <alexG> ekr: couldn t we move ahead with GUM like it is today.
15:50:43 <alexG> dom: i heard your point, ad i find it compeling
15:51:05 <alexG> today, GUM is working on any origin, and there dis no compelling reason that we see to move away from that today.
15:51:55 <alexG> domenic: the worse outcome would be for users to see that you guys are putting together specs without making sure we re looking forward the future, and just saying that s how we do it today, and so be it. We would like you guys to have a future direction statement.
15:52:00 <GeunHyung> GeunHyung has joined #mediacap
15:52:01 <varun> varun has joined #mediacap
15:52:12 <alexG> ekr: what about a non normative note.
15:52:34 <alexG> hta: what about a statement like " a conform ant browser might decide to make this available over https only."
15:52:44 <npdoty> that doesn't lend itself to interoperability
15:52:47 <alexG> ekr: i thought it was the car, but if it s not, i d be happy to do it."
15:52:51 <alexG> hta: let s make it the case.
15:52:55 <dom> s/might decide/MAY decide/
15:53:02 <alexG> matthew: source selection
15:53:17 <dromasca> dromasca has joined #mediacap
15:53:19 <npdoty> +1
15:53:38 <alexG> domenic: someone brought the interop issue. one problem would be if one browser would work only over https, and another one would not, then call would not be established.
15:54:13 <alexG> ekr: can we stop saying that people that don t want to go for https don t care about the users.
15:54:34 <alexG> ekr: we have disagreement here, and let's agree to disagree.
15:54:38 <eric_carlson_> eric_carlson_ has joined #mediacap
15:54:53 <alexG> ekr: can we state that everybody wants to do what is right for the user, we just disagree about how to do it?
15:54:55 <alexG> domenic: ok
15:55:10 <alexG> matthew: i was observing that the GUM API as it stands might not have this property
15:55:27 <alexG> matthew: but we are having other things in the spec that potentially change the profile, hum, usage of this thing.
15:56:05 <alexG> getuserdevices has the possibility to enumerate devices and expose some things. it does not change the security profile, but give us the capacity to expose more or less informations that in turn influence the user decision
15:56:19 <alexG> matthew: is there an opportunity there to use this ?
15:56:25 <npdoty> s/matthew/martin/
15:56:33 <alexG> ekr: my bad :)
15:57:07 <alexG> dom: we have a rough agreement
15:57:14 <alexG> ... that non normative note is good
15:57:24 <alexG> domenic: yes, and i encourage that note to encourage https
15:57:34 <alexG> hta: any volunteer to draft this note
15:57:45 <alexG> ekr: i suggest that justin does it
15:58:04 <alexG> hta: ekr has volunteered to do it, and requested help from justin.
15:58:31 <alexG> hta: domenic thank you for having showed up, and enabled this discussion
15:58:33 <mt> mt has joined #mediacap
15:58:37 <Zakim> -Domenic
15:58:39 <alexG> dom: we re happy for you to stay of course if you want
15:58:45 <alexG> domenic: ok, good luck guys
15:59:06 <dom> Zakim, who's on the call?
15:59:06 <Zakim> On the phone I see TPAC
15:59:20 <dom> Topic: MediaStreamTrack.ended
15:59:31 <alexG> jib: presenting mediastreamtrack.ended
15:59:43 <alexG> jib: i m just going to show the problem
15:59:48 <alexG> jib: present a solution
15:59:52 <alexG> jib: and then we can speak about it
16:00:03 <alexG> jib: JS arrow functions as an example
16:00:12 <alexG> jib: <slide 3>
16:00:24 <alexG> I'm also going to use promises
16:00:47 <alexG> jib: here is background info and links
16:01:13 <alexG> burn: and it will also be part of the specs
16:01:18 <alexG> jib: <slide 4>
16:01:25 <alexG> jib: we have this ended event
16:01:34 <alexG> jib: the only thing it tells you is that the track has ended.
16:01:52 <alexG> jib: two kind of problems
16:02:05 <alexG> jib: call could have hanged up or dropped (which one?)
16:02:33 <alexG> jib: GUM could have stop capturing, have had permission problem, or a driver issue (which one?)
16:02:39 <alexG> jib: <slide 5>
16:02:51 <alexG> jib: so I propose an ended promise
16:03:16 <alexG> jib: allows to differentiate between two cases: success and failure
16:03:55 <alexG> jib: consistent with usage of promises for state change
16:04:21 <alexG> ekr: why not a "started" equivalent?
16:04:34 <alexG> ekr: my point is that not all those events have state changes
16:05:11 <alexG> jib: i m not proposing to replace the existing ones, i just want to show another way to get the errors and differentiate between several "types" of ended tracks
16:05:33 <alexG> hta: history of the problem: can we tell the difference between a track that ended between an error or not
16:05:40 <alexG> ekr: my concern is API consistency
16:05:56 <alexG> burn: you did not say you suggested we should remove the original one
16:06:17 <hta> q?
16:06:21 <alexG> ekr: that s then even worse if we don t remove: we have  two APIs for the same things, and I don t know when to use which
16:06:32 <alexG> sss(MS):
16:06:46 <alexG> is it the right way to handle all the errors, from different objects
16:06:54 <dom> s/sss/ShijunSun/
16:07:01 <juberti> juberti has joined #mediacap
16:07:07 <juberti> q+
16:07:09 <mt> mt has joined #mediacap
16:07:25 <alexG> jib: let s get to the second example
16:07:27 <alexG> <slide 7>
16:07:34 <pthatcher> pthatcher has joined #mediacap
16:07:53 <philcohen> philcohen has joined #mediacap
16:07:55 <Jun_MA_> Jun_MA_ has joined #mediacap
16:08:00 <alexG> jib: in this example, I don't care if I succeeded, it is just showing the different syntaxes
16:08:17 <alexG> jib: you can do a switch
16:08:51 <alexG> jib: i did a pull request where I pull all the existing errors and show how this would look like.
16:09:00 <Zakim> disconnecting the lone participant, TPAC, in Team_(mediacap)15:04Z
16:09:02 <Zakim> Team_(mediacap)15:04Z has ended
16:09:02 <Zakim> Attendees were TPAC, Domenic
16:09:04 <alexG> jib: here the error can happen upfront, or later on
16:09:18 <alexG> jib: you just don t want to end up not catching an error
16:09:23 <dom> ack justin
16:09:37 <alexG> jib: and there has been no other proposal that does all that so far.
16:10:10 <alexG> juberti: i wouldn t like to use the excuse of having promises for GUM to use them everywhere else.
16:10:17 <alexG> ekr: i agree with justin
16:10:18 <fluffy> fluffy has joined #mediacap
16:10:21 <alexG> jib: does seem like ......
16:10:35 <alexG> shijunshun: +1
16:10:45 <alexG> stefan: do we have the need for this?
16:10:51 <alexG> ekr/juberti: yes
16:11:00 <Ruinan_> Ruinan_ has joined #mediacap
16:11:14 <alexG> jib: you need to ale *some changes*
16:11:30 <alexG> ekr/justin: yes
16:11:37 <alexG> jib: then why not using prmises?
16:11:44 <DanD> DanD has joined #mediacap
16:12:01 <alexG> ekr: why not in this case, but not all events have that need, and we should note use promises everywhere because they are good for GUM.
16:12:08 <alexG> jib: I hear the consistency argument
16:12:20 <alexG> jib: there dis another pattern
16:12:31 <alexG> jib: we should use the best language that solves the problem
16:12:38 <alexG> ekr: i do not thing promises is that language
16:12:54 <alexG> adam: events happen more than once
16:13:00 <alexG> jib: ended only happens once
16:13:15 <alexG> adam: yes, but for other events, it does not stand and promises should not be used.
16:13:16 <Domenic> promises for state transitions that happen only once and that people might be interested in after the fact are strictly better tha nevents
16:13:23 <Domenic> events are not appropriate for that case
16:13:24 <alexG> ekr: it can t be all promises
16:13:30 <Domenic> and we have only used them because historically they were all we had
16:13:36 <mt1> mt1 has joined #mediacap
16:14:02 <fjh> fjh has joined #mediacap
16:14:19 <alexG> juberti: we changed from having a consistent use of callbacks, and now we would have some promises and some callbacks, and I don t like that as it does not bring such added value.
16:14:32 <dom> Domenic, the argument that is being made is that mixing events and promises for handling events makes for a confusing API
16:14:35 <Domenic> you have to be looking for consistency among things that are alike
16:14:41 <alexG> burn: we spend a lot of time defining which one should be event and which one should be callbacks
16:14:45 <Domenic> things that can jhappen more than once and things that happen once are not alike
16:14:58 <dom> well, both describe the object state machine
16:15:05 <alexG> burn: and we spend a lot of time making sure that programmers could almost guess from the pattern when one should be used.
16:15:22 <alexG> dom: we need a tech proposal.
16:15:25 <Domenic> dom: that's fair
16:15:29 <alexG> ek: right, i m happy to write a proposal
16:15:41 <alexG> hta: there is such a proposal in the bug that triggered that proposal
16:15:48 <alexG> er: even better, i ll do nothing!
16:16:04 <alexG> hta: there seems to be a rough consensus that we should extend events and not use promises.
16:16:16 <alexG> jib: any other questions on this?
16:16:19 <jib> jib has joined #mediacap
16:16:21 <alexG> jib: thank you
16:17:06 <alexG> hta: we are now pretty ahead of schedule
16:17:14 <alan-i> alan-i has joined #mediacap
16:17:31 <dom> Topic: Audio output device enumeration
16:17:35 <alexG> hta: let's have the audio output device enumeration discussion
16:19:06 <dom> -> https://www.w3.org/wiki/images/d/d6/Output_Device_Selection%2C_TPAC_2014.pdf Justin's slides
16:19:26 <fjh_> fjh_ has joined #mediacap
16:20:12 <alexG> juberti: in addition to having enumeration of input device, we also have the same feature for OUTPUT devices but we have no way to access it.
16:20:26 <alexG> juberti: why would we do that? #1 requested feature, before screensharing and others.
16:20:37 <alexG> juberti: usage scenario
16:21:02 <alexG> juberti: changing to usb or bluetooth headset
16:21:13 <alexG> juberti: right now, haven to change the system settings
16:21:18 <npdoty> does "in chrome" mean "in the web page, not in browser chrome"?
16:21:26 <alexG> <slide 4>
16:21:57 <alexG> juberti: no API for setting devices.
16:22:19 <alexG> juberti: we have a way to enumerate them, but no way to SET them
16:22:24 <npdoty> why do we even have a way to enumerate output devices?
16:22:47 <dom> npdoty, this idea was to enable this use case
16:23:00 <dom> (even though we've been missing the last piece of that puzzle)
16:23:08 <alexG> juberti: you want to avoid a few use case where arbitrary webpage cannot play content on your audio without user consent.
16:23:19 <alexG> juberti: a prompt would not be practical
16:23:28 <alexG> juberti: <slide 5>
16:23:50 <alexG> juberti: for any mediaElement (<audio. or <video>) would have an ID
16:24:06 <alexG> juberti: by default, set to empty, and use default output (always OK, today;s case)
16:24:38 <alexG> juberti: specific devices could deb set (unsung the enum API info) is application is authorized. web audio could also use it.
16:24:50 <alexG> juberti: <slide 7>
16:25:22 <alexG> juberti: most cases you could use the same group IS for input / output devices.
16:25:59 <alexG> juberti: for other apps that would need finer granularity, there would be another way of doing this.
16:26:07 <alexG> burn: permission is then for the group by default?
16:26:14 <dom> q+ to talk about where to spec this, coordination with other groups
16:26:15 <alexG> juberti: exactly.
16:26:36 <alexG> dan: would that show all permutations in the grouping? How do you define the grouping?
16:26:53 <alexG> juberti: that s for composite device, they have the same device ID / group ID.
16:27:07 <alexG> ekr: what would be the lifetime of the permission ?
16:27:14 <alexG> juberti: same as GUM.
16:27:35 <alexG> ekr: as long as origin is tagged, the permission stays.
16:28:28 <alexG> martin: if you have persistent permission, it means yo have access to all device at any time.
16:28:47 <alexG> juberti: yes, if you have access to all INPUT devices, and all OUTPUT devices are grouped with input device, that s true.
16:28:55 <alexG> martin: I think we should make it explicit.
16:29:33 <alexG> juberti: the coupling is quite elegant, and better than just using input devices.
16:29:42 <alexG> martin: we don t need more prompt
16:29:52 <npdoty> q+ to ask if the cases are so often coupled, why does it need to be exposed at all?
16:30:21 <dom> q- later
16:30:34 <npdoty> indeed. why are we pushing this onto the page?
16:30:53 <alexG> adam: even if I , as an application, have access to all the input device, i might not have access to all output devices?
16:31:10 <dom> for proper UX, npdoty (it's hard to build a nice user experience when everything is pushed to the browser chrome)
16:31:11 <alexG> juberti: you can already enumerate all of them, you just can t use output device.
16:31:35 <alexG> juberti: you know by using system permission, y ou already have practical access to all devices.
16:31:46 <npdoty> dom, the group thinks proper UX is more likely to happen if we distribute it out to every different web developer in the world
16:31:48 <npdoty> ?
16:32:00 <alexG> juberti: i think that 99% will either use the default setting, or ONE specific coupling they will give permission to.
16:32:21 <alexG> shijunshun: how to handle one the fly plugging in or plugging out devices
16:32:28 <alexG> juberti: not sure yet.
16:32:29 <dom> npdoty, I think that's a correct characterization, yes
16:32:44 <alexG> martin:  ....
16:34:06 <alexG> shijunshun: we have the notion of a default device, if anything is plugged in, the headphone has priority, and we fallback to default automatically. Now, it seems that webrtc would be a regression from what we propose today.
16:34:19 <alexG> matrin: i know how to solve that problem i think
16:34:34 <alexG> martin: there would be physical and logical devices
16:34:49 <alexG> by using logical devices, then we can switch on the fly between physical devices.
16:35:20 <alexG> shijunshun: does not have to be in the OS, could deb in IE.
16:35:20 <dom> q?
16:35:57 <alexG> juberti: enumartion API should preset those so the user know which one to choose from
16:36:26 <alexG> shijunshun: iframe might have different settings, so we have to be careful.
16:36:44 <alexG> juberti: things working out of iframe would be an issue anyway, if only for PeerConnection.
16:37:52 <alexG> shijunshun: my comment was more about the scope. do we want it restricted? do we want all page to control, including iframe, kind of overloading iframe settings?
16:37:58 <alexG> hta: about usage,
16:38:08 <alexG> hta: earlier in the week i was in the audio group
16:38:16 <alexG> hta: and they are very interesting in using the same mechanism.
16:38:37 <alexG> shujunshun: great, let's make sure the use case are all written.
16:38:45 <alexG> burn: let s say you are in an iframe
16:39:11 <alexG> burn: you can only set a device as output if you have permission to do, even though you could see it in the enum
16:39:31 <alexG> juberti: well not exactly, i think we can enumerate all, but you only get access from grouping.
16:39:49 <dom> ack npdoty
16:39:49 <Zakim> npdoty, you wanted to ask if the cases are so often coupled, why does it need to be exposed at all?
16:39:55 <stefanh> q?
16:39:57 <dom> q+ philcohen
16:39:59 <dom> q- later
16:40:19 <alexG> <someone from W3C> your assumption seems to be that the coupling is very frequent. It does not seems it need to be enumerated.  and you re also adding a whole list of permission dialogs.
16:40:22 <dom> q+ ekr
16:40:22 <dom> q- later
16:40:26 <alexG> juberti: this avoids permission dialog
16:40:42 <alexG> juberti: having a generic API ......
16:41:11 <alexG> juberti: the API we have here announce that abstraction, but underneath we have to deal with another layer ...
16:41:14 <burn> q+ to ask about stored permission state when this topic is done
16:41:29 <alexG> juberti: we have to deal with the cases where input and output are not a unique physical device.
16:42:00 <alexG> <someone from w3c>: if the browser does not handle the setting, will the website allow me to do it.
16:42:10 <alexG> martin: the site might have many things he wants to do at different point in time
16:42:27 <alexG> martin: if you play music, you might want to keep rendering that music on the same device.
16:42:41 <alexG> martin: but when you have a site that simultaneous plays music and communication
16:43:04 <fluffy> q?
16:43:05 <alexG> martin: you don t really have today the flexibility to handle the user experience the way you want
16:43:08 <dom> ack philcohen
16:43:20 <npdoty> s/<someone from w3c>/npdoty/
16:43:21 <ekr> ekr has joined #mediacap
16:43:30 <ekr> q?
16:43:31 <alexG> phil: many output devices in our case are not "grouped" with input device
16:43:33 <fluffy> q+
16:43:43 <alexG> and it s very important for us that the app should be able to use different devices.
16:44:00 <wy> wy has joined #mediacap
16:44:05 <dom> q- later burn
16:44:08 <alexG> phil: another use case: my son is listening to radio with headset, while i m watching a movie locally on my coputer
16:44:10 <dom> q+ burn
16:44:11 <alexG> computer
16:44:12 <dom> q- later
16:44:52 <alexG> juberti: we did an app that is media mixing, kind of garage band. There is no input for app. If we are saying that permission only from GUM, ....
16:45:08 <alexG> juberti: if you use a real pro audio app, you understand already the notion of door hanger
16:45:18 <npdoty> it sounds to me like we're suggesting that every page can choose non-coupled input/output (or maybe it won't have implemented it), which will cause more permission dialogs, but the user can also choose it separately on the browser
16:45:25 <alexG> juberti: for most of web users, the permission is much simpler
16:45:25 <mt1> q?
16:45:28 <mt1> q+
16:45:31 <npdoty> and if the user sets it in their browser first and then the site wants to change it?
16:45:44 <alexG> juberti: but this API also gives us the capacity to use door hanger for more professional apps.
16:45:45 <dom> ack ekr
16:45:54 <dom> q+ DanD
16:45:58 <dom> q-
16:46:00 <dom> q- burn
16:46:05 <npdoty> and if the user asks where they're supposed to configure audio output? in the site or in the browser? or in the site first but maybe overridden in the browser?
16:46:25 <alexG> ekr: do I understand that the goal is to allow a website to minimize the number of prompts for the most generic cases
16:46:29 <alexG> juberti: yes
16:46:48 <alexG> juberti: 90% would be: use the default or use that one specific set of devices.
16:46:55 <alexG> fluffy:
16:47:02 <jerome_> jerome_ has joined #mediacap
16:47:02 <ekr> I use the system microphone and the headset for sound
16:47:05 <alexG> fluffy: the app would enumerate the devices
16:47:24 <alexG> fluffy: the app would then ask permission for a specific device
16:47:37 <fluffy> q-
16:47:39 <alexG> fluffy: the door hanger would then kick in, and the app would get access?
16:47:53 <stefanh> q+ philcohen
16:47:58 <alexG> juberti: yes, or you have given persistent permission to that device beforehand and the door hanger would not even be needed
16:48:11 <alexG> martin: is there a need for labels for groups ....?
16:48:21 <alexG> martin: you said default and default group
16:48:48 <pthatcher> q+
16:48:52 <alexG> juberti: ....
16:49:34 <alexG> martin: the use case you mentioned is only for app that are already using this API
16:49:37 <alexG> juberti: yes
16:49:49 <alexG> martin: then they should be aware of this problem, and have an UI, and so on
16:49:57 <dom> ack mt
16:49:59 <dom> ack DanD
16:50:01 <npdoty> mt, because you think developers are unlikely to make mistakes about edge cases of hardware?
16:50:10 <alexG> juberti: well, yes, but they could still make a bad choice. generally, the complexity is not transferred to the app.
16:50:12 <alexG> dan:
16:50:34 <alexG> dan: would it be good to be able to select audio/video only to simplify the list ?
16:50:48 <dom> s/audio/input
16:50:51 <dom> s/video/output
16:51:40 <dom> ack DanD
16:51:43 <alexG> juberti: practicalities make it something we don t want.
16:51:50 <dom> q+ burn
16:52:14 <alexG> phil: is there a way that JS know in advance which permission it has access to?
16:52:14 <dom> q+ to ask where to spec this, talk about coordination with other groups
16:52:17 <alexG> juberti: yes
16:52:21 <dom> ack pthatcher
16:52:51 <alexG> phil: some devices are also accessible, how do we populate the drop down with that?
16:52:53 <dom> ack philcohen
16:53:14 <alexG> juberti: good point
16:53:40 <alexG> juberti: how do we do for output device, what we do with the input device? .... that s a good question, i need to think about that.
16:54:25 <alexG> phil: enumarate device might prompt once for allowing ALL devices to be used. so the enumerate API also allow them in one step.
16:54:38 <alexG> juberti: yes , could do that, but it would be difficult to understand by users.
16:55:01 <alexG> martin:
16:55:15 <ekr> q+
16:55:24 <npdoty> it would be a new permission model to say you get permission to things that are less egregious than any permissions you've already granted.
16:55:51 <alexG> juberti/martin: discussion about how to do it right.
16:56:12 <alexG> phil: just to clarify, i just want a way for the user to enable all the output device.
16:56:22 <alexG> juberti: we might b something new to enable what you propose
16:56:52 <dom> ack burn
16:57:06 <alexG> burn: the persistent permission implies access to all input devices
16:57:15 <alexG> burn: and that surprises me
16:57:36 <alexG> burn: <reading specs>
16:58:08 <mt1> q?
16:58:27 <alexG> burn: I'm realizing that we actually give permission to ALL devices, while I thought it would give permission for a specific device (the one i agree on in the prompt)
16:58:39 <gludi|3> gludi|3 has joined #mediacap
16:58:57 <ekr> q?
17:00:06 <alexG> burn: the implementation consequences are minimal (at least in chrome), but for the user it s quite a shock, I was not personally aware that i was giving away that much
17:00:53 <alexG> dom: we have to contact other groups for that discussion. e.g. web audio, HTMLMediaElement belongs to another group and so one and so forth. We need cross group coordination.
17:01:17 <alexG> juberti: I think we need to document the attack scenario, and reach consensus at least within the group before we bring it to other groups.
17:01:30 <gludi|4> gludi|4 has joined #mediacap
17:01:32 <alexG> dom: my perspective is that we should drealy try to spec it
17:01:39 <alexG> juberti: how do you do it?
17:01:46 <alexG> dom: you do a partial interface .....
17:01:53 <dom> ack me
17:01:53 <Zakim> dom, you wanted to ask where to spec this, talk about coordination with other groups
17:01:54 <alexG> juberti: yes, that would be way more efficient
17:01:57 <dom> ack ekr
17:02:41 <alexG> ekr: the problem i typically run into is when i am using the system microphone, with a non standard headset.
17:02:45 <alexG> ekr .....
17:02:55 <alexG> ekr: there are also hierarchy of devices .....
17:03:09 <richt_> richt_ has joined #mediacap
17:03:24 <alexG> dom: next steps?
17:03:39 <alexG> juberti: take this proposal and make it into a pull request against existing specs
17:03:47 <alexG> dom: I would make it a spec on its own.
17:03:57 <alexG> juberti: ok, is there a template, and where should that thing reside?
17:04:02 <alexG> dom: i can guide you.
17:04:12 <alexG> juberti: ok great, i know who to delegate to.
17:04:39 <alexG> juberti: i also think that there are a couple of questions that showed up here today and should be written as well in the document.
17:04:50 <alexG> hta: we re still ahead of schedule
17:05:06 <alexG> i propose a 15mn break
17:05:15 <alexG> hta: so break until 20 past.
17:07:09 <ekr> ekr has joined #mediacap
17:07:26 <mt> mt has joined #mediacap
17:09:58 <richt__> richt__ has joined #mediacap
17:14:20 <gludi|4> gludi|4 has joined #mediacap
17:17:27 <alan-i> alan-i has joined #mediacap
17:23:58 <mt> mt has joined #mediacap
17:25:35 <mt> mt has joined #mediacap
17:27:09 <mt1> mt1 has joined #mediacap
17:28:31 <GeunHyung_> GeunHyung_ has joined #mediacap
17:31:07 <saki> saki has joined #mediacap
17:32:32 <Ruinan> Ruinan has joined #mediacap
17:32:43 <ken__> ken__ has joined #mediacap
17:32:50 <ekr> ekr has joined #mediacap
17:32:55 <dom> Topic: Next steps for Media Capture and Streams document
17:33:48 <juberti> juberti has joined #mediacap
17:33:53 <npdoty> talking about Last Call
17:33:59 <npdoty> dom: a refresher on Last Call
17:34:09 <npdoty> ... assuming we get consensus to go to Last Call
17:34:16 <npdoty> ... have to make a number of decisions about how that last call will happen
17:34:32 <npdoty> ... have to decide the amount of time for comments. W3C Process minimum is 3 weeks, but can be longer
17:34:41 <npdoty> ... review will be open to everyone, but some groups we should specifically contact
17:35:05 <npdoty> ... during the time of the formal review period, need to formally track each comment, formally respond, formally seek feedback to our response
17:35:21 <npdoty> hta: a formal definition of "formal"?
17:35:42 <npdoty> dom: need to log each comment (like to the mailing list), needs to send a response, best effort to see that the comment is accepted by the commenter
17:35:46 <Shige> Shige has joined #mediacap
17:35:53 <npdoty> ... not every comment needs to be considered an issue
17:36:06 <npdoty> ... some comments may repeat existing issues without raising new information
17:36:28 <npdoty> ... even if the comment is not raising a new issue, need to indicate to the commenter, past discussion and arguments
17:36:54 <npdoty> burn: typically we track every comment that comes in. need to be prepared to give a proposed resolution
17:37:07 <npdoty> ... eg "we already discussed this and we decided not to do this" or "clarification we'll want to do"
17:37:15 <npdoty> ... need to communicate that proposed resolution to the commenter
17:37:27 <npdoty> ... make your best effort to get back their acceptance or rejection of your proposed resolution
17:37:43 <npdoty> ... often give a time limit, if we don't hear from you in two weeks, then we'll assume you accept our resolution
17:38:03 <npdoty> ... should separately track implied vs. explicit acceptance, in order to have clarity for the transition call later
17:38:21 <npdoty> dom: have a tool for tracking comments that we might or might not use
17:38:40 <npdoty> ... groups we have intersection with, groups mentioned in our charter
17:38:42 <mt> mt has joined #mediacap
17:38:43 <npdoty> ... first list of groups
17:39:03 <npdoty> ... WebPaps, TAG, Audio, HTML, WAI PF, IETF RTCWeb
17:39:12 <npdoty> s/WebPaps/Webapps/
17:39:37 <npdoty> ... forgot for the slides, but should add the Privacy Interest Group (PING)
17:39:39 <npdoty> npdoty: thanks
17:39:48 <npdoty> dom: might ask the RTCWeb group to formally chime in
17:39:55 <npdoty> ... just my suggestion, for reductions or extensions
17:39:58 <fluffy> q+
17:40:28 <npdoty> dom: once we're done with Last Call comments
17:40:31 <npdoty> ... either go to Candidate Recommendation (no substantive changes that requires more reviews)
17:40:38 <npdoty> ... otherwise, need to go back to Last Call
17:40:57 <npdoty> ... transition request to the W3C Director, including the detailed review of the comments we have received
17:41:28 <npdoty> ... for commenters who don't accept the resolution, would check whether we need a Formal Objection, with a separate process
17:41:51 <npdoty> ... Last Call can be a difficult period, which this group may be familiar with
17:42:01 <npdoty> ... attention from groups who may not have followed all the details of your work
17:42:10 <npdoty> burn: in my experience, Last Call can effectively be first call
17:42:13 <npdoty> ack fluffy
17:42:30 <npdoty> fluffy: do you try to get feedback from those groups before we get into the formal Last Call step?
17:42:41 <npdoty> burn: one way is to involve these groups before Last Call
17:42:55 <npdoty> ... ask them ahead of time. may save you from doing a second Last Call
17:43:08 <npdoty> dom: we've had a number of interactions with TAG and WebApps
17:43:21 <npdoty> ... had some early reviews from Privacy Interest Group, but doc has changed significantly
17:43:38 <npdoty> burn: met with WAI rep, indicated an area they care about a lot
17:43:44 <npdoty> ... should get involved sooner rather than later
17:43:56 <npdoty> fluffy: as comments get moved to Formal Objections, who can raise those?
17:44:18 <npdoty> dom: anyone can raise a Formal Objection.
17:44:24 <npdoty> no Membership requirement, any individual or organization
17:44:49 <npdoty> dom: Formal Objection is not something done cheaply, as a social matter. requires quite detailed documentation
17:45:14 <npdoty> hta: what constitutes a Last Call comment?
17:45:21 <GeunHyung_> GeunHyung_ has joined #mediacap
17:45:38 <npdoty> ... any message to the mailing list?
17:45:44 <npdoty> dom: if there's ambiguity, you can ask
17:45:52 <npdoty> ... most cases it's fairly clear
17:46:31 <npdoty> burn: in some groups, could say that anything from a public list was a Last Call comment
17:46:44 <npdoty> ... but now all groups are operating in public
17:46:59 <npdoty> ... social issues, but that doesn't stop some people
17:47:12 <npdoty> dom: understood that WG members should not raise Last Call comments, but can
17:47:21 <npdoty> ... for example, if you understand something that's new
17:47:29 <npdoty> ... could have a separate mailing list for comments
17:47:40 <npdoty> ... most groups just use public mailing lists
17:48:14 <npdoty> burn: for every comment, it's useful to have an email track as well as minutes. so that later you can point back to it
17:48:35 <npdoty> ... track discussion of comments, not just the comment itself
17:48:41 <npdoty> dom: the tool I'm thinking of can do some of this tracking
17:48:43 <ken> ken has joined #mediacap
17:49:08 <npdoty> <mic noise>
17:49:19 <npdoty> dom: when would we go to Last Call for getUserMedia?
17:49:39 <npdoty> hta: one requirement is to close the bugs
17:49:49 <npdoty> ... tomorrow we are going through the remaining bugs (8)
17:50:10 <npdoty> ... and the group needs consensus to go to Last Call
17:50:28 <npdoty> ... if we have wildly different opinions....
17:50:44 <npdoty> burn: time to go to Last Call is that we don't expect substantive changes (otherwise CR)
17:50:55 <npdoty> ... we have a note in the document today about things we're expressly seeking feedback on
17:51:16 <npdoty> ... about promise backward-compatibility navigator syntax
17:51:26 <npdoty> ... and a few editorial notes in the document
17:51:39 <donghoon> donghoon has joined #mediacap
17:51:56 <varun> varun has joined #mediacap
17:51:56 <npdoty> hta: once we close these 8 bugs, does the group believe it's in a state where we should issue a Last Call?
17:52:05 <npdoty> fluffy: how many people have read the document in the last six months?
17:52:18 <npdoty> ... read, not looked at
17:52:45 <npdoty> burn: we should not wait long at all to request review from these other groups, whether or not Last Call
17:53:06 <npdoty> dom: one of the advantages of wide review of Last Call is to limit ourselves about not wanting to make big substantive changes
17:53:10 <npdoty> ... developers don't like that as much
17:53:40 <npdoty> burn: the next exclusion period for intellectual property. Last Call triggers one
17:54:08 <npdoty> mt: what should we do with changes during this time? (don't want to make changes during the Last Call review)
17:54:15 <npdoty> dom: could make partial interfaces / new specs
17:54:27 <npdoty> ... or look at a new version, could be in a different branch
17:54:28 <ken_> ken_ has joined #mediacap
17:55:04 <npdoty> fluffy: should seriously read this document, because it's going to be frozen for a while
17:55:47 <npdoty> hta: where it's possible in a reasonable way to write a separate document that extends interfaces, that's preferable
17:56:04 <npdoty> ... a separate question about what makes sense about integrating or keeping a separate spec
17:56:17 <npdoty> burn: if you know you have something substantial to add to this document
17:56:26 <npdoty> ... then it's not really the last Last Call
17:56:41 <npdoty> ... putting the community through official review steps
17:56:53 <npdoty> mt: the tension between the idea that we have a living spec
17:57:09 <npdoty> fluffy: this is not a living spec. Last Call is a sign that we're freezing it
17:57:29 <npdoty> burn: you don't typically do a Last Call unless you're really indicating that you're done with it
17:57:41 <timeless> RRSAgent, draft minutes
17:57:41 <RRSAgent> I have made the request to generate http://www.w3.org/2014/10/30-mediacap-minutes.html timeless
17:57:42 <npdoty> hta: basic conflict between publishing Rec track vs. living specs
17:57:45 <varun_> varun_ has joined #mediacap
17:57:55 <timeless> RRSAgent, make logs world
17:58:09 <npdoty> fluffy: if we allocate ten people from this room to review this document beginning to end, would get a lot of comments
17:58:11 <timeless> Meeting: Media Capture F2F (TPAC2014)
17:58:20 <npdoty> ... we should do that before we issue a Last Call and get those comments from a dozen different groups
17:58:26 <timeless> RRSAgent, this meeting spans midnight
17:58:44 <npdoty> dom: goal should be a conservative approach to commenting
17:59:05 <npdoty> fluffy: we should fix the things that everyone will indicate that we fix
17:59:25 <npdoty> ekr: we should get approximate signoff from implementers, prior to Last Call
17:59:46 <npdoty> ... if those people are basically happy, we can talk about going to Last Call. but if they're not, then we need to resolve those issues first
18:00:08 <npdoty> fluffy: we put out a deadline for comments twice. only two responses?
18:00:25 <timeless> q?
18:00:30 <timeless> q+ to say i might read it
18:01:13 <npdoty> ... can we get volunteers from several, separate individuals from major implementers to review?
18:01:46 <npdoty> timeless: once we have an announce list for reviews, I'll be a part of it. I would do a pass, I would do a very detailed review
18:01:53 <npdoty> ack timeless
18:01:53 <Zakim> timeless, you wanted to say i might read it
18:02:13 <npdoty> ... or could contact some individuals like me separately
18:02:48 <npdoty> fluffy: everybody who's ever read it before has had a lot of comments. rate doesn't seem to be dropping
18:02:59 <npdoty> burn: need a full pass through of entire document
18:03:03 <npdoty> dom: specific action items?
18:03:09 <saki_> saki_ has joined #mediacap
18:03:12 <timeless> Zakim, who is on the call?
18:03:13 <npdoty> ... who volunteers?
18:03:13 <Zakim> apparently Team_(mediacap)15:04Z has ended, timeless
18:03:15 <Zakim> On IRC I see saki_, varun_, ken_, donghoon, GeunHyung_, mt, Shige, juberti, ekr, Ruinan, alan-i, jerome_, wy, fjh, jib, DanD, fluffy, Jun_MA_, philcohen, eric_carlson, adamR,
18:03:15 <Zakim> ... alexG, hta, shinwoo, ShijunS, npdoty, Domenic, burn, stefanh, RRSAgent, Zakim, dom, anssik, richt, Josh_Soref, derf_, xeoncore, slightlyoff, timeless, trackbot
18:03:26 <timeless> present+ Josh_Soref
18:03:51 <npdoty> hta: give it two weeks for comments. 15 November
18:04:13 <dom> ACTION: ShijunS to make full review of getUserMedia - due Nov 21
18:04:13 <trackbot> Error finding 'ShijunS'. You can review and register nicknames at <http://www.w3.org/2011/04/webrtc/mediacap/track/users>.
18:04:17 <dom> ACTION: Shijun to make full review of getUserMedia - due Nov 21
18:04:17 <trackbot> Error finding 'Shijun'. You can review and register nicknames at <http://www.w3.org/2011/04/webrtc/mediacap/track/users>.
18:04:49 <timeless> s/hi Domenic, thanks for joining! we're still getting set up here FWIW//
18:04:53 <gludi|4> gludi|4 has joined #mediacap
18:05:01 <timeless> s/ok, np.//
18:05:17 <timeless> s/lol wut//
18:05:18 <npdoty> mt: a big document. would take time, but IETF/vacation are conflicts
18:05:29 <dom> ACTION: martin to make full review of getUserMedia - due Nov 28
18:05:29 <trackbot> Error finding 'martin'. You can review and register nicknames at <http://www.w3.org/2011/04/webrtc/mediacap/track/users>.
18:05:31 <Domenic> Domenic has left #mediacap
18:05:42 <npdoty> burn: November and December can be a slow time for responses
18:05:48 <timeless> s/(hi everyone)//
18:05:55 <dom> ACTION: Josh to make full review of getUserMedia - due Nov 28
18:05:55 <trackbot> Created ACTION-30 - Make full review of getusermedia [on Josh Soref - due 2014-11-28].
18:06:21 <timeless> RRSAgent, draft minutes
18:06:21 <RRSAgent> I have made the request to generate http://www.w3.org/2014/10/30-mediacap-minutes.html timeless
18:06:23 <dom> ACTION: juberti to make full review of getUserMedia - due Nov 28
18:06:23 <trackbot> Error finding 'juberti'. You can review and register nicknames at <http://www.w3.org/2011/04/webrtc/mediacap/track/users>.
18:06:55 <timeless> s/:P//
18:07:11 <timeless> s|i/Toipc: Welcome/ScribeNick: dom||
18:07:49 <npdoty> hta: will note to the mailing list that we have a few volunteers for comments by November 28th, and we're soliciting more
18:08:14 <npdoty> burn: even comments indicating that you can't understand it, is useful information
18:08:15 <dom> ACTION: PhilCohen to do full review of getUserMedia - due Nov 28
18:08:15 <trackbot> Error finding 'PhilCohen'. You can review and register nicknames at <http://www.w3.org/2011/04/webrtc/mediacap/track/users>.
18:08:38 <npdoty> dom: but we do want to finalize this thing
18:08:43 <varun> varun has joined #mediacap
18:09:06 <npdoty> mt: will generate pull requests for editorial, grammatical things
18:09:48 <timeless> i/talking about Last Call/scribenick: npdoty/
18:10:04 <timeless> RRSAgent, draft minutes
18:10:04 <RRSAgent> I have made the request to generate http://www.w3.org/2014/10/30-mediacap-minutes.html timeless
18:10:05 <npdoty> fluffy: commits, can cherry pick, but grateful for any review at this point
18:11:27 <npdoty> stefanh: end of the morning agenda
18:11:36 <npdoty> ... will continue in this room after lunch with #webrtc
18:12:12 <npdoty> <agenda discussion>
18:12:43 <npdoty> Topic: Mediacapture bugs
18:13:09 <adamR> adamR has joined #mediacap
18:13:17 <npdoty> fluffy: "volume" is underdefined
18:13:23 <shinwoo> shinwoo has joined #mediacap
18:13:35 <npdoty> hta: could define as a number of decibels, which would be inconsistent wtih HTML
18:13:46 <npdoty> fluffy: but it's not that. my proposal is that it's a multiplier in a linear space
18:13:53 <npdoty> ... 0 is silence. 1 is maximum volume
18:14:08 <ken> ken has joined #mediacap
18:14:53 <npdoty> fluffy: a volume setting you can move up and down between 0 and 1
18:15:19 <npdoty> ... could be a linear or logarithmic curve, just pick one. this is linear
18:15:33 <npdoty> hta: using a constraint as if it were a control
18:15:43 <npdoty> ekr: if you want this, why not use WebAudio?
18:15:44 <eric_carlson> eric_carlson has joined #mediacap
18:15:52 <npdoty> dom: doesn't make sense as a constraint
18:15:58 <varun_> varun_ has joined #mediacap
18:16:21 <npdoty> fluffy: we had some confusion over 0.5. could remove "volume". not sure WebAudio covers all cases
18:16:23 <ken_> ken_ has joined #mediacap
18:16:28 <npdoty> ekr: is there some reason you can't do it with a filter?
18:16:40 <npdoty> fluffy: different implmenations will do it different ways
18:16:48 <npdoty> mt: isolated streams is an example
18:17:12 <npdoty> fluffy: maybe we shouldn't re-open whether to have volume or not. only proposed change is explaining the meaning of 0.5
18:17:20 <npdoty> hta: let's integrate this change and close this bug
18:17:32 <npdoty> burn: a clarification, not a change to the requirements for it.
18:17:38 <npdoty> ... if we all agree
18:18:41 <adamR_> adamR_ has joined #mediacap
18:20:11 <npdoty> mt: some encouragement will be provided. it's probably a bad idea to do it over an unauthenticated origin
18:20:29 <npdoty> hta: will assign that to ekr
18:20:31 <npdoty> q+
18:21:11 <npdoty> q-
18:21:30 <npdoty> npdoty: should be clear about whether the requirement on stored permissions is normative
18:21:36 <npdoty> ekr: it should be normative, as it is in IETF
18:22:04 <npdoty> npdoty: and that stored permissions section would be a good place for the additional encouragement, and should use a better definition for "secure origin"
18:22:11 <npdoty> ... may follow up in email
18:23:06 <npdoty> @@: constrainable pattern, which is abstract. and specific use in getUserMedia
18:23:27 <npdoty> ... specific use doesn't need to be abstract. should say exactly what is returned
18:24:00 <npdoty> ... reuse the existing MediaTrackContraintSet dictionary, which may be added to in the future
18:25:07 <npdoty> ... a second dictionary, a subset of the capability set
18:25:19 <npdoty> ... hopefully I get back success and get back values
18:25:42 <npdoty> ... capabilities is a superset of constraints which is a superset of settings
18:26:01 <saki> saki has joined #mediacap
18:26:03 <npdoty> ... pull request illuminates that the datatypes are related
18:26:25 <npdoty> ... should we write two more dictionaries (enumerating the same keys), or should we just re-use the same type?
18:26:52 <npdoty> ... re-use the same type because capabilities are exactly the same structure (based on the prose)
18:27:22 <npdoty> burn: IDL, we don't say that, that would be a change to the document
18:27:27 <mt> q+
18:28:05 <npdoty> @@: we could use a narrower data type for the returned set, but it could easily be the same data type
18:28:39 <npdoty> s/@@/jib/g
18:29:15 <npdoty> mt: no content-accessible type information are available
18:29:26 <npdoty> ... maybe it should return an array of strings rather than a dictionary anyway
18:30:05 <npdoty> ... don't mind about the difference between capabilities and constraints. tough for spec authors and implementers, but oh well
18:30:31 <npdoty> ... JavaScript more natural to use an array, with indexOf
18:31:09 <npdoty> jib: could be a fourth use of the dictionary. return a dictionary that you can enumerate, all the keys you find in there are supported
18:31:19 <npdoty> ... UA puts in some truthy, an object
18:31:32 <hoyounkim> hoyounkim has joined #mediacap
18:31:32 <npdoty> burn: trying to remember why we did it this way
18:32:08 <npdoty> fluffy, where are you?
18:32:27 <npdoty> burn: don't want to put the same defined type for all those different returns
18:32:32 <npdoty> ... because they're not the same return
18:32:57 <npdoty> jib: X, Y and Z are different things, even if they're the same type
18:33:27 <npdoty> ... we need more specific text. either this pull request with using the same dictionary, or we define more specific dictionaries
18:34:07 <npdoty> hta: separate discussion of getSupportedConstraints
18:34:08 <npdoty> q?
18:34:10 <npdoty> ack mt
18:34:30 <npdoty> ... capabilities, you might want to look at the value, modify it slightly and then send it back to the browser
18:35:04 <npdoty> burn: even if you want them to be almost the same data structure, I'd rather see different names for them
18:35:21 <npdoty> jib: different names, same type
18:35:39 <npdoty> ... argument type, argument name
18:36:49 <npdoty> dom: developers are not likely to read the spec
18:36:58 <npdoty> mt: something we typically leave to editorial discretion
18:37:17 <npdoty> ... if they can address it in some way, leave it up to them
18:37:25 <npdoty> ... we will review the outcome and ensure it's not crazy
18:37:28 <npdoty> ... acceptable?
18:37:50 <npdoty> jib: fine. but want to specify something, not just abstract types
18:37:54 <npdoty> burn: I hear you.
18:38:09 <npdoty> ... we already have the prose for it, but now have the IDL
18:38:50 <npdoty> fluffy: legal syntax is different
18:39:42 <npdoty> dom: has anyone started implementing?
18:40:07 <npdoty> jib: hoping not to make any functional changes at this point
18:40:29 <npdoty> hta: WG position is to leave to editorial discretion
18:40:31 <npdoty> dom: WebIDL must be valid
18:40:59 <npdoty> fluffy: editors please bring us a proposal
18:41:44 <npdoty> [adjourned for lunch.]
18:42:24 <npdoty> re-convene at 1pm
18:42:31 <npdoty> rrsagent, please draft the minutes
18:42:31 <RRSAgent> I have made the request to generate http://www.w3.org/2014/10/30-mediacap-minutes.html npdoty
18:42:31 <alan-i> alan-i has left #mediacap
18:45:10 <ken> ken has joined #mediacap
18:45:16 <mt> mt has joined #mediacap
18:46:18 <GeunHyung_> GeunHyung_ has left #mediacap
18:46:51 <hoyounkim> hoyounkim has joined #mediacap
18:48:27 <hoyounkim> hoyounkim has left #mediacap
19:03:15 <ekr> ekr has joined #mediacap
19:16:52 <ekr> ekr has joined #mediacap
19:23:07 <ken> ken has joined #mediacap
19:31:54 <jib> jib has joined #mediacap
19:33:52 <timeless> chair: hta
19:42:42 <ken_> ken_ has joined #mediacap
19:52:43 <hta> hta has joined #mediacap
19:56:08 <ekr> ekr has joined #mediacap
19:57:05 <ken> ken has joined #mediacap
19:59:05 <ekr1> ekr1 has joined #mediacap
19:59:31 <varun> varun has joined #mediacap
20:02:27 <ken_> ken_ has joined #mediacap
20:03:20 <adamR> adamR has joined #mediacap
20:08:37 <hta> hta has joined #mediacap
20:09:47 <dom> dom has joined #mediacap
20:11:10 <fluffy> fluffy has joined #mediacap
20:18:46 <eric_carlson> eric_carlson has joined #mediacap
20:19:21 <mt> mt has joined #mediacap
20:22:33 <eric_carlson_> eric_carlson_ has joined #mediacap
20:26:25 <dom> RRSAgent, draft minutes
20:26:25 <RRSAgent> I have made the request to generate http://www.w3.org/2014/10/30-mediacap-minutes.html dom
20:39:30 <mt> mt has joined #mediacap
20:42:39 <jib> jib has joined #mediacap
20:42:45 <eric_carlson> eric_carlson has joined #mediacap
20:45:17 <mt1> mt1 has joined #mediacap
20:49:29 <jib_> jib_ has joined #mediacap
20:54:35 <eric_carlson> eric_carlson has joined #mediacap
20:58:19 <lgombos_> lgombos_ has joined #mediacap
20:59:13 <eric_carlson_> eric_carlson_ has joined #mediacap
21:02:00 <eric_carlson> eric_carlson has joined #mediacap
21:02:56 <Zakim> Zakim has left #mediacap
21:10:49 <GeunHyung_> GeunHyung_ has joined #mediacap
21:18:42 <eric_carlson> eric_carlson has joined #mediacap
21:19:33 <fjh> fjh has joined #mediacap
21:26:10 <fjh> fjh has joined #mediacap
21:29:01 <eric_carlson_> eric_carlson_ has joined #mediacap
21:30:08 <fjh> fjh has joined #mediacap
21:30:37 <wy> wy has joined #mediacap
21:37:38 <npdoty> npdoty has joined #mediacap
21:38:10 <fjh> fjh has joined #mediacap
21:43:48 <npdoty_> npdoty_ has joined #mediacap
21:45:53 <ken> ken has joined #mediacap
22:01:23 <gludi|4> gludi|4 has joined #mediacap
22:04:47 <ekr> ekr has joined #mediacap
22:07:31 <ken> ken has joined #mediacap
22:11:00 <dom> dom has joined #mediacap
22:16:03 <fjh> fjh has joined #mediacap