# Device APIs and Policy Working Group Teleconference ## 06 Jan 2010 [Agenda][3] See also: [IRC log][4] ## Attendees Present Robin_Berjon, Frederick_Hirsch, ThomasRoessler, Dzung_Tran, Wonsuk_Lee, Paddy_Byers, Suresh_Chitturi, Laura_Arribas, Dominique_Hazael-Massieux, John_Morris, Marcin_Hanclik Regrets Anssi_Kostiainen, Marco_Marengo, DavidRogers Chair Robin_Berjon, Frederick_Hirsch Scribe John Morris ## Contents * [Topics][5] 1. [minutes approval][6] 2. [Policy][7] 3. [TAG response][8] 4. [api issues][9] * [Summary of Action Items][10] * * * Date: 06 January 2010 fjh, sorry but my internet connection is going up and down all the time I will do it next time if it's ok snowbound, unable to reach office and working from home :) **ACTION:** fjh fix Seoul time in agenda to be 24:00 [recorded in [http://www.w3.org/2010/01/06-dap-minutes.html#action01][11]] Created ACTION-78 - Fix Seoul time in agenda to be 24:00 [on Frederick Hirsch - due 2010-01-13]. similarly, agenda says 1400 UTC, I think it is 1500 UTC I am a member of the HTMLwg - but for some reason I am having trouble submitting the form to join this group - It looks like the form expired on new years - any ideas? tlr can you pls help cardona507? I am a student and "invited expert" - I don't represent a company per se I can scribe until my connection disappears paddy, perhaps you can scribe next week and we can choose someone else for today dom - should I send an email to the chairs? and if so where? ok, thanks yeah, we don't want a scribe that drops off or gets caught in an avalanche thank dom - have a good meeting everyone yes Scribe: John Morris ScribeNick: jmorris Paddy will scribe next week minutes from dec. 16 [http://lists.w3.org/Archives/Public/public-device- apis/2009Dec/att-0231/minutes-2009-12-16.html][12] ### minutes approval **RESOLUTION: minutes from 16-dec approved** ### Policy ReSpec, added refNote and additionalCopyrightHolders who? [http://lists.w3.org/Archives/Public/public-device- apis/2009Dec/0293.html][13] [http://lists.w3.org/Archives/Public/public-device- apis/2009Dec/0295.html][14] some discussion of document on list action-63? ACTION-63 -- Laura Arribas to review [http://lists.w3.org/Archives/Public/public-device-apis/2009Nov/0044.html][15] -- due 2009-11-25 -- CLOSED [http://www.w3.org/2009/dap/track/actions/63][16] TAG response ### TAG response [http://lists.w3.org/Archives/Public/public-device- apis/2009Dec/0297.htm][17] FH: any objection to sending to the TAG? [none] will send this today, given no comment [http://lists.w3.org/Archives/Public/public-device- apis/2009Dec/0297.html][18] **RESOLUTION: fhirsch to send tag response** ACTION-69? ACTION-69 -- Paddy Byers to provide use cases for the policy requirements document -- due 2009-12-11 -- OPEN [http://www.w3.org/2009/dap/track/actions/69][19] [Policy Use cases from Paddy][20] paddy: working on use cases how does this relate to policy requirements documents fhirsch: these should go into requirements documents +1 on integrating in requirements for now +1 +1 too fhirsch: tlr did work on security in apis [I think it would be useful if the use cases distinguished or highlighted which apply to widget vs open web apps] [+1 to dom] [me too!] paddy: need detail in use cases and derive requirements from them need to determine implied requirements in API apis should be capable of being used without presumption of trust paddy suggests possible requirement - apis should be capabable of being mediated by policy but not required to be mediated by policy dom asks whether use cases apply to non-trusted environment fhirsch: there will always be non-trusted cases paddy: there is not always a presumption of trust with web site [paddy captured well the questions I had in mind] with widget, one goes through an install process with some suggestion of trust paddy: there is a difference between two environments, but the apis should be capable of both environments I think we should strive for both environment dom: wg should be able to set ground rules for use of APIs in trusted environments fhirsch: dom put something on the list on this? Robin - i dont think i saw one as well **ACTION:** Paddy to integrate his use cases in policy requirements [recorded in [http://www.w3.org/2010/01/06-dap-minutes.html#action02][21]] Created ACTION-79 - Integrate his use cases in policy requirements [on Paddy Byers - due 2010-01-13]. fhirsch: paddy should work to integrate use cases in to requirements doc ACTION-77? ACTION-77 -- John Morris to provide a discussion of requirements for privacy -- due 2010-01-19 -- OPEN [http://www.w3.org/2009/dap/track/actions/77][22] ### api issues darobin: lots happening [very hard time hearing you robin] [I suggest sending the CfC now, with one week review] [+1] +1 to Dom darobin: should we wait to discuss CfC today or next week? s/Dom/Dom/ +1 we will discuss next week gah! brb darobin: not much work on other issues in past couple of weeks [waiting for maxf to return] maxf: ... discussions about what to put into each individual property about which we have info questions are unlined by general principles.... are there use cases for properties we are going to include decisions need to be made on case by case basis questions about how much privacy/security sensitivity with each property maxf: need to hear from people who care Thomas, you wanted to attempt framing the higher-level decision tlr: agree with max's framing at least for subset of comments, one approach to ask is this in scope for work we want to do broad question: do we want to provide info for run time execution environment e.g., cpu, etc. other comments: network area - do we believe that network is taken as a given or do we need more info on network connectivity sub issue - detailed info on network can equal location info.... zakjim, mute me schittur: tend agree that properties like cpu, etc., are attributes that vendors do not want to expose in practice, unlikely that apps will adjust based on these properties [I think the uses cases are for applications whose role is actually to deal with these low-level details] we should focus on more import things like displays, IO storage dom, right -- the question is whether we assume CPU and network are managed by the runtime, or whether we think we're managing them. prefer not to expose cpu, other details dom, you wanted to propose a framing dom: ... thanks maxf for work on this.... indeed, thanks maxf! +1 good way to frame this this for v1 of spec -- we only focus on general purpose application features thanks maxf! and we not focus on cpu and less general purpose properties darobin: this could be a separate spec versus a different version ... agree with dom's framing :) maxf: happy to focus on general purpose application features for completeness don't we want to cover CPU, however I am fine with moving it to later version maxf: temperature is hard does this principle mean, not include what is marked as "internal" don't know how to simply draft with several thermometers I'd drop thermo, battery, cpu, fan. +1 for moving general things to later version. darobin: might make sense to have more complex thermal but simpler cpu What is so hard about temperature? [I think something should be kept when attached with a "generic" use case] I'm fine with keeping external temperature, but would drop internal temperature sensors. fhirsch: not sure what "general purpose application features" mean Temperature is extremely important in mobile device maxf: I could write proposal on list Dzung, how about commenting on the phone? **ACTION:** maxf to write to list of properties to drop or simplify [recorded in [http://www.w3.org/2010/01/06-dap-minutes.html#action03][23]] Created ACTION-80 - Write to list on properties to drop or simplify [on Max Froumentin - due 2010-01-13]. I can't join today, actually I need to drop right now, sorry Input/Output, Codec support, Network coverage are fairly common and useful properties to have tlr: device management applications are not a generic use case not sure resolution is needed, but ok with me - still will have to make decisions of what it means Internal, and sensor related properties are very low-level and not general purpose properties "apps not directly targeted at monitoring the said sensors" PROPOSED RESOLUTION: use a "generic use case"/"apps not directly targeted at monitoring the said sensors" measurement to decide whether something is to be included in SysInfo or not good enough MF: sounds good [maybe s/SysInfo/SysInfo v1/] oh, yes, webapps globally reconfiguring the keyboard! That's fun. fhirsch: what about keyboard, camera flash? is that general? darobin: there is a general use case for knowing keyboard type tlr: some settings are set-able not all are just read-only some will lead to misunderstanding tlr: if this value is useful for more than just itself, it may be "generic" ... cpu fan value may monitor for itself RESOLUTION: use a "generic use case"/"apps not directly targeted at monitoring the said sensors" measurement to decide whether something is to be included in SysInfo or not **RESOLUTION: use a "generic use case"/"apps not directly targeted at monitoring the said sensors" measurement to decide whether something is to be included in SysInfo or not** in essence resolution says use case driven material can be included, platform specifics not included schittur: on calendar api, did sent out draft use cases and requirements looking at intersection of different calendar apis will send to whole group next week or soon after tlr: 2 questions: Thomas, you wanted to ask whether to track the "encrypted" piece as issue encrypted attribute on network interface re net interfaces, some sensor data might permit to infer additional info link to suresh message on calendar use cases - [http://lists.w3.org/Archives/Public/public-device-apis/2009Dec/0241.html][24] such as net interfaces or location darobin: open issues on these points tlr: will do so +1 to opening issues tlr: singing ... thanks closing call... thanks ## Summary of Action Items **[NEW]** **ACTION:** fjh fix Seoul time in agenda to be 24:00 [recorded in [http://www.w3.org/2010/01/06-dap-minutes.html#action01][11]] **[NEW]** **ACTION:** maxf to write to list of properties to drop or simplify [recorded in [http://www.w3.org/2010/01/06-dap-minutes.html#action03][23]] **[NEW]** **ACTION:** Paddy to integrate his use cases in policy requirements [recorded in [http://www.w3.org/2010/01/06-dap-minutes.html#action02][21]] [End of minutes] * * * Minutes formatted by David Booth's [scribe.perl][25] version 1.135 ([CVS log][26]) $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/0298.html [4]: http://www.w3.org/2010/01/06-dap-irc [5]: #agenda [6]: #item01 [7]: #item02 [8]: #item03 [9]: #item04 [10]: #ActionSummary [11]: http://www.w3.org/2010/01/06-dap-minutes.html#action01 [12]: http://lists.w3.org/Archives/Public/public-device- apis/2009Dec/att-0231/minutes-2009-12-16.html [13]: http://lists.w3.org/Archives/Public/public-device- apis/2009Dec/0293.html [14]: http://lists.w3.org/Archives/Public/public-device- apis/2009Dec/0295.html [15]: http://lists.w3.org/Archives/Public/public-device- apis/2009Nov/0044.html [16]: http://www.w3.org/2009/dap/track/actions/63 [17]: http://lists.w3.org/Archives/Public/public-device- apis/2009Dec/0297.htm [18]: http://lists.w3.org/Archives/Public/public-device- apis/2009Dec/0297.html [19]: http://www.w3.org/2009/dap/track/actions/69 [20]: http://lists.w3.org/Archives/Public/public-device- apis/2010Jan/0031.html [21]: http://www.w3.org/2010/01/06-dap-minutes.html#action02 [22]: http://www.w3.org/2009/dap/track/actions/77 [23]: http://www.w3.org/2010/01/06-dap-minutes.html#action03 [24]: http://lists.w3.org/Archives/Public/public-device- apis/2009Dec/0241.html [25]: http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm [26]: http://dev.w3.org/cvsweb/2002/scribe/