W3C home > Mailing lists > Public > public-device-apis@w3.org > November 2009

Draft minutes 2009-11-18 teleconference

From: Frederick Hirsch <frederick.hirsch@nokia.com>
Date: Wed, 18 Nov 2009 11:32:22 -0500
Message-Id: <6CA62A05-248C-43C8-91CB-BEA6B0FAF11B@nokia.com>
To: W3C Device APIs and Policy WG <public-device-apis@w3.org>
Cc: Frederick Hirsch <frederick.hirsch@nokia.com>
Attached are draft minutes for 2009-11-18 teleconference

regards, Frederick

Frederick Hirsch, Nokia
Co-Chair, W3C DAP Working Group

# Device APIs and Policy Working Group Teleconference

## 18 Nov 2009


See also: [IRC log][4]

## Attendees


    DomHazaelMassieux, Laszlo_Gombos, Robin_Berjon, Anssi_Kostiainen, Suresh,
Chitturi, BryanSullivan, Max_Froumentin, Marcin_Hanclik, Dzung_Tran,
Claes_Nilsson, Richard_Tibbett, Laura_Arribas, Ingmar_Kliche, Niklas_Widell


    Thomas_Roessler, Paddy_Byers


    Robin_Berjon, Frederick_Hirsch



## Contents

  * [Topics][5]

    1. [Administrativa][6]

    2. [f2f][7]

    3. [minutes][8]

    4. [policy segment][9]

    5. [Comparison between Nokia and BONDI on trust model and access

    6. [APIs][11]

    7. [Next Meeting][12]

  * [Summary of Action Items][13]

* * *

<trackbot> Date: 18 November 2009

<marengo> i'm not [IPCaller]

<ilkka> +Present Ilkka_Oksanen

<BryanSullivan> +present BryanSullivan

<darobin> Scribe: Arve

<darobin> ScribeNick: arve

<Suresh> Suresh just joined the bridge


### Administrativa

<fhirsch> [http://lists.w3.org/Archives/Public/public-device-

fhirsch: Geolocation WG is taking on API for orientation and acceleration data
from device

<maxf> arve: does it mean that that item won't be covered by this WG?

<BryanSullivan> "Acceleration" is not the same as "accelerometer", correct?

<maxf> robin: yes

<dom> I think Acceleration is the same as accelerometer

robin: This WG will not take on these item

<BryanSullivan> Accelerometer should be outside their scope

<Dzung_Tran> Did someone pass along the Compass spec that I did to the
Geolocation WG?

suresh: we need to find a way to handle overlap with other groups

BryanSullivan: Accelerometer is not the same as acceleration

<BryanSullivan> Accelerometer is in general an example issue for sensor API's
- GeoLocation is a special case.

we should be careful about geolocation wg expanding their scope

drogersuk: How do we logically separate accelerometer and acceleration data?

<Suresh> We need find a way to integrate other "device APIs" work (e.g. geo-
location, accelorometer) in to DAP WG deliverables or at the minimum reference

<dom> [as a point of order, I think people would better react on announcements
when they're made on the list, rather than waiting for the call to make their

<darobin> ack

<Zakim> darobin, you wanted to point out that this is a good reason to do
anything related to policy outside of the API specs and to point out that
we've already resolved that "general

<drogersuk> my point doesn't seem to have been minuted:

<drogersuk> drogersuk: We need to look at the clear logical separations
between functionality - e.g. geolocation and accelerometer, they are probably
independent functions

<darobin> RB: to Suresh's point, I would like to say that we should simply do
policy orthogonally from APIs so that we can also cover other WGs' APIs

<darobin> RB: to Bryan's I would like to point out that we're not working on
generic sensors, so there's no chartered requirements to prevent Geo from
doing Accelerometer — if they have the bandwidth then by all means we should
be happy to have less to do

<maxf> Geolocation WG's action item where draft on "orientation and
acceleration" is proposed: [http://www.w3.org/2009/11/03-geolocation-

<marcin> +1 to orthogonality

<Suresh> I agree with what Robin just said in separating the policy from APIs

<dom> [I think that "FUture APIs are not considered a priority" is a
sufficient statement to make to clarify the situation]

<darobin> +1 to dom

<marcin> +1 to dom & darobin

+1 to dom

<drogersuk> we don't want to discourage people from creating new things though

<drogersuk> it just won't be discussed as it is not in charter

<marcin> specifying policy for existing APIs will be a good exercise for the
future APIs

<fhirsch> F2F Scheduling

<scribe> **ACTION:** dom will update home page to reflect "Future apis are not
a priority" [recorded in [http://www.w3.org/2009/11/18-dap-

<trackbot> Created ACTION-61 - Will update home page to reflect "Future apis
are not a priority" [on Dominique Hazaël-Massieux - due 2009-11-25].

<fhirsch> [http://lists.w3.org/Archives/Member/member-device-

### f2f

<fhirsch> [http://www.w3.org/2002/09/wbs/43696/prague-f2f-dates/results][18]

<dom> PROPOSED RESOLUTION: next WG F2F in Prague on March 16 to 18

going once

going twice

drogersuk: 16-18 might collide with SXSW for some members

<richt> I may go to SXSW but it is not yet confirmed

drogersuk: need to avoid overlap with omtp meeting, there seems to be none

darobin: only overlap with SXSW currently seems to be drogersuk

drogersuk: there will be noe overlap with OMTP

dom: april an alternative

arve: would prefer march

<fhirsch> prefer march

<darobin> drogersuk: OMTP are always happy to host in London

fhirsch: would propose resolution

<darobin> **ACTION:** Robin to contact Prague uni to ask if we can meet on
16-18/03 [recorded in [http://www.w3.org/2009/11/18-dap-

<wonsuk> +1 for March

<trackbot> Created ACTION-62 - Contact Prague uni to ask if we can meet on
16-18/03 [on Robin Berjon - due 2009-11-25].

**RESOLUTION: Meeting date set to 16-18/03 2010**

fhirsch: Is the meeting 2.5 days or 3?

+1 to 2.5

<drogersuk> +1

<Claes> +1 for 2.5

<wonsuk> +1 for 2.5

<maxf> +1

<Laura_Arribas> +1 for 2.5

<marengo> +1 for 2.5

<drogersuk> lol make it 3.5 then

<darobin> I think 5.5

<marcin> 0 to 2.5 and/or 3

<AnssiK> why not 2^2?

proposed resolution: meeting will be 2.5 days?

**RESOLUTION: meeting will be 2.5 days**

<darobin> RB: we could perhaps start at 11 the first day and finish at 1530
the last day

### minutes

fhirsch: any objections to approving minutes from last meeting

<darobin> [http://www.w3.org/2009/dap/#roadmap][20]

<fhirsch> Policy Requirements Editors Draft updated

fhirsch: please review document

<fhirsch> [http://lists.w3.org/Archives/Public/public-device-

<scribe> **ACTION:** Laura_Arribas to review
[recorded in [http://www.w3.org/2009/11/18-dap-minutes.html#action03][22]]

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

<dom> **ACTION:** Laura to review [http://lists.w3.org/Archives/Public/public-
device-apis/2009Nov/0044.html][21] [recorded in [http://www.w3.org/2009/11/18

<trackbot> Created ACTION-63 - Review [http://lists.w3.org/Archives/Public
/public-device-apis/2009Nov/0044.html][21] [on Laura Arribas - due

<Laura_Arribas> **ACTION:** Laura Arribas to review last reqs document
[recorded in [http://www.w3.org/2009/11/18-dap-minutes.html#action05][24]]

<trackbot> Created ACTION-64 - Arribas to review last reqs document [on Laura
Arribas - due 2009-11-25].

[?] Contacts API updated to use vCard

<fhirsch> richard notes has updated contacts using vcard, working on security
considerations and use cases

<darobin> richt++

### policy segment

<fhirsch> Markup for implicit consent

<Suresh> richard, can you post the link to the contacts API draft, please?

<fhirsch> [http://lists.w3.org/Archives/Public/public-device-

<richt> Contacts API Latest Editor's Draft:

<maxf> ok. I'll call back

<maxf> no

<richt> regarding the contacts api: you may need to do a refresh or clear
cache. I was having problems with the etags (or something) not refreshing the

<dom> Bryan, [http://lists.w3.org/Archives/Public/public-device-
apis/2009Oct/att-0120/minutes-2009-10-07.html#item06][27] re agreement to
publish FPWD

<fhirsch> action-47?

<trackbot> ACTION-47 -- Laura Arribas to provide input on trust model and
access control model definitions -- due 2009-11-10 -- PENDINGREVIEW

<trackbot> [http://www.w3.org/2009/dap/track/actions/47][28]

maxf: I had the action item to explore reusing security from file upload

for implicit user consent

maxf: the idea was to figure out if model applied to other apis

<dom> +1 on figuring the process to specify possible markup aspects of our
APIs as we go

fhirsch: does this apply for widgets and/or webapps?

maxf: will investigate

<maxf> arve: do we have the necessary expertise in the area?

<maxf> … just as much about usability

<fhirsch> frederick asks where we define input types, robin notes either in
HTML WG or here as appropriate, can do later

<BryanSullivan> +1 to no "one shoe fits all"

<maxf> … I would propose relieveing max of his action item and revisit it

<fhirsch> need to define input element for each API , part of API definition

<maxf> … e.g. file system access. There's a lot about making the API usable. …
geolocation ...

<Suresh> i don't believe this model of input="xx" fits all the use cases,

<richt> agree with suresh but we need use cases in our documents though to
justify that.

<fhirsch> max, can you please check status of HTML WG and how process would
proceed for defining input types

<dom> [I think the idea behind MaxF's action was to put some ideas on the
table that we can take from when looking at specific APIs]

Suresh: too early to agree on the topic

<BryanSullivan> we need to recognize that a UI-based approach will not address
all use cases, e.g. to create accessible webapps or that work well in
input/output constrained devices.

Suresh: are we restricting ourselves to this, or is it just one of many

fhirsch: it's one option, not _the_ option

<dom> [well, the important thing would be to look at specific use cases that
wouldn't be addressed by this, so that we understand better the limits of the

<dom> [I think the people that are skeptic should do that :) ]

<AnssiK> <input type="foo"> approach is nice in a sense it provides both
programmatic (via DOM API) and declarative (ie. markup) mechanisms

+1 to darobin's written proposal

<fhirsch> action-47?

<trackbot> ACTION-47 -- Laura Arribas to provide input on trust model and
access control model definitions -- due 2009-11-10 -- PENDINGREVIEW

<trackbot> [http://www.w3.org/2009/dap/track/actions/47][28]

<Dzung_Tran> agree with robin, each person who owns their API needs to apply
the input/output as you see fit

<dom> [Laura's comparison of BONDI/Nokia trust model and access contrl][29]

<dom> ScribeNick: dom

### Comparison between Nokia and BONDI on trust model and access control

Laura: both approaches are significantly similar

... the major difference is that Nokia considers the trust manager and the
access manager separately

... the access manager makes the final access decision

... BONDI has a different architecture — the trust decision is included in the
access manager

... there are also differences in the policies

... Nokia consider 2 polices: trust, and access control

... BONDI doesn't make that differenciation and includes everything in the
same policy

<lgombos> have a hard limit, have to drop of, sorry

Laura: I would welcome reviews on my summary

... I don't have specific ideas on how to integrate in the requirements

Frederick: I'm not quite sure why BONDI wouldn't consider access control and
trust management as separate concerns

<richt> unfortunately I need to leave the call for another meeting :(

Frederick: I need to look more closely in the specs

<richt> I will catch up with the minutes and follow up on the mailing list.

<Dzung_Tran> So should we review and discuss on the mail list?

Laura: it allows to group permissions in different domains

<Suresh> i don't think trust and access control should be treated separately,
a decision needs to be take with both into account

Bryan: the distinction between trust and policy in Nokia is essentially a way
to organize the data (the files)

... it's equivalent to what we have in BONDI

... they're functionally equivalent, it's just the way the data is organized

Frederick: so Policy Management is out of scope of our work, but it has an
impact on our scope of work on policy definitions

... I'll look more closely to the BONDI specs

David: in BONDI, we've left open policy management

... In the discussions on the mailing list, I'm not sure what are the
alternatives on defining a policy framework at some point (e.g. for
filesystems API)

Frederick: could you send an email on that topic?

David: I've done that already

Bryan: the management of policy (storage, updates, user decision involvement)
is out of scope

... the definition of a policy file, an expression of a policy as a set of API
permissions etc, should be in scope

... it's not directly influenced by policy management

... it's more dependent on APIs and their security aspects

... if we go deeper into UI considerations, we also need to take into account
enabling a similar set of features in a policy-based approach

Frederick: I keep coming back to the question of who's writing the policy

... if you don't have a model of this, I think it's hard to understand the use
cases for the policy framework

### APIs

Robin: we've discussed making Capture a priority item for the roadmap

<drogersuk> correction to minutes above: For people who are saying we don't
need policy - I don't see the alternative once you've run out all the ways of
designing the API securely apart from deferring the decision to the user - I'd
like to see input to this because it will help the FileAPI and FileSystem API
discussions progress

PROPOSED RESOLUTION: Make capture (Video/Photo/Sound) a priority API

**RESOLUTION: Make capture (Video/Photo/Sound) a priority API**

Robin: within the priority documents, I would like to assign action items for
people to come up with first editors drafts

... we already have one for contacts (Richard), but everyone is welcomed to

... Richard has already started working on Calendar, but would be helpful if
he got help

... what about messaging?

Claes: I'm interested to take on that

Robin: Daniel Coloma was also interested

<Dzung_Tran> I can take on Capture

<scribe> **ACTION:** Claes to provide an editors draft of the Messaging API -
due in two weeks [recorded in [http://www.w3.org/2009/11/18-dap-

<trackbot> Created ACTION-65 - provide an editors draft of the Messaging API
[on Niklas Nilsson - due 1970-01-01].

Frederick: suresh, did you mention you were interested in Calendar?

Suresh: yes, but RObin said Richard was working on it

<nwidell> ACtion-65 should be on nwidell

Suresh: I'll work with him


<trackbot> ACTION-65 -- Niklas Nilsson to provide an editors draft of the
Messaging API -- due 1970-01-01 -- OPEN

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

Robin: what about Capture? Dzung?

<Dzung_Tran> Sure

<scribe> **ACTION:** Dzung to provide an editors draft of the Capture API
[recorded in [http://www.w3.org/2009/11/18-dap-minutes.html#action07][32]]

<trackbot> Created ACTION-66 - Provide an editors draft of the Capture API [on
Dzung Tran - due 2009-11-25].

Ingmar: I'm happy to help on Capture as well

Robin: if any of the editors don't have access to CVS, please contact Dom (but
not DOM)

... what about FileSystems?

... I'll take a stab at it

<scribe> **ACTION:** Robin to provide a first editors draft of the FileSystems
API [recorded in [http://www.w3.org/2009/11/18-dap-minutes.html#action08][33]]

<trackbot> Created ACTION-67 - Provide a first editors draft of the
FileSystems API [on Robin Berjon - due 2009-11-25].

Bryan: I'll provide feedback on it

Robin: We've had sysInfo in CVS for a while

... please provide feedback as soon as possible

... so that we can decide to move to FPWD

Bryan: I've provided input FWIW

<Dzung_Tran> Sorry what is FWIW?


<trackbot> ACTION-58 -- Bryan Sullivan to make a concrete proposal with a
vocabulary-based approach to system & events, with a few examples (e.g.
battery level) -- due 2009-11-11 -- OPEN

<trackbot> [http://www.w3.org/2009/dap/track/actions/58][34]

Bryan: regarding the FWPD of requirements, it wasn't clear to me that we had
reached consensus on the content of the document

... I'd like to see my set of requirements integrated in the document

... it looks like new requirements are impeded to get in the document

<fhirsch> FPWD simply means to publish draft which is subject to change

Robin: as an editor, I was hoping you would provide help in adding your reqs

... put it in the document — that will make it more likely for people to react

David: maybe there should be a separate call for editors to help them set them

Robin: I'm not saying that people should always put their feedback in the doc;
but when not getting feedback, it can be a useful tool

... regarding helping editors, it would be helpful to know what the questions

... send me emails, and then I can figure out the best format to help people

Maxf: you've listed the 4 priority APIs documents, but also listed capture
which is in the "other" category

Robin: we've just resolved to make it a priority

MaxF: but what happens with the other ones?

... I'm in the editors pool

... I could either help on the priority ones, or start working on another one

Robin: it's perfectly fine to start on a new one; we might just spend less
time discussing it

MaxF: who wrote Sys and Events?

Robin: Dzung

Maxf: I'd like to help with that one

<drogersuk> just to understand, is this based on any of the input?

Robin: please coordinate on the list

<Dzung_Tran> Sure, no problem

David: is SysInfo based on any of the input doc?

Robin: I think it's something Dzung came up with

<Dzung_Tran> Yes, it is based on Nokia, BONDI, ..

David: Would Dzung be willing to look at the input to the charter and
integrate it in SysInfo

<drogersuk> ok thanks

Robin: Dzung says on IRC it's based on Nokia and BONDI

... it probably took them into account

David: Ok, just wanted to clarify that point

### Next Meeting

[@@@]: I'm seeing a lot of regrets for next week

Robin: we might have to cancel

<Dzung_Tran> I think we should cancel

[xxx]: can't we make a decision now?

+1 on canceling

<fhirsch> need to decide in advance so people can plan

<Dzung_Tran> Most people in US are out on Thanksgiving holiday

**RESOLUTION: no meeting next week, next meeting on Dec 2**


<nwidell> -nwidell

<Dzung_Tran> l8r

<Dzung_Tran> -

<marengo> /me bye

<marcin> bye bye

## Summary of Action Items

**[NEW]** **ACTION:** Claes to provide an editors draft of the Messaging API -
due in two weeks [recorded in [http://www.w3.org/2009/11/18-dap-

**[NEW]** **ACTION:** dom will update home page to reflect "Future apis are
not a priority" [recorded in [http://www.w3.org/2009/11/18-dap-

**[NEW]** **ACTION:** Dzung to provide an editors draft of the Capture API
[recorded in [http://www.w3.org/2009/11/18-dap-minutes.html#action07][32]]

**[NEW]** **ACTION:** Laura Arribas to review last reqs document [recorded in

**[NEW]** **ACTION:** Laura to review [http://lists.w3.org/Archives/Public
/public-device-apis/2009Nov/0044.html][21] [recorded in

**[NEW]** **ACTION:** Laura_Arribas to review
[recorded in [http://www.w3.org/2009/11/18-dap-minutes.html#action03][22]]

**[NEW]** **ACTION:** Robin to contact Prague uni to ask if we can meet on
16-18/03 [recorded in [http://www.w3.org/2009/11/18-dap-

**[NEW]** **ACTION:** Robin to provide a first editors draft of the
FileSystems API [recorded in [http://www.w3.org/2009/11/18-dap-

[End of minutes]

* * *

Minutes formatted by David Booth's [scribe.perl][35] version 1.135 ([CVS

$Date: 2009-03-02 03:52:20 $

   [1]: http://www.w3.org/Icons/w3c_home

   [2]: http://www.w3.org/

   [3]: http://lists.w3.org/Archives/Public/public-device-

   [4]: http://www.w3.org/2009/11/18-dap-irc

   [5]: #agenda

   [6]: #item01

   [7]: #item02

   [8]: #item03

   [9]: #item04

   [10]: #item05

   [11]: #item06

   [12]: #item07

   [13]: #ActionSummary

   [14]: http://lists.w3.org/Archives/Public/public-device-

   [15]: http://www.w3.org/2009/11/03-geolocation-minutes.html#action05

   [16]: http://www.w3.org/2009/11/18-dap-minutes.html#action01

   [17]: http://lists.w3.org/Archives/Member/member-device-

   [18]: http://www.w3.org/2002/09/wbs/43696/prague-f2f-dates/results

   [19]: http://www.w3.org/2009/11/18-dap-minutes.html#action02

   [20]: http://www.w3.org/2009/dap/#roadmap

   [21]: http://lists.w3.org/Archives/Public/public-device-

   [22]: http://www.w3.org/2009/11/18-dap-minutes.html#action03

   [23]: http://www.w3.org/2009/11/18-dap-minutes.html#action04

   [24]: http://www.w3.org/2009/11/18-dap-minutes.html#action05

   [25]: http://lists.w3.org/Archives/Public/public-device-

   [26]: http://dev.w3.org/2009/dap/contacts/Overview.html

   [27]: http://lists.w3.org/Archives/Public/public-device-

   [28]: http://www.w3.org/2009/dap/track/actions/47

   [29]: http://lists.w3.org/Archives/Public/public-device-

   [30]: http://www.w3.org/2009/11/18-dap-minutes.html#action06

   [31]: http://www.w3.org/2009/dap/track/actions/65

   [32]: http://www.w3.org/2009/11/18-dap-minutes.html#action07

   [33]: http://www.w3.org/2009/11/18-dap-minutes.html#action08

   [34]: http://www.w3.org/2009/dap/track/actions/58

   [35]: http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm

   [36]: http://dev.w3.org/cvsweb/2002/scribe/

Received on Wednesday, 18 November 2009 16:33:08 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:32:13 UTC