13:30:59 RRSAgent has joined #dap 13:30:59 logging to http://www.w3.org/2010/09/15-dap-irc 13:31:01 RRSAgent, make logs world 13:31:01 Zakim has joined #dap 13:31:03 Zakim, this will be DAP 13:31:03 ok, trackbot; I see UW_DAP()10:00AM scheduled to start in 29 minutes 13:31:04 Meeting: Device APIs and Policy Working Group Teleconference 13:31:04 Date: 15 September 2010 13:31:38 Agenda: http://lists.w3.org/Archives/Public/public-device-apis/2010Sep/0066.html 13:32:38 Chair: Robin_Berjon, Frederick_Hirsch 13:32:53 Present+ Robin_Berjon, Frederick_Hirsch 13:34:41 Regrets+ John_Morris, Niklas_Widell, Laura _Arribas, Claes_Nilsson 13:35:07 Regrets+ Marco_Marengo 13:48:37 AnssiK has joined #dap 13:48:46 darobin has joined #dap 13:57:20 UW_DAP()10:00AM has now started 13:57:27 +??P2 13:57:33 Zakim, ??P2 is me 13:57:33 +darobin; got it 13:57:49 + +1.202.637.aaaa 13:57:52 Suresh has joined #dap 13:58:02 Present+ Suresh_Chitturi 13:58:19 +[IPcaller] 13:58:24 Present+ Anssi_Kostiainen 13:58:31 zakim, IPcaller is me 13:58:31 +fjh; got it 13:58:35 zakim, who is here? 13:58:35 On the phone I see darobin, +1.202.637.aaaa, fjh 13:58:36 On IRC I see Suresh, darobin, AnssiK, Zakim, RRSAgent, fjh, lgombos, Marcos, tlr, wmaslowski, ingmar, ilkka, dom, trackbot 13:58:56 zakim, aaaa is enewland 13:58:56 +enewland; got it 13:58:59 + +358.504.86aabb 13:59:05 zakim, aabb is AnssiK 13:59:05 +AnssiK; got it 13:59:05 enewland has joined #dap 13:59:26 present+ erica_newland 13:59:43 + +358.504.86aacc 13:59:50 Zakim, mute aacc 13:59:50 +358.504.86aacc should now be muted 13:59:54 Fan_HU has joined #dap 14:00:05 zakim, aacc is ilkka 14:00:05 +ilkka; got it 14:00:15 present+ Fan_HU 14:00:44 zakim, code? 14:00:44 the conference code is 3279 (tel:+1.617.761.6200 tel:+33.4.26.46.79.03 tel:+44.203.318.0479), dom 14:00:51 +??P10 14:01:06 Present+ Dominique_Hazael-Massieux 14:01:06 zakim, who is here? 14:01:06 On the phone I see darobin, enewland, fjh, AnssiK, ilkka (muted), ??P10 14:01:06 On IRC I see Fan_HU, enewland, Suresh, darobin, AnssiK, Zakim, RRSAgent, fjh, lgombos, Marcos, tlr, wmaslowski, ingmar, ilkka, dom, trackbot 14:01:13 zakim, ??P10 is me 14:01:13 +dom; got it 14:01:16 *Fan: havent dialled yet 14:01:24 bryan has joined #dap 14:01:29 zakim, who is here? 14:01:30 On the phone I see darobin, enewland, fjh, AnssiK, ilkka (muted), dom 14:01:34 On IRC I see bryan, Fan_HU, enewland, Suresh, darobin, AnssiK, Zakim, RRSAgent, fjh, lgombos, Marcos, tlr, wmaslowski, ingmar, ilkka, dom, trackbot 14:01:54 + +1.408.216.aadd 14:01:58 -ilkka 14:02:00 zakim, aadd is Suresh 14:02:00 +Suresh; got it 14:02:16 richt has joined #dap 14:02:33 + +1.425.214.aaee 14:02:45 + +44.208.849.aaff 14:02:47 + +1.760.705.aagg - is perhaps correct 14:02:55 zakim, who's noisy? 14:02:59 present+bryan_sullivan 14:03:05 zakim, aaee is Fan_HU 14:03:05 +Fan_HU; got it 14:03:06 dom, listening for 10 seconds I heard sound from the following: Suresh (6%), darobin (5%), fjh (73%) 14:03:11 +[IPcaller] 14:03:20 +ilkka 14:03:21 zakim, aagg is me 14:03:21 sorry, richt, I do not recognize a party named 'aagg' 14:03:22 zakim, who is here? 14:03:22 On the phone I see darobin, enewland, fjh, AnssiK, dom, Suresh, Fan_HU, +44.208.849.aaff, correct, [IPcaller], ilkka 14:03:23 zakim bryan_sullivan aaee handle 14:03:25 On IRC I see richt, bryan, Fan_HU, enewland, Suresh, darobin, AnssiK, Zakim, RRSAgent, fjh, lgombos, Marcos, tlr, wmaslowski, ingmar, ilkka, dom, trackbot 14:03:26 zakim, aaff is Fan_HU 14:03:26 zakim, mute illka 14:03:30 +Fan_HU; got it 14:03:34 zakim, mute ilkka 14:03:34 sorry, dom, I do not know which phone connection belongs to illka 14:03:36 Zakim, mute ilkka 14:03:42 zakim, aaee is bryan 14:03:42 ilkka should now be muted 14:03:46 ilkka was already muted, darobin 14:03:48 sorry, fjh, I do not recognize a party named 'aaee' 14:03:48 thanks 14:03:56 zakim, who is here? 14:03:58 On the phone I see darobin, enewland, fjh, AnssiK, dom, Suresh, Fan_HU, Fan_HU.a, correct, [IPcaller], ilkka (muted) 14:03:58 zakim, aaee is me 14:04:03 sorry, richt, I do not recognize a party named 'aaee' 14:04:07 On IRC I see richt, bryan, Fan_HU, enewland, Suresh, darobin, AnssiK, Zakim, RRSAgent, fjh, lgombos, Marcos, tlr, wmaslowski, ingmar, ilkka, dom, trackbot 14:04:08 maoteo has joined #dap 14:04:24 Dong-Young has joined #dap 14:04:32 Present+ Dong-Young_Lee 14:04:48 Dzung_Tran has joined #dap 14:04:54 Present+ Maria-Oteo 14:04:54 zakim, who is here? 14:04:54 On the phone I see darobin, enewland, fjh, AnssiK, dom, Suresh, Fan_HU, Fan_HU.a, correct, [IPcaller], ilkka (muted) 14:04:56 On IRC I see Dzung_Tran, Dong-Young, maoteo, richt, bryan, Fan_HU, enewland, Suresh, darobin, AnssiK, Zakim, RRSAgent, fjh, lgombos, Marcos, tlr, wmaslowski, ingmar, ilkka, dom, 14:04:56 Present+ Dzung_Tran 14:04:58 ... trackbot 14:05:08 Present+ Ilkka_Oksanen 14:05:36 zakim, Fan_HU.a is tmp 14:05:36 +tmp; got it 14:05:43 zakim, Fan_HU is Bryan 14:05:43 +Bryan; got it 14:05:50 Zakim, tmp is Fan_HU 14:05:50 +Fan_HU; got it 14:06:03 + +1.650.335.aahh 14:06:10 Present+ Richard_Tibbett 14:06:17 Zakim, aahh is James_Salsman 14:06:17 +James_Salsman; got it 14:06:28 zakim, aahh james 14:06:28 I don't understand 'aahh james', fjh 14:06:29 Zakim, aagg is maybe richt 14:06:29 I don't understand 'aagg is maybe richt', dom 14:06:38 zakim, aahh is jsalsman 14:06:38 sorry, fjh, I do not recognize a party named 'aahh' 14:06:44 Zakim, correct is probably richt 14:06:44 +richt?; got it 14:06:59 no yet 14:07:56 ScribeNick: Bryan 14:07:58 scribenick: bryan 14:08:06 topic: announcements 14:08:48 + +1.617.588.aaii - is perhaps Luis 14:08:49 fjh: will plan to have a bridge at tpac 14:08:53 ACTION: Dom to request bridge reservation for TPAC 14:08:53 Created ACTION-269 - Request bridge reservation for TPAC [on Dominique Hazaël-Massieux - due 2010-09-22]. 14:08:59 WG questionnaire (for all), http://www.w3.org/2002/09/wbs/43696/tpac2010dap/ 14:09:12 TPAC registration (for in-person attendees) http://www.w3.org/2002/09/wbs/35125/TPAC2010reg/ 14:09:20 DOM 3 Last Call 14:09:20 http://lists.w3.org/Archives/Public/public-device-apis/2010Sep/0060.html 14:09:34 (note that 22 people say they will attend to TPAC, but only 16 have effectively registered http://www.w3.org/2002/09/wbs/35125/TPAC2010reg/registrants#DeviceAP ) 14:09:44 fjh: minutes approval 14:09:56 topic: minutes approval 14:09:59 Approve 1 September minutes 14:10:00 http://lists.w3.org/Archives/Public/public-device-apis/2010Sep/att-0007/minutes-2010-09-01.html 14:10:05 fjh: 1st sept call 14:10:08 proposed RESOLUTION: Minutes from 1 Sept 2010 approved 14:10:18 RESOLUTION: Minutes from 1 Sept 2010 approved 14:10:27 topic: access control 14:10:31 Published Tuesday 7 Sept, see http://www.w3.org/News/2010#entry-8886 14:10:41 http://lists.w3.org/Archives/Public/public-device-apis/2010Sep/0043.html 14:10:58 lgombos has joined #dap 14:11:01 -> http://www.w3.org/TR/2010/NOTE-dap-policy-reqs-20100629/ Device APIs ACcess Control Use cases and Requirements (TR in Sep 7) 14:11:18 fjh: published 7 sept with use case stories, by dom 14:11:51 -> http://dev.w3.org/2009/dap/policy-reqs/ Access Control Use Cases editors draft 14:12:11 s/with use case/, updated in editors draft with use case/ 14:12:35 fjh: open to publishing as soon as new changes are agreed, e.g. with features 14:12:36 (I think publishing it along with the features draft sounds like a good idea) 14:12:45 topic: features 14:12:53 http://lists.w3.org/Archives/Public/public-device-apis/2010Sep/0016.html 14:13:10 zakim, call thomas-781 14:13:10 ok, tlr; the call is being made 14:13:12 +Thomas 14:13:13 fjh: updated the draft, dom suggested to remove features 14:13:18 zakim, I am thomas 14:13:18 ok, tlr, I now associate you with Thomas 14:13:20 zakim, mute me 14:13:20 Thomas should now be muted 14:13:52 q+ 14:13:52 fjh: didn't go into features as trouble finding use cases for it in BONDI 14:14:41 bryan: notes that features were intended to be used for API versioning 14:15:19 bryan: capabilities probably enough if at same level of granularity 14:15:31 q? 14:15:45 q+ jsalsman 14:16:03 ack suresh 14:16:15 (we already resolved not to worry about APIs versioning) 14:16:29 bryan: ok with not using features in DAP 14:16:35 suresh: thats OK in BONDI context given the explanation by bryan 14:16:44 no API versioning was the very first decision this working group made :) 14:17:01 (I propose the stop talking about "features" or "capabilities", but only talking about "permissions" 14:17:02 suresh: in the context of widgets we need though some representation of the APIs as feature tags 14:17:24 fjh: isn't that the same as the API 14:17:33 [+1 to dom, though the DOM has "feature strings"] 14:18:03 suresh: may not need the same level as BONDI provided, but in what the feature config requires we need to define features 14:18:09 q 14:18:18 -ilkka 14:18:35 fjh: we don't need features ala bondi to do permissons but do in config 14:19:00 At the minimum we need to specify the "features" that are required for using our APIs in the context of widgets 14:19:05 what Widgets have is "feature": http://www.w3.org/TR/widgets/#feature0 14:19:14 +ilkka 14:19:15 dom: my proposal goes a bit further - rather than capabilities and features, focus instead on permissions 14:19:15 zakim, mute me 14:19:16 ilkka should now be muted 14:19:25 Balaji has joined #dap 14:20:24 yes so we need to standardize the set of "feature names" which is an IRI 14:20:25 james: re granularity, the issue is connotation , i.e. what you want your devices to be able to do. re features and capabilities its more about how to write the document - if we use only features, where are the capabilities supposed to go 14:20:38 Present+Balaji_NerellaVenkataramana 14:20:54 fjh: permissions would be more obvious - the feature/capabilties model in bondi adds complexity we dont need 14:21:09 james: where would capabilities go if taken out 14:22:45 fjh: essentially the same thing, we can discuss granularity, but attempts to access are permitted or not. we need the concept of permissions fundamentally, and also a way to define those things that are permitted or not 14:23:55 dom: want to focus only on permissions, not a distinction between features and capabilities 14:24:19 fjh: maybe misunderstood that the intent was to remove capabilities 14:24:31 shepazu has joined #dap 14:24:50 fjh: meant that we need trust domains, permissions, and naming to bind to feature elements in widget spec 14:24:53 q+ 14:25:03 ack jsalsman 14:25:03 ack jsal 14:25:06 james: supports the proposal 14:25:06 ack bryan 14:25:33 + +91.80.67.82.aajj 14:26:12 Widgets spec requires that the feature names is a IRI 14:26:23 fjh: re using feature strings vs abstracted device capabilities, robin had a proposal to define capabilities and prefix as needed with a base API reference 14:27:41 Zakim, aajj is Maria 14:27:42 +Maria; got it 14:28:05 zakim, who's noisy? 14:28:16 dom, listening for 10 seconds I heard sound from the following: fjh (71%), Bryan (5%), Maria (52%) 14:28:16 bryan: would like to have the more generic string to enable a single policy for different APIs using the same device capabilities 14:28:17 zakim, mute maria 14:28:18 Maria should now be muted 14:28:33 fjh: versioning would still need to be considered 14:28:39 I was not 14:29:01 zakim, unmute maoteo 14:29:01 sorry, dom, I do not know which phone connection belongs to maoteo 14:29:11 zakim, unmute Maria 14:29:11 Maria should no longer be muted 14:29:20 fjh: summary, we dont need features and will call the things permissions, id the method that applies to a permission with a string 14:29:31 fjh: propose dom do work on that 14:29:49 RESOLUTION: we will not include the concept of features in the DAP V1 work 14:30:36 fjh: clarifying, features here means specifically as used in the bondi sense 14:30:39 -richt? 14:31:14 richt_ has joined #dap 14:31:15 Marcos_ has joined #dap 14:31:19 suresh: we are collapsing features and capabilities into one thing and calling them permissions 14:31:28 + +1.760.705.aakk - is perhaps Alan 14:31:38 zakim, aakk is me 14:31:38 sorry, richt_, I do not recognize a party named 'aakk' 14:31:48 s/suresh/fjh/ 14:32:54 zakim, who's noisy? 14:33:05 dom, listening for 10 seconds I heard sound from the following: darobin (9%), fjh (62%), Bryan (9%) 14:33:07 bryan: bondi included the distinction to enable control of permission for device capabilities shared by different APIs 14:33:49 [I think the high level resolution is that we're using a single layer of permissions, more than on the specific word] 14:34:28 james: recommend using the term connotation rather than permission 14:34:42 s/term connotation/term with a positive/ 14:34:45 fjh: thinks permissions has a positive connotation 14:34:51 s/positive/positive connotation/ 14:35:14 access pemissions 14:35:26 zakim, who's noisy? 14:35:36 dom, listening for 10 seconds I heard sound from the following: darobin (5%), fjh (100%), Bryan (5%), Maria (29%) 14:35:40 Zakim, mute maria 14:35:40 Maria should now be muted 14:35:41 fjh: permissions is used elsewhere and we should use the same term 14:35:41 zakim, mute maria 14:35:41 Maria was already muted, tlr 14:35:58 fjh: permissions is a straightforward concept 14:36:38 dom: at this time, what we are agreeing is to use a single layer of permissions - the name for that we can decide later on - as a start I will refer to permissions but we can settle that later 14:36:55 jamesL withdraw the objection 14:37:05 james: withdraws the objection 14:37:05 s/jamesL/james/ 14:37:37 PROPOSED RESOLUTION: we will use a single layer model for access permissions 14:37:52 RESOLUTION: we will use a single layer model for access permissions 14:38:44 james: can we defer or resolve to replace the work permissions with a more positive connotation 14:38:57 ACTION-263 due next week 14:38:57 ACTION-263 Take a stab at DAP features doc due date now next week 14:39:04 fjh: let see what dom comes up with and we will discuss it on the list 14:39:25 this conversation is becoming a bit circular right? perhaps dom can propose something and we can rediscuss on the call next week if necessary. 14:39:38 james: preferred to defer the resolution 14:39:47 take it to the mailing list? 14:40:08 dom: the resolution is only about the modeling and not the name/terms of the concepts in it 14:41:44 topic: WARP in browser context 14:41:58 http://lists.w3.org/Archives/Public/public-device-apis/2010Sep/0034.html 14:42:08 not much to do with this 14:42:11 right now 14:42:12 robin: dont recommend discussing this now 14:42:19 keep it on the list 14:42:22 fjh: the proponents are not on the call 14:42:29 topic: privacy 14:42:36 action-210? 14:42:36 ACTION-210 -- Alissa Cooper to summarize and add issues to ruleset doc -- due 2010-07-21 -- OPEN 14:42:36 http://www.w3.org/2009/dap/track/actions/210 14:42:53 topic: APIs 14:43:12 topic: Contacts 14:43:28 http://lists.w3.org/Archives/Public/public-contacts-coord/ 14:43:42 darobin: mailing list created for contacts coordination 14:44:06 darobin: progressing toward common understanding 14:44:19 darobin: a new draft was announced 14:44:28 q+ 14:44:46 http://www.w3.org/mid/9B2983F7-D3C0-4EE3-B9AF-BDCE6B53271B@robineko.com 14:44:46 richt: the draft looks into formats, proposed extensions, look at the cvs diff log for the changes 14:45:10 darobin: made a post about pending op 14:45:59 darobin: any sync in wrt needs to define the way it works in terms of HTML event loops and task queues 14:46:16 darobin: basically a mental model to explain the way things happen 14:47:24 darobin: e.g. if a request is cancelled before completion the two actions related to this need to put on a task queue so they are handled in the right order 14:47:36 richt: so the need is to understand the process model etc 14:48:05 richt: the HTML device spec has pending op specified, is that the best place to put this 14:48:39 darobin: different APIs will have different needs re what to do when cancel is called - so we need specific text for each spec 14:49:01 richt: will see what can be done for contacts re this 14:49:14 darobin: we can use the text for the other APIs as template 14:49:36 q? 14:49:37 darobin: anne form opera will be able to help 14:49:40 ack Suresh 14:49:42 [I've added the need to look at asyncronous calls in terms of the HTML5 event loop in http://www.w3.org/2009/dap/wiki/ApiCheckList] 14:50:08 suresh: was on the contacts coordination call - thought we should discuss this and decide what is next 14:50:16 q+ 14:50:44 zakim, unmute me 14:50:44 Thomas should no longer be muted 14:50:47 ack tlr 14:50:51 ack Thom 14:50:52 suresh: we got info on what is being done but there was no decision on how to converge - do we want to discuss this now or give more time for this 14:51:25 tlr: there is an ongoing discussion between ietf and poco -that needs time 14:51:53 tlr: the mapping between vcard3 and cab needs to be considered as this might impact vcard4 14:52:09 tlr: the OMA has the action item to review the info available 14:52:31 suresh: expecting Christina to respond - she has the action 14:52:47 tlr: that response should clarify the story 14:53:32 suresh: looking back at the API, don't know what happened to the note re contacts schema for further study 14:54:13 zakim, aajj is yourHandle 14:54:13 sorry, Balaji, I do not recognize a party named 'aajj' 14:54:26 richt: made some changes to reflect the call discussion, so removed the note re poco schema. we are not now saying that we are compatible with poco etc 14:54:31 also my fault; I probably referred to our API as PoCo-based on multiple occasions 14:54:33 zakim, aajj is balaji 14:54:33 sorry, fjh, I do not recognize a party named 'aajj' 14:54:43 zakim, who is here? 14:54:43 On the phone I see darobin, enewland, fjh, AnssiK, dom, Suresh, Bryan, Fan_HU, [IPcaller], James_Salsman, Luis, Thomas, ilkka (muted), Maria (muted), Alan 14:54:45 richt: but focusing on extensions, how to include them 14:54:47 On IRC I see Marcos, richt_, shepazu, Balaji, lgombos, Dzung_Tran, Dong-Young, maoteo, bryan, Fan_HU, enewland, Suresh, darobin, AnssiK, Zakim, RRSAgent, fjh, tlr, wmaslowski, 14:54:49 ... ingmar, ilkka, dom, trackbot 14:55:05 richt: still up in the air, not a specific mapping to vcard or poco 14:55:31 suresh: the formats refer to poco schema still - seems to be dependent 14:55:51 richt: those attributes are vcard attributes (all are) 14:56:22 suresh: need to reflect the open issue re formats 14:56:31 richt: will put a statement back in 14:57:12 -> http://lists.w3.org/Archives/Public/public-device-apis/2010Sep/0072.html Dom's comments on updated contacts draft 14:57:37 suresh: some comments were provided on the list re attributes related to social networking - we should avoid dependency on these e.g. relationships 14:57:50 richt: these are vcard4 attributes 14:58:12 [relationship can be used outside of a social network, I would think] 14:58:16 suresh: to be useful, we need a service tied to the contacts format 14:58:39 (this is all about ISSUE-98) 14:58:43 ISSUE-98? 14:58:43 ISSUE-98 -- On what data model should the contacts API be based? -- open 14:58:43 http://www.w3.org/2009/dap/track/issues/98 14:59:07 richt: don't agree we have social attributes specifically - this is still ongoing and we need to continue the coordination work on the coord list 14:59:15 -enewland 14:59:29 richt: we need to be active in that discussion to influence it 15:00:10 richt: do detail the specific issues on the list 15:00:34 rrsagent, generate minutes 15:00:34 I have made the request to generate http://www.w3.org/2010/09/15-dap-minutes.html fjh 15:00:42 suresh: a lot depends upon convergence in the coord group - we need a plan b in case that does not happen 15:02:00 richt: the timelines for poco and vcard are their own - we could go for example with a vcard subset and let the market decide what is useful 15:03:03 richt: looking at including an html integration part to the spec - may delay until we address current feedback 15:03:18 richt: this will include integrating with the device element of html 15:03:45 darobin: concerned about the dependency in the spec - maybe better outside 15:03:50 (separate spec sounds better to me) 15:04:05 richt: how about a non-normative section 15:04:09 q+ salsman 15:04:17 ack salsman 15:05:18 topic: Capture 15:05:45 darobin: action on John for privacy, not here so that will wait 15:06:04 -Suresh 15:06:16 james: on device element with audio, there are no open echo cancellation algorithms 15:06:37 darobin: its unclear whether the device element is in scope for this group 15:06:49 -Luis 15:07:17 darobin: the element is a couple of months away from being published - but a good point for the a/v part of the device element 15:07:19 http://lists.w3.org/Archives/Public/public-device-apis/2010Sep/0010.html 15:07:29 HTML Device is already being implemented: https://labs.ericsson.com/blog/beyond-html5-conversational-voice-and-video-implemented-webkit-gtk ;) 15:07:38 zakim, unmute me 15:07:38 ilkka should no longer be muted 15:07:44 darobin: we have an open cfc for capture - believe most comments have been resolved 15:07:58 ilkka: not all, but most of them 15:08:13 in the lab 15:08:19 zakim, mute me 15:08:21 ilkka should now be muted 15:08:57 [group goes textual due to ilkka's noise] 15:09:11 ilkka, are the missing ones important? 15:09:33 [I'm hoping the remaining issues be documented in the draft itself] 15:09:51 darobin: we are trying to check if all the changes have been included - need to know if we can move ahead and publish - if the remaining issues are minor, propose to move forward with a pwd 15:09:56 ilkka, can you put notes for the issues that weren't fixed? 15:10:22 darobin: need to put notes for the issues that weren't fixed? 15:10:34 illka: ok 15:10:58 darobin: anyone objecting to publishing with notes? 15:11:20 james: there were some concerns about objections re audio 15:11:33 I believe that the audio format was discussed on the WHATWG without resolution (what to choose is the problem). 15:11:50 james: does anyone object to a proposed audio format? 15:12:15 dom: we discussed this and had resolved to not recommend a default at this time 15:12:22 start of discussion on WHATWG: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-September/028337.html 15:12:44 PROPOSED RESOLUTION: publish Media Capture API as new draft with issues highlighted in the document 15:13:17 james: have w3c considered what should be default formats? 15:13:28 darobin: yes, unsure where though 15:13:38 (+1 on audio codec discussion belonging to HTML WG) 15:13:43 tlr: the location for that should be in HTML5 in the html wg 15:13:58 james: did that two weeks ago and there was no objection 15:14:18 james: at least one member said it would be difficult to obtain concensus 15:14:50 dom: suggest to move this to html wg where there is a defined process for consensus 15:15:22 darobin: we don't want different spec in w3c to recommend different options 15:15:25 RESOLUTION: publish Media Capture API as new draft with issues highlighted in the document 15:15:25 RESOLUTION: publish Media Capture API as new draft with issues highlighted in the document 15:15:55 ACTION: Ilkka to add notes to the MCAPI draft and ping Robin when ready 15:15:55 Created ACTION-270 - Add notes to the MCAPI draft and ping Robin when ready [on Ilkka Oksanen - due 2010-09-22]. 15:16:08 topic: calendar 15:16:18 http://lists.w3.org/Archives/Public/public-calendar-coord/ 15:16:21 -Thomas 15:16:41 darobin: new coordination call and mailing list - suggest to join if you have interest 15:16:57 q+ to ask about schedule/roadmap for calendar API FPWD 15:17:19 s/*Fan: havent dialled yet// 15:17:29 s/zakim bryan_sullivan aaee handle// 15:17:31 darobin: on the call, we discussed status and call connects group described their work including caldav restful version and xcal, json version etc - we agreed to keep in touch on the issues 15:17:34 ack dom 15:17:34