# Device APIs and Policy Working Group Teleconference ## 15 Jul 2010 [Agenda][3] ## Attendees Present Alissa_Cooper, Anssi_Kostiainen, Claes_Nilsson, Daniel_Coloma, Dominique_Hazael-Massieux, Fan_HU, Frederick_Hirsch, Ian_Fette, Ilkka_Oksanen, John_Morris, Kangchan_Lee, KiYoung, Kim, LauraA, Marco_Marengo, Maria_Oteo, Neil_Stratford, Niklas_Widell, Paddy_Byers, Richard_Tibbett, Robin_Berjon, Seung-Yeon_Lee, Soonho_Lee, Suresh, Suresh_Chitturi, Wojciech_Masłowski, Wonsuk_Lee, Younsung_Chu, bryan_sullivan, meeting_room, Laura_Arribas, Tyler_Close, Ingmar_Kliche Regrets Chair Robin_Berjon, Frederick_Hirsch Scribe nwidell, ilkka, ilkka_, Claes, FanH, danielcoloma ## Contents * [Topics][4] 1. [App Launcher API][5] 2. [Privacy][6] 3. [Sysinfo API updateSysinfo API update][7] 4. [Sysinfo API update][8] 5. [Messaging API][9] 6. [Contacts API][10] 7. [PowerBox/REST][11] 8. [Powerbox][12] * [Summary of Action Items][13] * * * trackbot-ng, start telecon Date: 15 July 2010 Presence+ Dong-Young_Lee scribenick: nwidell ### App Launcher API Agenda modification, start with app launcher API instaead of privacy/policy (slides describing the App Launcher API shown) (insert reference to slides here) for widget.openURL(), see [http://www.w3.org/TR/widgets-apis/#the- openurl-method][14] fjh: How will API realte to policy/privacy? tlr notes that registration of URIs can be managed but non-uri based approach is risky and needs care tlr: Dangerous to be able to discover application name from URI fjh, you wanted to ask about privacy and security implications of application launcher tlr: anything that can be used to discover what can be done on object is dangerous. fjh: What about Discovery? robin: Some reqirements at the end look scary (discovery) 1. As long as we just say "do stuff with resource", we're in the same problem space that we have on the Web in general. bryan; still a way to describe functionality is useful john: very hard hard to to manage with trust model for app 2. Things get really, really scary when we derive the application that we invoke from user input or stuff that comes across the network. Think about attack surface, and about how to limit the number of applications that can be invoked. Bryan: in OMTP there was the option of access control. ... web apps that do not behave will be revoked by market/user/UA richt, you wanted to ask whether this needs to be an API at all. e.g. the Android Intents system works really well IMO without any hanging JS API. Bryan: UA should have a method to log and know what privacy things are touched +1 to richt +1 indeed richt: Do we really need an javascript API for this. Android has intents what is the need for javascript API versus browser URI handling richt: and will likely not implement similar JS API. tlr: What are the use cases for this work (taking into consideration previous experience with similar APIs) bryan: Can we see some examples of threats robin: 1) split down in smaller pieces (first URIs, then harder stuff) bryan: existing solution only allows launcing, but not pass parameters not in the URI itself (Android uses URIs for Intents as well, IIRC) [yes it does] (mimicking Android Intents for that API would probably be a nice model; it's just not clear that we want to go there quite yet) john: Can see some of the use cases, would it be sufficient with a small limited set of functionality, with query to discover if functionality is present robin: There is still a threat in that case tlr: Real system will have white list of "allowed" URIs bryan: This is not an IPC API. Only real sensitve is "arbitrary app execution" navigator.registerProtocolHandler() allows web sites (not native apps) to register themselves as URI protocol handlers [http://www.w3.org/TR/2010/WD-html5-20100304/webappapis.html#dom-navigator- registerprotocolhandler][15] (it would be nice to extend that method for widgets, I think) fjh: Widget has invokeURL, browser can invoke well known URLs. robin: Would be great to see concrete proposal [http://www.w3.org/TR/widgets-apis/#the-openurl-method][14] dom: Would like to see more info on Use Cases bryan: Are the existing UCs insufficient? +1 to dom, application launcher is more useful in web runtime than in browser tlr: More features than UCs, what is the UC that motivates taking the risk associated with functionality? **ACTION:** Kangchan to make a concrete proposal for AppLauncher [recorded in [http://www.w3.org/2010/07/15-dap-minutes.html#action01][16]] Created ACTION-219 - Make a concrete proposal for AppLauncher [on Kangchan Lee - due 2010-07-22]. **ACTION:** Bryan to make a concrete proposal for AppLauncher [recorded in [http://www.w3.org/2010/07/15-dap-minutes.html#action02][17]] Created ACTION-220 - Make a concrete proposal for AppLauncher [on Bryan Sullivan - due 2010-07-22]. ### Privacy fjh: (summary of yesterday's privacy discussion) thanks for the link Anssi. That is particularly interesting also. fjh: Goal is to actually agree on something [http://alissacooper.com/files/w3c-simple-privacy-policies.pdf][18] [Archived version of Alissa's slides on user privacy policies][19] (Alissa presents slides on privacy policies) alissa: Can be simplified down to small simple set of policies ... "one-time" policy single use, covers many of the existing "usefulness" use cases ... "personal" policy, longer retention of data for personalization purposes ... "profile" policy covers everything, most permissive, keep forever darobin, you wanted to wrap up towards a concrete propposal fjh: Good to see explicit list of what is included, but maybe is one-time to permissive, may need even more protection? john: Yes, some will need more, but it will not be practical wrt usefulness. Proposal is a compromise. ian: This conversation is similar to what was had at geolocation privacy ... all browser vendors consider this as difficult to include, users consider protection of content, not apis. The right place for privacy control is in the application ... not in the UA. fjh; There is some investigation into showing privacy of site in UA (site policy) scribe: (ref to Asa's paper at privacy WS) ian: That requires more work and investigation. ... policy depends on content of site, and use of site based on trust. s/(insert reference to slides here)/[http://lists.w3.org/Archives/Public/public-device-apis/2010Jul/att-0082 /app-launch_20100716_.pdf/][20] ian: Distinction between giving access to information and use of that information. tlr: Should the UA mediate privacy settings with sites? john: SImplify down to "all the rules are set on application side" ian: this is misinterpretation. Many sites allow privacy settings what info is exposed (e.g. facebook) john: But there are many more sites where users ... users should not need extensive privacy agreement. Thus "one-time" is very useful fjh: Why is different sending a policy file to site different from inputing info. ian: Problem is that UA can not realistically promise anything ... there are some security things that can be checked (access to camera, etc). Policy would be difficult. ... How would the sites react to new privacy rules. Fan Hu: distinction between how long things can be useful. Also, trust is not neccessarilty enforced in internet world tlr: is there a way to build a very simple negotiation around the policy work that Alissa is proposing -- e.g., site asking user agent whether there is a user preference within this scheme david: Right at the start at BONDI work, proposal to include in API request from developer request for info from user, but this was too complex ... safer for the user to have control of policy by having it local fjh: Attempt at summary: (1) Privacy is managed at web site only, (2) there is a separate set of policies managed by user dom: the issues have been identified. If there is a wish to progress with rule sets there must be a proposal. ian: if there is too much negotiation wrt policy between site and user that will not work ... unneccessary waste of user time john: There is still value in sending rules, understand the problems with constant negotiation. Instead one-way from user to ... site. The site may or may not honour policy, it may be up to regulators to enforce that policies are followed ian: Most large web sites (e.g. biggest targets for regulators) already have settable privacy settings john: Disagree, smaller sites will also be impacted fjh: IS there anything different in this group from geoloc. ian: the technical problem is that the UA cannot enforce privacy policy ... proposal to build prototype that would require opt int from sites. nwidell: Question about regulation in international scope alissa: there is already jurisdicational control over flow of data (but not perfect) bryan: browser roles include not giving access to sensitve things, and not sending things it shouldn't. Wouldn't this be privacy control in the UA? ian: device local control remains, problem is with remote policy management I think Ian's proposal of prototyping something via 3rd party cookies might be a good start and allowing other sites to read from this cookie a user's privacy/policy preferences. See if there is uptake from the industry and then return to the question of whether the UA needs to enforce this interaction. richt, I am sort of doubtful that sites will take it up. The idea behind the rulesets is that users take the incentives they already have and act on them, which might induce sites to change their policies. Sites do not have the incentive to make the first move. See, e.g., P3P. richt, his proposal can be translated into - let's see if sites that are proactively interested in addressing privacy will join in some new system, but the privacy concern arises with sites that are indifferent or harmful to privacy what she said ian: having the permissions requested up front is very much prefereable ... putting them into a manifest (similar to widgets manifest) dom: We are defining a set of features that can be used to request functionality/access to data tlr: Upfront permission request has usability cost similar to setting policy up front, comments? ian: Will keeping request/update close to actual task (e.g. at app store, or by settings inside app). Installing an app is a fairly familiar operation alissa: Can given permissions later be removed. ian: Multiple options, but for some applications it becomdes very difficult (combinatorial problem for complex apps) dom: Has user interaction been settled on? ian: partially (shown at Google IO), currently similar to installing Android apps. issue create api that allows agreeing to permissions up front fjh: can we have both policy/UI approach at the same time ian: yes (different use cases e.g. enterprise vs big internet) dom: would Chrome be interested in implementing settable policies? ian: current focus on consumer, if that is solved first enterprise UC can be solved later paddy: There is a misconcpetion that having policy avoids the need to have privacy/security baked into APIs. Must be able to handle ... "no-preconfigured-policy" UC as well as having possibility for preconfiguring some policy options. fjh: (Summary of Child Protection Center visit). ceop already provides browser integration via extensions. e.g. [https://addons.mozilla.org/en-US/firefox/addon/161843/][21] tlr: are there currently requirements that came out of CEOP meeting? fjh: see a potential use of parent settable policies as useful fjh; (wrap up) [http://lists.w3.org/Archives/Public/public-device- apis/2010Jul/0080.html][3] Agenda update - capture moved to Friday morning API session ### Sysinfo API updateSysinfo API update ### Sysinfo API update Scribenick: ilkka Scribenick: ilkka_ bryan_sullivan: new input from john to privacy section [http://dev.w3.org/2009/dap/system-info/][22] AnssiK: would be useful to try to think of user-understandable names for the groups - this may help in getting consistent UI across UA update to security and privacy considerations - [http://dev.w3.org/2009/dap/system-info/#security-and-privacy- considerations][23] bryan_sullivan: API functions are now grouped to 3 groups darobin: groups are problematic, they can be considered as implementation details (please let's not do "must" in 3.2 recipients) fjh: whether sections are normative or informational should be marked clearly group noted it was agreed to put common material like 3.2 into best practices jmorris: thought that it is requirment that there are three different permission groups ... three buckets should be defined in normative section dom: three groups should be the minimum for UAs bryan_sullivan: would like to see actual proposal from others ... section 3.2 is removed ... group "all" is removed ... normative language will be enhanced jmorris: section 4 could be divided to three part per three buckets s/^ // AnssiK: is URI string case-insensitive? bryan_sullivan: groups should have proper names my proposal was to make all URIs lowercase, i.e. [http://www.w3.org/2009/dap/sysinfo/][24] I suggest "Device Characteristics," "Network Characteristics," and "Sensor Results" for the three buckets ...each of the three buckets will be wrapped in tags right and referred to throughout the spec? jmorris: capture API is separate from these three buckets AnssiK: URIs in the specifications should be consistent, e.g. everything lower-case [http://lists.w3.org/Archives/Public/public-device- apis/2010Jul/0058.html][25] dom: we should first check which kind of naming conventions are used in Android — apparently they're using constants, so maybe our string solutions is better, but we should check if there was a conscious decision behind their choice robin: we don't want to enforce x-* as the extension prefix, we want vendors extensions to use vendor prefixes (e.g. att-*) "document origin" should be innermost document origin (using whatever terminology HTML 5 uses to express that) suggested wording "Identifiers may begin with '-' (dash). Names beginning with '-' are reserved for vendor-specific extensions. Such vendor- specific extensions should have the following format: '-' + vendor identifier + '-' + meaningful name." alissa: unclear what document origin means here. "URIs in general are case-sensitive. There may be URIs, or parts of URIs, where case doesn't matter (e.g., machine names), but identifying these may not be easy. Users should always consider that URIs are case-sensitive (to be on the safe side)." [http://www.w3.org/TR/html4/types.html][26] there's more wording for potential theft at [http://www.w3.org/TR/CSS2/syndata.html#vendor-keywords][27] bryan_sullivan: is the term "the document" clearly defined in this context? proposal: maybe use something like 'parent document origin' or 'child document origin'? [http://ietherpad.com/T3KEXexcQg][28] wmaslowski: let's use term "document" in same way as Geolocation uses it perhaps also the names of all the propertyIds should be all lowercase in addition to their URIs (ietherpad will be used to fine-tune the section in question) jmorris: watching use case is potentially problematic, timeout functionality would help the situation darobin: difficult to agree on timeout values i agree - add guidelines only tlr: other consern is multicore CPUs, do they fit to current API? ... algorithm to calculate properties in multicore case is needed ... informative text is enough L U N C H . davidrogers: "the APIs defined in this specification are intended to collect qualitative samples of the data" should be removed I'm on the queue (!) and I also to ask whether the API should must support: get(a,b,d) no problem, thanks are we starting yet:-) Scribenick: Claes [http://ietherpad.com/T3KEXexcQg][28] tlr: If nesting browsing content is different you should not need a separate permission. This issue is described in Ian Fette's input paper to the privcy workshop (I wonder: if an attacker was able to introduce an iframe in a "trusted" page, and load in that iframe a page that triggers a script with a given API, wouldn't the attacker gain access to the said API?) (maybe this doesn't matter; i.e. once you're in a position to insert an iframe, all the bets are off?) consumer vs marketer privacy expectations differ - [http://www.umass.edu/loop/talkingpoints/articles/105279.php][29] "Milne also says the issue of privacy management is important because businesses and marketers who violate consumer trust with what are perceived to be intrusive or dishonest practices can quickly lose customers. " ### Messaging API [http://dev.w3.org/2009/dap/messaging/][30] Daniel Coloma is presenting the Messaging API specification New version July 15 Iterfaces split for different messaging technologies Also added APIs for listing messages Added methods for folder management Missing messaging life cycle, e.g. moving messages between different folders Daniel see security issues with folder managent Outlook allows you to move messages to arbitrary folders which i don't personally like Robin: One option is to leave this to implementation (for instance, Android haven't made their SMS Content Provider part of the official API, partly because they're not ready to cast it in stone; probably a sign this isn't exactly trivial) [http://tools.ietf.org/html/draft-dusseault-httpmail-00][31] (expired draft) Tlr: Option 1: Model according to imap. Option 2: Entirely different, e.g., accessing email by http, base on search, labels, etc ... What can we do quickly, within DAP timeline? FWIW, I much prefer the previous version of the Messaging API: [http://dev.w3.org/cvsweb/~checkout~/2009/dap/messaging/Overview.html?rev=1.17 #widl-MessagingManager-createSMS][32] Tlr: basical Send... Nwidell: If we just stick to Send we don't add much compared to what we have today. I think folder management can be easily separated from access/create/send Nwidell: If we don't have folders we have no view of messages sent Dom: Need some middle way between just sending and advanced folder management. Look at use cases and evaluate complexity Robin: Don't need move unless you create a complete messaging client application Nwidell: Main issue with only having notifications is then I can't retrieve messages. Robin: Yes, you could. For example, get a permanent ID that could be used to retrieve the message later. or perhaps notifications with just the message type is good, and the implementation can show the relevant folder based on the type Paddy: refers to JSR 120 and 205 [JSR 120 Wireless Messaging API for Java ME][33] Bryan: Use same way as for Sys Info for permissions dropping off the call/IRC - regrets Nwidell: Wants to some fine grained permission system Suresh, you won't be about for Calendar and Contacts discussion coming up next? Filering: e-mailadresses are clear and easy to read but phone numbers more difficult for users s /filering/filtering Security parts need more work Nwidell: Folder management between special folders most interesting. Robin: Should we separate basic Send and Receive from folder management in separate documents? ... Keep simple minimal functionality in one specification +1 Robin, Most applications want to send a message not to read a message from folder. Proposal to cut out folder management and publich first public draft **ACTION:** Maria to draft a security section for Messaging [recorded in [http://www.w3.org/2010/07/15-dap-minutes.html#action03][34]] Created ACTION-221 - Draft a security section for Messaging [on Maria Angeles Oteo - due 2010-07-22]. Tlr volonters to review **ACTION:** tlr to review the Messaging security section [recorded in [http://www.w3.org/2010/07/15-dap-minutes.html#action04][35]] Created ACTION-222 - Review the Messaging security section [on Thomas Roessler - due 2010-07-22]. Basic specification contins Send and Receive mesages ACTION-222: triggers when ACTION-221 completed ACTION-222 Review the Messaging security section notes added "there is an ontology for that" Richard: If we take away folders we should go back to previous version and build on that Robin: SonyEricsson found issues with previous version n Prague. PROPOSED RESOLUTION: Split Messaging, try to reach FPWD with just create/send/receive ASAP; have a separate MessageFinder API mirroring Contacts and Gallery; build folder management on top of that +1 RESOLUTION: Split Messaging, try to reach FPWD with just create/send/receive ASAP; have a separate MessageFinder API mirroring Contacts and Gallery; build folder management on top of that Separate APIs for SMS, MMS and email or do we have a unified concept? Robin: For Find a unified view ... For Receive a separate view makes more sense. richt, you wanted to suggest that we publish revision 1.17 as the FPWD > [http://dev.w3.org/cvsweb/~checkout~/2009/dap/messaging/Overview.html?rev=1. 17][36] ### Contacts API richt: serviceId is not really necessary, and in returning data from composite sources it is complicated contacts changes, see CVS log at [http://dev.w3.org/cvsweb/2009/dap/contacts/Overview.html][37] richt: the absence of serviceId does not prevent sync ScribeNick: FanH dong-young: some applications need to know where contacts are stored, e.g. network address book, SIM card, etc. richt: 3rd party developers dont need to know where information is store, create a wall between diffrent applications darobin: similarities to moving msgs between folders in message API richt: user interactions can be used save contacts to different locations, e.g. choose 'save', 'save to' **RESOLUTION: remove serviceId** bryan: the resolution does prevent using ServiceID in another API in future richt: in case address book could dont provide all the field, it is up to the apps to fill the gaps ... the proposal is to access address book info from HTML5 device element robin: Device Element is highly unstable Add integration to 'future work' section? dom: we can be either reactive or proactive on the device element, which option should we take? robin: concern is that device element is a HTML5 object **ACTION:** Robin to pick up the thread on [recorded in [http://www.w3.org/2010/07/15-dap-minutes.html#action05][38]] Created ACTION-223 - Pick up the thread on [on Robin Berjon - due 2010-07-22]. wmaslowski: are we dropping the concept with integrating with HTML5 darobin: powerbox evaluation consider this, however we need concrete proposals **ACTION:** Wojciech to look into options for contacts API - due +3 weeks [recorded in [http://www.w3.org/2010/07/15-dap- minutes.html#action06][39]] Created ACTION-224 - look into options for contacts API [on Wojciech Maslowski - due 2010-08-05]. darobin: if we have , we don't have to deal with revocation ... and the user interaction workflow is simpler ... if not, we probably need a requirement for revocation ... and we need to understand how the infobar interaction relates to multiple API calls darobin: if we have , find() would be kept to privileged access apps richt: switch to topic - serialisation of interactions with the user ... introduced a FIFO mechanism, only deals with one method invoke at a time the question is should it be FIFO or LIFO? dong-young: is operations needs to wait for the previous one to complete, what happens if you have to save 100 contacts? ric richt: want dont allow 'save' in the current spec, for 'find' it should not be a problem darobin: we'd better consider future issues before we publish the first release dong-young : with only pending user auth, we'd use serialization. wonsuk: believe it is the responsibility of the javascript engine to do resource blocking bryan: need a synch on security sections of the APIs discussed [API Check List][40] dom: what import is to have a common 'framework' - things need to consider for the security section **ACTION:** Dom to look at a common analysis grid for security/privacy across APIs [recorded in [http://www.w3.org/2010/07/15-dap- minutes.html#action07][41]] Created ACTION-225 - Look at a common analysis grid for security/privacy across APIs [on Dominique Hazaël-Massieux - due 2010-07-22]. nwidell: save conacts to different address books which may handle things differently, are we comfortable enough to mandate behaviors? agenda item changes for tomorrow - coordination topic before 11am, checklist/review of API and document status richt: switch to 'stale object' issue darobin: concerned about the current proposal where address book information needs to be constantly pulled basically, the 'stale object' issue says, if I collect Contacts via a find(...) call, then another app calls save(...) and remove(...) on the same objects, the original objects are out of sync nwidell: concerned about fragmentation as functionatilites are splitted into different releases For the first version it should be enough to say that stale data is an issue with contacts data and give recommendations to minimise the problems it causes. Most importantantly: Avoid contacts data caching inside the app and do not pre-fetch contacts before they are really consumed. Presence+ Dong-Young_Lee darobin: we do additons to APIs only, e.g. reading only version APIs should not be broken by the succeeding version which supports writing one solution suggested for 'stale objects' was we could create an event listener that listens for Contact object updates and takes any necessary action accordingly, rather than parts of the proposal @ [http://lists.w3.org/Archives/Public/public-device-apis/2010Jun/0194.html][42] ACTION-225: started in [http://www.w3.org/2009/dap/wiki/ApiCheckList#Pri vacy_.26_Security_Considerations][43] ACTION-225 Look at a common analysis grid for security/privacy across APIs notes added ...such a solution could be added at a later time without breaking any existing Contacts 'read' spec ACTION-215? ACTION-215 -- Dominique Hazaël-Massieux to write up issues with write/delete access for Contacts APIs -- due 2010-07-21 -- OPEN [http://www.w3.org/2009/dap/track/actions/215][44] proposed updated agenda for tomorrow - [http://www.w3.org/2009/dap/agendas/2010-07-15.txt][45] bryan: this is a general topic across all APIs, we need to have a consistent approach to "updating" ACTION-215: this should serve as a starting point for write/update/delete access across APIs ACTION-215 Write up issues with write/delete access for Contacts APIs notes added **RESOLUTION: We splict contact into 'read' and 'write'** s/splict/split/ [Calendar API][46] New topic: calendar API s/New topic/Topic/ TimezonedDate: [http://lists.w3.org/Archives/Public/public-device- apis/2010Apr/0051.html][47] [discussion on option 1 vs option 2 in richt's email above] PROPOSED RESOLUTION: we release a spec of TimezonedDate extending ECMA Date object **RESOLUTION: we agreed to go for option 2** s/we agreed to go for option 2/we release a spec of TimezonedDate extending ECMA Date object/ **ACTION:** richard to start TimezonedDate spec [recorded in [http://www.w3.org/2010/07/15-dap-minutes.html#action08][48]] Created ACTION-226 - Start TimezonedDate spec [on Richard Tibbett - due 2010-07-22]. Recurring events: [http://lists.w3.org/Archives/Public/public-device- apis/2010Mar/0130.html][49] **ACTION:** Dom to compare iCalendar recurrence model with current Calendar API [recorded in [http://www.w3.org/2010/07/15-dap- minutes.html#action09][50]] Created ACTION-227 - Compare iCalendar recurrence model with current Calendar API [on Dominique Hazaël-Massieux - due 2010-07-22]. [iCalendar Transport-Independent Interoperability Protocol (iTIP)][51] tlr: our aim is to specify objects that are compatible with RFC 5546 **ACTION:** thomas to ping Cyrus Daboo re Calendar API - due 2010-07-31 [recorded in [http://www.w3.org/2010/07/15-dap-minutes.html#action10][52]] Created ACTION-228 - ping Cyrus Daboo re Calendar API [on Thomas Roessler - due 2010-07-31]. **ACTION:** Rich to go through [http://tools.ietf.org/html/rfc5546][51] and ensure the bindings provided map [recorded in [http://www.w3.org/2010/07/15-dap-minutes.html#action11][53]] Sorry, couldn't find user - Rich **ACTION:** richt to go through [http://tools.ietf.org/html/rfc5546][51] and ensure the bindings provided map [recorded in [http://www.w3.org/2010/07/15-dap-minutes.html#action12][54]] Created ACTION-229 - Go through [http://tools.ietf.org/html/rfc5546][51] and ensure the bindings provided map [on Richard Tibbett - due 2010-07-22]. dom: what calendar API does is to create ICS file that can be saved to the application dom: this relates to the app launcher api discussion: instead of launching application, you could create file-like objects with a media type that triggers the opening of the relevant application **ACTION:** Wojciech to specify "add to calendar" based on ICS-objects opening [recorded in [http://www.w3.org/2010/07/15-dap- minutes.html#action13][55]] Created ACTION-230 - Specify "add to calendar" based on ICS-objects opening [on Wojciech Maslowski - due 2010-07-22]. (I think the basic idea that we've discussed is allowing lunisolar calendar for non-recurrent events or limited-recurrent events) tlr: raised the lunar calendar issue, need to be compatible with existing systems. Liase with IETF This was my proposal (with limitation) for supporting luni-solar in the Calendar API: [http://lists.w3.org/Archives/Public/public-device- apis/2010Mar/0183.html][56] [http://www.w3.org/2009/dap/agendas/2010-07-15.txt][45] dom: the issue is largely with recurring events looks like outlook doesn't support recurring lunar events: [http://calendarswamp.blogspot.com/2005/08/outlook-2003-for-ical-import- use.html][57] yes it is ilkka_, good finding! dom: yep, that error message is pretty clear might be that nobody has solved ical lunar recurring problem [based on experimentation, it looks like Outlook does support recurring events in Lunar calendars, but can't export them] ### PowerBox/REST scribeNick: danielcoloma fjh: powerbox may be one solution to get user consent, but not the only one [announce a more recent powerbox draft (May 26, 2010)][58] ### Powerbox darobin: Many APIs specs state that if there is a pre-arranged trust relationship, the API is exposed ... Powerbox may address that trust relationship tyler: is there any interest in using Powerbox in any of the current specs (has powerbox been moved to dap cvs space? I think Tyler hasn't been nominated to the group yet) darobin: Contacts could be the easier one to start with [Contacts API editors draft][59] darobin: is Powerbox in CVS? tyler: not yet darobin: in order to do so you need to be nominated as participant in the WG Latest PB submission: [http://lists.w3.org/Archives/Public/public- device-apis/2010May/0133.html][58] darobin: Making it available in the CVS will simplify interactions in the WG ... please also use mailing list to have open discussions ... any other further update? tyler: second prototyping phase, when there is a powerbox request ... the user needs to select the provider. ... Small changes to the powerbox API. ... Will send an update to the list when the changes are stabilized. darobin: has there been any presentation in a Scandinavian fora? Claes: I did a presentation in which I mentioned the W3C DAP activities and the Powerbox contribution for REST based APIs ... We have done a JavaScript implementation for accessing the camera **ACTION:** Claes to look into what he can share re javascript-based android prototype of PowerBox [recorded in [http://www.w3.org/2010/07/15-dap- minutes.html#action14][60]] Created ACTION-231 - Look into what he can share re javascript- based android prototype of PowerBox [on Claes Nilsson - due 2010-07-22]. darobin: it would be great if you could share it with the group (great news, re incorporating of UMP in CORS! I hadn't followed that thread :) darobin: are you interested in a FPWD and what level of stability is needed before doing it? asked about status of UMP and previous issues related to it and CORs, response that CORS will either include all UMP functionality or UMP alone will be available, and that UMP functionality will be in webkit and firefox implemeneetations thus making this non an issue for concern with respect to Powerbox tyler: Powerbox looks like feature complete, but would prefer to see some specs using Powerbox (I'm not the model of user interactions we are building is actually compatible with PowerBox; but that's what we can find out with doing the match between Contacts and PowerBox, obviously) robin notes we can start with contacts and then gallery in the powerbox context (I think geolocation could be another candidate for PowerBox evaluation) darobin: The plan would be then, first of all uploading the spec to the CVS, adapting the contacts API to use Powerbox and assess if we could go then to a Powerbox FPWD bsullivan: Have you assessed the possibility of using Powerbox for FileSystem API? s/adapting the contacts API/seeing how the contacts API would be fit/ tyler: no, but it looks like a good idea. ... in general Powerbox is suitable for APIs that provide access to device resources action - tyler to join DAP WG, then arrange to upload powerbox to DAP CVS Sorry, couldn't find user - - dom: Who will be doing the analysis between Contacts and Powerbox? ACTION-96? ACTION-96 -- Robin Berjon to rewrite existing examples as PowerBox -- due 2010-03-03 -- CLOSED [http://www.w3.org/2009/dap/track/actions/96][61] **ACTION:** Robin to coordinate with Tyler on exposing Contacts through Powerbox [recorded in [http://www.w3.org/2010/07/15-dap- minutes.html#action15][62]] Created ACTION-232 - Coordinate with Tyler on exposing Contacts through Powerbox [on Robin Berjon - due 2010-07-22]. tyler: I can do it in conjunction with any other DAP member ACTION-232: follow-up of ACTION-96 ACTION-232 Coordinate with Tyler on exposing Contacts through Powerbox notes added ACTION-232 due +3 weeks ACTION-232 Coordinate with Tyler on exposing Contacts through Powerbox due date now +3 weeks fjh: We are still assessing policy and privacy lauraA: It looks like Powerbox could be compatible with the policy framework tyler: when a resource is trying be to accessed, two parameters are passed ... customer and recquisition (the policy framework also relies on environment contexts and parameters of the requisition) s/recquisition/requisition ISSUE: How do Powerbox and Policy interact and integrate Created ISSUE-94 - How do Powerbox and Policy interact and integrate ; please complete additional details at [http://www.w3.org/2009/dap/track/issues/94/edit][63] . dom: Once the documents are available in the CVS and we known how Powerbox maps with one API we can revisit the policy/security issue fjh: One possible item about privacy that is interesing is allowing users to indicate which resources he does not want to allow access to [Aza's 2nd take on privacy icons][64] [http://www.flickr.com/photos/azaraskin/4796824084/sizes/l/][65] ## Summary of Action Items **[NEW]** **ACTION:** Bryan to make a concrete proposal for AppLauncher [recorded in [http://www.w3.org/2010/07/15-dap-minutes.html#action02][17]] **[NEW]** **ACTION:** Claes to look into what he can share re javascript-based android prototype of PowerBox [recorded in [http://www.w3.org/2010/07/15-dap- minutes.html#action14][60]] **[NEW]** **ACTION:** Dom to compare iCalendar recurrence model with current Calendar API [recorded in [http://www.w3.org/2010/07/15-dap- minutes.html#action09][50]] **[NEW]** **ACTION:** Dom to look at a common analysis grid for security/privacy across APIs [recorded in [http://www.w3.org/2010/07/15-dap- minutes.html#action07][41]] **[NEW]** **ACTION:** Kangchan to make a concrete proposal for AppLauncher [recorded in [http://www.w3.org/2010/07/15-dap-minutes.html#action01][16]] **[NEW]** **ACTION:** Maria to draft a security section for Messaging [recorded in [http://www.w3.org/2010/07/15-dap-minutes.html#action03][34]] **[NEW]** **ACTION:** Rich to go through [http://tools.ietf.org/html/rfc5546][51] and ensure the bindings provided map [recorded in [http://www.w3.org/2010/07/15-dap-minutes.html#action11][53]] **[NEW]** **ACTION:** richard to start TimezonedDate spec [recorded in [http://www.w3.org/2010/07/15-dap-minutes.html#action08][48]] **[NEW]** **ACTION:** richt to go through [http://tools.ietf.org/html/rfc5546][51] and ensure the bindings provided map [recorded in [http://www.w3.org/2010/07/15-dap-minutes.html#action12][54]] **[NEW]** **ACTION:** Robin to coordinate with Tyler on exposing Contacts through Powerbox [recorded in [http://www.w3.org/2010/07/15-dap- minutes.html#action15][62]] **[NEW]** **ACTION:** Robin to pick up the thread on [recorded in [http://www.w3.org/2010/07/15-dap-minutes.html#action05][38]] **[NEW]** **ACTION:** thomas to ping Cyrus Daboo re Calendar API - due 2010-07-31 [recorded in [http://www.w3.org/2010/07/15-dap- minutes.html#action10][52]] **[NEW]** **ACTION:** tlr to review the Messaging security section [recorded in [http://www.w3.org/2010/07/15-dap-minutes.html#action04][35]] **[NEW]** **ACTION:** Wojciech to look into options for contacts API - due +3 weeks [recorded in [http://www.w3.org/2010/07/15 -dap-minutes.html#action06][39]] **[NEW]** **ACTION:** Wojciech to specify "add to calendar" based on ICS- objects opening [recorded in [http://www.w3.org/2010/07/15-dap- minutes.html#action13][55]] [End of minutes] * * * Minutes formatted by David Booth's [scribe.perl][66] version 1.135 ([CVS log][67]) $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/2010Jul/0080.html [4]: #agenda [5]: #item01 [6]: #item02 [7]: #item03 [8]: #item04 [9]: #item05 [10]: #item06 [11]: #item07 [12]: #item08 [13]: #ActionSummary [14]: http://www.w3.org/TR/widgets-apis/#the-openurl-method [15]: http://www.w3.org/TR/2010/WD-html5-20100304/webappapis.html#dom- navigator-registerprotocolhandler [16]: http://www.w3.org/2010/07/15-dap-minutes.html#action01 [17]: http://www.w3.org/2010/07/15-dap-minutes.html#action02 [18]: http://alissacooper.com/files/w3c-simple-privacy-policies.pdf [19]: http://lists.w3.org/Archives/Public/www-archive/2010Jul/att-0121/w3c- simple-privacy-policies.pdf [20]: http://lists.w3.org/Archives/Public/public-device- apis/2010Jul/att-0082/app-launch_20100716_.pdf/ [21]: https://addons.mozilla.org/en-US/firefox/addon/161843/ [22]: http://dev.w3.org/2009/dap/system-info/ [23]: http://dev.w3.org/2009/dap/system-info/#security-and-privacy- considerations [24]: http://www.w3.org/2009/dap/sysinfo/ [25]: http://lists.w3.org/Archives/Public/public-device- apis/2010Jul/0058.html [26]: http://www.w3.org/TR/html4/types.html [27]: http://www.w3.org/TR/CSS2/syndata.html#vendor-keywords [28]: http://ietherpad.com/T3KEXexcQg [29]: http://www.umass.edu/loop/talkingpoints/articles/105279.php [30]: http://dev.w3.org/2009/dap/messaging/ [31]: http://tools.ietf.org/html/draft-dusseault-httpmail-00 [32]: http://dev.w3.org/cvsweb/~checkout~/2009/dap/messaging/Overview.html?rev=1.17 #widl-MessagingManager-createSMS [33]: http://jcp.org/aboutJava/communityprocess/final/jsr120/ [34]: http://www.w3.org/2010/07/15-dap-minutes.html#action03 [35]: http://www.w3.org/2010/07/15-dap-minutes.html#action04 [36]: http://dev.w3.org/cvsweb/~checkout~/2009/dap/messaging/Overview.html?rev=1.17 [37]: http://dev.w3.org/cvsweb/2009/dap/contacts/Overview.html [38]: http://www.w3.org/2010/07/15-dap-minutes.html#action05 [39]: http://www.w3.org/2010/07/15-dap-minutes.html#action06 [40]: http://www.w3.org/2009/dap/wiki/ApiCheckList [41]: http://www.w3.org/2010/07/15-dap-minutes.html#action07 [42]: http://lists.w3.org/Archives/Public/public-device- apis/2010Jun/0194.html [43]: http://www.w3.org/2009/dap/wiki/ApiCheckList#Privacy_.26_Security_Con siderations [44]: http://www.w3.org/2009/dap/track/actions/215 [45]: http://www.w3.org/2009/dap/agendas/2010-07-15.txt [46]: http://dev.w3.org/2009/dap/calendar/ [47]: http://lists.w3.org/Archives/Public/public-device- apis/2010Apr/0051.html [48]: http://www.w3.org/2010/07/15-dap-minutes.html#action08 [49]: http://lists.w3.org/Archives/Public/public-device- apis/2010Mar/0130.html [50]: http://www.w3.org/2010/07/15-dap-minutes.html#action09 [51]: http://tools.ietf.org/html/rfc5546 [52]: http://www.w3.org/2010/07/15-dap-minutes.html#action10 [53]: http://www.w3.org/2010/07/15-dap-minutes.html#action11 [54]: http://www.w3.org/2010/07/15-dap-minutes.html#action12 [55]: http://www.w3.org/2010/07/15-dap-minutes.html#action13 [56]: http://lists.w3.org/Archives/Public/public-device- apis/2010Mar/0183.html [57]: http://calendarswamp.blogspot.com/2005/08/outlook-2003-for-ical- import-use.html [58]: http://lists.w3.org/Archives/Public/public-device- apis/2010May/0133.html [59]: http://dev.w3.org/2009/dap/contacts/ [60]: http://www.w3.org/2010/07/15-dap-minutes.html#action14 [61]: http://www.w3.org/2009/dap/track/actions/96 [62]: http://www.w3.org/2010/07/15-dap-minutes.html#action15 [63]: http://www.w3.org/2009/dap/track/issues/94/edit [64]: http://www.flickr.com/photos/azaraskin/4796824084/ [65]: http://www.flickr.com/photos/azaraskin/4796824084/sizes/l/ [66]: http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm [67]: http://dev.w3.org/cvsweb/2002/scribe/