See also: IRC log
<trackbot> Date: 03 November 2009
<dom> Minutes of Day 1
<DanielColoma> Scribe: DanielColoma
<scribe> ScribeNick: DanielColoma
<dom> Bryan’s use cases for Policy Interoperability
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 providers
<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?
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 vendors
... 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 definition
<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 focus
<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 sense
<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-apis/2009Nov/0006.html
Suresh: need to work in parallel, don't believe we are going to talk about security when defining APIs
<fjh> link to message http://lists.w3.org/Archives/Public/public-device-apis/2009Nov/0012.html
http://lists.w3.org/Archives/Public/public-device-apis/2009Nov/att-0012/SecurityPolicy_09.pdf
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 signing
... 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 domain
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 options
... 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 Interaction
<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 not
<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 features
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 infrastructure
... 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
http://lists.w3.org/Archives/Public/public-device-apis/2009Nov/0006.html
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]
<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-minutes.html#action02]
<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-minutes.html#action03]
<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 http://www.w3.org/2009/11/03-dap-minutes.html#action04]
<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
FH: we're going to go through Laura's comments on the requirements documents
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2009Oct/0243.html
<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/handbook/handbook_htmls/chapter6/images/sun_elevation.jpg
<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 example
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 morning
... 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 consent
<fjh> integrate section 6 to implicit consent section
Laura: the last question... is access control level at the feature level required
... 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 draft
... that it matches our concensus
<dom> Paddy’s comments
<fjh> paddy comments http://lists.w3.org/Archives/Public/public-device-apis/2009Nov/0004.html
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 offline
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 definition
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 definition
RESOLUTION: We'll update the document accordingly. Based on changes proposed by Laura, Paddy and Suresh
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
richt: I've put a placeholder in the spec for security and privacy considerations
... 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
<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 audiences
<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 consent
<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 for....
FH: i think there are two issues: user consent and the asynchronous call back issue
<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 installation
<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 there
<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-minutes.html#action05]
<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-minutes.html#action06]
<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 http://www.w3.org/2009/11/03-dap-minutes.html#action07]
<trackbot> Created ACTION-52 - Look at markup options for consent [on Max Froumentin - due 2009-11-10].
<inserted> ScribeNick: nallott
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 does
... needs to here a specifc use case for the identification of contact storage types
<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 .
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 case
... 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 types
robin: proposal: we make all functions asynchronous if it is a securtiy entry point
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-minutes.html#action08]
<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, find)
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 collection.
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: deleteData()
<marcin> http://www.w3.org/TR/DOM-Level-3-Core/core.html#ID-1734834066: removeChild()
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?
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 processing
<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-minutes.html#action09]
<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-minutes.html#action10]
<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]
<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)
<dom> http://lists.w3.org/Archives/Public/public-device-apis/2009Oct/0264.html
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
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]
<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]
<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/
<JereK> marcin, how? (or is the answer too long?)
<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-minutes.html#action14]
<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.
<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]
<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
<dom> ADJOURNED
