# Device APIs and Policy Working Group Teleconference ## 18 Nov 2009 [Agenda][3] See also: [IRC log][4] ## Attendees Present DomHazaelMassieux, Laszlo_Gombos, Robin_Berjon, Anssi_Kostiainen, Suresh, Chitturi, BryanSullivan, Max_Froumentin, Marcin_Hanclik, Dzung_Tran, Claes_Nilsson, Richard_Tibbett, Laura_Arribas, Ingmar_Kliche, Niklas_Widell Regrets Thomas_Roessler, Paddy_Byers Chair Robin_Berjon, Frederick_Hirsch Scribe Arve ## Contents * [Topics][5] 1. [Administrativa][6] 2. [f2f][7] 3. [minutes][8] 4. [policy segment][9] 5. [Comparison between Nokia and BONDI on trust model and access control][10] 6. [APIs][11] 7. [Next Meeting][12] * [Summary of Action Items][13] * * * Date: 18 November 2009 i'm not [IPCaller] +Present Ilkka_Oksanen +present BryanSullivan Scribe: Arve ScribeNick: arve Suresh just joined the bridge Yes ### Administrativa [http://lists.w3.org/Archives/Public/public-device- apis/2009Nov/0026.html][14] fhirsch: Geolocation WG is taking on API for orientation and acceleration data from device arve: does it mean that that item won't be covered by this WG? "Acceleration" is not the same as "accelerometer", correct? robin: yes I think Acceleration is the same as accelerometer robin: This WG will not take on these item Accelerometer should be outside their scope Did someone pass along the Compass spec that I did to the Geolocation WG? suresh: we need to find a way to handle overlap with other groups BryanSullivan: Accelerometer is not the same as acceleration Accelerometer is in general an example issue for sensor API's - GeoLocation is a special case. we should be careful about geolocation wg expanding their scope drogersuk: How do we logically separate accelerometer and acceleration data? We need find a way to integrate other "device APIs" work (e.g. geo- location, accelorometer) in to DAP WG deliverables or at the minimum reference them [as a point of order, I think people would better react on announcements when they're made on the list, rather than waiting for the call to make their points] ack darobin, you wanted to point out that this is a good reason to do anything related to policy outside of the API specs and to point out that we've already resolved that "general my point doesn't seem to have been minuted: drogersuk: We need to look at the clear logical separations between functionality - e.g. geolocation and accelerometer, they are probably independent functions RB: to Suresh's point, I would like to say that we should simply do policy orthogonally from APIs so that we can also cover other WGs' APIs RB: to Bryan's I would like to point out that we're not working on generic sensors, so there's no chartered requirements to prevent Geo from doing Accelerometer — if they have the bandwidth then by all means we should be happy to have less to do Geolocation WG's action item where draft on "orientation and acceleration" is proposed: [http://www.w3.org/2009/11/03-geolocation- minutes.html#action05][15] +1 to orthogonality I agree with what Robin just said in separating the policy from APIs [I think that "FUture APIs are not considered a priority" is a sufficient statement to make to clarify the situation] +1 to dom +1 to dom & darobin +1 to dom we don't want to discourage people from creating new things though it just won't be discussed as it is not in charter specifying policy for existing APIs will be a good exercise for the future APIs F2F Scheduling **ACTION:** dom will update home page to reflect "Future apis are not a priority" [recorded in [http://www.w3.org/2009/11/18-dap- minutes.html#action01][16]] Created ACTION-61 - Will update home page to reflect "Future apis are not a priority" [on Dominique Hazaël-Massieux - due 2009-11-25]. [http://lists.w3.org/Archives/Member/member-device- apis/2009Nov/0011.html][17] ### f2f [http://www.w3.org/2002/09/wbs/43696/prague-f2f-dates/results][18] PROPOSED RESOLUTION: next WG F2F in Prague on March 16 to 18 going once going twice drogersuk: 16-18 might collide with SXSW for some members I may go to SXSW but it is not yet confirmed drogersuk: need to avoid overlap with omtp meeting, there seems to be none darobin: only overlap with SXSW currently seems to be drogersuk drogersuk: there will be noe overlap with OMTP dom: april an alternative arve: would prefer march prefer march drogersuk: OMTP are always happy to host in London fhirsch: would propose resolution **ACTION:** Robin to contact Prague uni to ask if we can meet on 16-18/03 [recorded in [http://www.w3.org/2009/11/18-dap- minutes.html#action02][19]] +1 for March Created ACTION-62 - Contact Prague uni to ask if we can meet on 16-18/03 [on Robin Berjon - due 2009-11-25]. **RESOLUTION: Meeting date set to 16-18/03 2010** fhirsch: Is the meeting 2.5 days or 3? +1 to 2.5 +1 +1 for 2.5 +1 for 2.5 +1 +1 for 2.5 +1 for 2.5 lol make it 3.5 then I think 5.5 0 to 2.5 and/or 3 why not 2^2? proposed resolution: meeting will be 2.5 days? **RESOLUTION: meeting will be 2.5 days** RB: we could perhaps start at 11 the first day and finish at 1530 the last day ### minutes fhirsch: any objections to approving minutes from last meeting [http://www.w3.org/2009/dap/#roadmap][20] Policy Requirements Editors Draft updated fhirsch: please review document [http://lists.w3.org/Archives/Public/public-device- apis/2009Nov/0044.html][21] **ACTION:** Laura_Arribas to review [http://lists.w3.org/Archives/Public/public-device-apis/2009Nov/0044.html][21] [recorded in [http://www.w3.org/2009/11/18-dap-minutes.html#action03][22]] Sorry, couldn't find user - Laura_Arribas **ACTION:** Laura to review [http://lists.w3.org/Archives/Public/public- device-apis/2009Nov/0044.html][21] [recorded in [http://www.w3.org/2009/11/18 -dap-minutes.html#action04][23]] Created ACTION-63 - Review [http://lists.w3.org/Archives/Public /public-device-apis/2009Nov/0044.html][21] [on Laura Arribas - due 2009-11-25]. **ACTION:** Laura Arribas to review last reqs document [recorded in [http://www.w3.org/2009/11/18-dap-minutes.html#action05][24]] Created ACTION-64 - Arribas to review last reqs document [on Laura Arribas - due 2009-11-25]. [?] Contacts API updated to use vCard richard notes has updated contacts using vcard, working on security considerations and use cases richt++ ### policy segment Markup for implicit consent richard, can you post the link to the contacts API draft, please? [http://lists.w3.org/Archives/Public/public-device- apis/2009Nov/0115.html][25] Contacts API Latest Editor's Draft: [http://dev.w3.org/2009/dap/contacts/Overview.html][26] ok. I'll call back no regarding the contacts api: you may need to do a refresh or clear cache. I was having problems with the etags (or something) not refreshing the page. Bryan, [http://lists.w3.org/Archives/Public/public-device- apis/2009Oct/att-0120/minutes-2009-10-07.html#item06][27] re agreement to publish FPWD action-47? ACTION-47 -- Laura Arribas to provide input on trust model and access control model definitions -- due 2009-11-10 -- PENDINGREVIEW [http://www.w3.org/2009/dap/track/actions/47][28] maxf: I had the action item to explore reusing security from file upload control for implicit user consent maxf: the idea was to figure out if model applied to other apis +1 on figuring the process to specify possible markup aspects of our APIs as we go fhirsch: does this apply for widgets and/or webapps? maxf: will investigate arve: do we have the necessary expertise in the area? … just as much about usability frederick asks where we define input types, robin notes either in HTML WG or here as appropriate, can do later +1 to no "one shoe fits all" … I would propose relieveing max of his action item and revisit it later need to define input element for each API , part of API definition … e.g. file system access. There's a lot about making the API usable. … geolocation ... i don't believe this model of input="xx" fits all the use cases, agree with suresh but we need use cases in our documents though to justify that. max, can you please check status of HTML WG and how process would proceed for defining input types [I think the idea behind MaxF's action was to put some ideas on the table that we can take from when looking at specific APIs] Suresh: too early to agree on the topic we need to recognize that a UI-based approach will not address all use cases, e.g. to create accessible webapps or that work well in input/output constrained devices. Suresh: are we restricting ourselves to this, or is it just one of many options fhirsch: it's one option, not _the_ option [well, the important thing would be to look at specific use cases that wouldn't be addressed by this, so that we understand better the limits of the approach] [I think the people that are skeptic should do that :) ] approach is nice in a sense it provides both programmatic (via DOM API) and declarative (ie. markup) mechanisms +1 to darobin's written proposal action-47? ACTION-47 -- Laura Arribas to provide input on trust model and access control model definitions -- due 2009-11-10 -- PENDINGREVIEW [http://www.w3.org/2009/dap/track/actions/47][28] agree with robin, each person who owns their API needs to apply the input/output as you see fit [Laura's comparison of BONDI/Nokia trust model and access contrl][29] ScribeNick: dom ### Comparison between Nokia and BONDI on trust model and access control Laura: both approaches are significantly similar ... the major difference is that Nokia considers the trust manager and the access manager separately ... the access manager makes the final access decision ... BONDI has a different architecture — the trust decision is included in the access manager ... there are also differences in the policies ... Nokia consider 2 polices: trust, and access control ... BONDI doesn't make that differenciation and includes everything in the same policy have a hard limit, have to drop of, sorry Laura: I would welcome reviews on my summary ... I don't have specific ideas on how to integrate in the requirements document Frederick: I'm not quite sure why BONDI wouldn't consider access control and trust management as separate concerns unfortunately I need to leave the call for another meeting :( Frederick: I need to look more closely in the specs I will catch up with the minutes and follow up on the mailing list. So should we review and discuss on the mail list? Laura: it allows to group permissions in different domains i don't think trust and access control should be treated separately, a decision needs to be take with both into account Bryan: the distinction between trust and policy in Nokia is essentially a way to organize the data (the files) ... it's equivalent to what we have in BONDI ... they're functionally equivalent, it's just the way the data is organized Frederick: so Policy Management is out of scope of our work, but it has an impact on our scope of work on policy definitions ... I'll look more closely to the BONDI specs David: in BONDI, we've left open policy management ... In the discussions on the mailing list, I'm not sure what are the alternatives on defining a policy framework at some point (e.g. for filesystems API) Frederick: could you send an email on that topic? David: I've done that already Bryan: the management of policy (storage, updates, user decision involvement) is out of scope ... the definition of a policy file, an expression of a policy as a set of API permissions etc, should be in scope ... it's not directly influenced by policy management ... it's more dependent on APIs and their security aspects ... if we go deeper into UI considerations, we also need to take into account enabling a similar set of features in a policy-based approach Frederick: I keep coming back to the question of who's writing the policy ... if you don't have a model of this, I think it's hard to understand the use cases for the policy framework ### APIs Robin: we've discussed making Capture a priority item for the roadmap correction to minutes above: For people who are saying we don't need policy - I don't see the alternative once you've run out all the ways of designing the API securely apart from deferring the decision to the user - I'd like to see input to this because it will help the FileAPI and FileSystem API discussions progress PROPOSED RESOLUTION: Make capture (Video/Photo/Sound) a priority API **RESOLUTION: Make capture (Video/Photo/Sound) a priority API** Robin: within the priority documents, I would like to assign action items for people to come up with first editors drafts ... we already have one for contacts (Richard), but everyone is welcomed to help ... Richard has already started working on Calendar, but would be helpful if he got help ... what about messaging? Claes: I'm interested to take on that Robin: Daniel Coloma was also interested I can take on Capture **ACTION:** Claes to provide an editors draft of the Messaging API - due in two weeks [recorded in [http://www.w3.org/2009/11/18-dap- minutes.html#action06][30]] Created ACTION-65 - provide an editors draft of the Messaging API [on Niklas Nilsson - due 1970-01-01]. Frederick: suresh, did you mention you were interested in Calendar? Suresh: yes, but RObin said Richard was working on it ACtion-65 should be on nwidell Suresh: I'll work with him ACTION-65? ACTION-65 -- Niklas Nilsson to provide an editors draft of the Messaging API -- due 1970-01-01 -- OPEN [http://www.w3.org/2009/dap/track/actions/65][31] Robin: what about Capture? Dzung? Sure **ACTION:** Dzung to provide an editors draft of the Capture API [recorded in [http://www.w3.org/2009/11/18-dap-minutes.html#action07][32]] Created ACTION-66 - Provide an editors draft of the Capture API [on Dzung Tran - due 2009-11-25]. Ingmar: I'm happy to help on Capture as well Robin: if any of the editors don't have access to CVS, please contact Dom (but not DOM) ... what about FileSystems? ... I'll take a stab at it **ACTION:** Robin to provide a first editors draft of the FileSystems API [recorded in [http://www.w3.org/2009/11/18-dap-minutes.html#action08][33]] Created ACTION-67 - Provide a first editors draft of the FileSystems API [on Robin Berjon - due 2009-11-25]. Bryan: I'll provide feedback on it Robin: We've had sysInfo in CVS for a while ... please provide feedback as soon as possible ... so that we can decide to move to FPWD Bryan: I've provided input FWIW Sorry what is FWIW? ACTION-58? ACTION-58 -- Bryan Sullivan to make a concrete proposal with a vocabulary-based approach to system & events, with a few examples (e.g. battery level) -- due 2009-11-11 -- OPEN [http://www.w3.org/2009/dap/track/actions/58][34] Bryan: regarding the FWPD of requirements, it wasn't clear to me that we had reached consensus on the content of the document ... I'd like to see my set of requirements integrated in the document ... it looks like new requirements are impeded to get in the document FPWD simply means to publish draft which is subject to change Robin: as an editor, I was hoping you would provide help in adding your reqs there ... put it in the document — that will make it more likely for people to react :) David: maybe there should be a separate call for editors to help them set them up Robin: I'm not saying that people should always put their feedback in the doc; but when not getting feedback, it can be a useful tool ... regarding helping editors, it would be helpful to know what the questions are ... send me emails, and then I can figure out the best format to help people out Maxf: you've listed the 4 priority APIs documents, but also listed capture which is in the "other" category Robin: we've just resolved to make it a priority MaxF: but what happens with the other ones? ... I'm in the editors pool ... I could either help on the priority ones, or start working on another one Robin: it's perfectly fine to start on a new one; we might just spend less time discussing it MaxF: who wrote Sys and Events? Robin: Dzung Maxf: I'd like to help with that one just to understand, is this based on any of the input? Robin: please coordinate on the list Sure, no problem David: is SysInfo based on any of the input doc? Robin: I think it's something Dzung came up with Yes, it is based on Nokia, BONDI, .. David: Would Dzung be willing to look at the input to the charter and integrate it in SysInfo ok thanks Robin: Dzung says on IRC it's based on Nokia and BONDI ... it probably took them into account David: Ok, just wanted to clarify that point ### Next Meeting [@@@]: I'm seeing a lot of regrets for next week Robin: we might have to cancel I think we should cancel [xxx]: can't we make a decision now? +1 on canceling need to decide in advance so people can plan Most people in US are out on Thanksgiving holiday **RESOLUTION: no meeting next week, next meeting on Dec 2** [adjourned] -nwidell l8r - /me bye bye bye ## Summary of Action Items **[NEW]** **ACTION:** Claes to provide an editors draft of the Messaging API - due in two weeks [recorded in [http://www.w3.org/2009/11/18-dap- minutes.html#action06][30]] **[NEW]** **ACTION:** dom will update home page to reflect "Future apis are not a priority" [recorded in [http://www.w3.org/2009/11/18-dap- minutes.html#action01][16]] **[NEW]** **ACTION:** Dzung to provide an editors draft of the Capture API [recorded in [http://www.w3.org/2009/11/18-dap-minutes.html#action07][32]] **[NEW]** **ACTION:** Laura Arribas to review last reqs document [recorded in [http://www.w3.org/2009/11/18-dap-minutes.html#action05][24]] **[NEW]** **ACTION:** Laura to review [http://lists.w3.org/Archives/Public /public-device-apis/2009Nov/0044.html][21] [recorded in [http://www.w3.org/2009/11/18-dap-minutes.html#action04][23]] **[NEW]** **ACTION:** Laura_Arribas to review [http://lists.w3.org/Archives/Public/public-device-apis/2009Nov/0044.html][21] [recorded in [http://www.w3.org/2009/11/18-dap-minutes.html#action03][22]] **[NEW]** **ACTION:** Robin to contact Prague uni to ask if we can meet on 16-18/03 [recorded in [http://www.w3.org/2009/11/18-dap- minutes.html#action02][19]] **[NEW]** **ACTION:** Robin to provide a first editors draft of the FileSystems API [recorded in [http://www.w3.org/2009/11/18-dap- minutes.html#action08][33]] [End of minutes] * * * Minutes formatted by David Booth's [scribe.perl][35] version 1.135 ([CVS log][36]) $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/2009Nov/0116.html [4]: http://www.w3.org/2009/11/18-dap-irc [5]: #agenda [6]: #item01 [7]: #item02 [8]: #item03 [9]: #item04 [10]: #item05 [11]: #item06 [12]: #item07 [13]: #ActionSummary [14]: http://lists.w3.org/Archives/Public/public-device- apis/2009Nov/0026.html [15]: http://www.w3.org/2009/11/03-geolocation-minutes.html#action05 [16]: http://www.w3.org/2009/11/18-dap-minutes.html#action01 [17]: http://lists.w3.org/Archives/Member/member-device- apis/2009Nov/0011.html [18]: http://www.w3.org/2002/09/wbs/43696/prague-f2f-dates/results [19]: http://www.w3.org/2009/11/18-dap-minutes.html#action02 [20]: http://www.w3.org/2009/dap/#roadmap [21]: http://lists.w3.org/Archives/Public/public-device- apis/2009Nov/0044.html [22]: http://www.w3.org/2009/11/18-dap-minutes.html#action03 [23]: http://www.w3.org/2009/11/18-dap-minutes.html#action04 [24]: http://www.w3.org/2009/11/18-dap-minutes.html#action05 [25]: http://lists.w3.org/Archives/Public/public-device- apis/2009Nov/0115.html [26]: http://dev.w3.org/2009/dap/contacts/Overview.html [27]: http://lists.w3.org/Archives/Public/public-device- apis/2009Oct/att-0120/minutes-2009-10-07.html#item06 [28]: http://www.w3.org/2009/dap/track/actions/47 [29]: http://lists.w3.org/Archives/Public/public-device- apis/2009Nov/0128.html [30]: http://www.w3.org/2009/11/18-dap-minutes.html#action06 [31]: http://www.w3.org/2009/dap/track/actions/65 [32]: http://www.w3.org/2009/11/18-dap-minutes.html#action07 [33]: http://www.w3.org/2009/11/18-dap-minutes.html#action08 [34]: http://www.w3.org/2009/dap/track/actions/58 [35]: http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm [36]: http://dev.w3.org/cvsweb/2002/scribe/