# Device APIs and Policy Working Group Teleconference ## 16 Jul 2010 [Agenda][3] See also: [IRC log][4] ## Attendees Present meeting_room, paddy, John_Morris, Frederick_Hirsch, Ilkka_Oksanen, Alissa_Cooper, Neil_Stratford, Dominique_Hazael-Massieux, Soonho_Lee, Marco_Marengo, Ingmar_Kliche, Wonsuk_Lee, Claes_Nilsson, Niklas_Widell, Richard_Tibbett, Seung-Yeon_Lee, LauraA, Daniel_Coloma, Fan_HU, Maria_Oteo, Younsung_Chu, KiYoung_Kim, hong_woo, Paddy_Byers, Kangchan_Lee Regrets Chair Robin_Berjon, Frederick_Hirsch Scribe nstratford ## Contents * [Topics][5] 1. [Capture][6] 2. [Sysinfo cfc status][7] 3. [Coordination with Other Groups][8] 4. [Next face to face meeting][9] 5. [Privacy][10] 6. [Policy][11] * [Summary of Action Items][12] * * * Date: 16 July 2010 ScribeNick: nstratford scribeNick: nstratford nstratford, [http://www.w3.org/2005/Incubator/audio/][13] ### Capture Presence+ Dong-Young_Lee reminder - agenda - discuss F2F after TPAC [HTML Form Based Media Capturing Editors draft][14] darobin: New re-arrangement of the API - we need to agree on the plan, when to have a draft and how soon to release. Good short-term interest - should push something out quickly and get feedback/implementations. ilkka: Two separate specification - 1. Form based (better name ideas?) - simple addition to html 5 - main discussion point is that the spec is now different, controlled by dap, or more integrated to html5 darobin: easier to get the spec out rather than wait for html 5 consensus +1 to darobin darobin: we can extend it, just not clash with it and coordinate not to cause problems ilkka: addition we are proposing are additions to the accept parameter darobin: ok not to validate as html 5 -> [http://dev.w3.org/html5/spec/number-state.html#attr-input- accept][15] Accept parameter in HTML5 richt: do the source parameter and the media file api need to be bound together here? is it necessary to have both - can see the source parameter without this api darobin: feedback that MediaFile is being implemented ilkka: is a small extension to File richt: change type to be mime-type - need to be consistent darobin: FormatData - eg. file.format.codecs - should it be a subfield or directly on MediaFile? Maybe inherit from FormatData and File? the parameters in FormatData also need to be made 'readonly'. further to the type/mime-type discussion I'd suggest that type can be removed from the 'MediaFile' interface as it is already provided in the 'File' interface The Blob interface already has a type attribute, cf [http://dev.w3.org/2006/webapi/FileAPI/#dfn-type][16] tlr: since using mime-types - respect for extension points - do we need to mirror them ... mime parameters are a list of tag value pairs ... check formats actually use parameters - eg. video dom: remove the type attibute darobin: sequence or array for MediaList? ilkka: same as for FileList wonsuk: most of the information is covered by Media Annotations api - need to be consistent [API for Media Resource 1.0][17] ilkka: we should avoid overlap, but downside is creating dependencies (but that spec is in last call) wonsuk: Location information in the capture api? darobin: Should remove gelocation information from images ... should have a note that we are looking into alignment with media annotations dom: Should remove the trusted environments example from section 5 darobin: Do we say enough in section 5 to properly integrate with html5? ... Impacts of exposing capture attribute in the dom - parameter is easier to implement tlr: Do we need to specify what happens if you have an input element is changed in the dom? darobin: agree that prefer a parameter over an attribute? (I think the FileAPI, HTML5, RFC4281 should be normative refs; WebIDL should also be added as normative ref) **ACTION:** Dom to update media capture form for publication next week [recorded in [http://www.w3.org/2010/07/16-dap-minutes.html#action01][18]] Created ACTION-233 - Update media capture form for publication next week [on Dominique Hazaël-Massieux - due 2010-07-23]. Interesting angle to this stuff: [http://blog.nihilogic.dk/2008/05 /reading-exif-data-with-javascript.html.][19] Any potential that this covers the FormatData interface parameters? (no EXIF for video yet though :-( ) PROPOSED RESOLUTION: we publish capture-forms as an update to TR /capture-api pending the changes discussed today are implemented richt, I think leaving EXIF to the javasript layer is probably best for now bryan: intent is to split into two peices - leaves all the capture part to the implementation (clarification) Claes: shouldn't this just be an update to html5? dom, I agree that the Media Capture spec goes a lot further than EXIF info, which is currently limited to a small number of formats. bsulliva: between dap and webapps we have the charter to connect html5 web runtime to the world - so it's better fitting here claes: Many other things can build on top of the input element **ACTION:** dom to seek review of capture-forms from HTML WG, Webapps once FPWD is published [recorded in [http://www.w3.org/2010/07/16-dap- minutes.html#action02][20]] Created ACTION-234 - Seek review of capture-forms from HTML WG, Webapps once FPWD is published [on Dominique Hazaël-Massieux - due 2010-07-23]. bsulliva: Can we be more specific in the reference to html5 in the specification? where does it talk about creating media files? ... as part of the File Upload state feature ... What about the name of the specification? - the short name will change (html media capture) [http://dev.w3.org/2009/dap/camera/Overview-API.html][21] **RESOLUTION: we publish html-media-capture as an update to TR/capture-api pending the changes discussed today are implemented** RESOLUTION: we publish a WD of Media Capture API as soon as Ingmar has polished it **ACTION:** Ingmar to polish Media Capture [recorded in [http://www.w3.org/2010/07/16-dap-minutes.html#action03][22]] Created ACTION-235 - Polish Media Capture [on Ingmar Kliche - due 2010-07-23]. ### Sysinfo cfc status darobin: Security section has been re-writen, changed the privacy section - new editors draft before decide on last cal ACTION-191? ACTION-191 -- James Salsman to send pre-LC editorial comments on system-info and camera/Media Capture -- due 2010-06-16 -- CLOSED [http://www.w3.org/2009/dap/track/actions/191][23] [http://www.w3.org/2009/dap/track/actions/191][23] -- and ACTION-202 have james email - [http://lists.w3.org/Archives/Public/public-device- apis/2010Jul/0077.html][24] s/[http://www.w3.org/2009/dap/track/actions/191][23] -- and ACTION-202 have// ### Coordination with Other Groups tlr: Calendar - internatonalisation, timezone. Contacts (how fits with IETF vcard?) darobin: Units from sysinfo - which bandwidth metric/luminance/decibel s;[http://www.w3.org/2009/dap/track/actions/191][23] -- and ACTION-202 have;; tlr: Sysinfo: network, contacts, calendar - need more on messaging before review richt: Portable contacts people as well bsulliva: difficulty because we have our own schema - OMA are trying to do things in a coordinated way - how close can CAB(?) be to what they need RE: OMA CAB/PoCo/vCard relationship to Contacts API -> [http://lists.w3.org/Archives/Public/public-device-apis/2010Jun/0273.html][25] darobin: make sure CAB are aware of our work Dong-Young: CAB is defining it's own format, concerns related to deployment because of own format - making effort to make compatible with vCard - should be in this group as well richt: A lot of people are behind portable contacts that go beyond vCard - but portable contacts inherits from vCard - scope of the contacts api is much larger List of providers of Portable Contacts information: [http://wiki.portablecontacts.net/Software-and-Services-using-Portable- Contacts][26] tlr: Three way coordination between IETF vCard, CAB and us is required **ACTION:** thomas to report back on IETF relationships after Maastricht meeting [recorded in [http://www.w3.org/2010/07/16-dap- minutes.html#action04][27]] Created ACTION-236 - Report back on IETF relationships after Maastricht meeting [on Thomas Roessler - due 2010-07-23]. ACTION-236: Calendar formats and protocols (calDAV, recurrence model, solilunar calendar and internationalization) ACTION-236 Report back on IETF relationships after Maastricht meeting notes added ACTION-236: Contacts API (PoCo, Vcard, relationship to OMA CAB work) ACTION-236 Report back on IETF relationships after Maastricht meeting notes added ACTION-236: Sysinfo (bandwidth metrics) ACTION-236 Report back on IETF relationships after Maastricht meeting notes added **ACTION:** Robin to talk to TC-39 about TimezonedDate once it's ready [recorded in [http://www.w3.org/2010/07/16-dap- minutes.html#action05][28]] Created ACTION-237 - Talk to TC-39 about TimezonedDate once it's ready [on Robin Berjon - due 2010-07-23]. ACTION-236 due 2010-07-31 ACTION-236 Report back on IETF relationships after Maastricht meeting due date now 2010-07-31 action-236? ACTION-236 -- Thomas Roessler to report back on IETF relationships after Maastricht meeting -- due 2010-07-31 -- OPEN [http://www.w3.org/2009/dap/track/actions/236][29] bsulliva: Working to align with OMA work - SysInfo attributes and CPM(?) for messaging APIs - CPM is a broad framework for messaging of all types **ACTION:** bsulliva to inform OMA groups of our status [recorded in [http://www.w3.org/2010/07/16-dap-minutes.html#action06][30]] Created ACTION-238 - Inform OMA groups of our status [on Bryan Sullivan - due 2010-07-23]. ### Next face to face meeting **ACTION:** Dom to prepare survey on finding a date for a F2F meeting in Seoul, in Feb/Mar 2011 [recorded in [http://www.w3.org/2010/07/16-dap- minutes.html#action07][31]] Created ACTION-239 - Prepare survey on finding a date for a F2F meeting in Seoul, in Feb/Mar 2011 [on Dominique Hazaël-Massieux - due 2010-07-23]. **ACTION:** Kangchan to look into hosting at ETRI in late Feb/early Mar 2011 [recorded in [http://www.w3.org/2010/07/16-dap- minutes.html#action08][32]] Created ACTION-240 - Look into hosting at ETRI in late Feb/early Mar 2011 [on Kangchan Lee - due 2010-07-23]. **RESOLUTION: first meeting of 2011 in Korea** and **RESOLUTION: The group thanks David and WAC for hosting** ### Privacy fjh: powerbox and privacy ... might be possible to use rulesets in powerbox seems logical to integrate user privacy information with introduction/discovery mechanism bsulliva: a protocol in which you have a provider interact with an authoriser on behalf of the user is what powerbox is about not to say inappropriate for APIs as discussed earlier, though we've also discussed issues for that alissa: somewhere there has to be a UI element that allows the user to stablish what privacy aplies with which data alissa: user needs to get involved at one point. thus, there needs to be a UI element Claes: powebox allows the user to install the provider you trust jmorris: for control policies powerbox might be a good thing, we will look at it to get a better understanding Dong-Young: for attaching privacy rules, this can be easly implemented by a header in HTTP, fhj: not just a technical problem, need to consider the whole ecosystem dom: we identified the set of issues. we should at least rough ideas how we are going to deal with these issues fjh: we just listed the issues against it dom: we have a plan. we have these issues, we need to decide if we address them or ignore them. dom: alissa will document the issues jmorris: we'll go through the list and provide responses to these items ... some items are resolvable. We might want to identify communities that would implement this. ... if we are not able to find this community, that we might not want to spend time on this dom: all the privacy investment we are doing is not in rulesets jmorris notes powerbox might be able to enable access decisions including privacy as inputs, but might not help transmitting rules aspect dom: in terms of experimental implementations, there were two options presented alissa: having a sort of RI will be the only way to make some progress dom: i might be able to help +1 for RI on rule sets darobin: me too. I think it's better if it was not hosted by W3C discussion of possible prototype alisaa: we would need 2 parts: browser extension and a site that makes use of them. darobin: it could be simpler, just having a site, where a user configures the privacy settings bsulliva: a specification of some sort of data format is required, like rule sets. I think we should write a recommendation to support rule sets. jmorris: ... bsulliva: to me rule set is just a definition of a preference or an intent jmorris, the ability to block contextual advertising in a user- generated privacy policy is going to jar with a lot of web business models. i.e. you get the service for free in exchange for contextual advertising. fjh: this is not a technical concern, is a political concern ...'contextual advertising' is often the price you pay for free services. This also applies to the cost/benefit ratio of other compromises of user privacy. bsulliva: why do we need to define a default policy? jmorris: the value is that it works with many websites want default privacy policy that works widely on the web want policy that can be understood and is meaningful dom: what Bryan was pointing to is that it makes sense to have possible values of the rule sets defined buy-in from various stakeholders is important jmorris: i agree with that. the rule set document should get buy in from the privacy community. fjh: should we have an action to look at powerbox? jmorris: fine, we are happy to look at powerbox. bsulliva: result from this discussion: we don't feel is good to define a framework in which the policy is set by the user? fjh: we didn't say that.. bsulliva: we have a proposal for having 3 buckets because we think is simpler. Are we going to allow users to say "no, i don't want to allow..." ? alissa: there are the 3 choices and they are what they are tlr: I don't really know what it means "to break the web", it's better to frame this issue and focus on next steps, etc fjh: the assumption is that by doing some simplification it might get adopted more easily bryan asks about maintenance and change related to rulesets over time alissa: there are arguments on both sides. Some think it's too complex, some others think it's not complex enough bsulliva: one last point, tying to the work being done elsewhere. When we get to the point of defining a policy framework, if we define set policies with specific settings, it's going to be difficult to comply to all different markets. ISSUE: different regulatory environments and relationship to privacy and rulesets Created ISSUE-95 - Different regulatory environments and relationship to privacy and rulesets ; please complete additional details at [http://www.w3.org/2009/dap/track/issues/95/edit][33] . tlr: regarding different regulatory environments, as John set about the privacy community, this is also something that will come up for privacy. fjh, you wanted to ask about actions and next steps ### Policy API sections, Features ok [http://dev.w3.org/2009/dap/features/][34] [Privacy & Security Consideration][35] dom: I added privacy and security sub-sections in the API checklist the checklist now includes questions that should be answered by each API in privacy and security considerations section ... I am going to send a link to the mailing list ... this should be part of our regular check list fjh: we are all free to add to these questions fjh: Features --> i created a draft including the feature definitions from BONDI ... I reference the feature element in P&C ... I am not sure we want to define a set of capabilities fjh's draft: [http://dev.w3.org/2009/dap/features/][34] paddy: how does this document relate to existing documents? ... it would make sense to have just one set of definitions we all agree on fjh: it might be good to focus on the features draft and not worry about repeating content in different docs paddy: the scope of this document is --> defining what a feature is, define a list of features and those definitions are going to be linked to a different API draft dom: we don't need to restrict ourselves to the set of APIs this WG is defining, like Geolocation fjh: i agree. I didn't include references to the API docs yet, but these should be there, of course. Rather than using [http://dev.w3.org/2009/dap/features/*][36] for features maybe we should use [http://w3.org/device/f/*][37] or something similar? It's probably not a big deal right now....bikesheding aside :-/ fjh: not sure what else we could do with policy right now dom: It was interesting that Ian stated that a policy might be something they consider for the future paddy: There is interest around the table to define the policy framework well but support is needed from all those interested in moving the policy work forward. The discussion with Ian was quite encouraging. **ACTION:** fjh to review and update policy requirements [recorded in [http://www.w3.org/2010/07/16-dap-minutes.html#action09][38]] Created ACTION-241 - Review and update policy requirements [on Frederick Hirsch - due 2010-07-23]. **ACTION:** paddy to review and update policy requirements [recorded in [http://www.w3.org/2010/07/16-dap-minutes.html#action10][39]] Created ACTION-242 - Review and update policy requirements [on Paddy Byers - due 2010-07-23]. fjh: 2 things to do ... feature stuff and requirements&policy update requirements to clarify focus and objectives (I think it's critical to define use cases for the in-entreprise usage of the policy framewr) paddy notes trust domains, rule separation topic to discuss later; whether to use XACML or something similar or not etc dom: in the requirements document, we could include use cases of policy in the enteprise context possible use case - configuration for child protection/use by operator etc paddy: do any operators around the room have any views of the enterprise use cases? enterprise use case might not be driven by operator, but by enterprise itself dom: we are talking about the policy reqs document to make it more interesting for other parties bsulliva: we could help to give an example of these use cases (Especially, in web application for B2B, it's so important to consider enterprise use cases) fjh: are we done with policy? fjh: we are done with policy now. Here is the link to the message I sent with comment on the Policy Rulesets proposal: [http://lists.w3.org/Archives/Public/public-device- apis/2010Jul/0099.html][40] fjh: should we go through the issues? [http://www.w3.org/2009/dap/track/issues/open][41] fjh: I'll bring up the issues list ISSUE-26? ISSUE-26 -- How to refer to API -- open [http://www.w3.org/2009/dap/track/issues/26][42] ISSUE-29? ISSUE-29 -- Should DAP APIs support "API Keys" -- open [http://www.w3.org/2009/dap/track/issues/29][43] social network requires application specific key sounds like extensibility point needed. Goal to enable authentication to service by javascript ISSUE-29 and ISSUE-30 are the same or related ISSUE-34? ISSUE-34 -- Protecting data versus protecting apis -- open [http://www.w3.org/2009/dap/track/issues/34][44] see note from Richard ISSUE-56 closed ISSUE-56 Add custom copyright notice closed ISSUE-54? ISSUE-54 -- What messaging use cases cannot be fulfilled by existing URI schemes (mailto, sms, mms)? -- open [http://www.w3.org/2009/dap/track/issues/54][45] issue-54 closed ISSUE-54 What messaging use cases cannot be fulfilled by existing URI schemes (mailto, sms, mms)? closed issue-78? ISSUE-78 -- Capture has a minimisation problem with EXIF data (e.g. it could be Geotagged) -- open [http://www.w3.org/2009/dap/track/issues/78][46] add warning to capture API regarding EXIF data next teleconference is 4 August adjourn ## Summary of Action Items **[NEW]** **ACTION:** bsulliva to inform OMA groups of our status [recorded in [http://www.w3.org/2010/07/16-dap-minutes.html#action06][30]] **[NEW]** **ACTION:** Dom to prepare survey on finding a date for a F2F meeting in Seoul, in Feb/Mar 2011 [recorded in [http://www.w3.org/2010/07/16 -dap-minutes.html#action07][31]] **[NEW]** **ACTION:** dom to seek review of capture-forms from HTML WG, Webapps once FPWD is published [recorded in [http://www.w3.org/2010/07/16-dap- minutes.html#action02][20]] **[NEW]** **ACTION:** Dom to update media capture form for publication next week [recorded in [http://www.w3.org/2010/07/16-dap- minutes.html#action01][18]] **[NEW]** **ACTION:** fjh to review and update policy requirements [recorded in [http://www.w3.org/2010/07/16-dap-minutes.html#action09][38]] **[NEW]** **ACTION:** Ingmar to polish Media Capture [recorded in [http://www.w3.org/2010/07/16-dap-minutes.html#action03][22]] **[NEW]** **ACTION:** Kangchan to look into hosting at ETRI in late Feb/early Mar 2011 [recorded in [http://www.w3.org/2010/07/16-dap- minutes.html#action08][32]] **[NEW]** **ACTION:** paddy to review and update policy requirements [recorded in [http://www.w3.org/2010/07/16-dap-minutes.html#action10][39]] **[NEW]** **ACTION:** Robin to talk to TC-39 about TimezonedDate once it's ready [recorded in [http://www.w3.org/2010/07/16-dap- minutes.html#action05][28]] **[NEW]** **ACTION:** thomas to report back on IETF relationships after Maastricht meeting [recorded in [http://www.w3.org/2010/07/16-dap- minutes.html#action04][27]] [End of minutes] * * * Minutes formatted by David Booth's [scribe.perl][47] version 1.135 ([CVS log][48]) $Date: 2009-03-02 03:52:20 $ [1]: http://www.w3.org/Icons/w3c_home [2]: http://www.w3.org/ [3]: http://www.w3.org/2009/dap/agendas/2010-07-15.txt [4]: http://www.w3.org/2010/07/16-dap-irc [5]: #agenda [6]: #item01 [7]: #item02 [8]: #item03 [9]: #item04 [10]: #item05 [11]: #item06 [12]: #ActionSummary [13]: http://www.w3.org/2005/Incubator/audio/ [14]: http://dev.w3.org/2009/dap/camera/ [15]: http://dev.w3.org/html5/spec/number-state.html#attr-input-accept [16]: http://dev.w3.org/2006/webapi/FileAPI/#dfn-type [17]: http://www.w3.org/TR/mediaont-api-1.0/ [18]: http://www.w3.org/2010/07/16-dap-minutes.html#action01 [19]: http://blog.nihilogic.dk/2008/05/reading-exif-data-with- javascript.html. [20]: http://www.w3.org/2010/07/16-dap-minutes.html#action02 [21]: http://dev.w3.org/2009/dap/camera/Overview-API.html [22]: http://www.w3.org/2010/07/16-dap-minutes.html#action03 [23]: http://www.w3.org/2009/dap/track/actions/191 [24]: http://lists.w3.org/Archives/Public/public-device- apis/2010Jul/0077.html [25]: http://lists.w3.org/Archives/Public/public-device- apis/2010Jun/0273.html [26]: http://wiki.portablecontacts.net/Software-and-Services-using- Portable-Contacts [27]: http://www.w3.org/2010/07/16-dap-minutes.html#action04 [28]: http://www.w3.org/2010/07/16-dap-minutes.html#action05 [29]: http://www.w3.org/2009/dap/track/actions/236 [30]: http://www.w3.org/2010/07/16-dap-minutes.html#action06 [31]: http://www.w3.org/2010/07/16-dap-minutes.html#action07 [32]: http://www.w3.org/2010/07/16-dap-minutes.html#action08 [33]: http://www.w3.org/2009/dap/track/issues/95/edit [34]: http://dev.w3.org/2009/dap/features/ [35]: http://www.w3.org/2009/dap/wiki/ApiCheckList#Privacy_.26_Security_Con siderations [36]: http://dev.w3.org/2009/dap/features/* [37]: http://w3.org/device/f/* [38]: http://www.w3.org/2010/07/16-dap-minutes.html#action09 [39]: http://www.w3.org/2010/07/16-dap-minutes.html#action10 [40]: http://lists.w3.org/Archives/Public/public-device- apis/2010Jul/0099.html [41]: http://www.w3.org/2009/dap/track/issues/open [42]: http://www.w3.org/2009/dap/track/issues/26 [43]: http://www.w3.org/2009/dap/track/issues/29 [44]: http://www.w3.org/2009/dap/track/issues/34 [45]: http://www.w3.org/2009/dap/track/issues/54 [46]: http://www.w3.org/2009/dap/track/issues/78 [47]: http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm [48]: http://dev.w3.org/cvsweb/2002/scribe/