See also: IRC log
<trackbot> Date: 05 May 2010
<scribe> scribenick: enewland
<darobin> Scribe: Erica
<fjh> Call for Exclusions, System Info API
call for exclusions for system info
<fjh> http://lists.w3.org/Archives/Member/member-device-apis/2010May/0000.html
no other announcements
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2010Apr/att-0117/minutes-2010-04-28.html
RESOLUTION: minutes from 28 April 2010 approved
meeting to be held next week as usual
<fjh> policy framework
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2010May/0011.html
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 previously,
... 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 presented.
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
enewland: nothing new to report
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 release
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 later
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
<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
<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 sound?
... 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
<maxf> :)
<fjh> http://docs.jquery.com/QUnit
<AnssiK> http://github.com/phonegap/mobile-spec
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 critical.
... 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 test.
... 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 use.
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-apis/2010Apr/0132.html
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-testing
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
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