# Device APIs and Policy Working Group Teleconference ## 28 Apr 2010 [Agenda][3] See also: [IRC log][4] ## Attendees Present Robin_Berjon, Frederick_Hirsch, Erica_Newland, LauraA, Anssi_Kostiainen, Alissa_Cooper, David_Rogers, Dominique_Hazael-Massieux, Ilkka_Oksanen, Suresh_Chitturi, Claes_Nilsson, Niklas_Widell, Maria_Oteo, Marco_Marengo, Ingmar_Kliche, Soonho_Lee Regrets John_Morris, WonSuk_Lee Chair Robin_Berjon, Frederick_Hirsch Scribe alissa, dom, maxf ## Contents * [Topics][5] 1. [Admin][6] 2. [Minutes approval][7] 3. [Privacy][8] 4. [API discussion][9] 5. [parameter style][10] 6. [editor for tasks][11] 7. [misc APIs][12] * [Summary of Action Items][13] * * * Date: 28 April 2010 ok scribenick: alissa ### Admin Privacy workshop, Mon/Tue 12-13 July 2010, London Privacy workshop, Mon/Tue 12-13 July 2010, London [http://www.w3.org/2010/api-privacy-ws/][14] fjh: our F2F is now starting Weds, July 14 drogersuk: OMTP is flexible with hosting [http://www.ceop.gov.uk/][15] drogersuk: also arranging a visit to CEOP one evening of F2F (will be IRC only first 30 minutes of this call potentially we could setup two separate visits, but these will not infringe directly on the meetings - they would be after ScribeNick: dom frederick: not sure if we should have a 2 or 3 days meeting ... probably won't need to discuss privacy given that we'll have discussed it for two days during the workshop before Bryan: I suggest going for 3 days ... our F2F meetings are fairly productive personally I'm not avail for Fri Robin: suggests 2.5 days to allow for people to leave early on Friday ... re privacy, I'm hoping we'll get new input from the workshop that will be worth processing Frederick: does anybody have a problem with 2.5 days? David: we can accommodate for that one way or another re hosting **RESOLUTION: Next F2F on July 14 to 16 in London** does it end at 12:00noon on the 3rd day? **RESOLUTION: Next F2F on July 14 to 16 in London, ending at 2 or 3pm on Friday** frederick: our hosts will need to look into lunch & logistics (note that attendance at the workshop requires sending a position paper) ### Minutes approval [http://lists.w3.org/Archives/Public/public-device- apis/2010Apr/att-0080/minutes-2010-04-21.html][16] 21 April 2010 **RESOLUTION: Minutes of April 21st approved** ScribeNick: alissa Policy requirements and framework [http://dev.w3.org/2009/dap/policy-reqs/][17] **ACTION:** fjh to review policy requirements and propose changes [recorded in [http://www.w3.org/2010/04/28-dap-minutes.html#action01][18]] Created ACTION-166 - Review policy requirements and propose changes [on Frederick Hirsch - due 2010-05-05]. [http://dev.w3.org/2009/dap/policy/][19] will resume scribing now layering model considerations can move to requirements doc? fjh: Laura still needs to add trust domain stuff from Nokia Laura: still working on it ... maybe done early next week fjh: two different things in document ... 1 model of how security works ... 2 detailed XACML profile ... 1 very tied to 2 ... XACML profile could be its own doc ... but issues still lie in model piece ... maybe need some layering to separate out XACML dom: no problem with the length, but perhaps the scope we might want to split framework into model and separate xacml profile document dom: rules lang, ID model, model for environment, capacities model,policy decision model -- lots of stuff ... makes it harder to get reviews, to get browsers to look at it, etc. [Dom's comment on policy framework][20] fjh: could make XACML part separate pretty easily ... not a whole lot in the rest of the doc ... need suggestions on way forward **ACTION:** Dom to make a concrete proposal for policy framework based on his comments [http://lists.w3.org/Archives/Public/public-device- apis/2010Apr/0030.html][20] [recorded in [http://www.w3.org/2010/04/28-dap- minutes.html#action02][21]] Created ACTION-167 - Make a concrete proposal for policy framework based on his comments [http://lists.w3.org/Archives/Public/public-device- apis/2010Apr/0030.html][20] [on Dominique Hazaël-Massieux - due 2010-05-05]. fjh: next step: Laura to finish, others to think about way forward comment from Claes <[http://lists.w3.org/Archives/Public/public-device- apis/2010Apr/0084.html][22] Claes: tables defining the subject attributes -- didn't understand [http://dev.w3.org/2009/dap/policy/#subject-attributes][23] Laura: have not had time to respond yet Claes: important to be able to identify a unique web application, not just domain (this is an example of why identity in itself is probably worth a spec on its own :) fjh: will take this to the list identity is one area to call out Suresh: sent an email awhile ago asking how the warp (?) spec in widgets group is relevant to policy ... if you run this against widget environment, widget config will come into effect [http://www.w3.org/TR/2010/CR-widgets-access-20100420/][24] fjh: answer was that warp was an intermediate specification- we should look at it darobin: warp is in CR ... it's one use case, so if policy doesn't cover what warp does, that's a problem Suresh: couldn't we just reference it? darobin: it's fine to redefine it ... otherwise might have to caveat warp out Suresh: if we can reference it, we should darobin: not sure how reusable warp is, not certain issue: note relationship of WARP to DAP policy work Created ISSUE-83 - Note relationship of WARP to DAP policy work ; please complete additional details at [http://www.w3.org/2009/dap/track/issues/83/edit][25] . ### Privacy privacy requirements [http://dev.w3.org/2009/dap/privacy-reqs/][26] [http://lists.w3.org/Archives/Public/public-device- apis/2010Apr/0088.html][27] this draft fills in details, removes ambiguous language and adds new requirements this could impact API work **ACTION:** Alissa to incorporate edits into Privacy Requirements. [recorded in [http://www.w3.org/2010/04/28-dap-minutes.html#action03][28]] Created ACTION-168 - Incorporate edits into Privacy Requirements. [on Alissa Cooper - due 2010-05-05]. (I had trouble with the interpretation of "mutually exclusive" in Alissa's response; I think we should talk about subsetting relationships rather) fjh: had some placeholder text for APIs [http://lists.w3.org/Archives/Public/public-device- apis/2010Apr/0086.html][29] ACTION-114? ACTION-114 -- Alissa Cooper to phrase the temporary privacy section -- due 2010-03-23 -- PENDINGREVIEW [http://www.w3.org/2009/dap/track/actions/114][30] [yeah, that's part of what I was thinking about — but I need to ground those ideas in examples to see if it would make sense] fjh: can editors put in the text? (I am attending this conference call only via IRC.) **ACTION:** Frederick to insert temporary privacy language into the APIs. [recorded in [http://www.w3.org/2010/04/28-dap- minutes.html#action04][31]] Created ACTION-169 - Insert temporary privacy language into the APIs. [on Frederick Hirsch - due 2010-05-05]. ### API discussion ACTION-142? ACTION-142 -- Max Froumentin to propose two interfaces Outgoing and Incoming messages for messaging API -- due 2010-03-25 -- PENDINGREVIEW [http://www.w3.org/2009/dap/track/actions/142][32] darobin: hasn't been much feedback on this -- should we go ahead with it? [][33] Suresh: don't see why we want to split into incoming and outgoing ... only distinguished by send ... if we split will need interface for draft message, e.g. [Messaging API discussions at the F2F][34] maxf: I don't have insight into which way we're going, just need to make a choice ... don't have a strong opinion dom: we had the distinction because incoming should be read-only ... send on incoming doesn't make any sense ... maybe incoming/outgoing is misleading; it should be about whether it will be sent ... distinction has value darobin: same intf with different rules? Suresh: have exception on send for incoming the proposal I had: [http://www.w3.org/mid/4BD04FAA.2010107@opera.com][35] Suresh: can address use case with what we have ah, no. darobin: might want to filter received messages to make them readable bryan: messages should be editable in the inbox [http://www.w3.org/mid/4BCF032E.9050900@opera.com][36] bryan: once you've stored a message, you need an ID to edit ... the attributes end up becoming similar between the two ... although there are exceptions darobin: hearing more arguments in favor of single interface Suresh: once we have folder management, we can come back to this darobin: not strongly tied to folders ... sent mail folder is more of an implementation detail Suresh: can tag msgs as sent or received darobin: if object fields are similar, it's a small decision between object type and type flag ... hearing stronger consensus for single interface dom: already have a type flag ... need to disambiguate names 'status' **RESOLUTION: Messages have a single interface irrespective of their type. Need a better name for type (status?).** close ACTION-142 ACTION-142 Propose two interfaces Outgoing and Incoming messages for messaging API closed maxf: so we're not keeping a per-type (MMS, SMS) interface then? Suresh: should separate interfaces based on messaging type ... BONDI separates the interfaces [actually these two are half-orthogonal — if we have separate for incoming/ougoing *and* for types we get IncomingSMS, OutgoingSMS, IncomingEmail, ...] Suresh: right now we create a superset interface and we're silent for what doesn't apply [given a unified in/out interface, if we split we just get Email, SMS, MMS] Suresh: implementations might have separate modules for different messaging technologies darobin: some implementations might only support email Suresh: separation lets implementations pick bryan: extension to specific message types is a useful approach (attachments aren't relevant for SMS, e.g.) ... defining message types is a better approach +1 with Bryan: different interfaces handles the attribute errors automatically Suresh: makes spec longer (which we'll have to do for incoming/outgoing :) ) Suresh: will miss exception cases **RESOLUTION: Have multiple interfaces for different messaging technologies (i.e., message types).** darobin, you wanted to bring up numerical constants (this relations to ACTION-139) ACTION-139? ACTION-139 -- Max Froumentin to fix section 5 "supported messaging types" in Messaging API to clarify handling of non-supported attributes -- due 2010-03-25 -- OPEN [http://www.w3.org/2009/dap/track/actions/139][37] maxf: will wait to update until receiving something from Suresh I was asking about a resolution on the priority attribute Suresh: priority attribute is not applicable for SMS and MMS, but it is for email ... since we're separating, we should add it to email bryan: why isn't priority applicable to MMS? Suresh: it's not defined in the MMS spec ... user-defined priority (another item that my MUA lets me set at writing time: reply-to) dom: could have generic getheader and setheader? darobin: concerned about security issues (in XHR had to jump hoops re headers) (at least getHeader() should exist?) [yeah, getHeader() makes sense — note that it can return an array] Suresh: list of headers is not long right now darobin: there are many email headers dom: PHP lets you write any header bryan: could deal with security issues separately from API functionality (maybe we should decide on abstraction level of Messaging API) bryan: could define specific attributes for most common message fields, but use others by name through generic mechanism [we could WebIDL setter/getter? not sure if it's worth it, though] [email from Suresh: X-Original-To, Delivered-To, Received, X-AuditID, X-MimeOLE, Content-class, MIME-Version....] **ACTION:** Robin to review the options for headers on emails [recorded in [http://www.w3.org/2010/04/28-dap-minutes.html#action05][38]] Created ACTION-170 - Review the options for headers on emails [on Robin Berjon - due 2010-05-05]. ISSUE: which headers to support setting/getting in Messaging API? Created ISSUE-84 - Which headers to support setting/getting in Messaging API? ; please complete additional details at [http://www.w3.org/2009/dap/track/issues/84/edit][39] . darobin: lots of different headers that might need support ... will draft an email with use cases, review XHR nwidell: question of size and scope of API ... do we really have a use case for replacing outlook? go for 80/20 bryan: providing a message where you can get/set fields by name, keeps API small ... if we have something generic, market will find useful ways to leverage it ScribeNick: maxf Suresh: we didn't talk about ability to identify messages by Service, like in Contacts ... people have different email accounts. +1 Suresh: retrieving by service is useful. ... e.g. different mailboxes [you get some emails from Opera, others from GMail, etc. different accounts] Suresh: different accounts +1 (was thinking about same thing before going AWOL ;-) darobin: account-ID sounds better than service-ID [][40] ### parameter style darobin: seems to be heading towards using object literals ... objections? dom: I'm not sure I would call it a consensus ... about half and half darobin: happy to keep discussion alive dom: perhaps we need to wait a bit, see if anybody reacts further darobin: ok ### editor for tasks (this was about ISSUE-55) darobin: david suggested he might be able to find someone ACTION-147? ACTION-147 -- David Rogers to look for an editor for the Tasks API -- due 2010-03-25 -- OPEN [http://www.w3.org/2009/dap/track/actions/147][41] Hello? Suresh: is Tasks among the priority APIs? Can you hear me? darobin: not necessarily, but editors would be welcome drogersuk: didn't see any responses when I asked close ACTION-147 ACTION-147 Look for an editor for the Tasks API closed ACTION-147: no one took up the offer ACTION-147 Look for an editor for the Tasks API notes added darobin: then we might just have to wait ### misc APIs darobin: we're going to need a test framework soon [A Proposal for the Testing Framework, Soonho Lee][42] +1 darobin: dom also looked at it wttjs dom: I found WTTGS which generates test cases based on webidl ... it's not as good as it could be, not too good for async interfaces [][40] bah [][43] darobin: widlproctools might be a better start. Hoping I'll be able to work on it soon. s/-> [http://www.w3.org/mid/n2n708552fb1004071110x6d98c6e6t85e83eef0 eef52de@mail.gmail.com//][44] ACTION-150? ACTION-150 -- David Rogers to send BONDI experience with testing for device APIs -- due 2010-03-25 -- OPEN [http://www.w3.org/2009/dap/track/actions/150][45] s/drogersuk: trying to lobby for your case with new Bondi CEO (Geoff Jackson?)// sorry example of W3C minuting! drogersuk: dom, let's speak offline about it, cause I think we have a plan. **ACTION:** drogersuk and Dom to speak offline on testing framework [recorded in [http://www.w3.org/2010/04/28-dap-minutes.html#action06][46]] Created ACTION-171 - And Dom to speak offline on testing framework [on David Rogers - due 2010-05-05]. drogersuk: there's a large amount of interest, since manufacturers need to be able to claim compliance ... we'd like to endorse Marcos' job with widgets specs darobin: we should try and get him on this group to help. And we should try and gather as much manufacturer power as possible ack ! I need to jump onto another conference call, see you guys later (regrets for next two weeks from me) ## Summary of Action Items **[NEW]** **ACTION:** Alissa to incorporate edits into Privacy Requirements. [recorded in [http://www.w3.org/2010/04/28-dap-minutes.html#action03][28]] **[NEW]** **ACTION:** Dom to make a concrete proposal for policy framework based on his comments [http://lists.w3.org/Archives/Public/public-device- apis/2010Apr/0030.html][20] [recorded in [http://www.w3.org/2010/04/28-dap- minutes.html#action02][21]] **[NEW]** **ACTION:** drogersuk and Dom to speak offline on testing framework [recorded in [http://www.w3.org/2010/04/28-dap-minutes.html#action06][46]] **[NEW]** **ACTION:** fjh to review policy requirements and propose changes [recorded in [http://www.w3.org/2010/04/28-dap-minutes.html#action01][18]] **[NEW]** **ACTION:** Frederick to insert temporary privacy language into the APIs. [recorded in [http://www.w3.org/2010/04/28-dap- minutes.html#action04][31]] **[NEW]** **ACTION:** Robin to review the options for headers on emails [recorded in [http://www.w3.org/2010/04/28-dap-minutes.html#action05][38]] [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://lists.w3.org/Archives/Public/public-device- apis/2010Apr/0093.html [4]: http://www.w3.org/2010/04/28-dap-irc [5]: #agenda [6]: #item01 [7]: #item02 [8]: #item03 [9]: #item04 [10]: #item05 [11]: #item06 [12]: #item07 [13]: #ActionSummary [14]: http://www.w3.org/2010/api-privacy-ws/ [15]: http://www.ceop.gov.uk/ [16]: http://lists.w3.org/Archives/Public/public-device- apis/2010Apr/att-0080/minutes-2010-04-21.html [17]: http://dev.w3.org/2009/dap/policy-reqs/ [18]: http://www.w3.org/2010/04/28-dap-minutes.html#action01 [19]: http://dev.w3.org/2009/dap/policy/ [20]: http://lists.w3.org/Archives/Public/public-device- apis/2010Apr/0030.html [21]: http://www.w3.org/2010/04/28-dap-minutes.html#action02 [22]: http://lists.w3.org/Archives/Public/public-device- apis/2010Apr/0084.html [23]: http://dev.w3.org/2009/dap/policy/#subject-attributes [24]: http://www.w3.org/TR/2010/CR-widgets-access-20100420/ [25]: http://www.w3.org/2009/dap/track/issues/83/edit [26]: http://dev.w3.org/2009/dap/privacy-reqs/ [27]: http://lists.w3.org/Archives/Public/public-device- apis/2010Apr/0088.html [28]: http://www.w3.org/2010/04/28-dap-minutes.html#action03 [29]: http://lists.w3.org/Archives/Public/public-device- apis/2010Apr/0086.html [30]: http://www.w3.org/2009/dap/track/actions/114 [31]: http://www.w3.org/2010/04/28-dap-minutes.html#action04 [32]: http://www.w3.org/2009/dap/track/actions/142 [33]: http://lists.w3.org/Archives/Public/public-device- apis/2010Apr/0079.html [34]: http://www.w3.org/2010/03/18-dap-minutes#item01 [35]: http://www.w3.org/mid/4BD04FAA.2010107@opera.com [36]: http://www.w3.org/mid/4BCF032E.9050900@opera.com [37]: http://www.w3.org/2009/dap/track/actions/139 [38]: http://www.w3.org/2010/04/28-dap-minutes.html#action05 [39]: http://www.w3.org/2009/dap/track/issues/84/edit [40]: http://www.w3.org/mid/n2n708552fb1004071110x6d98c6e6t85e83eef0eef52de @mail.gmail.com [41]: http://www.w3.org/2009/dap/track/actions/147 [42]: http://www.w3.org/mid/490BF875279F7549BEBA47ADC8F369DB6C92435F8D@SKT- MBXA.SKT.AD [43]: http://suika.fam.cx/www/webidl2tests/readme.en.html [44]: http://www.w3.org/mid/n2n708552fb1004071110x6d98c6e6t85e83eef0eef52de @mail.gmail.com// [45]: http://www.w3.org/2009/dap/track/actions/150 [46]: http://www.w3.org/2010/04/28-dap-minutes.html#action06 [47]: http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm [48]: http://dev.w3.org/cvsweb/2002/scribe/