W3C home > Mailing lists > Public > public-device-apis@w3.org > May 2010

Draft minutes 2010-05-05

From: Frederick Hirsch <frederick.hirsch@nokia.com>
Date: Wed, 5 May 2010 11:15:29 -0400
Message-Id: <DDE7DD2E-4211-4AC7-BFF8-8166E8C4758E@nokia.com>
To: W3C Device APIs and Policy WG <public-device-apis@w3.org>
Cc: Frederick Hirsch <frederick.hirsch@nokia.com>
Attached are Draft minutes from 2010-05-05 teleconference, HTML  
follows text. Please review in advance of approval at next week's  

Thanks Erica for scribing!

regards, Frederick

Frederick Hirsch

# Device APIs and Policy Working Group Teleconference

## 05 May 2010


See also: [IRC log][4]

## Attendees


    Robin_Berjon, Frederick_Hirsch, Dzung_Tran, Soonho_Lee, LauraA, enewland,
Anssi_Kostiainen, Suresh_Chitturi, Brian_Leroux, Claes_Nilsson, Max_Froumentin


    Alissa_Cooper, John_Morris, Dom, Ilkka_Oksanen


    Robin_Berjon, Frederick_Hirsch



## Contents

  * [Topics][5]

    1. [administrative][6]

    2. [Minutes approval][7]

    3. [Policy requirements and rulesets][8]

    4. [Privacy requrements and rulesets][9]

    5. [APIs - SysInfo][10]

    6. [APIs - Testing][11]

    7. [APIs messaging][12]

  * [Summary of Action Items][13]

* * *

<trackbot> Date: 05 May 2010

<scribe> scribenick: enewland

<darobin> Scribe: Erica

### administrative

<fjh> Call for Exclusions, System Info API

call for exclusions for system info

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

no other announcements

### Minutes approval

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

**RESOLUTION: minutes from 28 April 2010 approved**

meeting to be held next week as usual

### Policy requirements and rulesets

<fjh> policy framework

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

Laura: introducing email she sent morning of May 5, 2010.

... outlined some differences between NOKIA document and policy document

... NOKIA document covers trust domain and access policies

... trust manager and access manager are independent elements

... 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.

... for example. Trust domain request picture: data flow from access request
to assign appropriate trust domain to given Web content.

... 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

... trust policy and access policy would be handled by same PDP

...concerns: if we follow this approach, there are a few major changes that
need to be done to security model as it now stands

... need to define trust policies from scratch

... different structures, naming, etc.

... this trust domain approach can already be done using security model as we
have it now.

... may not need explicit trust manager or trust policy. possible to write a
security policy following a trust domain approach

... one section for each trust domain that policy writer wants to define

... first question to answer: where are we now and what are steps forward?

choice between having explicit trust domains as nokia has proposed versus
doing as we have in bondi submission

fjh: we need to think more deeply about this. Figure out what else the
implications are there.

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.

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

... 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

fjh: it might be beneficial to go through with trust domain approach but let's
give it a little time on the list

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

<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

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

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.

... so key difference in terms of data flow is one-step approach versus
goosestep approach.

fjh: you wouldn't need first step repeatedly in a series of API calls.

LauraA: web content would be assigned trust domain and that would work for all
access requests afterward

fjh: seems like this change is doable. If we think this is right thing to do,
we can go ahead and do it.

... We will talk about it next week.

<Suresh> There is an email from Paddy on this subject

### Privacy requrements and rulesets

enewland: nothing new to report

### APIs - SysInfo

darobin: is it enough to have four positions in sysinfo orientation?

max: four positions is enough.

**RESOLUTION: SysInfo - four orientations are enough**

<fjh> keep current list of camera properties? supportsVideo, hasFlash,

<fjh> sensorPixels, maxZoomFactor

darobin: list of camera properties. is current list enough?

maxf: there is no need to go beyond that.

Claes: what we have today is fine.

Thomas: we have maximum zoom factor, do we have minimum zoom factor?

... for example, wide angle lenses

Max: idea was to avoid going into focal length.

... idea was to avoid going into focal length

darobin: We are near last call, could ask for some review before last call and
make that part of the email.

**RESOLUTION: SysInfo - the current list of camera properties is enough**

darobin: flag it as a resolution that we are ok but will flag as needing to be
reviewed in email

... should we have no sensors, such as heart rate, step counters

... etc

<fjh> including question of focal length in email requesting review

