<fjh> trackbot-ng, start telecon
<trackbot> Date: 15 July 2010
<Dong-Young> Presence+ Dong-Young_Lee
<nwidell> scribenick: nwidell
<fjh> Agenda modification, start with app launcher API instaead of privacy/policy
(slides describing the App Launcher API shown)
(insert reference to slides here)
<AnssiK> for widget.openURL(), see http://www.w3.org/TR/widgets-apis/#the-openurl-method
fjh: How will API realte to policy/privacy?
<fjh> 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
<Zakim> 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)
<tlr> 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
<tlr> 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
<Zakim> 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
<dom> +1 to richt
<darobin> +1 indeed
richt: Do we really need an javascript API for this. Android has intents
<fjh> 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
<dom> (Android uses URIs for Intents as well, IIRC)
<darobin> [yes it does]
<dom> (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"
<AnssiK> 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
<dom> (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
<fjh> http://www.w3.org/TR/widgets-apis/#the-openurl-method
dom: Would like to see more info on Use Cases
bryan: Are the existing UCs insufficient?
<soonho> +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?
<darobin> ACTION: Kangchan to make a concrete proposal for AppLauncher [recorded in http://www.w3.org/2010/07/15-dap-minutes.html#action01]
<trackbot> Created ACTION-219 - Make a concrete proposal for AppLauncher [on Kangchan Lee - due 2010-07-22].
<darobin> ACTION: Bryan to make a concrete proposal for AppLauncher [recorded in http://www.w3.org/2010/07/15-dap-minutes.html#action02]
<trackbot> Created ACTION-220 - Make a concrete proposal for AppLauncher [on Bryan Sullivan - due 2010-07-22].
fjh: (summary of yesterday's privacy discussion)
<richt> thanks for the link Anssi. That is particularly interesting also.
fjh: Goal is to actually agree on something
<alissa> http://alissacooper.com/files/w3c-simple-privacy-policies.pdf
<dom> Archived version of Alissa's slides on user privacy policies
(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
<Zakim> 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.
<Kangchan> s/(insert reference to slides here)/http://lists.w3.org/Archives/Public/public-device-apis/2010Jul/att-0082/app-launch_20100716_.pdf/
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
<richt> 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.
<alissa> 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.
<jmorris> 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
<jmorris> 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).
<richt> ceop already provides browser integration via extensions. e.g. https://addons.mozilla.org/en-US/firefox/addon/161843/
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)
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2010Jul/0080.html
<fjh> Agenda update - capture moved to Friday morning API session
<ilkka_> Scribenick: ilkka
<ilkka_> Scribenick: ilkka_
bryan_sullivan: new input from john to privacy section
<fjh> http://dev.w3.org/2009/dap/system-info/
<dom> AnssiK: would be useful to try to think of user-understandable names for the groups - this may help in getting consistent UI across UA
<fjh> update to security and privacy considerations - http://dev.w3.org/2009/dap/system-info/#security-and-privacy-considerations
bryan_sullivan: API functions are now grouped to 3 groups
darobin: groups are problematic, they can be considered as implementation details
<dom> (please let's not do "must" in 3.2 recipients)
fjh: whether sections are normative or informational should be marked clearly
<fjh> 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
<AnssiK> my proposal was to make all URIs lowercase, i.e. http://www.w3.org/2009/dap/sysinfo/
<jmorris> I suggest "Device Characteristics," "Network Characteristics," and "Sensor Results" for the three buckets
<richt> ...each of the three buckets will be wrapped in <dfn> 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
<dom> http://lists.w3.org/Archives/Public/public-device-apis/2010Jul/0058.html
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
<darobin> robin: we don't want to enforce x-* as the extension prefix, we want vendors extensions to use vendor prefixes (e.g. att-*)
<alissa> "document origin" should be innermost document origin (using whatever terminology HTML 5 uses to express that)
<darobin> 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.
<fjh> "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)."
<fjh> http://www.w3.org/TR/html4/types.html
<darobin> there's more wording for potential theft at http://www.w3.org/TR/CSS2/syndata.html#vendor-keywords
bryan_sullivan: is the term "the document" clearly defined in this context?
<richt> proposal: maybe use something like 'parent document origin' or 'child document origin'?
<tlr> http://ietherpad.com/T3KEXexcQg
wmaslowski: let's use term "document" in same way as Geolocation uses it
<AnssiK> 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
<drogersuk> 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
<darobin> L
<darobin> U
<darobin> N
<darobin> C
<darobin> H
davidrogers: "the APIs defined in this specification are intended to collect qualitative samples of the data" should be removed
<richt> I'm on the queue (!) and I also to ask whether the API should must support: get(a,b,d)
<Suresh> no problem, thanks
<Suresh> are we starting yet:-)
<Claes> Scribenick: Claes
<tlr> http://ietherpad.com/T3KEXexcQg
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
<dom> (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?)
<dom> (maybe this doesn't matter; i.e. once you're in a position to insert an iframe, all the bets are off?)
<fjh> consumer vs marketer privacy expectations differ - http://www.umass.edu/loop/talkingpoints/articles/105279.php
<fjh> "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. "
<Suresh> http://dev.w3.org/2009/dap/messaging/
Daniel Coloma is presenting the Messaging API specification
<scribe> 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
<Suresh> Outlook allows you to move messages to arbitrary folders which i don't personally like
Robin: One option is to leave this to implementation
<dom> (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)
<tlr> http://tools.ietf.org/html/draft-dusseault-httpmail-00
<tlr> (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?
<richt> 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
Tlr: basical Send...
Nwidell: If we just stick to Send we don't add much compared to what we have today.
<Suresh> 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.
<Suresh> 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
<dom> JSR 120 Wireless Messaging API for Java ME
Bryan: Use same way as for Sys Info for permissions
<Suresh> dropping off the call/IRC - regrets
Nwidell: Wants to some fine grained permission system
<richt> 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
<soonho> +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
<darobin> ACTION: Maria to draft a security section for Messaging [recorded in http://www.w3.org/2010/07/15-dap-minutes.html#action03]
<trackbot> Created ACTION-221 - Draft a security section for Messaging [on Maria Angeles Oteo - due 2010-07-22].
Tlr volonters to review
<darobin> ACTION: tlr to review the Messaging security section [recorded in http://www.w3.org/2010/07/15-dap-minutes.html#action04]
<trackbot> Created ACTION-222 - Review the Messaging security section [on Thomas Roessler - due 2010-07-22].
Basic specification contins Send and Receive mesages
<tlr> ACTION-222: triggers when ACTION-221 completed
<trackbot> ACTION-222 Review the Messaging security section notes added
<dom> "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.
<darobin> 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
<dom> +1
<darobin> 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.
<Zakim> 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
<darobin> richt: serviceId is not really necessary, and in returning data from composite sources it is complicated
<fjh> contacts changes, see CVS log at http://dev.w3.org/cvsweb/2009/dap/contacts/Overview.html
<darobin> richt: the absence of serviceId does not prevent sync
<inserted> 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
<richt> Add <device> 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
<darobin> ACTION: Robin to pick up the thread on <device> [recorded in http://www.w3.org/2010/07/15-dap-minutes.html#action05]
<trackbot> Created ACTION-223 - Pick up the thread on <device> [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
<dom> ACTION: Wojciech to look into <input type="contacts"> options for contacts API - due +3 weeks [recorded in http://www.w3.org/2010/07/15-dap-minutes.html#action06]
<trackbot> Created ACTION-224 - look into <input type="contacts"> options for contacts API [on Wojciech Maslowski - due 2010-08-05].
<dom> darobin: if we have <input type=contacts>, we don't have to deal with revocation
<dom> ... and the user interaction workflow is simpler
<dom> ... if not, we probably need a requirement for revocation
<dom> ... and we need to understand how the infobar interaction relates to multiple API calls
<dom> darobin: if we have <input type="contacts">, 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
<richt> 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
<hwoo> 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
<darobin> API Check List
dom: what import is to have a common 'framework' - things need to consider for the security section
<dom> 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]
<trackbot> 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?
<fjh> 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
<richt> 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
<ilkka_> 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.
<Dong-Young> 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
<richt> 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
<dom> ACTION-225: started in http://www.w3.org/2009/dap/wiki/ApiCheckList#Privacy_.26_Security_Considerations
<trackbot> ACTION-225 Look at a common analysis grid for security/privacy across APIs notes added
<richt> ...such a solution could be added at a later time without breaking any existing Contacts 'read' spec
<dom> ACTION-215?
<trackbot> ACTION-215 -- Dominique Hazaël-Massieux to write up issues with write/delete access for Contacts APIs -- due 2010-07-21 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/215
<fjh> proposed updated agenda for tomorrow - http://www.w3.org/2009/dap/agendas/2010-07-15.txt
bryan: this is a general topic across all APIs, we need to have a consistent approach to "updating"
<dom> ACTION-215: this should serve as a starting point for write/update/delete access across APIs
<trackbot> ACTION-215 Write up issues with write/delete access for Contacts APIs notes added
RESOLUTION: We splict contact into 'read' and 'write'
<dom> s/splict/split/
<dom> Calendar API
<scribe> New topic: calendar API
<dom> s/New topic/Topic/
<richt> TimezonedDate: http://lists.w3.org/Archives/Public/public-device-apis/2010Apr/0051.html
<dom> [discussion on option 1 vs option 2 in richt's email above]
<dom> PROPOSED RESOLUTION: we release a spec of TimezonedDate extending ECMA Date object
RESOLUTION: we agreed to go for option 2
<dom> s/we agreed to go for option 2/we release a spec of TimezonedDate extending ECMA Date object/
<dom> ACTION: richard to start TimezonedDate spec [recorded in http://www.w3.org/2010/07/15-dap-minutes.html#action08]
<trackbot> Created ACTION-226 - Start TimezonedDate spec [on Richard Tibbett - due 2010-07-22].
<richt> Recurring events: http://lists.w3.org/Archives/Public/public-device-apis/2010Mar/0130.html
<dom> ACTION: Dom to compare iCalendar recurrence model with current Calendar API [recorded in http://www.w3.org/2010/07/15-dap-minutes.html#action09]
<trackbot> Created ACTION-227 - Compare iCalendar recurrence model with current Calendar API [on Dominique Hazaël-Massieux - due 2010-07-22].
<dom> iCalendar Transport-Independent Interoperability Protocol (iTIP)
tlr: our aim is to specify objects that are compatible with RFC 5546
<tlr> 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]
<trackbot> Created ACTION-228 - ping Cyrus Daboo re Calendar API [on Thomas Roessler - due 2010-07-31].
<richt> ACTION: Rich to go through http://tools.ietf.org/html/rfc5546 and ensure the bindings provided map [recorded in http://www.w3.org/2010/07/15-dap-minutes.html#action11]
<trackbot> Sorry, couldn't find user - Rich
<richt> ACTION: richt to go through http://tools.ietf.org/html/rfc5546 and ensure the bindings provided map [recorded in http://www.w3.org/2010/07/15-dap-minutes.html#action12]
<trackbot> Created ACTION-229 - Go through http://tools.ietf.org/html/rfc5546 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> 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
<dom> 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]
<trackbot> Created ACTION-230 - Specify "add to calendar" based on ICS-objects opening [on Wojciech Maslowski - due 2010-07-22].
<dom> (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
<richt> 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
<fjh> http://www.w3.org/2009/dap/agendas/2010-07-15.txt
dom: the issue is largely with recurring events
<ilkka_> looks like outlook doesn't support recurring lunar events: http://calendarswamp.blogspot.com/2005/08/outlook-2003-for-ical-import-use.html
<darobin> yes it is
<dom> ilkka_, good finding!
<ilkka_> dom: yep, that error message is pretty clear
<ilkka_> might be that nobody has solved ical lunar recurring problem
<dom> [based on experimentation, it looks like Outlook does support recurring events in Lunar calendars, but can't export them]
<danielcoloma> scribeNick: danielcoloma
fjh: powerbox may be one solution to get user consent, but not the only one
<dom> announce a more recent powerbox draft (May 26, 2010)
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
<dom> (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
<dom> Contacts API editors draft
darobin: is Powerbox in CVS?
tyler: not yet
darobin: in order to do so you need to be nominated as participant in the WG
<Claes> Latest PB submission: http://lists.w3.org/Archives/Public/public-device-apis/2010May/0133.html
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
<dom> 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]
<trackbot> 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
<dom> (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?
<fjh> 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
<fjh> 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
<dom> (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)
<fjh> robin notes we can start with contacts and then gallery in the powerbox context
<dom> (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?
<dom> 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
<fjh> action - tyler to join DAP WG, then arrange to upload powerbox to DAP CVS
<trackbot> Sorry, couldn't find user - -
dom: Who will be doing the analysis between Contacts and Powerbox?
<dom> ACTION-96?
<trackbot> ACTION-96 -- Robin Berjon to rewrite existing examples as PowerBox -- due 2010-03-03 -- CLOSED
<trackbot> http://www.w3.org/2009/dap/track/actions/96
<darobin> ACTION: Robin to coordinate with Tyler on exposing Contacts through Powerbox [recorded in http://www.w3.org/2010/07/15-dap-minutes.html#action15]
<trackbot> 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
<dom> ACTION-232: follow-up of ACTION-96
<trackbot> ACTION-232 Coordinate with Tyler on exposing Contacts through Powerbox notes added
<dom> ACTION-232 due +3 weeks
<trackbot> 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
<dom> (the policy framework also relies on environment contexts and parameters of the requisition)
s/recquisition/requisition
<darobin> ISSUE: How do Powerbox and Policy interact and integrate
<trackbot> 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 .
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
<darobin> Aza's 2nd take on privacy icons
<dom> http://www.flickr.com/photos/azaraskin/4796824084/sizes/l/