# Device APIs and Policy Working Group Teleconference ## 15 Sep 2010 [Agenda][3] See also: [IRC log][4] ## Attendees Present Robin_Berjon, Frederick_Hirsch, Suresh_Chitturi, Anssi_Kostiainen, erica_newland, Fan_HU, Dominique_Hazael-Massieux, bryan_sullivan, Dong- Young_Lee, Maria-Oteo, Dzung_Tran, Ilkka_Oksanen, Richard_Tibbett, Balaji_NerellaVenkataramana Regrets John_Morris, Niklas_Widell, Laura__Arribas, Claes_Nilsson, Marco_Marengo Chair Robin_Berjon, Frederick_Hirsch Scribe Bryan ## Contents * [Topics][5] 1. [announcements][6] 2. [minutes approval][7] 3. [access control][8] 4. [features][9] 5. [WARP in browser context][10] 6. [privacy][11] 7. [APIs][12] 8. [Contacts][13] 9. [Capture][14] 10. [calendar][15] 11. [sysinfo][16] * [Summary of Action Items][17] * * * Date: 15 September 2010 ScribeNick: Bryan scribenick: bryan ### announcements fjh: will plan to have a bridge at tpac **ACTION:** Dom to request bridge reservation for TPAC [recorded in [http://www.w3.org/2010/09/15-dap-minutes.html#action01][18]] Created ACTION-269 - Request bridge reservation for TPAC [on Dominique Hazaël-Massieux - due 2010-09-22]. WG questionnaire (for all), [http://www.w3.org/2002/09/wbs/43696/tpac2010dap/][19] TPAC registration (for in-person attendees) [http://www.w3.org/2002/09/wbs/35125/TPAC2010reg/][20] DOM 3 Last Call [http://lists.w3.org/Archives/Public/public-device- apis/2010Sep/0060.html][21] (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][22] ) fjh: minutes approval ### minutes approval Approve 1 September minutes [http://lists.w3.org/Archives/Public/public-device- apis/2010Sep/att-0007/minutes-2010-09-01.html][23] fjh: 1st sept call proposed RESOLUTION: Minutes from 1 Sept 2010 approved **RESOLUTION: Minutes from 1 Sept 2010 approved** ### access control Published Tuesday 7 Sept, see [http://www.w3.org/News/2010#entry-8886][24] [http://lists.w3.org/Archives/Public/public-device- apis/2010Sep/0043.html][25] [Device APIs ACcess Control Use cases and Requirements (TR in Sep 7)][26] fjh: published 7 sept , updated in editors draft with use case stories, by dom [Access Control Use Cases editors draft][27] fjh: open to publishing as soon as new changes are agreed, e.g. with features (I think publishing it along with the features draft sounds like a good idea) ### features [http://lists.w3.org/Archives/Public/public-device- apis/2010Sep/0016.html][28] fjh: updated the draft, dom suggested to remove features ... didn't go into features as trouble finding use cases for it in BONDI bryan: notes that features were intended to be used for API versioning bryan: capabilities probably enough if at same level of granularity (we already resolved not to worry about APIs versioning) bryan: ok with not using features in DAP suresh: thats OK in BONDI context given the explanation by bryan no API versioning was the very first decision this working group made :) (I propose the stop talking about "features" or "capabilities", but only talking about "permissions" suresh: in the context of widgets we need though some representation of the APIs as feature tags fjh: isn't that the same as the API [+1 to dom, though the DOM has "feature strings"] suresh: may not need the same level as BONDI provided, but in what the feature config requires we need to define features q fjh: we don't need features ala bondi to do permissons but do in config At the minimum we need to specify the "features" that are required for using our APIs in the context of widgets what Widgets have is "feature": [http://www.w3.org/TR/widgets/#feature0][29] dom: my proposal goes a bit further - rather than capabilities and features, focus instead on permissions yes so we need to standardize the set of "feature names" which is an IRI 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 fjh: permissions would be more obvious - the feature/capabilties model in bondi adds complexity we dont need james: where would capabilities go if taken out 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 dom: want to focus only on permissions, not a distinction between features and capabilities fjh: maybe misunderstood that the intent was to remove capabilities ... meant that we need trust domains, permissions, and naming to bind to feature elements in widget spec james: supports the proposal Widgets spec requires that the feature names is a IRI 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 bryan: would like to have the more generic string to enable a single policy for different APIs using the same device capabilities fjh: versioning would still need to be considered I was not fjh: summary, we dont need features and will call the things permissions, id the method that applies to a permission with a string ... propose dom do work on that **RESOLUTION: we will not include the concept of features in the DAP V1 work** fjh: clarifying, features here means specifically as used in the bondi sense ... we are collapsing features and capabilities into one thing and calling them permissions bryan: bondi included the distinction to enable control of permission for device capabilities shared by different APIs [I think the high level resolution is that we're using a single layer of permissions, more than on the specific word] james: recommend using the term with a positive rather than permission fjh: thinks permissions has a positive connotation connotation access pemissions fjh: permissions is used elsewhere and we should use the same term ... permissions is a straightforward concept 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 james withdraw the objection james: withdraws the objection PROPOSED RESOLUTION: we will use a single layer model for access permissions **RESOLUTION: we will use a single layer model for access permissions** james: can we defer or resolve to replace the work permissions with a more positive connotation ACTION-263 due next week ACTION-263 Take a stab at DAP features doc due date now next week fjh: let see what dom comes up with and we will discuss it on the list this conversation is becoming a bit circular right? perhaps dom can propose something and we can rediscuss on the call next week if necessary. james: preferred to defer the resolution take it to the mailing list? dom: the resolution is only about the modeling and not the name/terms of the concepts in it ### WARP in browser context [http://lists.w3.org/Archives/Public/public-device- apis/2010Sep/0034.html][30] not much to do with this right now robin: dont recommend discussing this now keep it on the list fjh: the proponents are not on the call ### privacy action-210? ACTION-210 -- Alissa Cooper to summarize and add issues to ruleset doc -- due 2010-07-21 -- OPEN [http://www.w3.org/2009/dap/track/actions/210][31] ### APIs ### Contacts [http://lists.w3.org/Archives/Public/public-contacts-coord/][32] darobin: mailing list created for contacts coordination ... progressing toward common understanding ... a new draft was announced [http://www.w3.org/mid/9B2983F7-D3C0-4EE3-B9AF- BDCE6B53271B@robineko.com][33] richt: the draft looks into formats, proposed extensions, look at the cvs diff log for the changes darobin: made a post about pending op ... any sync in wrt needs to define the way it works in terms of HTML event loops and task queues ... basically a mental model to explain the way things happen ... 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 richt: so the need is to understand the process model etc ... the HTML device spec has pending op specified, is that the best place to put this darobin: different APIs will have different needs re what to do when cancel is called - so we need specific text for each spec richt: will see what can be done for contacts re this darobin: we can use the text for the other APIs as template ... anne form opera will be able to help [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][34]] suresh: was on the contacts coordination call - thought we should discuss this and decide what is next ... 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 tlr: there is an ongoing discussion between ietf and poco -that needs time ... the mapping between vcard3 and cab needs to be considered as this might impact vcard4 ... the OMA has the action item to review the info available suresh: expecting Christina to respond - she has the action tlr: that response should clarify the story suresh: looking back at the API, don't know what happened to the note re contacts schema for further study 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 also my fault; I probably referred to our API as PoCo-based on multiple occasions richt: but focusing on extensions, how to include them ... still up in the air, not a specific mapping to vcard or poco suresh: the formats refer to poco schema still - seems to be dependent richt: those attributes are vcard attributes (all are) suresh: need to reflect the open issue re formats richt: will put a statement back in [Dom's comments on updated contacts draft][35] suresh: some comments were provided on the list re attributes related to social networking - we should avoid dependency on these e.g. relationships richt: these are vcard4 attributes [relationship can be used outside of a social network, I would think] suresh: to be useful, we need a service tied to the contacts format (this is all about ISSUE-98) ISSUE-98? ISSUE-98 -- On what data model should the contacts API be based? -- open [http://www.w3.org/2009/dap/track/issues/98][36] 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 ... we need to be active in that discussion to influence it ... do detail the specific issues on the list suresh: a lot depends upon convergence in the coord group - we need a plan b in case that does not happen 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 ... looking at including an html integration part to the spec - may delay until we address current feedback ... this will include integrating with the device element of html darobin: concerned about the dependency in the spec - maybe better outside (separate spec sounds better to me) richt: how about a non-normative section ### Capture darobin: action on John for privacy, not here so that will wait james: on device element with audio, there are no open echo cancellation algorithms darobin: its unclear whether the device element is in scope for this group ... the element is a couple of months away from being published - but a good point for the a/v part of the device element [http://lists.w3.org/Archives/Public/public-device- apis/2010Sep/0010.html][37] HTML Device is already being implemented: [https://labs.ericsson.com/blog/beyond-html5-conversational-voice-and-video- implemented-webkit-gtk][38] ;) darobin: we have an open cfc for capture - believe most comments have been resolved ilkka: not all, but most of them in the lab [group goes textual due to ilkka's noise] ilkka, are the missing ones important? [I'm hoping the remaining issues be documented in the draft itself] 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 ilkka, can you put notes for the issues that weren't fixed? darobin: need to put notes for the issues that weren't fixed? illka: ok darobin: anyone objecting to publishing with notes? james: there were some concerns about objections re audio I believe that the audio format was discussed on the WHATWG without resolution (what to choose is the problem). james: does anyone object to a proposed audio format? dom: we discussed this and had resolved to not recommend a default at this time start of discussion on WHATWG: [http://lists.whatwg.org/htdig.cgi /whatwg-whatwg.org/2010-September/028337.html][39] PROPOSED RESOLUTION: publish Media Capture API as new draft with issues highlighted in the document james: have w3c considered what should be default formats? darobin: yes, unsure where though (+1 on audio codec discussion belonging to HTML WG) tlr: the location for that should be in HTML5 in the html wg james: did that two weeks ago and there was no objection ... at least one member said it would be difficult to obtain concensus dom: suggest to move this to html wg where there is a defined process for consensus darobin: we don't want different spec in w3c to recommend different options RESOLUTION: publish Media Capture API as new draft with issues highlighted in the document **RESOLUTION: publish Media Capture API as new draft with issues highlighted in the document** **ACTION:** Ilkka to add notes to the MCAPI draft and ping Robin when ready [recorded in [http://www.w3.org/2010/09/15-dap- minutes.html#action02][40]] Created ACTION-270 - Add notes to the MCAPI draft and ping Robin when ready [on Ilkka Oksanen - due 2010-09-22]. ### calendar [http://lists.w3.org/Archives/Public/public-calendar-coord/][41] darobin: new coordination call and mailing list - suggest to join if you have interest ... 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 dom, you wanted to ask about schedule/roadmap for calendar API FPWD dom: we had talked about publishing a pwd for calendar - wonder about the status (also, what about TimezonedDate publication?) richt: long overdue, stuck re a couple of issues. A good way forward e.g. xcalendar and mapping to js - will get the draft ready in the next two weeks to month darobin: good to get it out before tpac richt: can do [http://dev.w3.org/2009/dap/calendar/TimezonedDate.html][42] dom: re creating a new timezone date interface, drafting is in progress and can this be included in the near term? richt: a rough draft is in progress, not sure what approach to use darobin: a service requires a connection and service discovery james: it would be useful to discuss the underlying julian date and what info is available from it darobin: when we publish calendar we should try to include this james: include the ISO spec with a description of the number of bits it takes richt: the ISO format is the cause of the problem ### sysinfo darobin: not much movement since the last version - we need to review the draft to move to last call soon dom, you wanted to ask about pendingop Using an ISO date in a recurring rule there is no way to represent a timezone rule (or timezone id). Instead it uses timezone offset at a fixed point in time. That does not represent the time for any further recurring date of the event. dom: re need to integrate with HTML5 event loops - this is needed here also ...if the timezone offset changes to -4 then the ISO representation (of e.g. -5)will be coordinating the call at the wrong time. darobin: yes, all async interfaces need that so it needs to be included before last call ...hence the TimezonedDate object darobin: would rather solve it once for all specs **ACTION:** Robin to figure out the event loop stuff for sysinfo [recorded in [http://www.w3.org/2010/09/15-dap-minutes.html#action03][43]] Created ACTION-271 - Figure out the event loop stuff for sysinfo [on Robin Berjon - due 2010-09-22]. ISSUE: Sysinfo asynchronous calls needs to be expressed in terms of events loop Created ISSUE-102 - Sysinfo asynchronous calls needs to be expressed in terms of events loop ; please complete additional details at [http://www.w3.org/2009/dap/track/issues/102/edit][44] . james: should the capture API be closer to last call - due to issues with network attributes ... are there any attributes that are off limits - any restrictions on what the network attributes can include ... for example packet sniffing darobin: what is the relationship with sysinfo james: we need a wide variety of quality of service metrics darobin: we resolved that, and unless there is new info we have agreed on the current set of attributes james, do you have a pointer to a specific proposal for additions? james: still think there is a need to a wide array of quality of service metrics from the network interface [SysInfo is certainly not targeted for use by network engineers] ## Summary of Action Items **[NEW]** **ACTION:** Dom to request bridge reservation for TPAC [recorded in [http://www.w3.org/2010/09/15-dap-minutes.html#action01][18]] **[NEW]** **ACTION:** Ilkka to add notes to the MCAPI draft and ping Robin when ready [recorded in [http://www.w3.org/2010/09/15-dap- minutes.html#action02][40]] **[NEW]** **ACTION:** Robin to figure out the event loop stuff for sysinfo [recorded in [http://www.w3.org/2010/09/15-dap-minutes.html#action03][43]] [End of minutes] * * * Minutes formatted by David Booth's [scribe.perl][45] version 1.135 ([CVS log][46]) $Date: 2009-03-02 03:52:20 $ [1]: http://www.w3.org/Icons/w3c_home [2]: http://www.w3.org/ [3]: http://lists.w3.org/Archives/Public/public-device- apis/2010Sep/0066.html [4]: http://www.w3.org/2010/09/15-dap-irc [5]: #agenda [6]: #item01 [7]: #item02 [8]: #item03 [9]: #item04 [10]: #item05 [11]: #item06 [12]: #item07 [13]: #item08 [14]: #item09 [15]: #item10 [16]: #item11 [17]: #ActionSummary [18]: http://www.w3.org/2010/09/15-dap-minutes.html#action01 [19]: http://www.w3.org/2002/09/wbs/43696/tpac2010dap/ [20]: http://www.w3.org/2002/09/wbs/35125/TPAC2010reg/ [21]: http://lists.w3.org/Archives/Public/public-device- apis/2010Sep/0060.html [22]: http://www.w3.org/2002/09/wbs/35125/TPAC2010reg/registrants#DeviceAP [23]: http://lists.w3.org/Archives/Public/public-device- apis/2010Sep/att-0007/minutes-2010-09-01.html [24]: http://www.w3.org/News/2010#entry-8886 [25]: http://lists.w3.org/Archives/Public/public-device- apis/2010Sep/0043.html [26]: http://www.w3.org/TR/2010/NOTE-dap-policy-reqs-20100629/ [27]: http://dev.w3.org/2009/dap/policy-reqs/ [28]: http://lists.w3.org/Archives/Public/public-device- apis/2010Sep/0016.html [29]: http://www.w3.org/TR/widgets/#feature0 [30]: http://lists.w3.org/Archives/Public/public-device- apis/2010Sep/0034.html [31]: http://www.w3.org/2009/dap/track/actions/210 [32]: http://lists.w3.org/Archives/Public/public-contacts-coord/ [33]: http://www.w3.org/mid/9B2983F7-D3C0-4EE3-B9AF- BDCE6B53271B@robineko.com [34]: http://www.w3.org/2009/dap/wiki/ApiCheckList [35]: http://lists.w3.org/Archives/Public/public-device- apis/2010Sep/0072.html [36]: http://www.w3.org/2009/dap/track/issues/98 [37]: http://lists.w3.org/Archives/Public/public-device- apis/2010Sep/0010.html [38]: https://labs.ericsson.com/blog/beyond-html5-conversational-voice-and- video-implemented-webkit-gtk [39]: http://lists.whatwg.org/htdig.cgi/whatwg- whatwg.org/2010-September/028337.html [40]: http://www.w3.org/2010/09/15-dap-minutes.html#action02 [41]: http://lists.w3.org/Archives/Public/public-calendar-coord/ [42]: http://dev.w3.org/2009/dap/calendar/TimezonedDate.html [43]: http://www.w3.org/2010/09/15-dap-minutes.html#action03 [44]: http://www.w3.org/2009/dap/track/issues/102/edit [45]: http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm [46]: http://dev.w3.org/cvsweb/2002/scribe/