# Device APIs and Policy Working Group Teleconference ## 09 Dec 2009 [Agenda][3] See also: [IRC log][4] ## Attendees Present Dzung_Tran, Marco_Marengo, Frederick_Hirsch, Anssi_Kostiainen, Niklas_Widell, Ilkka, Oksanen, Marcin_Hanclik, Robin_Berjon, Laura_Arribas, Dominique_Hazael_Massieux, Thomas_Roessler, Max_Froumentin, Claes_Nilsson, Wonsuk_Lee, John_Morris, David, Rogers Regrets Suresh_Chitturi, Arve Chair Robin_Berjon, Frederick_Hirsch Scribe ilkka ## Contents * [Topics][5] 1. [Welcome, agenda review, scribe selection][6] 2. [Policy Segment][7] 3. [API Segment][8] * [Summary of Action Items][9] * * * Date: 09 December 2009 Scribenick: ilkka ### Welcome, agenda review, scribe selection [http://lists.w3.org/Archives/Public/public-device- apis/2009Dec/0155.html][3] fjh: any additions to agenda? ... lets cancel calls during holiday period minutes [http://lists.w3.org/Archives/Public/public-device- apis/2009Dec/0154.html][10] **RESOLUTION: Calls are cancelled on 23rd and 30th of December** [December 2 proposed minutes][11] trust **RESOLUTION: minutes from 2nd of December are approved** [http://lists.w3.org/Archives/Public/public-device- apis/2009Dec/0153.html][12] ### Policy Segment fjh: differences between Nokia and BONDI policy frameworks are described in the above mail ACTION-38? ACTION-38 -- Claes Nilsson to should issue recommendation on the granularity of the security system -- due 2009-11-09 -- OPEN [http://www.w3.org/2009/dap/track/actions/38][13] Claes: I have action from Santa Clara meeting to provide input, will happen in one week fjh: Laura, do you anything to add to requirements Adding trust and use cases to requirements TAG and Policy [TAG issue on privacy and policy][14] Laura_Arribas: will follow up soon fjh: this is useful information, but not sure yet how to respond **ACTION:** frederick to draft a response TAG issue on privacy and policy [recorded in [http://www.w3.org/2009/12/09-dap- minutes.html#action01][15]] Created ACTION-73 - Draft a response TAG issue on privacy and policy [on Frederick Hirsch - due 2009-12-16]. ### API Segment darobin: I would like to ask editors of each draft to mail list of current issues richt: small tweaks this week ... in contacts API ... It will still take some time to be able to upload first version Calendar API [http://www.w3.org/mid/CC26A8D2-49CF-4137-8ABC- 08D18FD921A0@berjon.com][16] darobin: File system & file writer API: updated version will be available in couple days. Feedback welcome. [Next steps on Capture API?, from Dzung Tran][17] Dzung_Tran: Capture API: discussion ongoing regarding how to build the UI **ACTION:** Robin to send an email to list summarising the options for or not in Capture [recorded in [http://www.w3.org/2009/12/09-dap- minutes.html#action02][18]] Created ACTION-74 - Send an email to list summarising the options for or not in Capture [on Robin Berjon - due 2009-12-16]. [Progress report on Messaging from Niklas][19] ACTION-65? ACTION-65 -- Niklas Widell to provide an editors draft of the Messaging API -- due 2009-12-02 -- OPEN [http://www.w3.org/2009/dap/track/actions/65][20] darobin: discussion ongoing whether to have programmatical API or based solution, or both nwidell: first version of messaging API will be based on BONDI messaging API s/BONDI messaging API/ [][21] s/3986/3986/ RFC 3986 uri scheme here's the I-D I had in mind [SMS URI scheme (proposed)][22] maxf, you wanted to ask about the granularity of CVS commits RFC 3986 is the wrong reference for this darobin: it better to have first version soon even if it's not well thought maxf: when to do CVS commits? darobin: always when the change makes sense +1 to release early, release often (of course, with git we won't have that problem anymore ;) +1 to commit early, commit very often darobin: announce your changes because not all are subscribed to DAP-commits mailing list shorter commit logs are easier to read and comment on marcin: updated MMS related drafts exists tlr: what are the requirements that can't be fulfilled using this URI scheme? [maybe we can raise an issue about this point?] PROPOSED ISSUE: Make sure that uses cases for messaging don't overlap with linking PROPOSED ISSUE: what use cases justify using an API on top of the existing URI schemes PROPOSED ISSUE: What messaging use cases cannot be fulfilled by existing URI schemes (mailto, sms, mms)? ISSUE: What messaging use cases cannot be fulfilled by existing URI schemes (mailto, sms, mms)? Created ISSUE-54 - What messaging use cases cannot be fulfilled by existing URI schemes (mailto, sms, mms)? ; please complete additional details at [http://www.w3.org/2009/dap/track/issues/54/edit][23] . marcin: I'll comment the draft when it's available [Systems Info & Events API editors draft][24] [Proposed core interface for systems info, with get, set, and watch][25] maxf: get(), set() and watch() are the core funtions of the API [Discussion on units, value ranges for SysInfo][26] maxf: spec is written in an abstracted way ... e.g. temperature can be a value between 0 and 1 dom, you wanted to ask about roadmap dom: we have now file writer api, how about full file system API? [I think personally file writing is a more interesting priority than the other operations] dom: should file system API be a priority API? Dave: file system API is a priority API richt: full file system API for v1 is too big task for the record, "My Documents" is *not* a useful sandbox. it translates into "most of my interesting data" just an example - x sandbox underlying platform can always constrain to specific sandboxes for specific purposes / applications / websites what's the conclusion of this discussion? ok, so the DAP homepage is already reflecting that, thanks PROPOSED RESOLUTION: all of File API is a priority, but Writing > Directory to clarify my point was that beyond file writer api, the next acheivable spec would be a limited sandboxed file system api rather than focussing on the a full file-system api for v1. PROPOSED RESOLUTION: all of File API is a priority, inside the API, file writer is a priority compared to other parts of the API full file-system api = directories. A sandboxed model would not provide any directory traversal o multi-level trees (sandboxes are flat structures) From the sideline, Opera has a sandboxed model for file system access with the sandbox defined along "mountpoints" not a flat structure, but honest-to-[deity] tree structures, path traversal rules, and transparent traversal in to archives BONDI is still deciding about sandbox vs. full FS I would like the WG to adopt this model, because it actually works davidRogers: there is no concensus about the priority interesting stuff arve. does Opera have anything to provide to DAP? davidRogers: we are not yet ready to make a resolution richt, dom, ilkka - see this [http://dev.opera.com/articles/view/file-i-o-api-for-widgets/][27] we could then argue the finer points of actually accessing files but this is what we have implementation experience with q darobin: no resolution on this call reminder - wg members should review the drafts, and make comments on the list davidRogers: file writer API is in conflict with BONDI proposal Issues should also be raised in tracker and discussed on the list I think there are 3 topics: 1) File reader might need additional work from DAP; 2) that additional work needs to be a priority over File writing; 3) File writing is a priority over directory mangement I think we can agree on 3); I hadn't heard about 1) and 2) before **ACTION:** David to send OMTP position on the file API organization [recorded in [http://www.w3.org/2009/12/09-dap-minutes.html#action03][28]] Created ACTION-75 - Send OMTP position on the file API organization [on David Rogers - due 2009-12-16]. (I think Richard should bring his ideas to the list — we're unlikely to be able to digest a detailed proposal on the phone :) +1 to dom richt: in priority-wise: file writing > sand boxing > directory management Ilkka, that is my proposal. Thanks. That is a better way of looking at how to proceed. meeting adjourned thanks ilkka ## Summary of Action Items **[NEW]** **ACTION:** David to send OMTP position on the file API organization [recorded in [http://www.w3.org/2009/12/09-dap-minutes.html#action03][28]] **[NEW]** **ACTION:** frederick to draft a response TAG issue on privacy and policy [recorded in [http://www.w3.org/2009/12/09-dap- minutes.html#action01][15]] **[NEW]** **ACTION:** Robin to send an email to list summarising the options for or not in Capture [recorded in [http://www.w3.org/2009/12/09-dap- minutes.html#action02][18]] [End of minutes] * * * Minutes formatted by David Booth's [scribe.perl][29] version 1.135 ([CVS log][30]) $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/2009Dec/0155.html [4]: http://www.w3.org/2009/12/09-dap-irc [5]: #agenda [6]: #item01 [7]: #item02 [8]: #item03 [9]: #ActionSummary [10]: http://lists.w3.org/Archives/Public/public-device- apis/2009Dec/0154.html [11]: http://lists.w3.org/Archives/Public/public-device- apis/2009Dec/att-0154/02-dap-minutes.html [12]: http://lists.w3.org/Archives/Public/public-device- apis/2009Dec/0153.html [13]: http://www.w3.org/2009/dap/track/actions/38 [14]: http://lists.w3.org/Archives/Public/public-device- apis/2009Dec/0130.html [15]: http://www.w3.org/2009/12/09-dap-minutes.html#action01 [16]: http://www.w3.org/mid/CC26A8D2-49CF-4137-8ABC-08D18FD921A0@berjon.com [17]: http://lists.w3.org/Archives/Public/public-device- apis/2009Dec/0150.html [18]: http://www.w3.org/2009/12/09-dap-minutes.html#action02 [19]: http://lists.w3.org/Archives/Public/public-device- apis/2009Dec/0165.html [20]: http://www.w3.org/2009/dap/track/actions/65 [21]: http://tools.ietf.org/html/rfc3986 [22]: http://tools.ietf.org/html/draft-wilde-sms-uri-20 [23]: http://www.w3.org/2009/dap/track/issues/54/edit [24]: http://dev.w3.org/2009/dap/system-info/ [25]: http://dev.w3.org/2009/dap/system-info/#the-system-interface [26]: http://lists.w3.org/Archives/Public/public-device- apis/2009Dec/0146.html [27]: http://dev.opera.com/articles/view/file-i-o-api-for-widgets/ [28]: http://www.w3.org/2009/12/09-dap-minutes.html#action03 [29]: http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm [30]: http://dev.w3.org/cvsweb/2002/scribe/