13:01:59 <RRSAgent> RRSAgent has joined #dap
13:01:59 <RRSAgent> logging to http://www.w3.org/2010/05/05-dap-irc
13:02:01 <trackbot> RRSAgent, make logs world
13:02:01 <Zakim> Zakim has joined #dap
13:02:03 <trackbot> Zakim, this will be DAP
13:02:03 <Zakim> ok, trackbot; I see UW_DAP()10:00AM scheduled to start in 58 minutes
13:02:04 <trackbot> Meeting: Device APIs and Policy Working Group Teleconference
13:02:04 <trackbot> Date: 05 May 2010
13:02:19 <fjh> Chair: Robin_Berjon, Frederick_Hirsch
13:02:32 <fjh> Present+ Robin_Berjon, Frederick_Hirsch
13:03:23 <fjh> Regrets: Alissa_Cooper, John_Morris
13:03:55 <fjh> Agenda: http://lists.w3.org/Archives/Public/public-device-apis/2010May/0006.html
13:10:48 <dom> Regrets+ Dom
13:16:35 <fjh> Regrets- Dom
13:16:43 <fjh> Regrets+ Dominique_Hazaël-Massieux
13:32:59 <arve> arve has joined #dap
13:48:36 <Dzung_Tran> Dzung_Tran has joined #dap
13:48:43 <Dzung_Tran> Present+ Dzung_Tran
13:49:40 <Marcos> Marcos has joined #dap
13:53:02 <marengo> marengo has joined #dap
13:55:26 <fjh> Regrets+ Ilkka_Oksanen
13:56:34 <darobin> darobin has joined #dap
13:57:29 <Zakim> UW_DAP()10:00AM has now started
13:57:32 <Zakim> +??P21
13:57:35 <fjh> zakim, ??P21 is me
13:57:35 <Zakim> +fjh; got it
13:58:42 <AnssiK> AnssiK has joined #dap
13:59:11 <soonho> soonho has joined #dap
13:59:32 <Zakim> +AnssiK
13:59:48 <LauraA> LauraA has joined #dap
13:59:50 <Zakim> +enewland
13:59:50 <enewland> enewland has joined #dap
13:59:57 <Zakim> +suresh
13:59:59 <soonho> Present+ Soonho_Lee
14:00:04 <LauraA> Present+ LauraA
14:00:04 <enewland> Present+ enewland
14:00:19 <AnssiK> Present+ Anssi_Kostiainen
14:00:31 <Suresh> Suresh has joined #dap
14:00:41 <Suresh> Present+ Suresh_Chitturi
14:01:11 <brianleroux> brianleroux has joined #dap
14:01:16 <darobin> Present+ Robin_Berjon
14:01:20 <Zakim> +LauraA
14:01:33 <brianleroux> Present+ Brian_Leroux
14:01:44 <Zakim> +darobin
14:01:44 <Claes> Claes has joined #dap
14:01:47 <Zakim> +maxf
14:02:03 <Claes> Present+ Claes_Nilsson
14:02:08 <Zakim> + +1.604.685.aaaa
14:02:24 <maxf> Present+ Max_Froumentin
14:03:23 <fjh> zakim, who is here?
14:03:23 <Zakim> On the phone I see fjh, AnssiK, enewland, suresh, LauraA, darobin, maxf, +1.604.685.aaaa
14:03:26 <Zakim> On IRC I see Claes, brianleroux, Suresh, enewland, LauraA, soonho, AnssiK, darobin, marengo, Marcos, Dzung_Tran, arve, Zakim, RRSAgent, fjh, tlr, maxf, ilkka, ingmar, dom, shepazu,
14:03:28 <Zakim> ... trackbot
14:03:29 <Zakim> +Claes
14:03:43 <Zakim> - +1.604.685.aaaa
14:03:53 <fjh> zakim, who is here?
14:03:53 <Zakim> On the phone I see fjh, AnssiK, enewland, suresh, LauraA, darobin, maxf, Claes
14:03:55 <Zakim> On IRC I see Claes, brianleroux, Suresh, enewland, LauraA, soonho, AnssiK, darobin, marengo, Marcos, Dzung_Tran, arve, Zakim, RRSAgent, fjh, tlr, maxf, ilkka, ingmar, dom, shepazu,
14:04:00 <Zakim> ... trackbot
14:04:24 <Zakim> + +1.604.685.aabb
14:05:01 <brianleroux> zakim, aabb is brianleroux
14:05:01 <Zakim> +brianleroux; got it
14:05:18 <enewland> scribenick: enewland
14:05:34 <darobin> Scribe: Erica
14:05:50 <Zakim> +Bryan
14:05:52 <enewland> TOPIC: administrative
14:06:01 <arve> arve has left #dap
14:06:10 <fjh> Call for Exclusions, System Info API
14:06:12 <enewland> call for exclusions for system info
14:06:21 <fjh> http://lists.w3.org/Archives/Member/member-device-apis/2010May/0000.html
14:06:23 <enewland> no other announcements
14:06:34 <enewland> TOPIC: Minutes approval
14:06:39 <fjh> http://lists.w3.org/Archives/Public/public-device-apis/2010Apr/att-0117/minutes-2010-04-28.html
14:06:49 <bryan_sullivan> bryan_sullivan has joined #dap
14:06:56 <enewland> RESOLUTION: minutes from 28 April 2010 approved
14:07:27 <enewland> meeting to be held next week as usual
14:07:40 <enewland> TOPIC: Policy requirements and rulesets
14:07:57 <fjh> policy framework
14:07:58 <fjh> http://lists.w3.org/Archives/Public/public-device-apis/2010May/0011.html
14:08:08 <enewland> Laura: introducing email she sent morning of May 5, 2010.
14:08:22 <fjh> zakim, who is here?
14:08:22 <Zakim> On the phone I see fjh, AnssiK, enewland, suresh, LauraA, darobin, maxf, Claes, brianleroux, Bryan
14:08:24 <Zakim> On IRC I see bryan_sullivan, Claes, brianleroux, Suresh, enewland, LauraA, soonho, AnssiK, darobin, marengo, Marcos, Dzung_Tran, Zakim, RRSAgent, fjh, tlr, maxf, ilkka, ingmar,
14:08:26 <Zakim> ... dom, shepazu, trackbot
14:09:06 <enewland> ...outlined some differences between NOKIA document and policy document
14:09:14 <enewland> ....NOKIA document covers trust domain and access policies
14:09:29 <enewland> ...trust manager and access manager are independent elements
14:09:50 <enewland> ...first major difference: to match NOKIA's input, need to define trust policies and access policies separately, instead of one generic security policy for everything.
14:10:49 <enewland> ...for example. Trust domain request picture: data flow from access request to assign appropriate trust domain to given Web content. 
14:12:30 <enewland> ...NOKIA document has separate trust manager, with separate trust domain and sends that back to access requester. when access requester needs to request access to specific api it sends trust domain that had been requested previously,
14:12:54 <enewland> ...trust policy and access policy would be handled by same PDP
14:13:12 <fjh> q+
14:13:29 <enewland> ...concerns: if we follow this approach, there are a few major changes  that need to be done to security model as it now stands
14:13:36 <enewland> ...need to define trust policies from scratch
14:13:47 <enewland> ...different structures, naming, etc. 
14:14:04 <enewland> ...this trust domain approach can already be done using security model as we have it now. 
14:14:21 <enewland> ...may not need explicit trust manager or trust policy. possible to write a security policy following a trust domain approach
14:14:31 <enewland> ...one section for each trust domain that policy writer wants to define
14:14:57 <enewland> ...first question to answer: where are we now and what are steps forward?
14:16:04 <enewland> choice between having explicit trust domains as nokia has proposed versus doing as we have in bondeye submission
14:16:33 <Suresh> s/bondeye/bondi
14:18:11 <bryan_sullivan> q+
14:18:38 <enewland> fjh: we need to think more deeply about this. Figure out what else the implications are there.
14:18:48 <fjh> q-
14:19:42 <enewland> LauraA: I understand we need to be explicit defining trust domains. We could modifiy what we already have to make it more trust domain explicit. Trying to explain how a policy will be written following trust domain approach but not necessarily demanding such an approach from the beginning.
14:19:48 <fjh> ack bryan
14:20:22 <enewland> bryan_sullivan: changes are what is necessary. Trust domain concept and management of trust domains as separate set of directives is something that was discussed early in bondi as well. To manage trust separately from policy
14:20:49 <enewland> ...to simplify evolution of what we wanted to do in bondi. To find mechanisms for delegation of trust, etc. It is easily doable throughwhat LauraA has presented.
14:21:08 <Suresh> q+
14:21:13 <fjh> ack Suresh
14:21:13 <enewland> fjh: it might be beneficial to go through with trust domain approach but let's give it a little time on the list
14:21:48 <tlr> zakim, call thomas-781
14:21:48 <Zakim> ok, tlr; the call is being made
14:21:50 <Zakim> +Thomas
14:21:58 <tlr> zakim, I am thomas
14:21:58 <Zakim> ok, tlr, I now associate you with Thomas
14:22:00 <tlr> zakim, mute me
14:22:00 <Zakim> Thomas should now be muted
14:22:37 <enewland> suresh: question for clarification. In current draft, step #2 is access request. Seems as though this access request, which is same as bondi's, is generic in that it combines trust domain and access information. But with this new, modified approach, trust domain and access are separated. So, in document it is difficult to understand what gets passed in step #2 in terms of data and how this is a change. is it just making things more explicit or is there more
14:22:57 <fjh> my understanding from conversation is that from BONDI perspective changing to make explicit trust domains should not be a big problem, and could be done
14:24:02 <enewland> LauraA: In step 2 there is this access request.  When access requester has to request access to a specific API, this access request would be sent together with the trust domain that was assigned before hand.  For widgets, the trust domain request may usually be carried out by the installer, so trust domain is assigned from beginning
14:24:29 <enewland> suresh: so you would first validate trust domain and then make access request, but if trust domain is already available then you can skip the first step. 
14:24:52 <enewland> Suresh: so key difference in terms of data flow is one-step approach versus goosestep approach.
14:25:06 <enewland> fjh: you wouldn't need first step repeatedly in goosestep approach.
14:25:11 <Suresh> q-
14:25:31 <enewland> LauraA: web content would be assigned trust domain and that would work for all access requests afterward
14:25:37 <fjh> s/in goosestep approach/in a series of API calls/
14:26:10 <enewland> fjh: seems like this change is doable. If we think this is right thing to do, we can go ahead and do it.
14:26:17 <LauraA> q+
14:26:37 <LauraA> q-
14:26:41 <enewland> fjh: We will talk about it next week.
14:26:44 <Suresh> There is an email from Paddy on this subject
14:27:47 <enewland> TOPIC: Privacy requrements and rulesets
14:28:04 <enewland> enewland: nothing new to report
14:28:25 <enewland> TOPIC: APIs - SysInfo
14:29:13 <enewland> darobin: is it enough to have four positions in sysinfo orientation?
14:29:51 <enewland> max: four positions is enough. 
14:30:00 <darobin> RESOLUTION: SysInfo - four orientations are enough
14:30:13 <fjh> keep current list of camera properties? supportsVideo, hasFlash,   
14:30:13 <fjh> sensorPixels, maxZoomFactor
14:30:26 <enewland> darobin: list of camera properties. is current list enough?
14:30:45 <enewland> maxf: there is no need to go beyond that. 
14:31:37 <enewland> Claes: what we have today is fine.
14:31:47 <tlr> q+
14:31:51 <tlr> ack thomas
14:32:04 <enewland> Thomas: we have maximum zoom factor, do we have minimum zoom factor?
14:32:18 <enewland> ...for example, wide angle lenses
14:33:06 <enewland> Claes?: idea was to avoid going into focal length.
14:33:21 <fjh> s/Claes?/Max
14:33:30 <enewland> Max: idea was to avoid going into focal length
14:33:44 <Zakim> -LauraA
14:34:09 <Zakim> +LauraA
14:35:06 <enewland> darobin: We are near last call, could ask for some review before last call and make that part of the email.
14:35:31 <darobin> RESOLUTION: SysInfo - the current list of camera properties is enough
14:35:39 <enewland> darobin: flag it as a resolution that we are ok but will flag as needing to be reviewed in email
14:35:50 <enewland> darobin: should we have no sensors, such as heart rate, step counters
14:35:53 <enewland> ...etc
14:36:03 <fjh> including question of focal length in email requesting review
14:36:49 <enewland> max: ambient noise, atmospheric pressure, etc. are environmental sensors. But what about more human sensors? heart rate, etc.
14:37:42 <enewland> Claes: The main purpose in including sensors in this specification is that this specification is supposed to be a simple interface that explains common use cases. 
14:38:00 <fjh> human sensors have even more privacy considerations
14:38:30 <enewland> ...perhaps it is a bit inconsistent to say that the current sensors are all environmental sensors but not the user. So perhaps we should change scope of sensors we support.
14:38:55 <fjh> q+
14:39:30 <darobin> ack fjh 
14:39:32 <enewland> ...more generic specification for sensors may be coming in the future, but if we want to get something out within this release, that would be good. there are common use cases for heart rate and step counter
14:39:38 <enewland> fjh: there are privacy implications here
14:39:42 <tlr> q+
14:39:49 <fjh> q?
14:39:54 <darobin> ack tlr 
14:39:54 <enewland> ...different privacy concerns, ways of addressing them, limits on how they can be used
14:39:58 <darobin> ack Thomas
14:40:20 <enewland> Thomas: We are not talking about the properties of the device but of the individual. This is a different set of sensors from what we have been discussing so far
14:40:26 <Dzung_Tran> I like the idea of specifying that the sensors we are supporting is environmental type
14:40:50 <Dzung_Tran> We address the heart rate and other type of sensors in next release
14:41:04 <enewland> ...we are starting to talk about the user, and should probably put them in separate API
14:41:05 <fjh> +1 to tlr, different type of information
14:42:09 <fjh>  /me what french accent? :)
14:42:10 <enewland> darobin : probably want to make it a separate spec
14:42:28 <fjh> s/\/me what french accent? :)//
14:42:59 <darobin> RESOLUTION: scope of SysInfo stays the same, we will look into user sensors later
14:43:05 <enewland> darobin: this is on the road map for future improvements 
14:43:52 <darobin> ISSUE-76?
14:43:52 <trackbot> ISSUE-76 -- Available/Preferred Networks in sysinfo -- OPEN
14:43:52 <trackbot> http://www.w3.org/2009/dap/track/issues/76
14:44:12 <darobin> close ISSUE-76
14:44:12 <trackbot> ISSUE-76 Available/Preferred Networks in sysinfo closed
14:44:14 <enewland> darobin: that issue should be closed
14:44:18 <darobin> ISSUE-79?
14:44:18 <trackbot> ISSUE-79 -- Fingerprinting privacy issue related to sysinfo, need for feedback on privacy risk -- OPEN
14:44:18 <trackbot> http://www.w3.org/2009/dap/track/issues/79
14:44:34 <darobin> close ISSUE-79
14:44:34 <trackbot> ISSUE-79 Fingerprinting privacy issue related to sysinfo, need for feedback on privacy risk closed
14:45:02 <Suresh> q+
14:45:03 <enewland> darobin: intend to release last call of ISSUE-79 within week. how does that sound?
14:45:39 <enewland> darobin: clarification. The idea is to tell people that we are planning to go to last call, point them to draft and go to last call
14:45:41 <darobin> ack Suresh 
14:46:10 <enewland> suresh: clarification - is intention of last call to gather feedback on current draft or also can we change something if we notice something missing. Is it open to new properties?
14:46:44 <enewland> darobin: the idea is to ask people to review it very carefully and if all goes well then we move on to the recommendations and implementation testing. would not be open to new things
14:46:59 <enewland> suresh: unfortunately, we haven't done throgouh review of the scope of this draft. Could we delay by one week?
14:47:24 <enewland> darobin: proposal was to give people one or two weeks to review before going to last call. Purpose was to announce that we were thinking of going to last call soon.
14:47:44 <Claes> 2 weeks
14:47:55 <fjh> s/throgouh/thorough/
14:48:17 <darobin> RESOLUTION: announce a two week pre-LC review period for SysInfo, then move it to LC if all goes well
14:48:30 <tlr> ack thomas
14:48:49 <darobin> RESOLUTION: The WG love Max
14:49:02 <enewland> TOPIC: APIs - Testing
14:49:03 <maxf> :)
14:49:19 <fjh> http://docs.jquery.com/QUnit
14:49:28 <AnssiK> http://github.com/phonegap/mobile-spec
14:49:29 <enewland> darobin: Appropriate given that we are planning first last call. Last call is period when we should start thinking seriously about testing.
14:50:08 <enewland> ...we discussed using qnix and mobile spec. 
14:50:42 <darobin> s/qnix/QUnit/
14:50:55 <darobin> s/mobile spec/mobile-spec/
14:51:08 <enewland> brian: mobile-spec is suite of QUnit spec. We have been favoring performance over total compliance. 
14:51:30 <enewland> brian: For the most part it works well. Supports asynchronous testing, which is critical. 
14:52:10 <enewland> brian: automation is still a problem. You can run inside emulators but they don't really emulate anything. Tend to have manual tests, run on actual devices
14:52:48 <enewland> brian: there will be failures on some devices. Sometimes device doesn't have capability to run a particular interface. For example, if phone doesn't have GPS then that test will fail, but that doesn't mean we shouldn't have GPS test.
14:53:24 <enewland> ...QUnit is good. mobile-spec is a good starting point, even if we don't eventually use it. It is complete and well organized. 
14:54:24 <enewland> ...we also have some techs coming in soon from Deutch Telecom, they have added Bondi 1.1 APIs. Soon you will be able to choose which APIs you want to use.
14:54:41 <enewland> darobin: Having looked at number of testing frameworks, it seems that QUnit is most adapted to our needs.
14:54:51 <enewland> ...has anyone else looked into similar questions?
14:55:03 <AnssiK> q+
14:55:12 <darobin> ack AnssiK 
14:55:23 <enewland> AnssiK: QUnit is a fairly sold choice. 
14:55:27 <fjh> http://lists.w3.org/Archives/Public/public-device-apis/2010Apr/0132.html 
14:56:13 <enewland> ...good presentation by John Rissak. Will find it and paste it to IRC
14:57:01 <enewland> brian: There's also another program, device anywhere. Proprietary but offer automated testing. Perhaps could look into that so we could take this to next step of automation
14:57:01 <bryan_sullivan> q+
14:57:08 <AnssiK> http://www.slideshare.net/jeresig/understanding-javascript-testing
14:57:44 <enewland> darobin: presumably DAP would not get involved in creating an automated framework. But if tests we produce can be imported into another system, that would be a big plus. People can feed their tests back to us. 
14:57:51 <darobin> ack bryan_sullivan 
14:58:07 <enewland> bryan_sullivan: We can compare this to test framework that has been developed for use in bondi.
14:58:28 <AnssiK> s/sold/solid/
14:58:39 <AnssiK> s/Rissak/Resig/
14:58:50 <Zakim> -Claes
14:58:59 <enewland> ...Question. If I want to validate that I can send a message - sending an email to myself, for example - is that easily done within this test framework.
14:59:46 <enewland> darobin: When people fill out instantation reports they report whether or not they successfully, for instance, received an email afterwords.
14:59:47 <Zakim> +Claes
15:00:24 <enewland> bryan_sullivan: Will test framework directly support ability to send and receive a message, for example.  Or do we need to create mini-test apps.
15:01:31 <enewland> brianleroux: Get into functional testing....
15:02:03 <enewland> bryan_sullivan: The problem is that to fully test an API, you need to see if API supports normative validation.
15:02:27 <bryan_sullivan> q-
15:02:49 <enewland> darobin: There is some level of agreement on qUnit and moving forward with mobile specs. 
15:02:58 <enewland> ....group should look into sysinfo testing in mobile spec
15:03:13 <enewland> brianleroux: i can work on putting that in over the next week
15:03:46 <enewland> brianleroux: will send message to list with pointers to documentation
15:03:47 <darobin> q?
15:04:03 <enewland> darobin: no other comments with respect to testing. moving on
15:04:40 <enewland> TOPIC: APIs messaging
15:05:04 <brianleroux> \me =)
15:05:24 <enewland> darobin: any other API topics
15:05:43 <enewland> ...none raised.
15:05:57 <enewland> frederick: request that people look at LauraA's email on policy framework.
15:06:28 <Zakim> -Bryan
15:06:29 <enewland> darobin: adjourned for this week. darobin won't be here next week
15:06:31 <Zakim> -Thomas
15:06:34 <Zakim> -darobin
15:06:35 <Zakim> -Claes
15:06:38 <Zakim> -AnssiK
15:06:47 <AnssiK> AnssiK has left #dap
15:06:51 <Zakim> -LauraA
15:06:52 <Zakim> -suresh
15:06:52 <Zakim> -brianleroux
15:06:54 <Zakim> -enewland
15:06:54 <Zakim> -fjh
15:07:02 <fjh> rrsagent, generate minutes
15:07:02 <RRSAgent> I have made the request to generate http://www.w3.org/2010/05/05-dap-minutes.html fjh
15:07:04 <Zakim> -maxf
15:07:05 <Zakim> UW_DAP()10:00AM has ended
15:07:09 <Zakim> Attendees were fjh, AnssiK, enewland, suresh, LauraA, darobin, maxf, +1.604.685.aaaa, Claes, +1.604.685.aabb, brianleroux, Bryan, Thomas
15:07:43 <fjh> ScribeNick: darobin
15:07:51 <fjh> rrsagent, generate minutes
15:07:51 <RRSAgent> I have made the request to generate http://www.w3.org/2010/05/05-dap-minutes.html fjh
15:07:51 <enewland> enewland has left #dap
15:09:01 <shepazu> shepazu has joined #dap
15:14:06 <Marcos> Marcos has joined #dap
16:07:37 <tlr> tlr has joined #dap
17:07:53 <Zakim> Zakim has left #dap