max: ambient noise, atmospheric pressure, etc. are environmental sensors. But
what about more human sensors? heart rate, etc.

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.

<fjh> human sensors have even more privacy considerations

Claes: 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.

... 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

fjh: there are privacy implications here

... different privacy concerns, ways of addressing them, limits on how they
can be used

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

<Dzung_Tran> I like the idea of specifying that the sensors we are supporting
is environmental type

<Dzung_Tran> We address the heart rate and other type of sensors in next

Thomas: we are starting to talk about the user, and should probably put them
in separate API

<fjh> +1 to tlr, different type of information

darobin: probably want to make it a separate spec

**RESOLUTION: scope of SysInfo stays the same, we will look into user sensors

darobin: this is on the road map for future improvements

<darobin> ISSUE-76?

<trackbot> ISSUE-76 -- Available/Preferred Networks in sysinfo -- OPEN

<trackbot> [http://www.w3.org/2009/dap/track/issues/76][17]

<darobin> close ISSUE-76

<trackbot> ISSUE-76 Available/Preferred Networks in sysinfo closed

darobin: that issue should be closed

<darobin> ISSUE-79?

<trackbot> ISSUE-79 -- Fingerprinting privacy issue related to sysinfo, need
for feedback on privacy risk -- OPEN

<trackbot> [http://www.w3.org/2009/dap/track/issues/79][18]

<darobin> close ISSUE-79

<trackbot> ISSUE-79 Fingerprinting privacy issue related to sysinfo, need for
feedback on privacy risk closed

darobin: intend to release last call of ISSUE-79 within week. how does that

... 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

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?

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

suresh: unfortunately, we haven't done thorough review of the scope of this
draft. Could we delay by one week?

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.

<Claes> 2 weeks

**RESOLUTION: announce a two week pre-LC review period for SysInfo, then move
it to LC if all goes well**

<darobin> RESOLUTION: The WG love Max

### APIs - Testing

<maxf> :)

<fjh> [http://docs.jquery.com/QUnit][19]

<AnssiK> [http://github.com/phonegap/mobile-spec][20]

darobin: Appropriate given that we are planning first last call. Last call is
period when we should start thinking seriously about testing.

... we discussed using QUnit and mobile-spec.

brian: mobile-spec is suite of QUnit spec. We have been favoring performance
over total compliance.

... For the most part it works well. Supports asynchronous testing, which is

... 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

... 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

... QUnit is good. mobile-spec is a good starting point, even if we don't
eventually use it. It is complete and well organized.

... 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

darobin: Having looked at number of testing frameworks, it seems that QUnit is
most adapted to our needs.

... has anyone else looked into similar questions?

AnssiK: QUnit is a fairly solid choice.

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

AnssiK: good presentation by John Resig. Will find it and paste it to IRC

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

<AnssiK> [http://www.slideshare.net/jeresig/understanding-javascript-

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.

bryan_sullivan: We can compare this to test framework that has been developed
for use in bondi.

... 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.

darobin: When people fill out instantation reports they report whether or not
they successfully, for instance, received an email afterwords.

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.

brianleroux: Get into functional testing....

bryan_sullivan: The problem is that to fully test an API, you need to see if
API supports normative validation.

darobin: There is some level of agreement on qUnit and moving forward with
mobile specs.

... group should look into sysinfo testing in mobile spec

brianleroux: i can work on putting that in over the next week

... will send message to list with pointers to documentation

darobin: no other comments with respect to testing. moving on

### APIs messaging

darobin: any other API topics

... none raised.

frederick: request that people look at LauraA's email on policy framework.

darobin: adjourned for this week. darobin won't be here next week

## Summary of Action Items

[End of minutes]

* * *

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

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

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

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

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

   [4]: http://www.w3.org/2010/05/05-dap-irc

   [5]: #agenda

   [6]: #item01

   [7]: #item02

   [8]: #item03

   [9]: #item04

   [10]: #item05

   [11]: #item06

   [12]: #item07

   [13]: #ActionSummary

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

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

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

   [17]: http://www.w3.org/2009/dap/track/issues/76

   [18]: http://www.w3.org/2009/dap/track/issues/79

   [19]: http://docs.jquery.com/QUnit

   [20]: http://github.com/phonegap/mobile-spec

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

   [22]: http://www.slideshare.net/jeresig/understanding-javascript-testing

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

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

Received on Wednesday, 5 May 2010 15:16:28 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:53:43 UTC