16:34:27 <RRSAgent> RRSAgent has joined #dap
16:34:27 <RRSAgent> logging to http://www.w3.org/2009/11/03-dap-irc
16:34:29 <trackbot> RRSAgent, make logs world
16:34:29 <Zakim> Zakim has joined #dap
16:34:31 <trackbot> Zakim, this will be DAP
16:34:31 <Zakim> I do not see a conference matching that name scheduled within the next hour, trackbot
16:34:32 <trackbot> Meeting: Device APIs and Policy Working Group Teleconference
16:34:32 <trackbot> Date: 03 November 2009
16:34:56 <dom> s/Teleconference/F2F Day 2/
16:35:03 <dom> Chair: Robin, Frederick
16:35:13 <dom> Agenda: http://www.w3.org/2009/dap/wiki/F2F_Agenda_2-3_November_2009%2C_TPAC
16:35:39 <dom> -> http://www.w3.org/2009/11/02-dap-minutes.html Minutes of Day 1
16:35:51 <dom> RRSAgent, draft minutes
16:35:51 <RRSAgent> I have made the request to generate http://www.w3.org/2009/11/03-dap-minutes.html dom
16:36:50 <Claes> Claes has joined #dap
16:36:59 <soonho> soonho has joined #dap
16:37:14 <Claes> Present+ Claes_Nilsson
16:37:23 <dom> Present+ DomHM
16:37:31 <darobin> darobin has joined #dap
16:37:56 <DanielColoma> Present+ DanielColoma
16:38:57 <marengo> marengo has joined #dap
16:38:58 <maxf> maxf has joined #dap
16:39:06 <marengo> Present+ Marco_Marengo
16:39:06 <slewontin> slewontin has joined #dap
16:39:08 <Bryan> Present+ BryanSullivan
16:39:22 <maxf> Present+ maxf
16:39:24 <Laura_Arribas> Laura_Arribas has joined #dap
16:39:29 <slewontin> present+ Steve Lewontin
16:39:40 <Laura_Arribas> Present+ Laura_Arribas
16:39:42 <AnssiK> AnssiK has joined #dap
16:39:49 <AnssiK> Present+ Anssi_Kostiainen
16:40:13 <Kangchan> Kangchan has joined #dap
16:40:55 <richt> richt has joined #dap
16:41:06 <richt> Present+ Richard_Tibbett
16:41:11 <nwidell> nwidell has joined #dap
16:41:28 <nwidell> Present +Niklas_Widell
16:42:47 <Kangchan> Present+ Kangchan_Lee
16:42:50 <Claes1> Claes1 has joined #dap
16:43:42 <jmorris> jmorris has joined #dap
16:44:17 <kaz> kaz has joined #dap
16:44:26 <kaz> kaz has left #dap
16:45:35 <Ingmar> Ingmar has joined #dap
16:45:37 <drogersuk> drogersuk has joined #dap
16:46:47 <DanielColoma> Scribe: DanielColoma
16:47:03 <DanielColoma> ScribeNick: DanielColoma
16:47:08 <mmielke> mmielke has joined #dap
16:47:34 <soonho> Present+ Soonho_Lee
16:48:24 <dom> -> http://lists.w3.org/Archives/Public/public-device-apis/2009Nov/0011.html Bryan’s use cases for Policy Interoperability
16:49:51 <DanielColoma> Bryan: Lots of devices with potentially multiple Web Runtimes
16:50:07 <DanielColoma> ... consistency depends on the availability of a consistent language
16:51:56 <DanielColoma> ... users with multiple devices expect the same security UE across all of them
16:52:56 <DanielColoma> ... lots of questions about who do what with regards to policies
16:54:15 <nord_c> nord_c has joined #dap
16:55:13 <mani> mani has joined #dap
16:56:04 <Ingmar> Present+ Ingmar_Kliche
16:56:12 <DanielColoma> ... use case 3 provides an example of the policy lifecycle
16:56:33 <fjh> q+
16:56:50 <DanielColoma> ... start with a default policy, that can be modified by the end-user and also by a remote management server 
16:56:58 <dom> q+ to ask about existing/planned implementations of similar systems
16:57:33 <DanielColoma> fhisch: lots of actors in the use cases
16:57:55 <DanielColoma> ... question, what if multiple SIM Cards are used in the device?
16:58:51 <slewontin> q+
16:59:28 <arve> arve has joined #dap
16:59:31 <DanielColoma> bryan: It will depend on how policies on the device depend on the service providers
17:00:16 <Suresh> Suresh has joined #dap
17:00:19 <fjh> who are the actors: end-user, mobile service provider, internet service provider, developer
17:00:23 <DanielColoma> ... the user is the key party on choice if decissions are to be made
17:00:24 <fjh> ack fjh
17:00:26 <fjh> ack dom
17:00:26 <Zakim> dom, you wanted to ask about existing/planned implementations of similar systems
17:00:55 <DanielColoma> dom: who has expressed interest in such a policy system in WRT?
17:00:57 <fjh> Topic: Policy Use Case
17:01:14 <DanielColoma> bryan: there are browser vendors involved in BONDI
17:01:37 <DanielColoma> dom: the charter says we will define a policy framework
17:01:39 <mib_l0vf3b> mib_l0vf3b has joined #dap
17:01:56 <Suresh> Present+Suresh Chitturi
17:02:06 <Suresh> Present+
17:02:13 <nwidell> Present+ Niklas_Widell
17:02:40 <DanielColoma> dom: the success of such a proposal depends on the commitment of the browser vendors
17:03:30 <JonathanJ> JonathanJ has joined #dap
17:03:44 <JonathanJ> Present+JonathanJ
17:03:52 <DanielColoma> dom: this a much broader topic to what is stated in the charter
17:04:44 <Suresh> q+
17:05:23 <marcin> marcin has joined #dap
17:05:51 <dom> ack slewo
17:05:59 <DanielColoma> fhisch: the key question is whether we need that level of detail to achieve the targets of the charter
17:06:10 <fjh> ack slewontin
17:06:53 <DanielColoma> slewontin: nokia has not considered use cases such as the widget vendor providing also the policy
17:07:05 <fjh> fjh has joined #dap
17:07:18 <DanielColoma> ... decoupled policy framework from management
17:08:10 <DanielColoma> ... key issues are how policies are specified and enforced
17:09:27 <Marcos> Marcos has joined #dap
17:09:35 <DanielColoma> 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
17:09:58 <JonathanJ> rrsagent, draft minutes
17:09:58 <RRSAgent> I have made the request to generate http://www.w3.org/2009/11/03-dap-minutes.html JonathanJ
17:10:20 <tlr> tlr has joined #dap
17:11:02 <mmani> mmani has joined #dap
17:12:56 <DanielColoma> Suresh: when is the policy enforced: at installation, during runtime? what are the implications of policy changes
17:13:39 <fjh> fjh has joined #dap
17:13:46 <dom> q?
17:13:48 <fjh> zakim, who is here?
17:13:49 <DanielColoma> fhisch: my assumption is that policy is check during every invocation
17:13:49 <Zakim> sorry, fjh, I don't know what conference this is
17:13:49 <dom> ack su
17:13:50 <Zakim> On IRC I see fjh, mmani, tlr, Marcos, marcin, JonathanJ, mib_l0vf3b, Suresh, arve, nord_c, markusm, drogersuk, Ingmar, jmorris, Claes1, nwidell, richt, Kangchan, AnssiK,
17:13:53 <fjh> q?
17:13:53 <Zakim> ... Laura_Arribas, slewontin, maxf, marengo, darobin, soonho, Zakim, RRSAgent, DanielColoma, MoZ, Bryan, Hixie, lgombos, ilkka, arg, trackbot, dom
17:13:56 <DanielColoma> s/check/checked
17:14:55 <howard> howard has joined #dap
17:15:23 <Suresh> We need to define a framework that can be testable/interoperable but also provide flexibilty to allow different policy documents
17:15:49 <DanielColoma> fhisch: feedback from other UE centric communities is not very positive on these kind of use cases such as corporate use cases
17:16:03 <Kai> Kai has joined #dap
17:16:44 <fjh> q+
17:16:49 <DanielColoma> Ileana: challenge is finding a common denominator on all the views
17:17:11 <DanielColoma> ... the definition of APIs should hence be the key priority
17:18:19 <DanielColoma> fhisch: security is key, we should consider security as part of the API definition
17:20:05 <shepazu> shepazu has joined #dap
17:20:14 <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
17:21:02 <DanielColoma> bryan: the determination of the security sensitive aspects should be the key focus
17:21:19 <dom> q+
17:21:25 <fjh> ack fjh
17:21:34 <Suresh> including context, national, business, enterprise, etc.
17:22:49 <fjh> discussion of whether to wait to define policy framework 
17:22:55 <DanielColoma> dom: waiting to see if we need to define the policy exchange format makes sense
17:23:00 <fjh> dom notes there are other security items we can work on
17:23:11 <howard> howard has joined #dap
17:23:22 <DanielColoma> dom: ... we can focus on other security aspects
17:23:39 <Suresh> i like the idea of working in parallel
17:23:57 <Suresh> q+
17:23:59 <fjh> see http://lists.w3.org/Archives/Public/public-device-apis/2009Nov/0006.html
17:24:12 <dom> ack dom
17:24:16 <MikeSmith> MikeSmith has joined #dap
17:24:22 <fjh> ack suresh
17:25:27 <DanielColoma> Suresh: need to work in parallel, don't believe we are going to talk about security when defining APIs
17:27:08 <soonho> soonho has joined #dap
17:27:20 <DanielColoma> topic updated Nokia policy input
17:28:05 <fjh> link to message http://lists.w3.org/Archives/Public/public-device-apis/2009Nov/0012.html
17:28:07 <DanielColoma> http://lists.w3.org/Archives/Public/public-device-apis/2009Nov/att-0012/SecurityPolicy_09.pdf
17:29:09 <DanielColoma> slewontin: similar to BONDI approach, BONDI model for capabilities may be a bit better
17:29:23 <DanielColoma> ... it is not Nokia proposal in opposition to BONDI proposal
17:30:14 <DanielColoma> ... two components: trust component and access control component
17:30:45 <DanielColoma> ... a trust domain is governed by a trust policy
17:31:30 <DanielColoma> ... trust policy is harder to get right than access control policy
17:31:59 <fjh> s/topic updated/Topic: Updated
17:32:31 <DanielColoma> ... trust policy depends on aspect related with business issues such as signing
17:32:40 <DanielColoma> s/aspect/aspects
17:34:10 <DanielColoma> ... hence it is important to split trust from access control policies
17:34:13 <fjh> slewontin recommends separate trust policy from access policy, 
17:34:25 <fjh> minimize user interaction
17:34:58 <DanielColoma> ... it is also key to minimize prompting
17:36:19 <DanielColoma> ... it is useful to have the concept of persistency as a way to minimize user prompting
17:36:27 <DanielColoma> s/to have/to support
17:36:29 <fjh> stephen notes value of persistent sessions, allow install time initialization with minimal subsequent configuration and prompting
17:36:30 <marcin> marcin has joined #dap
17:36:31 <fjh> q+
17:38:25 <DanielColoma> bryan: in BONDI concepts such as blanket, session and one-shot restrict the persistency decisions that the user may take
17:39:04 <fjh> note that we need to allow user revocation or change of these decisions at any time
17:39:41 <fjh> users need information to make reasonable choices
17:40:18 <fjh> sl notes hence capability strings need some semantics
17:40:26 <DanielColoma> slewontin: semantics are essential for allowing the user to take well-informed decisions
17:40:41 <drogersuk> drogersuk has joined #dap
17:40:54 <DanielColoma> s/semantics/capability semantics
17:41:31 <DanielColoma> ... key message: minimizing prompting and make it more meaningful
17:42:02 <howard> howard has joined #dap
17:42:27 <Suresh> q+
17:42:51 <DanielColoma> ... another issue is that is possible to have very rich policies with this kind of framework
17:43:12 <DanielColoma> ... but at the end of the day most of the policies are all or nothing
17:46:05 <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?
17:47:28 <DanielColoma> fhirsch: do we need to distinguish between APIs that launch native applications vs. programmatical APIs
17:47:31 <Bryan> q+
17:47:46 <AnssiK> q+
17:49:38 <nwidell> quit
17:50:20 <DanielColoma> fhirsch: Persistent security choices is of endeavour importance
17:50:21 <tlr> q?
17:50:45 <DanielColoma> ... especially the possibility to minimize during installation time the prompts required during runtime 
17:51:36 <fjh> ack fjh
17:52:05 <fjh> ack Suresh
17:52:37 <DanielColoma> Suresh: having two separate documents is a design choice
17:53:00 <fjh> stephen notes do not need to define how to establish trust domain but allow binding of domain to access control 
17:53:14 <DanielColoma> slewontin: what needs to be done is the mapping
17:53:38 <nwidell> nwidell has joined #dap
17:54:21 <fjh> q+
17:54:24 <DanielColoma> Suresh: what is the distinction between features and capabilities?
17:54:39 <fjh> I'd like an explanation of how features fit into the flow described in the paper
17:55:04 <DanielColoma> slewontin: we started with Symbian capabilities
17:55:19 <DanielColoma> Suresh: different platforms may have different mappings between capabilities and features
17:56:06 <DanielColoma> fhirsch: DAP should define the capabilities and the link to the APIs defined in DAP
17:56:31 <claudio2> claudio2 has joined #dap
17:56:40 <fjh> ack Bryan
17:57:18 <fabrice> fabrice has joined #dap
17:57:34 <fjh> Bryan notes subject element in Bondi poilcy allows associate with trust domain
17:57:54 <DanielColoma> bryan: similar to BONDI approach, BONDI enables the trust domain definition through the subject element
17:58:08 <DanielColoma> slewontin: it is basically the same model implemented in a different manner
17:58:57 <DanielColoma> bryan: is automated access enabled?
17:59:19 <DanielColoma> slewontin: yes, sending a message can be achieved through two different options
17:59:39 <DanielColoma> .. 1 - using the native app pre-populating the fields (destination, body...)
17:59:42 <fjh> two approaches - one sms message where user chooses to edit/send prepopulated msg, versus api that sends message arg without user interaction
17:59:43 <schittur2> schittur2 has joined #dap
17:59:45 <DanielColoma> s/../.../
18:00:10 <fjh> ack AnssiK
18:00:20 <Bryan> q-
18:00:21 <DanielColoma> ... 2 - Using messaging capability programatically with no User Interaction
18:01:07 <schittur2> The work flow on how the policy document is installed, applied and managed needs to be understood and discussed
18:01:16 <schittur2> nick/ Suresh
18:01:23 <schittur2> nick\ Suresh
18:02:17 <DanielColoma> Anssik: what if the device does not support a particular feature, e.g. no messaging client?
18:02:51 <DanielColoma> ... need to have a mechanism to know if the invocation has been successful or not
18:03:27 <DanielColoma> q+
18:04:07 <Suresh> you can declare which features you "require" for the widget to run . See <feature> element
18:04:11 <DanielColoma> q-
18:04:37 <DanielColoma> fhisch: is that not supported through the feature element?
18:05:03 <DanielColoma> danielcoloma: BONDI uses the feature element to express dependencies on device features
18:06:07 <DanielColoma> slewontin: risk of non-deterministic behaviour should be considered
18:06:57 <DanielColoma> bryan: we need to educate developers
18:07:55 <fjh> q?
18:08:58 <DanielColoma> slewontin: the flow diagrama included in the document is a very simple example
18:09:09 <DanielColoma> fhisch: where are features in that workflow?
18:09:26 <DanielColoma> slewontin: features are used in step number 5
18:09:38 <DanielColoma> slewonting: features are embedded in the APIs
18:09:47 <DanielColoma> s/slewonting/slewontin
18:12:20 <Suresh> Capabilities used in the access control policy need to be mapped to the feature/API before access is granted.
18:12:44 <DanielColoma> 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
18:14:37 <fjh> ack fjh
18:14:52 <DanielColoma> slewontin: another aspect that needs to be considered is what happens if a widget is installed in removable media and it is removed
18:15:19 <Bryan> q+
18:15:26 <DanielColoma> ... and later on mounted again. What happens with the persistent decissions recorded before?
18:15:36 <tlr> q?
18:16:07 <fjh> ack Bryan
18:16:16 <Bryan> q+
18:16:17 <DanielColoma> fhisch: is there any notion of session expiration?
18:16:26 <DanielColoma> slewontin: not now
18:16:32 <Bryan> q-
18:17:24 <DanielColoma> bryan: need to conclude on something, we have different things on the table and we need to decide what is doable
18:23:09 <DanielColoma> slewontin: BONDI and Nokia approaches are very similar, will be happy with a specification that functionally does the right thing
18:23:58 <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;
18:23:58 <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
18:24:24 <DanielColoma> Topic: Work Items agreed on 2nd November session
18:24:28 <DanielColoma> http://lists.w3.org/Archives/Public/public-device-apis/2009Nov/0006.html
18:25:19 <DanielColoma> fhisch: need to check if the list is the right one and volunteers
18:26:10 <dom> [should we try to look at one API (Contacts? Camera?) and do the exercice of looking at its policy side?]
18:26:42 <JonathanJ> rrsagent, draft minutes
18:26:42 <RRSAgent> I have made the request to generate http://www.w3.org/2009/11/03-dap-minutes.html JonathanJ
18:30:14 <fjh> action: david provide use case with threat model scenarios
18:30:14 <trackbot> Created ACTION-45 - Provide use case with threat model scenarios [on David Rogers - due 2009-11-10].
18:31:02 <JariA> JariA has joined #dap
18:31:09 <DanielColoma> Suresh: should item 5 be assigned to each API "owner"
18:31:59 <DanielColoma> dom: we could have a look at one of the APIs we are already working in to check this approach
18:34:21 <Claes1> Do we have a decision on a "generic" sensor API?
18:34:42 <fjh> model for naming capbilities and semantics
18:35:48 <DanielColoma> ACTION: Daniel to provide input of capability definition and semantics
18:35:48 <trackbot> Created ACTION-46 - Provide input of capability definition and semantics [on Daniel Coloma - due 2009-11-10].
18:36:34 <Laura_Arribas> action: Laura to provide input on trust model and access control model definitions
18:36:34 <trackbot> Created ACTION-47 - Provide input on trust model and access control model definitions [on Laura Arribas - due 2009-11-10].
18:36:34 <Suresh> Suresh has joined #dap
18:37:28 <soonho> soonho has left #dap
18:38:05 <Suresh> action: Suresh to propose a defintion for API access control, and a possible model for policy enforcement
18:38:05 <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].
18:55:39 <marengo> marengo has joined #dap
18:57:46 <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
18:58:06 <markusm> markusm has joined #dap
19:01:27 <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
19:10:35 <mmani> I will speak up during the meeting further on this.
19:12:01 <timeless_mbp> timeless_mbp has joined #dap
19:12:27 <timeless> Scribe: timeless
19:12:31 <timeless> ScribeNick: timeless
19:12:39 <claudio> claudio has joined #dap
19:12:41 <timeless> Topic: Requirements Comments
19:12:49 <Claes> Claes has joined #dap
19:13:15 <soonho> soonho has joined #dap
19:13:24 <timeless> FH: we're going to go through Laura's comments on the requirements documents
19:13:50 <darobin> darobin has joined #dap
19:13:57 <JonathanJ> JonathanJ has joined #dap
19:14:06 <fjh> http://lists.w3.org/Archives/Public/public-device-apis/2009Oct/0243.html
19:14:20 <Suresh> d
19:14:58 <timeless> FH: We need the link to the BONDI 1.1 draft definitions of "feature"
19:15:21 <nord_c> nord_c has joined #dap
19:15:22 <timeless> Suresh: I think the definitions don't belong to the policy
19:15:36 <timeless> FH: They apply to everything, so it makes sense to put them in the requirements doc
19:16:07 <timeless> FH: We have an API Requirements Document and a Policy Requirements Document
19:16:21 <timeless> FH: We might have a packaging issue of where we put stuff
19:16:52 <JereK> JereK has joined #dap
19:17:03 <timeless> FH: Please mention the device capability comment again
19:17:12 <timeless> ... the second one... start there
19:17:17 <Suresh> we should consider putting all the definitions in one place
19:19:16 <timeless> [Laura describes some portion of her email]
19:19:27 <jmorris> so does this picture work:  http://landsathandbook.gsfc.nasa.gov/handbook/handbook_htmls/chapter6/images/sun_elevation.jpg
19:19:51 <Marcos> Marcos has joined #dap
19:19:54 <Suresh> rename APIs -> device APIs
19:20:22 <ArtB> ArtB has joined #dap
19:20:38 <ArtB> rrsagent, pointer?
19:20:38 <RRSAgent> See http://www.w3.org/2009/11/03-dap-irc#T19-20-38
19:20:55 <fjh> suggestion to take material relating capabiltity to feature as separate paragraph, first feature, then capability defintion then info on relationship
19:20:59 <timeless> s/capabiltity/capability/
19:21:04 <timeless> s/defintion/definition/
19:21:23 <timeless> Laura: the next comment is relating to the feature definition
19:21:44 <timeless> [Laura looks for a link]
19:22:14 <timeless> FH: I'd like to accept these edits 
19:22:30 <timeless> FH: and agree that I'll make changes
19:22:33 <timeless> q+ Suresh 
19:22:52 <timeless> Laura: the next comment is a question, already raised by Steve this morning
19:23:04 <timeless> Laura: User control over decisions and rationale...
19:23:28 <nwidell> nwidell has joined #dap
19:23:37 <fjh> add examples on implicit user authorization - e.g. sms example, camera example
19:24:22 <JonathanJ> rrsagent, draft minutes
19:24:22 <RRSAgent> I have made the request to generate http://www.w3.org/2009/11/03-dap-minutes.html JonathanJ
19:24:22 <timeless> Laura: I think we agree that prompting should be avoided
19:24:46 <timeless> Laura: But for e.g. sms sending, explicit consent probably is necessary
19:24:51 <timeless> FH: I'll draft some text to cover this
19:25:00 <timeless> FH: I think it needs more work
19:25:18 <timeless> ACTION FJH to update the requirements doc with edits based on Laura's comments
19:25:18 <trackbot> Created ACTION-49 - Update the requirements doc with edits based on Laura's comments [on Frederick Hirsch - due 2009-11-10].
19:25:27 <AnssiK> AnssiK has joined #dap
19:25:38 <timeless> Laura: the next three related to open issues for resolution
19:25:55 <timeless> Laura: issue 1: user authorization v. policy authorities
19:26:22 <timeless> ... I expressed my opinion that bondi's approach that bryan covered this morning
19:26:28 <timeless> ... covers both approaches
19:26:39 <timeless> ... allowing an access control model
19:26:46 <timeless> ... or leaving the trust model out
19:26:52 <timeless> [ scribe can't follow well ]
19:27:06 <timeless> Laura: I think this comes from paddy's email
19:27:11 <timeless> ... I agree with what he stated
19:27:34 <timeless> ... I think bondi's approach, leaving it open to the implementor, is good
19:27:54 <timeless> FH: So we might need to edit this, so that the questions indicate what will happen, instead of that we don't know
19:28:11 <timeless> Laura: 2, regarding granularity of user decisions
19:28:31 <timeless> .. here, again, I agree with the proposed approach
19:28:37 <timeless> ... that both approaches should be considered
19:28:44 <timeless> q?
19:29:18 <timeless> Laura: 3, in some cases, applications have something to say ...
19:29:27 <timeless> ... when taking security policy decisions ...
19:29:41 <timeless> ... an example in the document: a user explicitly clicks send an email now
19:29:49 <timeless> ... the user shouldn't get a confirmation request
19:30:14 <timeless> FH: I think this is another case of implicit consent
19:30:18 <timeless> ... I think we should make a new section
19:30:43 <timeless> ... Now that we have a defined concept of implicit consent
19:30:59 <timeless> ... I propose that we take this out and make a new section about implicit consent
19:31:06 <fjh> integrate section 6 to implicit consent section
19:31:28 <timeless> Laura: the last question... is access control level at the feature level required
19:31:50 <timeless> ... and is it required at the capabilities level
19:32:20 <tlr> tlr has joined #dap
19:32:44 <timeless> Suresh: we're already making a distinction between...
19:33:01 <timeless> FH: I'm saying that access controls may only be on the feature...
19:33:13 <timeless> Laura: I think it should be done in both feature and device capability
19:33:58 <timeless> FH: Bryan does it make sense to make the requirements document ...
19:34:26 <timeless> FH: Update the requirements draft
19:34:37 <timeless> ... and agree later to have a resolution to indicate that we're happy with the draft
19:34:43 <Kai> Kai has joined #dap
19:34:56 <timeless> ... that it matches our concensus
19:35:27 <dom> -> http://lists.w3.org/Archives/Public/public-device-apis/2009Nov/0004.html Paddy’s comments
19:35:37 <fjh> paddy comments http://lists.w3.org/Archives/Public/public-device-apis/2009Nov/0004.html
19:36:03 <timeless> Laura: the first point paddy raises is about applicability
19:36:08 <timeless> ... widgets or websites as well
19:36:19 <timeless> ... in the case of bondi, both widgets and websites are covered
19:36:27 <timeless> ... different attributes are defined for both cases
19:36:37 <timeless> FH: Don't we agree that we're handling both websites and widgets?
19:36:53 <timeless> FH: Proposed resolution that we're covering both websites and widgets
19:36:57 <timeless> [no objections]
19:37:11 <timeless> RESOLUTION: We're covering both websites and widgets
19:38:04 <timeless> Laura: the first five are related to widgets...
19:38:24 <timeless> FH: This is talking about kinds of policies we could make
19:38:33 <slewontin> q+
19:38:38 <timeless> FH: I think this is something we could put in a draft for people to review offline
19:38:57 <timeless> Laura: I agree with paddy's point. In order to agree to define a policy, it's necessary to 
19:39:03 <timeless> ... have examples
19:39:14 <timeless> FH: we'll put use cases into a doc
19:39:24 <timeless> Laura: relating to user configuration
19:39:31 <timeless> ... when a user makes a security decision
19:39:37 <timeless> ... this decision should be stored in the policy
19:39:45 <timeless> ... so the user doesn't have to make the decision repeatedly
19:40:01 <timeless> FH: so this is a request for persistence of user consent...
19:40:26 <fjh> proposal to address persistence of user consent
19:40:49 <timeless> ack Suresh
19:40:54 <timeless> Suresh: on definitions ...
19:41:23 <timeless> ... for the naming of the API
19:41:30 <timeless> ... I think it's better to rename it to Device APIS
19:41:32 <fjh> rename API to Device APIs
19:41:34 <timeless> s/APIS/APIs/
19:41:50 <timeless> Suresh: I think the bit about Web IDL sounds more like a requirement than a definition
19:41:58 <timeless> FH: Maybe it doesn't belong in the policy document
19:42:08 <fjh> remove WebIDL from API defin
19:42:10 <timeless> Suresh: it isn't relevant to the definition
19:42:23 <timeless> Suresh: Similarly the DCC API could be used
19:42:36 <fjh> remove that as well
19:42:48 <timeless> Suresh: moving to the Device Capability definition ...
19:43:04 <timeless> ... you don't give an example of how one capability could map to another api
19:43:26 <timeless> [Suresh mentions something about Java]
19:43:29 <timeless> Suresh: I think a definition should be generic
19:43:38 <timeless> ... and easy to understand
19:43:57 <timeless> Suresh: remove the last sentence "Note that ..." in the device capability definition
19:44:58 <timeless> RESOLUTION: We'll update the document accordingly. Based on changes proposed by Laura, Paddy and Suresh
19:44:59 <timeless> q?
19:45:20 <timeless> q-
19:45:25 <timeless> q- slewontin
19:45:33 <darobin> ack slewontin 
19:45:38 <timeless> Topic: Use Cases
19:45:58 <timeless> FH: looking at contacts or system info
19:46:09 <timeless> [ time check ]
19:46:14 <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.
19:46:27 <slewontin> q?
19:47:12 <timeless> [ FH reviews the Agenda -- and lunch is on it ]
19:47:45 <timeless> Suresh: on the policy requirements, is it agreed?
19:47:50 <timeless> FH: no, it is not agreed
19:48:05 <timeless> ... we've had some comments/review which will make it better
19:48:19 <timeless> FH: we can see about agreeing at the next meeting
19:48:25 <timeless> ... if we don't agree, we can work on it on the list
19:50:37 <fjh> plsn forward - edit requirements document as agreed, discuss on list, resolve to accept as reflecting consensus at subsequent meeting
19:50:52 <fjh> s/plsn/plan
19:51:04 <timeless> 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
19:51:10 <dom> -> http://dev.w3.org/2009/dap/contacts/Overview.html Contacts API
19:51:16 <timeless> ... I've put a placeholder in the spec for security and privacy considerations
19:51:45 <timeless> .... I've taken a Q from the Geolocation group
19:52:03 <fjh> security considerations for both implementers and consumers
19:52:07 <timeless> ... each API should be standalone
19:52:11 <dom> s/Q/cue/
19:52:31 <timeless> ... I think security/privacy considerations should be included with each API
19:52:45 <slewontin> q+
19:52:45 <timeless> FH: I'm not sure we should do exactly what geolocation did
19:53:04 <timeless> q?
19:53:12 <timeless> ack slewontin
19:53:44 <timeless> slewontin: the comment I had at this point: Part of what needs to be in security considerations is the way that the semantics of ....
19:54:00 <timeless> [ slewontin will put that comment into the chat ]
19:54:14 <timeless> slewontin: we ought to have a model of what capability semantics
19:54:28 <timeless> ... for example, semantics should be composed of 
19:54:55 <timeless> ... for pim data
19:55:03 <timeless> ... we might identify a subcategory: contacts data
19:55:16 <timeless> ... there's how you might define the data part of the capability semantics
19:55:25 <timeless> ... and then we define a set of operations
19:55:30 <timeless> ... enumerate
19:55:42 <timeless> ... I'm not proposing that as the model, but it helps to have a model in mind
19:56:03 <timeless> ... having the data and operations in mind enables better structuring of security modeling/concerns
19:56:17 <timeless> FH: I think it's clear that there are certain generic operations
19:56:44 <timeless> slewontin: We have a notion at Nokia of user info as opposed to system data
19:57:04 <fjh> ack slewontin
19:57:06 <Suresh> Suresh has joined #dap
19:57:40 <timeless> [ richt talks about how Geolocation does this ]
19:58:05 <maxf> http://dev.w3.org/geo/api/spec-source.html
19:58:17 <dom> s/http/-> http/
19:58:23 <dom> s/html/html Geolocation API/
19:58:24 <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
19:58:28 <dom> RRSAgent, draft minutes
19:58:28 <RRSAgent> I have made the request to generate http://www.w3.org/2009/11/03-dap-minutes.html dom
19:58:43 <Suresh> q+
19:58:51 <fjh> categorize security and privacy guidelines for developer and  consumers
19:58:53 <fjh> q+
19:59:08 <Bryan> q+
19:59:37 <Suresh> I think what we want to know ultimately is to understand which API calls related to a particular device capability and feature string
19:59:52 <dom> q?
19:59:58 <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.
20:00:11 <dom> ScribeNick: Laura_Arribas
20:00:16 <dom> ScribeNick: Suresh
20:01:01 <fjh> q?
20:01:04 <fjh> ack Suresh
20:01:10 <tlr> tlr has joined #dap
20:01:29 <fjh> suresh agrees we should have security considerations for varous audiences
20:01:29 <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
20:02:04 <fjh> suresh notes that each spec needs normative definition of capabilities and features related to that API
20:03:46 <fjh> robin notes that we could have separate document that lists capabilities and features associated with apis
20:04:05 <Suresh> FH: what is the conculsion?
20:04:35 <nallott> nallott has joined #DAP
20:05:05 <Suresh> Robin: Web IDL with annotations can be messy
20:05:21 <fjh> q+
20:05:52 <Suresh> richars: do we take the apporach of geo-loc API?
20:06:07 <nwidell> q+
20:06:24 <dom> ack fjh
20:06:26 <Suresh> FH: we should not mimic that approach but look at it case by case
20:06:28 <dom> ack br
20:06:32 <fjh> ack fh
20:07:14 <fjh> q+
20:07:15 <Suresh> Bryan: Geo-loc is fairly loose in terms of testability,
20:07:39 <dom> ack nw
20:07:42 <fjh> ack nwidell
20:07:43 <Suresh> Bryan: We should make sure all the normative parts are testable and focus on those that are normative
20:07:44 <Bryan> q-
20:08:19 <slewontin> q+
20:08:43 <Suresh> ??: Having security considerations in every section may be confusing
20:09:06 <fjh> s/??/Nicholas/
20:09:28 <tlr_> tlr_ has joined #dap
20:09:28 <nwidell> s/Nicholas/Niklas/
20:09:30 <fjh> need to make considerations visible
20:10:03 <dom> q?
20:10:08 <dom> ack fjh
20:10:17 <slewontin> q-
20:11:25 <dom> [I think should this risk reveal as true, I think we'll look into tooling to reduce the risk]
20:11:35 <Suresh> FH: we don't need to go the way exactly how geo-priv has done, especially whether the location can be shared outside, etc
20:12:23 <Suresh> FH: i also agree that we need to find a good way to organize this but first we need to get the content
20:12:35 <dom> q+ to propose starting to look at actual security/privacy risks in contacts api
20:12:43 <AnssiK> AnssiK has joined #dap
20:12:46 <fjh> differences should be obvious
20:12:48 <fjh> ack dom
20:12:48 <Zakim> dom, you wanted to propose starting to look at actual security/privacy risks in contacts api
20:12:55 <Claes> Claes has joined #dap
20:13:48 <fjh> q+
20:14:17 <Suresh> Richard: Do we need to add security considerations to each API?
20:14:24 <tlr> tlr has joined #dap
20:14:37 <Suresh> FH: We need to have privacy and threats for each API
20:14:41 <dom> [changing contacts e;g. to get you to call a surtaxed number; I have a great business plan idea]
20:15:02 <Bryan> q+
20:15:32 <Suresh> FH: We list all the generic threats and reference the APIs that would relate to these threats
20:16:18 <Suresh> q+
20:16:47 <Suresh> Bryan: threats can be complicated process, we need to spend a lot of time
20:17:02 <Suresh> Bryan: We can simplify by group the operations ...
20:17:08 <fjh> q?
20:17:12 <fjh> ack fjh
20:17:15 <fjh> ack Bryan
20:17:23 <fjh> ack Suresh
20:18:12 <fjh> questions to ask of API; threats, privacy risks, user interaction
20:18:23 <Suresh> dom: User interaction part e.g. "do you want to acces the address book?" . This is a dimension we need to look.
20:18:41 <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.
20:18:46 <Suresh> FH: Good point: Is there an user interaction for each API?
20:20:30 <Suresh> David: For contacts there is a need for user inteaction
20:21:02 <Suresh> dom: We need to consider the user interactions not necessarily for contacts
20:21:33 <drogersuk> correction to the above, I said - I'm not sure there is a need for user interaction for contacts
20:21:43 <Suresh> Robin: For each API, i don;t see a need for user interaction
20:21:48 <drogersuk> there is no obvious user consent point
20:22:20 <fjh> q?
20:23:49 <Suresh> David: The user content shoudl be part of the policy
20:24:55 <arve> arve has joined #dap
20:25:18 <Suresh> q+
20:25:26 <timeless> q+
20:26:05 <Suresh> Robin: There could be an application that uses the contact API to ask for user consent
20:26:36 <fjh> ack timeless
20:27:49 <timeless> having a shelf exposing distinct address books
20:27:50 <arve> arve has joined #dap
20:27:57 <nwidell> q+
20:28:04 <fjh> ack Suresh
20:28:14 <timeless> is useful, but i would suggest *not* telling the app about the addition of distinct address books
20:28:46 <drogersuk> suresh: Is this not more a discussion about how you use the APIs
20:28:54 <ArtB> RRSAgent, make minutes
20:28:54 <RRSAgent> I have made the request to generate http://www.w3.org/2009/11/03-dap-minutes.html ArtB
20:28:58 <nord_c> nord_c has joined #dap
20:29:23 <timeless> ... instead of telling the application about new address books / los of address books
20:29:43 <timeless> ... if an address book mutates to gain/lose a contact, tell the application about the net change in contacts
20:30:18 <Bryan> q+
20:30:20 <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
20:31:16 <nallott> nallott has joined #DAP
20:31:16 <Suresh> I think the use case Robin is talking should be a functional requirement
20:31:22 <timeless> q-
20:32:00 <Suresh> Robin: these are examples that one could use to build security principles around APIs
20:33:43 <Suresh> FH: We need to understand in each API where the implict user consent applies
20:35:51 <Marcos> Marcos has joined #dap
20:36:12 <Suresh> nwidell: The contacts API is different from geo-location in the sense that it is more persistent
20:36:13 <fjh> q?
20:36:19 <fjh> ack nwidell
20:36:22 <fjh> ack Bryan
20:36:43 <fjh> zakim, this will be DAP
20:36:43 <Zakim> I do not see a conference matching that name scheduled within the next hour, fjh
20:38:16 <Suresh> 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....
20:38:23 <fjh> q?
20:39:05 <Suresh> FH: i think there are two issues: user consent and the asynchronous call back issue
20:39:33 <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]
20:39:46 <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
20:40:11 <Suresh> Robin: Asynchronous model allows non-blocking
20:40:44 <Suresh> Robin: i.e. does not force the user to respond
20:42:03 <JonathanJ> rrsagent, draft minutes
20:42:03 <RRSAgent> I have made the request to generate http://www.w3.org/2009/11/03-dap-minutes.html JonathanJ
20:45:08 <Suresh> dom: We should not make this too complex, but maybe set the policy during installation
20:45:20 <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
20:45:45 <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)
20:46:04 <Suresh> David: The policy be part of the manifest file
20:46:37 <fabrice> fabrice has joined #dap
20:49:14 <Suresh> Suresh has joined #dap
20:49:59 <dom> dom: I think we need to consider simple use cases for the restrictions that the policy framework can impose
20:50:10 <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
20:50:52 <drogersuk> Discussion on the necessity for policy to accurately describe detailed user intent
20:51:26 <dom> ACTION: Richard to add security/privacy considerations to Contacts API inspired from Geolocation 
20:51:26 <trackbot> Created ACTION-50 - Add security/privacy considerations to Contacts API inspired from Geolocation  [on Richard Tibbett - due 2009-11-10].
20:52:17 <maxf> q+
20:52:32 <darobin> ACTION: Tran to add security/privacy considerations to SysInfo API inspired from Geolocation 
20:52:32 <trackbot> Created ACTION-51 - Add security/privacy considerations to SysInfo API inspired from Geolocation  [on Dzung Tran - due 2009-11-10].
20:52:36 <dom> ack maxf
20:52:39 <fjh> ack maxf
20:53:40 <maxf> Max: I think it's worth exploring the markup option ( a la File Upload)
20:53:55 <dom> maxf, would you take an action to look into it?
20:53:57 <maxf> … its the best way to implement Consent-by-Initiative
20:53:59 <JereK> JereK has left #dap
20:54:17 <maxf> ACTION: maxf to look at markup options for consent
20:54:17 <trackbot> Created ACTION-52 - Look at markup options for consent [on Max Froumentin - due 2009-11-10].
20:54:50 <fabrice> fabrice has left #dap
21:08:12 <jmorris> jmorris has joined #dap
21:10:39 <MikeSmith> MikeSmith has joined #dap
21:14:45 <tlr> tlr has joined #dap
21:15:15 <Marcos> Marcos has joined #dap
21:15:52 <markusm> markusm has joined #dap
21:20:39 <Kai> Kai has joined #dap
21:32:58 <shepazu> shepazu has joined #dap
21:36:08 <jorlow> jorlow has joined #dap
21:36:10 <michaeln> michaeln has joined #dap
21:36:39 <michaeln> michaeln has left #dap
21:48:01 <nord_c> nord_c has joined #dap
21:56:54 <Marcos> Marcos has joined #dap
22:01:41 <nwidell> nwidell has joined #dap
22:01:45 <marengo> marengo has joined #dap
22:03:25 <soonho> soonho has joined #dap
22:04:13 <Claes> Claes has joined #dap
22:04:19 <darobin> darobin has joined #dap
22:05:08 <fjh> fjh has joined #dap
22:06:24 <nallott> nallott has joined #DAP
22:06:26 <drogersuk> drogersuk has joined #dap
22:07:42 <Suresh> Suresh has joined #dap
22:08:36 <Marcos> Marcos has joined #dap
22:10:09 <JariA> JariA has joined #dap
22:11:29 <nallott> topic: API Issue Review
22:12:45 <dom> i/<nallott>/ScribeNick: nallott/
22:13:38 <nallott> robin: intent 1 to use contacts as an example for an api review
22:13:38 <JonathanJ> JonathanJ has joined #dap
22:13:44 <Ingmar> Ingmar has joined #dap
22:14:09 <nallott> robin: intent 2 to review sysinfo and split into phase1 and phase 2
22:14:11 <claudio2> claudio2 has joined #dap
22:15:50 <nallott> robin: suggestion to put reference to each interface in the abstract
22:17:37 <AnssiK> q+
22:18:04 <mmani> mmani has joined #dap
22:20:00 <nallott> robin: conformance section specifies the product(s)  - it is againt the product which conformance is stated
22:20:28 <nallott> dom: for apis there will only be one product
22:20:55 <fhirsch> fhirsch has joined #dap
22:20:57 <JereK> JereK has joined #dap
22:23:07 <nallott> robin: editor tips: dont indent code blocks - class statement give free keyword highlighting
22:24:28 <nallott> anssi: should we abstract away the detail of the source of the contact
22:25:26 <nallott> richard: we have a requirement for multi address books - issues this raises, is how to indentify - which is default etc..
22:28:03 <Suresh> Suresh has joined #dap
22:28:17 <nallott> bryan: there is a requirement for the api to be able to selectively store in a particular address book  
22:29:55 <nallott> suresh: voices support for clearly distinguised adddress books
22:31:56 <nallott> bryan: the api should not be storage agnostic. 
22:33:34 <nallott> robin: the api does not need to make these distinctions, but the user agent does
22:34:56 <Suresh> q+
22:35:30 <AnssiK> q-
22:35:46 <Suresh> q+
22:36:10 <nallott> robin: needs to here a specifc use case for the identification of contact storage types
22:37:35 <dom> ISSUE: should we make the contacts API data-storage-aware?
22:37:35 <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 .
22:38:14 <Bryan> Bryan has joined #dap
22:38:17 <nallott> suresh: the distinction between SIM and phone contacts has long history and is know by the user
22:39:01 <dom> [it doesn't like look BONDI provides storage-awareness —  does it?]
22:39:31 <tlr_> tlr_ has joined #dap
22:42:17 <richt> BONDI API does not provide storage awareness currently
22:42:18 <JereK> q?
22:42:34 <JereK> q+ to present a use case 
22:42:57 <Bryan> q+
22:43:04 <dom> ack Sur
22:43:12 <dom> ack Jere
22:43:12 <Zakim> JereK, you wanted to present a use case
22:44:30 <nallott> jerek: use case for non-abstraction: when i search for contacts i need a handle so that i can retrieve contact details
22:44:36 <dom> ack B
22:44:40 <JereK> q-
22:45:18 <nallott> bryan: does not understand the distinction of the chrome and chromeless use case
22:47:42 <nallott> bryan: 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
22:47:50 <Bryan> q-
22:50:59 <nwidell> nwidell has joined #dap
22:51:55 <nallott> robin: proposal: we make all functions asynchronous if it is a securtiy entry point
22:52:06 <nallott> anssi: or it is a pending operation
22:58:36 <AnssiK> q+
22:59:00 <nallott> 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
22:59:40 <nallott> action: robin to make proposal on saving individual contacts to different address books
22:59:41 <trackbot> Created ACTION-53 - Make proposal on saving individual contacts to different address books [on Robin Berjon - due 2009-11-10].
23:00:16 <Magnus> Magnus has joined #dap
23:00:47 <nallott> 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)
23:01:28 <Bryan> q+
23:02:16 <nallott> marcin: draws attention to the design patterns that been already contributed to the group - to help with the harmonisation processs
23:02:36 <nallott> ack ansii
23:02:57 <nallott> ack AnssiK
23:06:26 <marcin> Design pattern: delete() item deletion, remove() for removal from collection.
23:07:03 <nallott> robin: use case for distinguishing address books is: address book synchronisations (analysing and propogating deltas)
23:07:10 <marcin> DOM3Core as example: http://www.w3.org/TR/DOM-Level-3-Core/core.html#ID-7C603781: deleteData()
23:07:18 <marcin> http://www.w3.org/TR/DOM-Level-3-Core/core.html#ID-1734834066: removeChild()
23:09:09 <nallott> nallott: we need to clearly iterate the use cases before we start talking about the api design
23:09:45 <Claes> q+
23:11:00 <soonho> soonho has left #dap
23:11:07 <soonho> soonho has joined #dap
23:11:11 <marcin> q+
23:11:40 <nallott> bryan: wanted clariffcation on the add address book
23:12:11 <nallott> robin: add is clealy tied to a typed owner - hence add is on address book - so add contat is implicit
23:14:14 <Bryan> q+
23:15:07 <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 
23:15:54 <tlr> tlr has joined #dap
23:16:14 <nallott> claes: q?
23:16:19 <nallott> q/
23:16:22 <nallott> q?
23:16:24 <Bryan> q-
23:16:30 <dom> ack cl
23:16:55 <dom> ack marc
23:18:01 <Bryan> q+
23:18:28 <nallott> marcin: teh application should not care where the data comes from - but that the contactable fields should determine how this contact is presented
23:19:53 <nallott> marcin: optional keyword is not valid on this example (optional fields should be at the end of the parameter list)
23:20:00 <slewontin> slewontin has joined #dap
23:20:13 <JereK> +1 for contact first
23:20:26 <slewontin> q+
23:20:57 <nallott> bryan: object to the statement that we dont care where the contacts come from
23:21:03 <Bryan> q-
23:21:15 <marcin> ErrorCallback should not be optional, since it could implicitly block processing
23:21:25 <dom> ACTION: Bryan to provide use cases where contacts API needs to be aware of source of contacts
23:21:25 <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].
23:23:01 <nallott> slweontin: 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)
23:24:52 <JereK> s/slweontin/slewontin/
23:26:13 <nallott> 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
23:27:06 <nallott> suresh: has reservations on supporting full vcard
23:27:24 <MikeSmith> MikeSmith has joined #dap
23:28:33 <fhirsch> fhirsch has joined #dap
23:31:16 <tlr> tlr has joined #dap
23:57:53 <Marcos> Marcos has joined #dap
00:07:36 <JereK> JereK has left #dap
00:08:05 <darobin> darobin has joined #dap
00:10:14 <JariA> JariA has joined #dap
00:10:23 <nwidell> Scribe: nwidell
00:10:31 <nwidell> ScribeNick: nwidell
00:12:05 <nwidell> david: Wrt draft proposal on RFID/NFC. Need to make decision on scope and what to do
00:12:08 <fhirsch> q+
00:12:26 <Kai> Kai has joined #dap
00:12:34 <nwidell> ... also scope has impact on IPR commitments
00:13:27 <dom> ack fh
00:13:32 <nwidell> ...question: Can we deliver it together with everything we have already committed to do?
00:14:28 <dom> ACTION: RObin to extract prioritary APIS and put on the group home page
00:14:28 <trackbot> Created ACTION-55 - Extract prioritary APIS and put on the group home page [on Robin Berjon - due 2009-11-11].
00:14:45 <nwidell> robin: we have already made a list of priorities within scope
00:14:45 <dom> q+ Jerek
00:15:05 <dom> ACTION: Robin to create a wiki page for future work on APIs
00:15:05 <trackbot> Created ACTION-56 - Create a wiki page for future work on APIs [on Robin Berjon - due 2009-11-11].
00:15:13 <slewontin> q-
00:15:19 <dom> ack Jere
00:15:23 <fhirsch> q?
00:15:27 <slewontin> q?
00:15:56 <nwidell> jere: does RFID require re-charter?
00:16:47 <nwidell> fh: no, robin: we already have slightly flexible wording
00:17:57 <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
00:18:01 <Marcos> Marcos has joined #dap
00:19:02 <nwidell> robin: prioritization is for group, individual members are encouraged to work on APIs not on prio list
00:19:29 <drogersuk> The group also agreed that as per a previous resolution the APIs in the charter would proceed according to the prioritisation previously agreed
00:23:25 <fhirsch> reolocation WG)
00:23:36 <Ileana> Ileana has joined #dap
00:23:37 <IleanaLeuca> IleanaLeuca has joined #dap
00:23:41 <fhirsch> Present+ Matt Womer
00:23:58 <nwidell> Matt Womer: Mentions contacts format discussion in Geolocation, some coordination useful
00:24:00 <dom> RESOLUTION: we'll use vCard as a starting point for the properties in the Contacts API (and likewise for iCalendar / Calendar API)
00:24:00 <JereK> JereK has joined #dap
00:24:10 <nwidell> Systems info API
00:24:19 <dom> s/Systems/Topic: Systems/
00:24:54 <dom> http://lists.w3.org/Archives/Public/public-device-apis/2009Oct/0264.html
00:25:18 <JonathanJ> JonathanJ has joined #dap
00:26:33 <nwidell> Bryan: We should take a vocabulary approach
00:26:47 <Kangchan> Kangchan has joined #dap
00:27:18 <JereK> q+ to ask whether the suggested vocabularies capture what we want
00:28:06 <dom> q+ Marcin
00:28:10 <dom> ack jere
00:28:10 <Zakim> JereK, you wanted to ask whether the suggested vocabularies capture what we want
00:28:11 <nwidell> ... a number of existing vocabularies does exist. No idea to 
00:28:42 <Ingmar> Ingmar has joined #dap
00:29:12 <dom> -> http://dev.w3.org/2009/dap/system-info/ Systems & info API
00:29:18 <nwidell> Jere: Do the existing vocabularies cover same scope as current SI proposal?
00:29:34 <fhirsch> action: fjh create wiki page with DAP draft documents 
00:29:34 <trackbot> Created ACTION-57 - Create wiki page with DAP draft documents  [on Frederick Hirsch - due 2009-11-11].
00:30:31 <Kangchan> Kangchan has joined #dap
00:30:36 <Suresh> Suresh has joined #dap
00:30:47 <dom> ACTION: Bryan to make a concrete proposal with a vocabulary-based approach to system & events, with a few examples (e.g. battery level)
00:30:47 <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].
00:30:55 <Suresh> q+
00:31:06 <tlr> tlr has joined #dap
00:31:30 <ILeuca> ILeuca has joined #dap
00:31:44 <nwidell> Bryan: BONDI has some of this already
00:31:49 <fhirsch> ack marcin
00:31:53 <dom> [Daniel notes that Telefonica also supports this approach]
00:32:21 <nwidell> Marcin: Vocabulary approach more optimized
00:34:50 <Ileana> Ileana has joined #dap
00:35:39 <dom> ack sure
00:36:59 <JereK> [notes that vocabulary-based approach does not cover events that pertain to the system info]
00:37:19 <Bryan> q+
00:37:38 <dom> zakim, close the queue
00:37:38 <Zakim> ok, dom, the speaker queue is closed
00:37:51 <marcin> Jere: events can be added to vocabulary approach
00:37:59 <dom> s/Jere:/Jere,/
00:38:00 <nwidell> suresh: what is the expected support from platform for the methods?
00:38:20 <Bryan> We should at least ensure that a list of properties should be consistent with the DCO: http://www.w3.org/TR/dcontology/
00:38:27 <JereK> marcin, how? (or is the answer too long?)
00:38:30 <dom> Topic: Administrativia
00:38:40 <dom> zakim, reopen the queue
00:38:40 <Zakim> ok, dom, the speaker queue is open
00:39:01 <dom> [Nov 11 is closed in some countries of Europe]
00:39:41 <marcin> Jere: e.g. propertyChangedCallback(propertyName, oldValue, newValue);
00:40:00 <matt> matt has joined #dap
00:40:55 <richt> s/Jere:/Jere,/
00:41:04 <marcin> Jere: oldValue & newValue could also be complex objects
00:41:05 <nwidell> fh: next telco Nov 25th
00:41:12 <dom> PROPOSED RESOLUTION: no meeting on Nov 11th, but keeping it on Nov 25th
00:41:22 <dom> RESOLUTION: no meeting on Nov 11th, but keeping it on Nov 25th
00:41:26 <matt> rrsagent, bookmark?
00:41:26 <RRSAgent> See http://www.w3.org/2009/11/03-dap-irc#T00-41-26
00:41:46 <JereK> marcin, it's the propertyName that bugs me
00:42:02 <dom> s/<dom> RES/<nwidell> RES/
00:42:08 <dom> RRSAgent, draft minutes
00:42:08 <RRSAgent> I have made the request to generate http://www.w3.org/2009/11/03-dap-minutes.html dom
00:42:10 <marcin> Jere, why?
00:42:55 <dom> Proposed possible weeks for a F2F in Prague: March 8, March 15
00:43:25 <dom> (for a 3 days F2F)
00:43:26 <JereK> marcin, my callback then needs to distinguish between the properties - I'd rather use dedicated callbacks. I think.
00:44:38 <marcin> Jere, we could have a model to register callbacks per property
00:46:28 <dom> ACTION: Dom to create a questionnaire for possible F2F in Prague in March
00:46:28 <trackbot> Created ACTION-59 - Create a questionnaire for possible F2F in Prague in March [on Dominique Hazaël-Massieux - due 2009-11-11].
00:47:08 <Marcos> Marcos has joined #dap
00:47:19 <JereK> [notes that XML Prague 2010 is March 13 & 14 if you already didn't - sorry, I was distracted]
00:47:32 <dom> ACTION-59: close date on Nov 13
00:47:32 <trackbot> ACTION-59 Create a questionnaire for possible F2F in Prague in March notes added
00:48:07 <marcin> Jere, in any model we may have e.g. 1000 properties. In the current sysinfo model you would have to register 1000 callbacks.
00:48:46 <nwidell> Topic: AoB
00:48:50 <JereK> marcin, I'm not interested in every one of them, but you have a point
00:49:12 <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
00:49:19 <nwidell> richard: Should we have a roadmap?
00:49:30 <JereK> marcin, we have to stop meeting like this :-)
00:49:47 <nwidell> dom: we should have something to document intended progress
00:49:55 <marcin> Jere, s/two callbacks (success+error)/one callback/
00:50:19 <dom> ACTION: Dom to create the DAP roadmap (in the wiki or wherever)
00:50:19 <trackbot> Created ACTION-60 - Create the DAP roadmap (in the wiki or wherever) [on Dominique Hazaël-Massieux - due 2009-11-11].
00:51:57 <nwidell> fh: please suggest things for agendas
00:52:49 <nwidell> fh: please indicate to list progress on actions
00:53:43 <dcoloma> dcoloma has joined #dap
00:57:09 <dom> ADJOURNED
00:57:15 <dom> RRSAgent, draft minutes
00:57:15 <RRSAgent> I have made the request to generate http://www.w3.org/2009/11/03-dap-minutes.html dom
00:57:16 <drogersuk> drogersuk has joined #dap
00:57:30 <dom> Zakim, bye
00:57:30 <Zakim> Zakim has left #dap
00:58:03 <soonho> soonho has left #dap
00:58:14 <dom> RRSAgent, bye
00:58:14 <RRSAgent> I see 15 open action items saved in http://www.w3.org/2009/11/03-dap-actions.rdf :
00:58:14 <RRSAgent> ACTION: david provide use case with threat model scenarios [1]
00:58:14 <RRSAgent>   recorded in http://www.w3.org/2009/11/03-dap-irc#T18-30-14
00:58:14 <RRSAgent> ACTION: Daniel to provide input of capability definition and semantics [2]
00:58:14 <RRSAgent>   recorded in http://www.w3.org/2009/11/03-dap-irc#T18-35-48
00:58:14 <RRSAgent> ACTION: Laura to provide input on trust model and access control model definitions [3]
00:58:14 <RRSAgent>   recorded in http://www.w3.org/2009/11/03-dap-irc#T18-36-34
00:58:14 <RRSAgent> ACTION: Suresh to propose a defintion for API access control, and a possible model for policy enforcement [4]
00:58:14 <RRSAgent>   recorded in http://www.w3.org/2009/11/03-dap-irc#T18-38-05
00:58:14 <RRSAgent> ACTION: Richard to add security/privacy considerations to Contacts API inspired from Geolocation  [5]
00:58:14 <RRSAgent>   recorded in http://www.w3.org/2009/11/03-dap-irc#T20-51-26
00:58:14 <RRSAgent> ACTION: Tran to add security/privacy considerations to SysInfo API inspired from Geolocation  [6]
00:58:14 <RRSAgent>   recorded in http://www.w3.org/2009/11/03-dap-irc#T20-52-32
00:58:14 <RRSAgent> ACTION: maxf to look at markup options for consent [7]
00:58:14 <RRSAgent>   recorded in http://www.w3.org/2009/11/03-dap-irc#T20-54-17
00:58:14 <RRSAgent> ACTION: robin to make proposal on saving individual contacts to different address books [8]
00:58:14 <RRSAgent>   recorded in http://www.w3.org/2009/11/03-dap-irc#T22-59-40
00:58:14 <RRSAgent> ACTION: Bryan to provide use cases where contacts API needs to be aware of source of contacts [9]
00:58:14 <RRSAgent>   recorded in http://www.w3.org/2009/11/03-dap-irc#T23-21-25
00:58:14 <RRSAgent> ACTION: RObin to extract prioritary APIS and put on the group home page [10]
00:58:14 <RRSAgent>   recorded in http://www.w3.org/2009/11/03-dap-irc#T00-14-28
00:58:14 <RRSAgent> ACTION: Robin to create a wiki page for future work on APIs [11]
00:58:14 <RRSAgent>   recorded in http://www.w3.org/2009/11/03-dap-irc#T00-15-05
00:58:14 <RRSAgent> ACTION: fjh create wiki page with DAP draft documents  [12]
00:58:14 <RRSAgent>   recorded in http://www.w3.org/2009/11/03-dap-irc#T00-29-34
00:58:14 <RRSAgent> ACTION: Bryan to make a concrete proposal with a vocabulary-based approach to system & events, with a few examples (e.g. battery level) [13]
00:58:14 <RRSAgent>   recorded in http://www.w3.org/2009/11/03-dap-irc#T00-30-47
00:58:14 <RRSAgent> ACTION: Dom to create a questionnaire for possible F2F in Prague in March [14]
00:58:14 <RRSAgent>   recorded in http://www.w3.org/2009/11/03-dap-irc#T00-46-28
00:58:14 <RRSAgent> ACTION: Dom to create the DAP roadmap (in the wiki or wherever) [15]
00:58:14 <RRSAgent>   recorded in http://www.w3.org/2009/11/03-dap-irc#T00-50-19
00:58:19 <JereK> JereK has left #dap