See also: IRC log
<trackbot> Date: 14 April 2010
<darobin> ah
<fjh> ScribeNick: ilkka
<fjh> 13-15 July 2010 F2F, London
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2010Apr/0019.html
fjh: 13-15 July is still the proposed date
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2010Apr/0029.html
<fjh> 7 April 2010
robin: email thread started about the bug in ReSpec, be aware of that
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2010Apr/att-0015/minutes-2010-04-07.html
<fjh> proposed RESOLUTION: minutes from 7 April approved
RESOLUTION: minutes from 7 April approved
<fjh> rulesets draft http://www.cdt.org/temp/privacy-rulesets.html
alissa: three elements: sharing, secondaty use and retention
... most important things covered
<fjh> suggest we need section noting that URIs will be associated with ruleset and conveyed
alissa: for elements set of attributes are defined
<dom> Frederick's comments
<dom> +1 on separating the ontology and the format for the time being
<jmorris> 2. For secondary use, 3.2, I do not understand why delivering ads is considered contextual or desired by the user. If I want a reminder of an event, ads are not part an inherent part of that interaction (or is the suggestion that they are in order to pay for it?) Isn't this the marketing-or-profiling category?
jmorris: Frederick has valid question about contextual ads, are they part of secondary use
<fjh> s/^marketing-or-profiling catego//
<fjh> s/^the suggestion that they are in order to pay for it?) Isn't this the //
<fjh> s/^an event, ads are not part an inherent part of that interaction (or is//
<fjh> s/^considered contextual or desired by the user. If I want a reminder of//
<dom> (my calculation was that the current attributes make for 432 possible options)
<fjh> s/^2. For secondary use, 3.2, I do not understand why delivering ads is//
jmorris: simplicity is essential
<fjh> john noted re point #2 that ads could be considered not contextual use but included for pragmatic reasons to enable adoption
<maoteo> maria present
<fjh> richard asks about how rulesets will be interpreted by various parties in workflow
<fjh> alissa notes that policy might not have an impact on law enforcement
<fjh> we might need a side note as to when rulesets might not be followed.
<fjh> richard notes that best practices for selection of profiles is needed
richt: it's must be logical for people to select the groups of data collectors that can get the information
<richt> The suggestion is that profiles are really the business end of privacy. Millions of developers are going to have to be able to choose a profile or ruleset that defines their service...
fjh: are there privacy glossary somewhere what we can reference
<richt> The suggestion is that privacy rulesets could be group centric (e.g. internal (service) usage, public access, 3rd-parties, law enforcement)...
<richt> which may allow people to logically 'follow their data' and digest and understand the data being provided...
<richt> ...to different entities.
<fjh> Privacy Requirements
p3p mentioned as an option
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2010Apr/0016.html
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2010Apr/0020.html
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2010Apr/0030.html
<dom> Dom: fwiw, I agree we should continue working on the document to get a better idea of the scope, but I'm still concerned about the amount of specification work that specifying the whole of this would require
<fjh> Laura agrees we should review scope of material of document
<fjh> to be used
fjh: next steps to be agreed on the mailing list
darobin: Messaging API CfC ongoing
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2010/0027.html
darobin: Comments received from Suresh
<maxf> +1
<dom> Dom: suresh made a point about the scope missing message management
<dom> ... given that FPWD is about scoping
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2010Apr/0018.html
<dom> ... I'm concerned that we don't have even a sketch of what this would be for FPWD
robin: first public draft for Messaging will be delayed
<maxf> … until we figure out whether to add Message Management to the specification
<darobin> proposed RESOLUTION: Messaging FPWD delayed until we have full scope
robin: main missing features are mailboxes, filtering and searching
<darobin> ACTION maxf to list scope of remaining work on Messaging before FPWD
<trackbot> Created ACTION-160 - List scope of remaining work on Messaging before FPWD [on Max Froumentin - due 2010-04-21].
<Zakim> dom, you wanted to suggest maybe splitting work?
dom: alternative option is to split messaging spec into two parts
<fjh> deciding on whether to split depends on time required for the additional decisions and work?
darobin: I want to see proposal first before deciding
<Zakim> fjh, you wanted to ask about time frame
maxf: probably it will not take long time to come up with the needed additions
<darobin> ACTION: maxf to make a proposal for Message Management, including whether it would be split from the main spec or not [recorded in http://www.w3.org/2010/04/14-dap-minutes.html#action01]
<trackbot> Created ACTION-161 - Make a proposal for Message Management, including whether it would be split from the main spec or not [on Max Froumentin - due 2010-04-21].
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2010Apr/0044.html
<fjh> ISSUE-79?
<trackbot> ISSUE-79 -- Fingerprinting privacy issue related to sysinfo, need for feedback on privacy risk -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/issues/79
<fjh> related to minimization
maxf: comment is about access control and minimization
<dom> API Checklist
robin: minimization is not specific issue to SysInfo
dom: check list is mainly for the last call
maxf: orientation comment is tricky to solve
... more people should review the sections in SysInfo they are interested
darobin: last call will wake up people
<darobin> RESOLUTION: Publish a heartbeat WD of Sysinfo
<darobin> ACTION Robin to make SysInfo ready for pub
<trackbot> Created ACTION-162 - Make SysInfo ready for pub [on Robin Berjon - due 2010-04-21].
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2010Apr/0043.html
robin: calendar problems are challenging
<richt> http://lists.w3.org/Archives/Public/public-device-apis/2010Mar/0183.html
<fjh> dom suggests proposal - only gregorian for recurrence
dom: I support Richard's proposal of not supporting non-Gregorian calendars for recurrence
<fjh> dom suggests deferring more complicated approach to v2
<richt> http://lists.w3.org/Archives/Public/public-device-apis/2010Mar/0176.html
richt: time for decisions
<dom> dom: we could support only bounded-recurrence for non-Gregorian calendars
robin: summary mail should be generated
<darobin> ACTION Robin to email i18n about the various options for calendaring
<trackbot> Created ACTION-163 - Email i18n about the various options for calendaring [on Robin Berjon - due 2010-04-21].
<dom> ... (i.e. in cases where there is only a finite number of events to be stored)
richt: some progress made offline
... Should DAP extend ECMA Date object? Open question
darobin: File API: system and directories is progressing nicely
<darobin> please review :)
<richt> richt: would be useful to resolve a couple of key issues (i.e. timezones and non-gregorian calendar support) on the mailing list this week for a semi-stable editor's draft to be published for the Calendar API...
<richt> I'd like to do this before next call.
robin: meeting adjourned
<wonsuk> bye. Thanks.
<maoteo> ;)