See also: IRC log
<trackbot> Date: 21 April 2010
<scribe> scribenick: Claes
IRC web client updated. New link at DAP page
<fjh> web based IRC client updated http://lists.w3.org/Archives/Member/member-device-apis/2010Apr/0007.html
RESOLUTION: April 14 Minutes approved
<fjh> Privacy rulesets
Alissa: Fine for WD ?
<fjh> Editorial update - ReSpec conversion <http://lists.w3.org/Archives/Public/public-device-apis/2010Apr/0070.html>
Fjh: Wants policy req and ruleset as WD simultaneously
... still some actions on Alissa and John on priv reqs
<fjh> alissa asks if we need to clarify rulesets before FPWD of policy rulesets
<fjh> I suggest we try to have FPWD of both privacy requirements and policy rulesets at same time, ask that focus now on actions related to privacy requiremetns
<trackbot> ACTION-153 -- Alissa Cooper to refine privacy requirements (with John) -- due 2010-04-07 -- OPEN
<trackbot> ACTION-158 -- John Morris to send proposed changes to list re privacy requirements -- due 2010-04-14 -- OPEN
<trackbot> ACTION-112 -- Alissa Cooper to separate privacy requirements on UA from other privacy requirements (on APIs, for user policies, and for best practices for recipients) -- due 2010-03-23 -- OPEN
<fjh> alissa notes privacy requirements on APIs versus UA requirements
Need to define how ruleset is used, not API specific req
<fjh> action-112 closed
<trackbot> ACTION-112 Separate privacy requirements on UA from other privacy requirements (on APIs, for user policies, and for best practices for recipients) closed
<fjh> Privacy section for API documents
<trackbot> ACTION-116 -- Bryan Sullivan to provide input on DCO mapping for SysInfo -- due 2010-03-24 -- OPEN
<darobin> [I note that the editors for the privacy requirements document aren't the right ones]
<fjh> Phrase the temporary privacy section
<trackbot> ACTION-130 -- Richard Tibbett to propose changes to calendar specification to address privacy minimization -- due 2010-03-24 -- OPEN
fjh: FPWD early next month
<fjh> Richard is starting with contacts should be applicable to calendar
Rich: Dealing with "Privacy by design section in contacts. Needs to be dealt with also in cal
Dom: Wants not to bundle policy reqs and rule set
<fjh> goal is to let people know of rulesets and approach
Dom: suggests to publich privacy reqs when done
fjh: Wants to get peoples attention and feedback
<darobin> [feedback from the TAG?]
<fjh> dom suggests getting feedback from html cg, webapps and internally in WG first before FPWD
<fjh> dom notes requirements doc can link to rulesets doc
fjh: Have a problem with publish a req doc with issues and no proposal for a solution.
... Focus more on privacy doc
<fjh> alissa notes need stated requirements on retention, secondary use
Discussion on publishing
<Zakim> dom, you wanted to say he doesn't think we've addressed his concern about scoping
Darobin: Suggest moving Messaging to FPWD
<trackbot> ACTION-161 -- Max Froumentin to make a proposal for Message Management, including whether it would be split from the main spec or not -- due 2010-04-21 -- OPEN
<fjh> suresh asks about supporting inspection, is it the same as message management
<fjh> robin notes yes
Suresh: Message (folder) managment to be included before FPWD?
Suresh suggests that we should wait until Max has made a proposal for message management.
<fjh> s/fjh: Topic APIs//
Daniel: Feedback from Bondi: Decided to merge messaging API and folder management.
<darobin> ACTION daniel to email the list explaining the differences between the successive BONDI approaches to messaging, and why the functionality got merged into a single API
<trackbot> Created ACTION-164 - Email the list explaining the differences between the successive BONDI approaches to messaging, and why the functionality got merged into a single API [on Daniel Coloma - due 2010-04-28].
<fjh> Timezoned dates - http://lists.w3.org/Archives/Public/public-device-apis/2010Apr/0051.html
Calendar Time zones and dates
<dom> (I prefer solution #2 in Richard's summary, but then, that's my proposal :) )
<fjh> didn't we decide earlier that we wanted to be REST compatible in our APIs?
Rich: Two proposals. Need decsion. Blocking cal API.
... Needs feedback on preferred solution.
<dom> [this relates to ISSUE-81]
<dom> (there is more than end and start; recurrence rules, for instance)
Rich: 3rd option, Rich can you state this in IRC?
<darobin> [I agree with Dom's feedback on this one]
<Zakim> dom, you wanted to say we should strive to make developers' life easier, rather than implementers or ourselves
<Suresh> Suresh: A 3rd proposal would be to specify a tz attribute in the Event interface
Dom: We should make a solution that is easier for developers
<darobin> "In case of conflict, consider users over authors over implementors over specifiers over theoretical purity."
Rich: Provide feedback on list
fjh: Implications on a RESTful approach?
Darobin: Not a big deal
<dom> (and bring it to public-script-coord as well)
Darobin: Suggest put a draft up wth option 2 and get feedbac
<darobin> ACTION Robin to take the TZDate discussion to public-script-coord
<trackbot> Created ACTION-165 - Take the TZDate discussion to public-script-coord [on Robin Berjon - due 2010-04-28].
<trackbot> ACTION-163 -- Robin Berjon to email i18n about the various options for calendaring -- due 2010-04-21 -- OPEN
Blocking factors for Cal is timezone issues and internatioization (Gregorian etc)
<dom> storage for Web APIs
Dom: Long disc in Web Apps on storage for web apps. Also aplicable for File Writer.
<richt> [calendar] My understanding is that blocking for calendar API is TimezonedDate object, expressing i18n dates/times and fixing the recurrence model
<richt> [calendar] non-blocking issue is to address minimization in the draft
<fjh> Thanks for scribing Claes.