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

Draft DAP minutes 2009-11-03, F2F day 2

From: Frederick Hirsch <frederick.hirsch@nokia.com>
Date: Tue, 3 Nov 2009 17:01:36 -0800
Message-Id: <C19BD842-82BE-489B-86DD-9BB5F61B2EF3@nokia.com>
To: W3C Device APIs and Policy WG <public-device-apis@w3.org>
Cc: Frederick Hirsch <frederick.hirsch@nokia.com>
Attached are draft DAP minutes 2009-11-03, F2F day 2

regards, Frederick

Frederick Hirsch

# Device APIs and Policy Working Group F2F Day 2

## 03 Nov 2009


See also: [IRC log][4]

## Attendees


    Claes_Nilsson, DomHM, DanielColoma, Marco_Marengo, BryanSullivan, maxf,
Steve, Lewontin, Laura_Arribas, Anssi_Kostiainen, Richard_Tibbett,
Niklas_Widell, Kangchan_Lee, Soonho_Lee, Ingmar_Kliche, Suresh, Chitturi,
JonathanJ, Matt, Womer



    Robin, Frederick


    DanielColoma, timeless, nwidell

## Contents

  * [Topics][5]

    1. [Policy Use Case][6]

    2. [Updated Nokia policy input][7]

    3. [Work Items agreed on 2nd November session][8]

    4. [Requirements Comments][9]

    5. [Use Cases][10]

    6. [API Issue Review][11]

    7. [Systems info API][12]

    8. [Administrativia][13]

    9. [AoB][14]

  * [Summary of Action Items][15]

* * *

<trackbot> Date: 03 November 2009

<dom> [Minutes of Day 1][16]

<DanielColoma> Scribe: DanielColoma

<scribe> ScribeNick: DanielColoma

<dom> [Bryan’s use cases for Policy Interoperability][17]

Bryan: Lots of devices with potentially multiple Web Runtimes

... consistency depends on the availability of a consistent language

... users with multiple devices expect the same security UE across all of them

... lots of questions about who do what with regards to policies

... use case 3 provides an example of the policy lifecycle

... start with a default policy, that can be modified by the end-user and also
by a remote management server

fhisch: lots of actors in the use cases

... question, what if multiple SIM Cards are used in the device?

bryan: It will depend on how policies on the device depend on the service

<fjh> who are the actors: end-user, mobile service provider, internet service
provider, developer

bryan: the user is the key party on choice if decissions are to be made

<Zakim> dom, you wanted to ask about existing/planned implementations of
similar systems

dom: who has expressed interest in such a policy system in WRT?

### Policy Use Case

bryan: there are browser vendors involved in BONDI

dom: the charter says we will define a policy framework

... the success of such a proposal depends on the commitment of the browser

... this a much broader topic to what is stated in the charter

fhisch: the key question is whether we need that level of detail to achieve
the targets of the charter

slewontin: nokia has not considered use cases such as the widget vendor
providing also the policy

... decoupled policy framework from management

... key issues are how policies are specified and enforced

bryan: the use cases are not the important thing, the fundamental question is
whether we need an interoperable format. The use cases are just illustrative

Suresh: when is the policy enforced: at installation, during runtime? what are
the implications of policy changes

fhisch: my assumption is that policy is checked during every invocation

<Suresh> We need to define a framework that can be testable/interoperable but
also provide flexibilty to allow different policy documents

fhisch: feedback from other UE centric communities is not very positive on
these kind of use cases such as corporate use cases

Ileana: challenge is finding a common denominator on all the views

... the definition of APIs should hence be the key priority

fhisch: security is key, we should consider security as part of the API

<fjh> as each api is developed we should understand the security aspects, as
well as application dialogs that reflect user choices that imply user consent

bryan: the determination of the security sensitive aspects should be the key

<Suresh> including context, national, business, enterprise, etc.

<fjh> discussion of whether to wait to define policy framework

dom: waiting to see if we need to define the policy exchange format makes

<fjh> dom notes there are other security items we can work on

dom: ... we can focus on other security aspects

<Suresh> i like the idea of working in parallel

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

Suresh: need to work in parallel, don't believe we are going to talk about
security when defining APIs

### Updated Nokia policy input

