See also: IRC log
<trackbot> Date: 21 October 2009
<fhirsch> Agenda: http://lists.w3.org/Archives/Public/public-device-apis/2009Oct/0195.html
<fhirsch> Chair: Robin Berjon and Frederick Hirsch
<dom> tlr, we have one person having asked for teleconf access to the F2F, but at this time we don't have a polycom reserved for the F2F according to http://www.w3.org/2009/11/TPAC/Schedule.html
<dom> I don't know if it is still time to ask for that additional equipment — susan's message isn't explicit about that http://lists.w3.org/Archives/Member/chairs/2009OctDec/0157.html
<tlr> I wonder whether we could solve this by using skype with a nice microphone.
<fhirsch> I thought we did have one reserved.
<tlr> fh, that was for xmlsec
<MoZ> fhirsch: MoZ is Mohamed Zergaoui from Innovimax
<tlr> Scribe: marengo
<fhirsch> ScribeNick: marengo
thx
<fhirsch> http://lists.w3.org/Archives/Public/public-device-apis/2009Oct/0194.html
<dom> TPAC registration closes on Oct 23
<tlr> yes, it's 1h earlier for Europe.
<tlr> http://esw.w3.org/topic/TPAC_Security_BOF
<tlr> informal session
<fhirsch> http://lists.w3.org/Archives/Public/public-device-apis/2009Oct/0166.html
resolution: minutes for 2009-10-14 are approved
<fhirsch> issue-32?
<trackbot> ISSUE-32 -- Features, Device Capabilities, their identification, and their role in policy. -- RAISED
<trackbot> http://www.w3.org/2009/dap/track/issues/32
<fhirsch> http://lists.w3.org/Archives/Public/public-device-apis/2009Oct/
Paddy: discussion kicked off on how features are identified
<fhirsch> http://lists.w3.org/Archives/Public/public-device-apis/2009Oct/0160.html
<marengo_> my connection dropped
<marengo_> sorry
<fhirsch> paddy: feature is ability to use capability for a specific api
<tlr> issue-28?
<trackbot> ISSUE-28 -- [Policy] Requirement for NO security prompting -- RAISED
<trackbot> http://www.w3.org/2009/dap/track/issues/28
paddy: brief discussion last week
<fhirsch> http://lists.w3.org/Archives/Public/public-device-apis/2009Oct/0185.html
<dom> Paddy's summary on ISSUE-28
paddy: tried to pull out the things which everybody agree
<dom> (linked to ACTION-28 - which I think can now be closed)
paddy: seems clear that the requirement isn't going away
... modal prompts are bad and avoidable with good api design
... user should know something is happening
... many questions have been raised on the ML
... One was about asking just once
... and giving fine grained decision support later
fhirsch: suggests to create issues related to such discussion
<fhirsch> ACTION: paddy to enter issues based on issue-28 [recorded in http://www.w3.org/2009/10/21-dap-minutes.html#action01]
<trackbot> Created ACTION-29 - Enter issues based on issue-28 [on Paddy Byers - due 2009-10-28].
fhirsch: objections to include in the requirements doc?
<Bryan> +1
resolution: paddy to start creating a draft Policy Requirements document related to issue-28
<fhirsch> issue: persisting state of user decisions
<trackbot> Created ISSUE-33 - Persisting state of user decisions ; please complete additional details at http://www.w3.org/2009/dap/track/issues/33/edit .
<fhirsch> Issue-33: related to blanket permission question
<trackbot> ISSUE-33 Persisting state of user decisions notes added
<scribe> ACTION: paddy to create a draft Policy Requirements document [recorded in http://www.w3.org/2009/10/21-dap-minutes.html#action02]
<trackbot> Created ACTION-30 - Create a draft Policy Requirements document [on Paddy Byers - due 2009-10-28].
<Bryan> have to drop chat, will be on the phone
Resolution: start requirements document using material from Paddy issue-28, issue-33
<fhirsch> issue-11?
<trackbot> ISSUE-11 -- Gathering requirements for FileSystem API -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/issues/11
<fhirsch> http://lists.w3.org/Archives/Public/public-device-apis/2009Oct/0193.html
marcin: we are talking about protecting apis
<fhirsch> protecting apis versus protecting data is possibly important consideration
<fhirsch> issue: Protecting data versus protecting apis
<trackbot> Created ISSUE-34 - Protecting data versus protecting apis ; please complete additional details at http://www.w3.org/2009/dap/track/issues/34/edit .
<fhirsch> issue-34: http://lists.w3.org/Archives/Public/public-device-apis/2009Oct/0193.html
<trackbot> ISSUE-34 Protecting data versus protecting apis notes added
marcin: in dap we try to create apis for mananing contacts, events, ...
... protecting the apis is not security
<fhirsch> isn't this a discussion of granularity of access control?
marcin: as a refinement of protecting apis we can go further and specify which parameters are valid or not
<fhirsch> Bryan: BONDI can define security sensitive parameters, e.g. limit access to file location
marcin: will clarify this in BONDI
fhirsch: will it work with things like Contacts
<fhirsch> filtering with tag based rules, e.g only sms to contact
<fhirsch> lewontin: Nokia API has conditional permissions
<fhirsch> ... operation at time of day for example
<fhirsch> ACTION: lewontin to share information on conditional permissions on list [recorded in http://www.w3.org/2009/10/21-dap-minutes.html#action03]
<trackbot> Created ACTION-31 - Share information on conditional permissions on list [on stephen lewontin - due 2009-10-28].
<fhirsch> try to do this before TPAC please
?action-16
<fhirsch> action-16?
<trackbot> ACTION-16 -- Bryan Sullivan to help review/compare device capabilities and features -- due 2009-09-30 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/16
<fhirsch> in progress, before f2f
<fhirsch> action-22?
<trackbot> ACTION-22 -- David Rogers to provide diffs for the BONDI versions -- due 2009-10-07 -- PENDINGREVIEW
<trackbot> http://www.w3.org/2009/dap/track/actions/22
<dom> close ACTION-22
<trackbot> ACTION-22 Provide diffs for the BONDI versions closed
<fhirsch> action-24?
<trackbot> ACTION-24 -- stephen lewontin to look into HTML5 security model -- due 2009-10-14 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/24
<fhirsch> in progress
<dom> paddy already got an action
<dom> ACTION-30?
<trackbot> ACTION-30 -- Paddy Byers to create a draft Policy Requirements document -- due 2009-10-28 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/30
<paddy> sorry was that a question to me?
<dom> ACTION-30?
<trackbot> ACTION-30 -- Frederick Hirsch to create a draft Policy Requirements document -- due 2009-10-28 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/30
<paddy> happy to share an action
fhirsch: f2f agenda ..... we'll work out which slots we'll use for policy discussion
... any suggestions for the agenda?
... regrets should be sent to the list, not just to the chairs
<fhirsch> http://lists.w3.org/Archives/Public/public-device-apis/2009Oct/0186.html
<fhirsch> System Info & Events API
<dom> First stab at System Info & Events API
<fhirsch> proposal here - http://dev.w3.org/2009/dap/system-info/Overview.html
<dom> A proposal for the Device API and Policy Working Group System Information and Events API.
<dom> (that seems to be an awful long document - I would rather see smaller modules)
<AnssiK> +1 for making the spec modular and weeding out parts which should go to v1
dom: suggests to keep only the things we are going to implement
<fhirsch> dom suggests may want to limit scope of the system info to cpu etc but not compass and sensors
<fhirsch> dom notes compass is important API but not as a system API
<dom> ACTION: Dom to look into existing work around compass API at geolocation / webapps [recorded in http://www.w3.org/2009/10/21-dap-minutes.html#action04]
<trackbot> Created ACTION-32 - Look into existing work around compass API at geolocation / webapps [on Dominique Hazaël-Massieux - due 2009-10-28].
<Zakim> dom, you wanted to talk about compass and geoloc
AnssiK: had a quick look at the spec and propose to try to find out what is feasible for v1
<fhirsch> need to consider implications of amount and scope of work, including interop
<fhirsch> all - Please review document and comment on list, which should be in system API, what should be in v2, and what should be a separate API
<fhirsch> ACTION: dzung to revise system api based on list feedback [recorded in http://www.w3.org/2009/10/21-dap-minutes.html#action05]
<trackbot> Created ACTION-33 - Revise system api based on list feedback [on Dzung Tran - due 2009-10-28].
<fhirsch> http://lists.w3.org/Archives/Public/public-device-apis/2009Oct/0190.html
<paddy> I don't think he's on the call
fhirsch: changes is 1.01 are corrections to callback names, error handling, ...
<fhirsch> http://bondi.omtp.org/1.01/apis/errata.html
fhirsch: from a high level point of view it does not add much to discussion
issue-16?
<trackbot> ISSUE-16 -- Gathering requirements for User Interaction API -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/issues/16
fhirsch: web apps and ui dap
<fhirsch> http://lists.w3.org/Archives/Public/public-device-apis/2009Oct/0177.html
<dom> Web NOtifications proposal in WebApps
AnssiK: had a look at prior art, received feedback on ml
... link to WebApps WG, they are implementing web notification system in webkit
... who's taking web notifications
<dom> [this suggests we should take it up - and thus follow-up on the public-webapps message]
<fhirsch> ansii notes examples are growl etc
AnssiK: (there's a discussion on the ML in the recent mails)
... multi-tasking use cases are considered
... mechanism to inform the user of an update
... without forcing the user to open the application
... we could take this
<dom> (there is also discussions in WebApps regarding an API discussing idleness/visibility of the browser context which is likely somewhat relevant to us as well: http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0223.html )
dom: let's wait until next week for a decision
<fhirsch> suggest we make decision next week, with Robin on call
<fhirsch> http://www.w3.org/2009/dap/track/issues/open
<fhirsch> earlier discussed API design patterns, this action should help with moving forward
<dom> ACTION-21?
<trackbot> ACTION-21 -- Bryan Sullivan to send comments about Arve's requirements for ISSUE-6 -- due 2009-09-30 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/21
everyone should prepare input for the requirements
<fhirsch> bryan suggests all prepare inputs for various API requirements for TPAC
<dom> (please introduce the topic on the mailing list beforehand, bryan)
<fhirsch> open actions http://www.w3.org/2009/dap/track/actions/open
fhirsch: review the open action points before tpac
<dom> (MWABP stands for Mobile Web Application Best Practices)
<fhirsch> adjourn