See also: IRC log
<trackbot> Date: 07 April 2010
<marengo> Zaki, aaaa is me
I'll scribe
<darobin> thanks paddy!
<scribe> scribenick: paddy
<fjh> Updated Capture API draft published, 1 April 2010
<fjh> http://www.w3.org/News/2010#entry-8759
<fjh> FPWD of File API: Writer published, 6 April 2010
<fjh> http://www.w3.org/News/2010#entry-8762
fjh: minutes are out: any changes wanted?
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2010Mar/att-0242/minutes-2010-03-31.html
RESOLUTION: minutes of 31 March approved
<fjh> ACTION-153
<fjh> ACTION-153?
<trackbot> ACTION-153 -- Alissa Cooper to refine privacy requirements (with John) -- due 2010-04-07 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/153
fjh: Had actions to review requirements - Alissa, do you have anything to say?
alissa: I tried to pare down to just talking about the requirements on APIs
<fjh> comments from Frederick at http://lists.w3.org/Archives/Public/public-device-apis/2010Apr/0011.html
alissa: we decided to separate from policy stuff and best practices for app developers
<fjh> updated editors draft with this revision, see http://dev.w3.org/2009/dap/privacy-reqs/
alissa: decided just to adjust text without changing too much
<fjh> Previous versions are visible in the CVS history
alissa: did some other editorial changes: tried to fill in big table with other elements of privacy
<fjh> http://dev.w3.org/cvsweb/2009/dap/privacy-reqs/Overview.html
alissa: I just don't think that the complete picture of what gets addressed where is obvious
jmorris: I thinkit would be helpful to have a couple of diagrams on architecture as discussed in Prague
fjh: alissa,, were you proposing additional text to address that?
... just to make sure new readers understand what we are trying to do
<darobin> -> some unfinished noodling http://dev.w3.org/2009/dap/docs/privacy-license.html
fjh: we do need to have a bit more to set out scope, context
jmorris: do we do it in this document? My personal vote is yes
fjh: yes, don't want to proliferate documents unnecessarily
darobin: I have an action to look at separate solutions, have drafted some text in a separate document
<fjh> Robin suggests using material from background section
darobin: are you looking for something like what's in the background section of that document?
<fjh> http://dev.w3.org/2009/dap/docs/privacy-license.html#background
alissa: yes, I think if something like this doc exists, then the API requirements doc can refer to it
jmorris: I don't think we need explanation in every doc; but should be somewhere publically visible when we first publish
... alissa and I can look at it, but it's a good start
<fjh> I suggest we copy background section from Robin's draft into requirements document
darobin: doc was just a brain dump, so steal the text and put in the requirements doc
fjh: alissa, jmorris: do you wish to take on editorial control?
<darobin> +1 to either or both alissa and jmorris to have editorial access
jmorris: I think it should be alissa
<fjh> ACTION: fjh to add background section into requirements with some edits [recorded in http://www.w3.org/2010/04/07-dap-minutes.html#action01]
<trackbot> Created ACTION-157 - Add background section into requirements with some edits [on Frederick Hirsch - due 2010-04-14].
darobin: review the text before copying it :)
... dom will set up access for editing
fjh: took out abuse cases; some of this might be in the requirements doc
... do you want to review how it relates to your part?
alissa: I can review but also welcome suggestions from the list
fjh: is there more to be said about this?
... next step is to decide what we do in the various API docs
... do we subsume these requirements into the individual API docs?
... should it be up to the document owners?
alissa: do we want the privacy issues to be explicit requirements on the APIs?
<fjh> I believe api docs should each list the privacy items and how they are addressed
alissa: I think there should be, but others may disagree
<darobin> +1
fjh: agree it should be explicit as requirements
... then we can determine the degree to which each API satisfies those requirements
... also we need a caveat about privacy requirements changing
bryan: I agree should indicate the scope of the requirements in the API docs
... but there should be a central place where the concepts, requirements are discussed in general terms
<fjh> each api should indicate how it supports or does not support, items in API table
<Zakim> richt, you wanted to talk about latest addition to Contacts API: http://dev.w3.org/2009/dap/contacts/Overview.html#design-considerations
richt: I added a section to contacts API to try out this idea
... to discuss issues relating to privacy and also other design considerations relating to the API
... added section "privacy by design"
<fjh> http://dev.w3.org/2009/dap/contacts/Overview.html#privacy-by-design
richt: but done in parallel to what has been happening in the privacy requirements document
... .. it would be great to get feedback, this is just embryonic at this stage
<fjh> maybe we should focus on contacts first, then revise other docs with similar agreed model
richt: quite useful to have as design considerations explicitly tailored to the requirements/issues of each API
... every API has different issues
<fjh> ok, so start is to get the facts for each API, then worry about formatting
<darobin> +1
fjh: get the facts down in each doc first, then worry about formatting
... if each API doc owner can create a privacy section, this will be a good starting point
... thanks to richt for this input
... next step for privacy will be to go through each API
... add background section
... review the big table
... decide what needs to be added in
... alissa, jmorris, did you have concerns about the text? were you going to do something about that?
... what is the size of the concern, and when will we have an update?
jmorris: concerns were mostly minor
... there were multiple contributors, and existing text is raising questions/issues rather than being presented logically
alissa: jmorris should forward proposed changes to list
fjh: trying to figure out what needs to happen before we can make a public draft
jmorris: can send input to list in next few days
fjh: licensing stuff as well?
<fjh> ACTION: jmorris to send proposed changes to list re privacy requirements [recorded in http://www.w3.org/2010/04/07-dap-minutes.html#action02]
<trackbot> Created ACTION-158 - Send proposed changes to list re privacy requirements [on John Morris - due 2010-04-14].
alissa: need more time for that part
fjh: achievable this month?
alissa: probably, but need another week
fjh: more comments on that requirements doc?
fjh: Laura, you did some edits on the policy framework - do you want to talk to what you did?
<fjh> ACTION-152?
<trackbot> ACTION-152 -- Laura Arribas to edit policy framework, reviewing BONDI material and editorial update -- due 2010-04-07 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/152
laura: yes
lauraA: I continued what drogers started, based on input from BONDI
<scribe> .. finished passing BONDI appendices document
<fjh> http://dev.w3.org/2009/dap/policy/
LauraA: focussing now on architecture based on BONDi A&S
... then will look at how to merge the Nokia submission
... the current draft now has a formal model
... but not yet ready for review, so people should wait until it is ready
... will email the list when ready for review
<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: can we make progress on other policy issues?
... do we have a solution to this issue? I'm not sure what we want to do
... is anyone thinking about this?
... I'm going to suggest that we focus on the functionality of sysinfo
... maxf - are you the editor?
<fjh> perhaps this is a minimization issue
jmorris: I think it is right to address via minimisation
fjh: then we do have a way to address it, so we have to talk about minimisation
<fjh> ACTION: maxf note minimization in sysinfo to address ISSUE-79 [recorded in http://www.w3.org/2010/04/07-dap-minutes.html#action03]
<trackbot> Created ACTION-159 - Note minimization in sysinfo to address ISSUE-79 [on Max Froumentin - due 2010-04-14].
<maxf> I'll try again
<maxf> and hang up
darobin: one thing that worries me is that the document is mature and nearly ready for LC
<maxf> to answer the question, I am the editor and I've not thought about policy much
darobin: so we need to address this issue before LC
... so we don't carry the issue into LC
... perhaps the resolution is simple, but it still needs to be written up
fjh: we need to say how it is addressed, eg the API design permits incomplete responses
darobin: currently in the API, it is an implementation decision as to what information is returned
<fjh> need note to warn implementations about need for minimization
fjh: so we have an implementation guideline
<darobin> [I think that adding concerns of fingerprinting and minimisation to http://dev.w3.org/2009/dap/system-info/#privacy-considerations-for-implementors might be enough]
fjh: need a paragraph in the doc saying the minimisation is important, and implementations may make minimised responses
... not necessarily controlled via policy
... darobin says address it before LC
maxf: ok
<fjh> ISSUE-38?
<trackbot> ISSUE-38 -- Use cases and threat model for security requirements -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/issues/38
fjh: other issue is about use cases and threat model
... drogers did something, is there more we need to do?
drogers: had to take a week off so unable to progress as intended
<fjh> david notes that we need linkages from threats to requirements
drogers: but have agreed to put a placeholder in the policy document so policy requirements are traceable back to threats
fjh: will you do a proposal for that?
drogers: yes, I will be able to progress soon
... already captured in existing action
<fjh> issue-37?
<trackbot> ISSUE-37 -- Domain spoofing and trust in the network layer -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/issues/37
fjh: another issue - out of scope?
... network layer, different layers of protocol stack
... and threats arising from network-layer attacks
... is this in scope?
drogers: yes, eg 3G vs Wifi
<fjh> david notes he will capture in threats, then we can discuss
drogers: need to capture in threats, and important consideration
... but decision will be later as to whether or not in scope
<fjh> ISSUE-17?
<trackbot> ISSUE-17 -- Summarize security issues and related requirements for file API -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/issues/17
fjh: issue 17 - should deal with file API - probably need to work on this
... but can't remember the status
... any comment?
darobin: hasn't been a whole lot of progress in last week
... one issue: rename "capture" to "media capture"
RESOLUTION: change "capture" to "media capture"
<fjh> but no change to shortname
darobin: we published capture and file writer
... hopefully getting some feedback
... richt, anything new on contacts you want to bring up?
richt: only really did the privacy section
... not many other changes
... similarly calendar is progressing, but slowly
darobin: will update the docs based on what we agreed today?
richt: sure
darobin: maxf indicated that changes agreed at f2f in messaging are addressed
... is that true?
maxf: yes, did first part of changes but not much time in last couple of weeks
... committed some changes this morning
... so should now be synchronised with what was agreed at f2f
darobin: doc seems to be broken, some styling isn't working
<richt> FYI, messaging URL: http://dev.w3.org/2009/dap/messaging/
darobin: also we agreed removing section 7 as it relates more to application launcher
maxf: I should have checked, that wasn't implemented in draft
darobin: would this then be ready for publication next week?
maxf: yes
darobin: as soon as checks are completed, send an email and we will issue CfC
... lets look at sysinfo
maxf: did changes discussed at f2f
... there are 2 or 3 things still to do, but should be really quick to complete it
... then will publish a new draft for the group
... since at the f2f we didn't create a definitive list of issues
darobin: if can focus on getting to LC it would be great
... looking at other drafts - anything else we haven't covered?
... if there's nothing else in terms of progress on APIs, suggest move to AOB
fjh: edits to ReSpec - will this break our docs?
darobin: this should not break anything, but report any problems you see
... there are at least 4 or 5 other groups using ReSpec but these have added nice new features
... anything else?
<darobin> ACTION-120?
<trackbot> ACTION-120 -- Robin Berjon to check with Geolocation WG re choice of object literals vs positional parameters in geo API -- due 2010-03-24 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/120
richt: wanted to focus on action 120
... related to style of these APIs - does this have significant impact on publication?
darobin: will do it now
... hope we don't get bogged down in long discussion on API styles
... nothing more to discuss