<fjh> link to message [http://lists.w3.org/Archives/Public/public-device-


slewontin: similar to BONDI approach, BONDI model for capabilities may be a
bit better

... it is not Nokia proposal in opposition to BONDI proposal

... two components: trust component and access control component

... a trust domain is governed by a trust policy

... trust policy is harder to get right than access control policy

... trust policy depends on aspects related with business issues such as

... hence it is important to split trust from access control policies

<fjh> slewontin recommends separate trust policy from access policy,

<fjh> minimize user interaction

slewontin: it is also key to minimize prompting

... it is useful to support the concept of persistency as a way to minimize
user prompting

<fjh> stephen notes value of persistent sessions, allow install time
initialization with minimal subsequent configuration and prompting

bryan: in BONDI concepts such as blanket, session and one-shot restrict the
persistency decisions that the user may take

<fjh> note that we need to allow user revocation or change of these decisions
at any time

<fjh> users need information to make reasonable choices

<fjh> sl notes hence capability strings need some semantics

slewontin: capability semantics are essential for allowing the user to take
well-informed decisions

... key message: minimizing prompting and make it more meaningful

... another issue is that is possible to have very rich policies with this
kind of framework

... but at the end of the day most of the policies are all or nothing

<fjh> is this a decision for the DAP WG, whether apis drive interfaces that
require user interaction as if using manually or APIs that allow programmatic
access without user interaction, or both?

fhirsch: do we need to distinguish between APIs that launch native
applications vs. programmatical APIs

<nwidell> quit

fhirsch: Persistent security choices is of endeavour importance

... especially the possibility to minimize during installation time the
prompts required during runtime

Suresh: having two separate documents is a design choice

<fjh> stephen notes do not need to define how to establish trust domain but
allow binding of domain to access control

slewontin: what needs to be done is the mapping

Suresh: what is the distinction between features and capabilities?

<fjh> I'd like an explanation of how features fit into the flow described in
the paper

slewontin: we started with Symbian capabilities

Suresh: different platforms may have different mappings between capabilities
and features

fhirsch: DAP should define the capabilities and the link to the APIs defined
in DAP

<fjh> Bryan notes subject element in Bondi poilcy allows associate with trust

bryan: similar to BONDI approach, BONDI enables the trust domain definition
through the subject element

slewontin: it is basically the same model implemented in a different manner

bryan: is automated access enabled?

slewontin: yes, sending a message can be achieved through two different

... 1 - using the native app pre-populating the fields (destination, body....)

<fjh> two approaches - one sms message where user chooses to edit/send
prepopulated msg, versus api that sends message arg without user interaction

slewontin: 2 - Using messaging capability programatically with no User

<schittur2> The work flow on how the policy document is installed, applied and
managed needs to be understood and discussed

<schittur2> nick/ Suresh

<schittur2> nick\ Suresh

Anssik: what if the device does not support a particular feature, e.g. no
messaging client?

... need to have a mechanism to know if the invocation has been successful or

<Suresh> you can declare which features you "require" for the widget to run .
See <feature> element

fhisch: is that not supported through the feature element?

danielcoloma: BONDI uses the feature element to express dependencies on device

slewontin: risk of non-deterministic behaviour should be considered

bryan: we need to educate developers

slewontin: the flow diagrama included in the document is a very simple example

fhisch: where are features in that workflow?

slewontin: features are used in step number 5

... features are embedded in the APIs

<Suresh> Capabilities used in the access control policy need to be mapped to
the feature/API before access is granted.

slewontin: all the APIs are part of the service infrastructure, the APIs have
some metadata that is used when they are integrated in the service

... another aspect that needs to be considered is what happens if a widget is
installed in removable media and it is removed

... and later on mounted again. What happens with the persistent decissions
recorded before?

fhisch: is there any notion of session expiration?

slewontin: not now

bryan: need to conclude on something, we have different things on the table
and we need to decide what is doable

slewontin: BONDI and Nokia approaches are very similar, will be happy with a
specification that functionally does the right thing

<Bryan> bryan: Propose we defer the final discussion on realization of policy
framework aspects (e.g. per the charter, a "XML (or other) formalism
describing a security policy for concrete APIs"), and consider this during
development of the API specs, taking into account the aspects of the basic
webapp/widget and device API environment, e.g. (a) Feature element of
config.xml (in widget package) and requestFeature() API, defining what
features are requested by the webapp;

<Bryan> (b) Access element of widget config.xml, controlling what web
resources can be accessed using HTTP/HTTPS; (c) API security sensitive
functions and how user choice can be implied through user actions, thus not
needing an explicit policy in those use cases

### Work Items agreed on 2nd November session


fhisch: need to check if the list is the right one and volunteers

<dom> [should we try to look at one API (Contacts? Camera?) and do the
exercice of looking at its policy side?]

<fjh> **ACTION:** david provide use case with threat model scenarios [recorded
in [http://www.w3.org/2009/11/03-dap-minutes.html#action01][21]]

<trackbot> Created ACTION-45 - Provide use case with threat model scenarios
[on David Rogers - due 2009-11-10].

Suresh: should item 5 be assigned to each API "owner"

dom: we could have a look at one of the APIs we are already working in to
check this approach

<Claes1> Do we have a decision on a "generic" sensor API?

<fjh> model for naming capbilities and semantics

<scribe> **ACTION:** Daniel to provide input of capability definition and
semantics [recorded in [http://www.w3.org/2009/11/03-dap-

<trackbot> Created ACTION-46 - Provide input of capability definition and
semantics [on Daniel Coloma - due 2009-11-10].

<Laura_Arribas> **ACTION:** Laura to provide input on trust model and access
control model definitions [recorded in [http://www.w3.org/2009/11/03-dap-

<trackbot> Created ACTION-47 - Provide input on trust model and access control
model definitions [on Laura Arribas - due 2009-11-10].

<Suresh> **ACTION:** Suresh to propose a defintion for API access control, and
a possible model for policy enforcement [recorded in

<trackbot> Created ACTION-48 - Propose a defintion for API access control, and
a possible model for policy enforcement [on Suresh Chitturi - due 2009-11-10].

<mmani> Is the output of the policy work expected to offer primitives to allow
SIP-standards-based applications (which rely on endpoint policy enforcement
through user-interactions as well as automated decision-enforcements offloaded
to the endpoint

<mmani> facilitating 3rd party endpoints (multi-vendor) - wired and wireless -
to interoperate on policies (PDP-PAP policy exchange and endpoints as PDP to
interpret and PEP to enforce consistently is very desirable to cosumer and
enterprise markets

<mmani> I will speak up during the meeting further on this.

<timeless> Scribe: timeless

<scribe> ScribeNick: timeless

### Requirements Comments

FH: we're going to go through Laura's comments on the requirements documents

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

<Suresh> d

FH: We need the link to the BONDI 1.1 draft definitions of "feature"

Suresh: I think the definitions don't belong to the policy

FH: They apply to everything, so it makes sense to put them in the
requirements doc

... We have an API Requirements Document and a Policy Requirements Document

... We might have a packaging issue of where we put stuff

... Please mention the device capability comment again

... the second one... start there

<Suresh> we should consider putting all the definitions in one place

[Laura describes some portion of her email]

<jmorris> so does this picture work: [http://landsathandbook.gsfc.nasa.gov/han

<Suresh> rename APIs -> device APIs

<fjh> suggestion to take material relating capability to feature as separate
paragraph, first feature, then capability definition then info on relationship

Laura: the next comment is relating to the feature definition

[Laura looks for a link]

FH: I'd like to accept these edits

... and agree that I'll make changes

Laura: the next comment is a question, already raised by Steve this morning

... User control over decisions and rationale...

<fjh> add examples on implicit user authorization - e.g. sms example, camera

Laura: I think we agree that prompting should be avoided

... But for e.g. sms sending, explicit consent probably is necessary

FH: I'll draft some text to cover this

... I think it needs more work

ACTION FJH to update the requirements doc with edits based on Laura's comments

<trackbot> Created ACTION-49 - Update the requirements doc with edits based on
Laura's comments [on Frederick Hirsch - due 2009-11-10].

Laura: the next three related to open issues for resolution

... issue 1: user authorization v. policy authorities

... I expressed my opinion that bondi's approach that bryan covered this

... covers both approaches

... allowing an access control model

... or leaving the trust model out

[ scribe can't follow well ]

Laura: I think this comes from paddy's email

... I agree with what he stated

... I think bondi's approach, leaving it open to the implementor, is good

FH: So we might need to edit this, so that the questions indicate what will
happen, instead of that we don't know

Laura: 2, regarding granularity of user decisions

... here, again, I agree with the proposed approach

... that both approaches should be considered

... 3, in some cases, applications have something to say ...

... when taking security policy decisions ...

... an example in the document: a user explicitly clicks send an email now

... the user shouldn't get a confirmation request

FH: I think this is another case of implicit consent

... I think we should make a new section

... Now that we have a defined concept of implicit consent

... I propose that we take this out and make a new section about implicit

<fjh> integrate section 6 to implicit consent section

Laura: the last question... is access control level at the feature level

... and is it required at the capabilities level

Suresh: we're already making a distinction between...

FH: I'm saying that access controls may only be on the feature...

Laura: I think it should be done in both feature and device capability

FH: Bryan does it make sense to make the requirements document ...

... Update the requirements draft

... and agree later to have a resolution to indicate that we're happy with the

... that it matches our concensus

<dom> [Paddy’s comments][27]

<fjh> paddy comments [http://lists.w3.org/Archives/Public/public-device-

Laura: the first point paddy raises is about applicability

... widgets or websites as well

... in the case of bondi, both widgets and websites are covered

... different attributes are defined for both cases

FH: Don't we agree that we're handling both websites and widgets?

... Proposed resolution that we're covering both websites and widgets

[no objections]

**RESOLUTION: We're covering both websites and widgets**

Laura: the first five are related to widgets...

FH: This is talking about kinds of policies we could make

... I think this is something we could put in a draft for people to review

Laura: I agree with paddy's point. In order to agree to define a policy, it's
necessary to

... have examples

FH: we'll put use cases into a doc

Laura: relating to user configuration

... when a user makes a security decision

... this decision should be stored in the policy

... so the user doesn't have to make the decision repeatedly

FH: so this is a request for persistence of user consent...

<fjh> proposal to address persistence of user consent

Suresh: on definitions ...

... for the naming of the API

... I think it's better to rename it to Device APIs

<fjh> rename API to Device APIs

Suresh: I think the bit about Web IDL sounds more like a requirement than a

FH: Maybe it doesn't belong in the policy document

<fjh> remove WebIDL from API defin

Suresh: it isn't relevant to the definition

... Similarly the DCC API could be used

<fjh> remove that as well

Suresh: moving to the Device Capability definition ...

... you don't give an example of how one capability could map to another api

[Suresh mentions something about Java]

Suresh: I think a definition should be generic

... and easy to understand

... remove the last sentence "Note that ..." in the device capability

**RESOLUTION: We'll update the document accordingly. Based on changes proposed
by Laura, Paddy and Suresh**

### Use Cases

FH: looking at contacts or system info

[ time check ]

<Laura_Arribas> BONDI 1.1 document Feature definition: A Feature is is a set
of JavaScript APIs and/or device behaviours that provide access to specified
Device Capabilities. A Feature is identified uniquely by IRI, and is the unit
of expression of dependencies by BONDI Web Applications.

[ FH reviews the Agenda -- and lunch is on it ]

Suresh: on the policy requirements, is it agreed?

FH: no, it is not agreed

... we've had some comments/review which will make it better

... we can see about agreeing at the next meeting

... if we don't agree, we can work on it on the list

<fjh> plan forward - edit requirements document as agreed, discuss on list,
resolve to accept as reflecting consensus at subsequent meeting

richt: there are things specific to contacts, but I don't think we have to do
that here, we can do it on the mailing list

<dom> [Contacts API][28]

richt: I've put a placeholder in the spec for security and privacy

... I've taken a cue from the Geolocation group

<fjh> security considerations for both implementers and consumers

richt: each API should be standalone

... I think security/privacy considerations should be included with each API

FH: I'm not sure we should do exactly what geolocation did

slewontin: the comment I had at this point: Part of what needs to be in
security considerations is the way that the semantics of ....

[ slewontin will put that comment into the chat ]

slewontin: we ought to have a model of what capability semantics

... for example, semantics should be composed of

... for pim data

... we might identify a subcategory: contacts data

... there's how you might define the data part of the capability semantics

... and then we define a set of operations

... enumerate

... I'm not proposing that as the model, but it helps to have a model in mind

... having the data and operations in mind enables better structuring of
security modeling/concerns

FH: I think it's clear that there are certain generic operations

slewontin: We have a notion at Nokia of user info as opposed to system data

[ richt talks about how Geolocation does this ]

<maxf> [Geolocation API][29]

<slewontin> One element of security considerations for each API is to be able
to describe the security-relevant semantics of the API. As an example, and
it's just an example, we could identify the semantics by some kind of tuple of
the data involved and the operation

<fjh> categorize security and privacy guidelines for developer and consumers

<Suresh> I think what we want to know ultimately is to understand which API
calls related to a particular device capability and feature string

<slewontin> To be more specific in my example, a contacts operation operates
on a contact database and performs operations such as enumeration, reading,
modifying, etc.

<dom> ScribeNick: Laura_Arribas

<dom> ScribeNick: Suresh

<fjh> suresh agrees we should have security considerations for varous

<slewontin> One advantage of such an approach is that it makes explicit the
threats: for example, enumeration can be the basis of a dos attack

<fjh> suresh notes that each spec needs normative definition of capabilities
and features related to that API

<fjh> robin notes that we could have separate document that lists capabilities
and features associated with apis

FH: what is the conculsion?

Robin: Web IDL with annotations can be messy

richars: do we take the apporach of geo-loc API?

FH: we should not mimic that approach but look at it case by case

Bryan: Geo-loc is fairly loose in terms of testability,

... We should make sure all the normative parts are testable and focus on
those that are normative

Niklas: Having security considerations in every section may be confusing

<fjh> need to make considerations visible

<dom> [I think should this risk reveal as true, I think we'll look into
tooling to reduce the risk]

FH: we don't need to go the way exactly how geo-priv has done, especially
whether the location can be shared outside, etc

... i also agree that we need to find a good way to organize this but first we
need to get the content

<fjh> differences should be obvious

<Zakim> dom, you wanted to propose starting to look at actual security/privacy
risks in contacts api

Richard: Do we need to add security considerations to each API?

FH: We need to have privacy and threats for each API

<dom> [changing contacts e;g. to get you to call a surtaxed number; I have a
great business plan idea]

FH: We list all the generic threats and reference the APIs that would relate
to these threats

Bryan: threats can be complicated process, we need to spend a lot of time

... We can simplify by group the operations ...

<fjh> questions to ask of API; threats, privacy risks, user interaction

dom: User interaction part e.g. "do you want to acces the address book?" .
This is a dimension we need to look.

<Bryan> Bryan: suggest that we focus on read & write permissions as a way to
represent basic CRUD permissions; also anyone expecting to do threat analysis
should be aware that this is an involved process that requires specialized
tools and skills. It's a good thing to do, if you have time, but the results
can be complex and not always all that helpful.

FH: Good point: Is there an user interaction for each API?

David: For contacts there is a need for user inteaction

dom: We need to consider the user interactions not necessarily for contacts

<drogersuk> correction to the above, I said - I'm not sure there is a need for
user interaction for contacts

Robin: For each API, i don;t see a need for user interaction

<drogersuk> there is no obvious user consent point

David: The user content shoudl be part of the policy

Robin: There could be an application that uses the contact API to ask for user

<timeless> having a shelf exposing distinct address books

<timeless> is useful, but i would suggest *not* telling the app about the
addition of distinct address books

<drogersuk> suresh: Is this not more a discussion about how you use the APIs

<timeless> ... instead of telling the application about new address books /
los of address books

<timeless> ... if an address book mutates to gain/lose a contact, tell the
application about the net change in contacts

<timeless> ... if the user adds address books, provide the same information:
there are new contacts, but not access to information about the specific
address book. merely more available contacts

I think the use case Robin is talking should be a functional requirement

Robin: these are examples that one could use to build security principles
around APIs

FH: We need to understand in each API where the implict user consent applies

nwidell: The contacts API is different from geo-location in the sense that it
is more persistent

Bryan: let's not think in terms of UI too much, but let's make sure the
apporach is accessible....asynchronous model is better for programming but not

FH: i think there are two issues: user consent and the asynchronous call back

<dom> [I think the key about UI and user interactions it to get the browsers
vendors to propose user interaction models and see what security/privacy
threats they leave open]

<Bryan> bryan: caution against taking too specific an approach dependent upon
UI, the dependency upon one UI related approach may not work on other cases or
be accessible

Robin: Asynchronous model allows non-blocking

... i.e. does not force the user to respond

dom: We should not make this too complex, but maybe set the policy during

<Bryan> bryan: re mandating or recommending asynchronous methods as a
dependency on the security model, this may be "better programming practice"
but it does complicate program design, i.e. instead of an implicit state model
for processing you have to code explicit state processing for handling
multiple outstanding asynchronous requests

<Bryan> bryan: e.g. if I want to read multiple contacts but only have prompt-
oneshot permissions. The presentation of multiple prompt windows can be
confusing to the user, and a modal approach may be better (or at least prompts
of the same type should be queued to prevent confusing the user and obscuring
the screen on small-screen devices)

David: The policy be part of the manifest file

<dom> dom: I think we need to consider simple use cases for the restrictions
that the policy framework can impose

<drogersuk> correction above - the policy cannot be accurately expressed
through the manifest file of a widget - you cannot assume a user's intent from

<drogersuk> Discussion on the necessity for policy to accurately describe
detailed user intent

<dom> **ACTION:** Richard to add security/privacy considerations to Contacts
API inspired from Geolocation [recorded in [http://www.w3.org/2009/11/03-dap-

<trackbot> Created ACTION-50 - Add security/privacy considerations to Contacts
API inspired from Geolocation [on Richard Tibbett - due 2009-11-10].

<darobin> **ACTION:** Tran to add security/privacy considerations to SysInfo
API inspired from Geolocation [recorded in [http://www.w3.org/2009/11/03-dap-

<trackbot> Created ACTION-51 - Add security/privacy considerations to SysInfo
API inspired from Geolocation [on Dzung Tran - due 2009-11-10].

<maxf> Max: I think it's worth exploring the markup option ( a la File Upload)

<dom> maxf, would you take an action to look into it?

<maxf> … its the best way to implement Consent-by-Initiative

<maxf> **ACTION:** maxf to look at markup options for consent [recorded in

<trackbot> Created ACTION-52 - Look at markup options for consent [on Max
Froumentin - due 2009-11-10].

<inserted> ScribeNick: nallott

### API Issue Review

robin: intent 1 to use contacts as an example for an api review

... intent 2 to review sysinfo and split into phase1 and phase 2

... suggestion to put reference to each interface in the abstract

... conformance section specifies the product(s) - it is againt the product
which conformance is stated

dom: for apis there will only be one product

robin: editor tips: dont indent code blocks - class statement give free
keyword highlighting

anssi: should we abstract away the detail of the source of the contact

richard: we have a requirement for multi address books - issues this raises,
is how to indentify - which is default etc..

bryan: there is a requirement for the api to be able to selectively store in a
particular address book

suresh: voices support for clearly distinguised adddress books

bryan: the api should not be storage agnostic.

robin: the api does not need to make these distinctions, but the user agent

... needs to here a specifc use case for the identification of contact storage

<dom> ISSUE: should we make the contacts API data-storage-aware?

<trackbot> Created ISSUE-43 - Should we make the contacts API data-storage-
aware? ; please complete additional details at
[http://www.w3.org/2009/dap/track/issues/43/edit][33] .

suresh: the distinction between SIM and phone contacts has long history and is
know by the user

<dom> [it doesn't like look BONDI provides storage-awareness — does it?]

<richt> BONDI API does not provide storage awareness currently

<Zakim> JereK, you wanted to present a use case

jerek: use case for non-abstraction: when i search for contacts i need a
handle so that i can retrieve contact details

bryan: does not understand the distinction of the chrome and chromeless use

... principle issue is that if i want to design an application that interacts
with contacts without a ui, where the user is implicity making choices on the
exposed storage type - then there is a clear need for explicit (typed) storage

robin: proposal: we make all functions asynchronous if it is a securtiy entry

anssi: or it is a pending operation

tlr: described the use case where user wants to save a contact and after the
contact has been created is given the choice which address book to save it to.
This does not work well where add contact necessarily comes after the address
book has been requested

<scribe> **ACTION:** robin to make proposal on saving individual contacts to
different address books [recorded in [http://www.w3.org/2009/11/03-dap-

<trackbot> Created ACTION-53 - Make proposal on saving individual contacts to
different address books [on Robin Berjon - due 2009-11-10].

asnsi: can we harmonise method names across all apis to make things easier for
the user - where these method names are doing similar things (e.g add, remove,

marcin: draws attention to the design patterns that been already contributed
to the group - to help with the harmonisation processs

<marcin> Design pattern: delete() item deletion, remove() for removal from

robin: use case for distinguishing address books is: address book
synchronisations (analysing and propogating deltas)

<marcin> DOM3Core as example: [http://www.w3.org/TR/DOM-Level-3-Core/core.html
#ID-7C603781:][35] deleteData()

<marcin> [http://www.w3.org/TR/DOM-Level-3-Core/core.html#ID-1734834066:][36]

nallott: we need to clearly iterate the use cases before we start talking
about the api design

bryan: wanted clariffcation on the add address book

robin: add is clealy tied to a typed owner - hence add is on address book - so
add contat is implicit

<dom> I think we need to write use cases, and as we develop the API, that we
write the code matching (roughly) these use cases

claes: q?


marcin: teh application should not care where the data comes from - but that
the contactable fields should determine how this contact is presented

... optional keyword is not valid on this example (optional fields should be
at the end of the parameter list)

<JereK> +1 for contact first

bryan: object to the statement that we dont care where the contacts come from

<marcin> ErrorCallback should not be optional, since it could implicitly block

<dom> **ACTION:** Bryan to provide use cases where contacts API needs to be
aware of source of contacts [recorded in [http://www.w3.org/2009/11/03-dap-

<trackbot> Created ACTION-54 - Provide use cases where contacts API needs to
be aware of source of contacts [on Bryan Sullivan - due 2009-11-10].

slewontin: should we go even further on the abstraction and produce a generic
data base api - with add/delete/search - where each data base has its own
schema on type (e.g. fields on contacts)

robin: open question for multi fields - such as contact fields - what do we do
if these fields to not map onto implementations - such as phonegap

suresh: has reservations on supporting full vcard

<nwidell> Scribe: nwidell

<scribe> ScribeNick: nwidell

david: Wrt draft proposal on RFID/NFC. Need to make decision on scope and what
to do

... also scope has impact on IPR commitments

...question: Can we deliver it together with everything we have already
committed to do?

<dom> **ACTION:** RObin to extract prioritary APIS and put on the group home
page [recorded in [http://www.w3.org/2009/11/03-dap-

<trackbot> Created ACTION-55 - Extract prioritary APIS and put on the group
home page [on Robin Berjon - due 2009-11-11].

robin: we have already made a list of priorities within scope

<dom> **ACTION:** Robin to create a wiki page for future work on APIs
[recorded in [http://www.w3.org/2009/11/03-dap-minutes.html#action11][39]]

<trackbot> Created ACTION-56 - Create a wiki page for future work on APIs [on
Robin Berjon - due 2009-11-11].

jere: does RFID require re-charter?

fh: no, robin: we already have slightly flexible wording

<drogersuk> The group have agreed to stick to the APIs in the charter and not
work on new APIs not in the charter for now

robin: prioritization is for group, individual members are encouraged to work
on APIs not on prio list

<drogersuk> The group also agreed that as per a previous resolution the APIs
in the charter would proceed according to the prioritisation previously agreed

<fhirsch> reolocation WG)

Matt Womer: Mentions contacts format discussion in Geolocation, some
coordination useful

<dom> RESOLUTION: we'll use vCard as a starting point for the properties in
the Contacts API (and likewise for iCalendar / Calendar API)

### Systems info API

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

Bryan: We should take a vocabulary approach

<Zakim> JereK, you wanted to ask whether the suggested vocabularies capture
what we want

Bryan: a number of existing vocabularies does exist. No idea to

<dom> [Systems & info API][41]

Jere: Do the existing vocabularies cover same scope as current SI proposal?

<fhirsch> **ACTION:** fjh create wiki page with DAP draft documents [recorded
in [http://www.w3.org/2009/11/03-dap-minutes.html#action12][42]]

<trackbot> Created ACTION-57 - Create wiki page with DAP draft documents [on
Frederick Hirsch - due 2009-11-11].

<dom> **ACTION:** Bryan to make a concrete proposal with a vocabulary-based
approach to system & events, with a few examples (e.g. battery level)
[recorded in [http://www.w3.org/2009/11/03-dap-minutes.html#action13][43]]

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

Bryan: BONDI has some of this already

<dom> [Daniel notes that Telefonica also supports this approach]

Marcin: Vocabulary approach more optimized

<JereK> [notes that vocabulary-based approach does not cover events that
pertain to the system info]

<marcin> Jere, events can be added to vocabulary approach

suresh: what is the expected support from platform for the methods?

<Bryan> We should at least ensure that a list of properties should be
consistent with the DCO: [http://www.w3.org/TR/dcontology/][44]

<JereK> marcin, how? (or is the answer too long?)

### Administrativia

<dom> [Nov 11 is closed in some countries of Europe]

<marcin> Jere, e.g. propertyChangedCallback(propertyName, oldValue, newValue);

<marcin> Jere: oldValue & newValue could also be complex objects

fh: next telco Nov 25th

<dom> PROPOSED RESOLUTION: no meeting on Nov 11th, but keeping it on Nov 25th

**RESOLUTION: no meeting on Nov 11th, but keeping it on Nov 25th**

<JereK> marcin, it's the propertyName that bugs me

<marcin> Jere, why?

<dom> Proposed possible weeks for a F2F in Prague: March 8, March 15

<dom> (for a 3 days F2F)

<JereK> marcin, my callback then needs to distinguish between the properties -
I'd rather use dedicated callbacks. I think.

<marcin> Jere, we could have a model to register callbacks per property

<dom> **ACTION:** Dom to create a questionnaire for possible F2F in Prague in
March [recorded in [http://www.w3.org/2009/11/03-dap-

<trackbot> Created ACTION-59 - Create a questionnaire for possible F2F in
Prague in March [on Dominique Hazaël-Massieux - due 2009-11-11].

<JereK> [notes that XML Prague 2010 is March 13 & 14 if you already didn't -
sorry, I was distracted]

<dom> ACTION-59: close date on Nov 13

<trackbot> ACTION-59 Create a questionnaire for possible F2F in Prague in
March notes added

<marcin> Jere, in any model we may have e.g. 1000 properties. In the current
sysinfo model you would have to register 1000 callbacks.

### AoB

<JereK> marcin, I'm not interested in every one of them, but you have a point

<marcin> Jere, in the vocabulary approach - if optimized well - you could only
have to register two callbacks (success+error) with some specification of
properties you want to observe

richard: Should we have a roadmap?

<JereK> marcin, we have to stop meeting like this :-)

dom: we should have something to document intended progress

<marcin> Jere, s/two callbacks (success+error)/one callback/

<dom> **ACTION:** Dom to create the DAP roadmap (in the wiki or wherever)
[recorded in [http://www.w3.org/2009/11/03-dap-minutes.html#action15][46]]

<trackbot> Created ACTION-60 - Create the DAP roadmap (in the wiki or
wherever) [on Dominique Hazaël-Massieux - due 2009-11-11].

fh: please suggest things for agendas

... please indicate to list progress on actions


## Summary of Action Items

**[NEW]** **ACTION:** Bryan to make a concrete proposal with a vocabulary-
based approach to system & events, with a few examples (e.g. battery level)
[recorded in [http://www.w3.org/2009/11/03-dap-minutes.html#action13][43]]

**[NEW]** **ACTION:** Bryan to provide use cases where contacts API needs to
be aware of source of contacts [recorded in [http://www.w3.org/2009/11/03-dap-

**[NEW]** **ACTION:** Daniel to provide input of capability definition and
semantics [recorded in [http://www.w3.org/2009/11/03-dap-

**[NEW]** **ACTION:** david provide use case with threat model scenarios
[recorded in [http://www.w3.org/2009/11/03-dap-minutes.html#action01][21]]

**[NEW]** **ACTION:** Dom to create a questionnaire for possible F2F in Prague
in March [recorded in [http://www.w3.org/2009/11/03-dap-

**[NEW]** **ACTION:** Dom to create the DAP roadmap (in the wiki or wherever)
[recorded in [http://www.w3.org/2009/11/03-dap-minutes.html#action15][46]]

**[NEW]** **ACTION:** fjh create wiki page with DAP draft documents [recorded
in [http://www.w3.org/2009/11/03-dap-minutes.html#action12][42]]

**[NEW]** **ACTION:** Laura to provide input on trust model and access control
model definitions [recorded in [http://www.w3.org/2009/11/03-dap-

**[NEW]** **ACTION:** maxf to look at markup options for consent [recorded in

**[NEW]** **ACTION:** Richard to add security/privacy considerations to
Contacts API inspired from Geolocation [recorded in

**[NEW]** **ACTION:** Robin to create a wiki page for future work on APIs
[recorded in [http://www.w3.org/2009/11/03-dap-minutes.html#action11][39]]

**[NEW]** **ACTION:** RObin to extract prioritary APIS and put on the group
home page [recorded in [http://www.w3.org/2009/11/03-dap-

**[NEW]** **ACTION:** robin to make proposal on saving individual contacts to
different address books [recorded in [http://www.w3.org/2009/11/03-dap-

**[NEW]** **ACTION:** Suresh to propose a defintion for API access control,
and a possible model for policy enforcement [recorded in

**[NEW]** **ACTION:** Tran to add security/privacy considerations to SysInfo
API inspired from Geolocation [recorded in [http://www.w3.org/2009/11/03-dap-

[End of minutes]

* * *

Minutes formatted by David Booth's [scribe.perl][47] 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://www.w3.org/2009/dap/wiki/F2F_Agenda_2-3_November_2009%2C_TPAC

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

   [5]: #agenda

   [6]: #item01

   [7]: #item02

   [8]: #item03

   [9]: #item04

   [10]: #item05

   [11]: #item06

   [12]: #item07

   [13]: #item08

   [14]: #item09

   [15]: #ActionSummary

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

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

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

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

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

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

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

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

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

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

   [26]: http://landsathandbook.gsfc.nasa.gov/handbook/handbook_htmls/chapter6

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

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

   [29]: http://dev.w3.org/geo/api/spec-source.html

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

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

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

   [33]: http://www.w3.org/2009/dap/track/issues/43/edit

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

   [35]: http://www.w3.org/TR/DOM-Level-3-Core/core.html#ID-7C603781:

   [36]: http://www.w3.org/TR/DOM-Level-3-Core/core.html#ID-1734834066:

   [37]: http://www.w3.org/2009/11/03-dap-minutes.html#action09

   [38]: http://www.w3.org/2009/11/03-dap-minutes.html#action10

   [39]: http://www.w3.org/2009/11/03-dap-minutes.html#action11

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

   [41]: http://dev.w3.org/2009/dap/system-info/

   [42]: http://www.w3.org/2009/11/03-dap-minutes.html#action12

   [43]: http://www.w3.org/2009/11/03-dap-minutes.html#action13

   [44]: http://www.w3.org/TR/dcontology/

   [45]: http://www.w3.org/2009/11/03-dap-minutes.html#action14

   [46]: http://www.w3.org/2009/11/03-dap-minutes.html#action15

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

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

Received on Wednesday, 4 November 2009 01:02:58 UTC

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