Device APIs and Policy Working Group Teleconference

<trackbot> Date: 28 October 2009

<fhirsch> ACTION: paddy to review Policy Requirements editors draft, see http://dev.w3.org/2009/dap/policy-reqs/ [recorded in http://www.w3.org/2009/10/28-dap-irc]

<trackbot> Created ACTION-34 - Review Policy Requirements editors draft, see http://dev.w3.org/2009/dap/policy-reqs/ [on Paddy Byers - due 2009-11-04].

<maxf> fhirsch: you didn't hear me then. Hmm

<maxf> that mute button...

<brianleroux> Brian LeRoux is in the 604

<arve> zarkim, marcos/arve is arve

<fhirsch> me zakim, who is here?

<brianleroux> ah, ok --- thx fhirsch

<darobin> arve, can you scribe?

<arve> Having tech problems here

<darobin> brianleroux, can you scribe?

<brianleroux> hey sorry --- just back

<brianleroux> heh

<darobin> Scribe: Brian LeRoux

<dom> ScribeNick: brianleroux

<fhirsch> http://www.w3.org/2009/dap/wiki/Main_Page

<fhirsch> tpac agenda

<fhirsch> http://www.w3.org/2009/dap/wiki/F2F_Agenda_2-3_November_2009%2C_TPAC

Welcome, etc. TPAC f2f needs the mailing list to raise as much as possible

minutes approval

<fhirsch> http://lists.w3.org/Archives/Public/public-device-apis/2009Oct/att-0203/minutes-2009-10-21.html

Resolution: minutes from 21 oct approved

Editorial Team Report

<fhirsch> http://lists.w3.org/Archives/Public/public-device-apis/2009Oct/0225.html (Frederick)

<fhirsch> policy requirements update

<fhirsch> contacts api update

<dom> Update to contacts API from Richard

<fhirsch> http://lists.w3.org/Archives/Public/public-device-apis/2009Oct/0230.html (Richard Tibbett)

richard: discussing how contacts api going async

<arve> +1 for flexible

<maxf> richard: main issue is strict or flexible definition of attributes. Also error handling

richard: mentioned that the attributes for contacts have three potential approaches that need resolving

maxf: no! thank you!!

dom: will be discussing api overlap at the f2f

<dom> Dom’s message to geolocation wg

<maxf> yep, Mon/Tue

robin: will ensure they have the meetings in the hallways / nothing formal

<darobin> I confirm that they're meeting at the same time as us

<darobin> ACTION: Robin to make sure that there is some co-ordination between Geolocation and DAP over Compass [recorded in http://www.w3.org/2009/10/28-dap-irc]

<trackbot> Created ACTION-35 - Make sure that there is some co-ordination between Geolocation and DAP over Compass [on Robin Berjon - due 2009-11-04].

<maxf> maxf: I'm in Geolocation and will attend their meeting and will be conveying this group's ideas

<fhirsch> dzung notes he was going to take compass out of the draft, so that can be given to the geolocation group

<scribe> ACTION: Dzung_tran will remove compass from the draft for the geolocaiton group [recorded in http://www.w3.org/2009/10/28-dap-irc]

<trackbot> Sorry, couldn't find user - Dzung_tran

<fhirsch> ACTION: dzung to take compass api out of system info api as a separate api document, to share with geolocation [recorded in http://www.w3.org/2009/10/28-dap-irc]

<trackbot> Created ACTION-36 - Take compass api out of system info api as a separate api document, to share with geolocation [on Dzung Tran - due 2009-11-04].

<darobin> ACTION: Dzung to split Compass out of SysInfo so that Geolocation can look at it, and adopt if they like it [recorded in http://www.w3.org/2009/10/28-dap-irc]

<trackbot> Created ACTION-37 - Split Compass out of SysInfo so that Geolocation can look at it, and adopt if they like it [on Dzung Tran - due 2009-11-04].

<fhirsch> action-36 closed

<trackbot> ACTION-36 Take compass api out of system info api as a separate api document, to share with geolocation closed

Policy

fhirsch: wants us to discuss a roadmap, review req's and security

<fhirsch> policy requirements draft

<fhirsch> http://dev.w3.org/2009/dap/policy-reqs/

fhirsch: pls review policy requirements (should be declarative, etc)
... features vs capabilities and trust models, granularity of security, notification dialogues
... wants feedback on the policy-reqs doc on the mailing list after review. aim for a editors draft at the f2f.

<fhirsch> may decide on FPWD

<darobin> ack

<fhirsch> seeking agreement of WG on editors draft content

<fhirsch> this first draft is to get us started, but does not represent consensus

bryan: feels that we need to get a sense of consensus before publishing a working draft

<fhirsch> would like to get to state where draft does represent consensus, and changes are made based on consensus

<fhirsch> please review the policy requiements draft before the f2f, discuss on list, including issues noted and gaps

<fhirsch> we need to decide how to fulfill the roadmap deliverable of the charter, f2f discussion?

<fhirsch> I noted that API docs probably should have security considerations and privacy considerations

<fhirsch> contacts api has place holder for this

richt: has put a placeholder in Contacts related to security
... ppl need to be aware that each API requires different security requirements

<Dzung_Tran> I agree

<inserted> ScribeNick: darobin

arve: agreed, each API may be implemented separately
... so each needs its own security considerations

<brianleroux> yes

<dom> ACTION-31?

<trackbot> ACTION-31 -- stephen lewontin to share information on conditional permissions on list -- due 2009-10-28 -- OPEN

<trackbot> http://www.w3.org/2009/dap/track/actions/31

APIs

<brianleroux> review progress on req docs and issues

<brianleroux> bryan: travelling through time, feels that the register protocol handler in html5 is specific to websites / not widgets / not related to the scope

<brianleroux> robin: handler can register itself for a protocal (which can be a web app)

<brianleroux> robin: do you mean something that does not have a url? bryan: essentially yes --- looking for an explanation have how we can use this feature in this context (the context of a widget on a device)

<brianleroux> bryan: conceptually addressed by html5 robin: needs more thinking to make it work for widgets

<brianleroux> robin: going to elaborate on the protocol handlers discussion as it relates to widgets

<brianleroux> essentially the URI is an internal representation to the widget only not able to register outside of its own context

<brianleroux> interesting thought that a widget could be addressable externally

<brianleroux> arve: content servers within widgets creates its own unique set of problems/opportunities

<brianleroux> well then

<brianleroux> =)

<brianleroux> bryan: reviewing the gaps between DAP and BONDI

<brianleroux> robin: wonders if anyone has anything about other APIs than Contacts and System?

<brianleroux> sorry,

<brianleroux> bryan: question about the Camera API --- feels recording from the microphone is vital

<brianleroux> robin: so if it can do pictures, video ... why not sound (it is an issue). makes it more of a capture api

<brianleroux> robin: the issue regarding recording should be resolved at f2f

<brianleroux> (ftr brianleroux +1 to Capture API)

<AnssiK> sysinfo and events is fairly extensive, do we still want to modularize it?

<Dzung_Tran> I think it makes sense to separate into AV recording

<AnssiK> ok, sounds like a plan

Other Business

<brianleroux> Meeting adjourned!