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

Draft minutes - 2010-01-06 teleconference

From: Frederick Hirsch <frederick.hirsch@nokia.com>
Date: Wed, 6 Jan 2010 10:55:43 -0500
Message-Id: <963AE179-2758-4797-8B53-4AFF43EAF4AA@nokia.com>
To: W3C Device APIs and Policy WG <public-device-apis@w3.org>
Cc: Frederick Hirsch <frederick.hirsch@nokia.com>
Draft minutes - 2010-01-06 teleconference, html follows text version.

Happy New Year!

regards, Frederick

Frederick Hirsch, Nokia
Co-Chair, W3C DAP Working Group

# Device APIs and Policy Working Group Teleconference

## 06 Jan 2010


See also: [IRC log][4]

## Attendees


    Robin_Berjon, Frederick_Hirsch, ThomasRoessler, Dzung_Tran, Wonsuk_Lee,
Paddy_Byers, Suresh_Chitturi, Laura_Arribas, Dominique_Hazael-Massieux,
John_Morris, Marcin_Hanclik


    Anssi_Kostiainen, Marco_Marengo, DavidRogers


    Robin_Berjon, Frederick_Hirsch


    John Morris

## Contents

  * [Topics][5]

    1. [minutes approval][6]

    2. [Policy][7]

    3. [TAG response][8]

    4. [api issues][9]

  * [Summary of Action Items][10]

* * *

<trackbot> Date: 06 January 2010

<paddy> fjh, sorry but my internet connection is going up and down all the

<paddy> I will do it next time if it's ok

<paddy> snowbound, unable to reach office and working from home :)

<fjh> **ACTION:** fjh fix Seoul time in agenda to be 24:00 [recorded in

<trackbot> Created ACTION-78 - Fix Seoul time in agenda to be 24:00 [on
Frederick Hirsch - due 2010-01-13].

<paddy> similarly, agenda says 1400 UTC, I think it is 1500 UTC

<cardona507> I am a member of the HTMLwg - but for some reason I am having
trouble submitting the form to join this group - It looks like the form
expired on new years - any ideas?

<fjh> tlr can you pls help cardona507?

<cardona507> I am a student and "invited expert" - I don't represent a company
per se

<paddy> I can scribe until my connection disappears

<fhirsch> paddy, perhaps you can scribe next week and we can choose someone
else for today

<cardona507> dom - should I send an email to the chairs? and if so where?

<paddy> ok, thanks

<darobin> yeah, we don't want a scribe that drops off

<darobin> or gets caught in an avalanche

<cardona507> thank dom - have a good meeting everyone


<darobin> Scribe: John Morris

<darobin> ScribeNick: jmorris

<fhirsch> Paddy will scribe next week

minutes from dec. 16

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

### minutes approval

**RESOLUTION: minutes from 16-dec approved**

### Policy

<fhirsch> ReSpec, added refNote and additionalCopyrightHolders


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

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

some discussion of document on list

<fhirsch> action-63?

<trackbot> ACTION-63 -- Laura Arribas to review
-- due 2009-11-25 -- CLOSED

<trackbot> [http://www.w3.org/2009/dap/track/actions/63][16]

<fhirsch> TAG response

### TAG response

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

<darobin> FH: any objection to sending to the TAG?

<darobin> [none]

<fhirsch> will send this today, given no comment

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

**RESOLUTION: fhirsch to send tag response**

<dom> ACTION-69?

<trackbot> ACTION-69 -- Paddy Byers to provide use cases for the policy
requirements document -- due 2009-12-11 -- OPEN

<trackbot> [http://www.w3.org/2009/dap/track/actions/69][19]

<dom> [Policy Use cases from Paddy][20]

paddy: working on use cases

how does this relate to policy requirements documents

fhirsch: these should go into requirements documents

<dom> +1 on integrating in requirements for now

<wonsuk> +1

<darobin> +1 too

fhirsch: tlr did work on security in apis

<dom> [I think it would be useful if the use cases distinguished or
highlighted which apply to widget vs open web apps]

<tlr> [+1 to dom]

<darobin> [me too!]

paddy: need detail in use cases and derive requirements from them

need to determine implied requirements in API

apis should be capable of being used without presumption of trust

<fhirsch> paddy suggests possible requirement - apis should be capabable of
being mediated by policy but not required to be mediated by policy

<fhirsch> dom asks whether use cases apply to non-trusted environment

fhirsch: there will always be non-trusted cases

paddy: there is not always a presumption of trust with web site

<dom> [paddy captured well the questions I had in mind]

with widget, one goes through an install process with some suggestion of trust

paddy: there is a difference between two environments, but the apis should be
capable of both environments

<Dzung_Tran> I think we should strive for both environment

dom: wg should be able to set ground rules for use of APIs in trusted

fhirsch: dom put something on the list on this?

<schittur2> Robin - i dont think i saw one as well

<dom> **ACTION:** Paddy to integrate his use cases in policy requirements
[recorded in [http://www.w3.org/2010/01/06-dap-minutes.html#action02][21]]

<trackbot> Created ACTION-79 - Integrate his use cases in policy requirements
[on Paddy Byers - due 2010-01-13].

fhirsch: paddy should work to integrate use cases in to requirements doc

<dom> ACTION-77?

<trackbot> ACTION-77 -- John Morris to provide a discussion of requirements
for privacy -- due 2010-01-19 -- OPEN

<trackbot> [http://www.w3.org/2009/dap/track/actions/77][22]

### api issues

darobin: lots happening

[very hard time hearing you robin]

<dom> [I suggest sending the CfC now, with one week review]

<tlr> [+1]

<fhirsch> +1 to Dom

darobin: should we wait to discuss CfC today or next week?

<tlr> s/Dom/Dom/

<schittur2> +1

we will discuss next week

<maxf> gah!

<maxf> brb

darobin: not much work on other issues in past couple of weeks

[waiting for maxf to return]

maxf: ... discussions about what to put into each individual property about
which we have info

questions are unlined by general principles....

are there use cases for properties we are going to include

decisions need to be made on case by case basis

questions about how much privacy/security sensitivity with each property

maxf: need to hear from people who care

<Zakim> Thomas, you wanted to attempt framing the higher-level decision

tlr: agree with max's framing

at least for subset of comments, one approach to ask is this in scope for work
we want to do

broad question: do we want to provide info for run time execution environment

e.g., cpu, etc.

other comments: network area - do we believe that network is taken as a given

or do we need more info on network connectivity

sub issue - detailed info on network can equal location info....

<tlr> zakjim, mute me


tend agree that properties like cpu, etc., are attributes that vendors do not
want to expose

in practice, unlikely that apps will adjust based on these properties

<dom> [I think the uses cases are for applications whose role is actually to
deal with these low-level details]

we should focus on more import things like displays, IO


<tlr> dom, right -- the question is whether we assume CPU and network are
managed by the runtime, or whether we think we're managing them.

prefer not to expose cpu, other details

<Zakim> dom, you wanted to propose a framing

dom: ... thanks maxf for work on this....

<darobin> indeed, thanks maxf!

<fhirsch> +1

good way to frame this this for v1 of spec -- we only focus on general purpose
application features

<tlr> thanks maxf!

and we not focus on cpu and less general purpose properties

darobin: this could be a separate spec versus a different version

... agree with dom's framing

<tlr> :)

maxf: happy to focus on general purpose application features

<Dzung_Tran> for completeness don't we want to cover CPU, however I am fine
with moving it to later version

maxf: temperature is hard

<fhirsch> does this principle mean, not include what is marked as "internal"

don't know how to simply draft with several thermometers

<tlr> I'd drop thermo, battery, cpu, fan.

<wonsuk> +1 for moving general things to later version.

darobin: might make sense to have more complex thermal but simpler cpu

<Dzung_Tran> What is so hard about temperature?

<dom> [I think something should be kept when attached with a "generic" use

<tlr> I'm fine with keeping external temperature, but would drop internal
temperature sensors.

fhirsch: not sure what "general purpose application features" mean

<Dzung_Tran> Temperature is extremely important in mobile device

maxf: I could write proposal on list

<tlr> Dzung, how about commenting on the phone?

<scribe> **ACTION:** maxf to write to list of properties to drop or simplify
[recorded in [http://www.w3.org/2010/01/06-dap-minutes.html#action03][23]]

<trackbot> Created ACTION-80 - Write to list on properties to drop or simplify
[on Max Froumentin - due 2010-01-13].

<Dzung_Tran> I can't join today, actually I need to drop right now, sorry

<schittur2> Input/Output, Codec support, Network coverage are fairly common
and useful properties to have

tlr: device management applications are not a generic use case

<fhirsch> not sure resolution is needed, but ok with me - still will have to
make decisions of what it means

<schittur2> Internal, and sensor related properties are very low-level and not
general purpose properties

<dom> "apps not directly targeted at monitoring the said sensors"

<darobin> PROPOSED RESOLUTION: use a "generic use case"/"apps not directly
targeted at monitoring the said sensors" measurement to decide whether
something is to be included in SysInfo or not

<tlr> good enough

<darobin> MF: sounds good

<dom> [maybe s/SysInfo/SysInfo v1/]

<tlr> oh, yes, webapps globally reconfiguring the keyboard! That's fun.

fhirsch: what about keyboard, camera flash? is that general?

darobin: there is a general use case for knowing keyboard type

tlr: some settings are set-able

not all are just read-only

some will lead to misunderstanding

tlr: if this value is useful for more than just itself, it may be "generic"

... cpu fan value may monitor for itself

<darobin> RESOLUTION: use a "generic use case"/"apps not directly targeted at
monitoring the said sensors" measurement to decide whether something is to be
included in SysInfo or not

**RESOLUTION: use a "generic use case"/"apps not directly targeted at
monitoring the said sensors" measurement to decide whether something is to be
included in SysInfo or not**

<fhirsch> in essence resolution says use case driven material can be included,
platform specifics not included

schittur: on calendar api, did sent out draft use cases and requirements

looking at intersection of different calendar apis

will send to whole group next week

or soon after

tlr: 2 questions:

<Zakim> Thomas, you wanted to ask whether to track the "encrypted" piece as

encrypted attribute on network interface

re net interfaces, some sensor data might permit to infer additional info

<fjh> link to suresh message on calendar use cases -

such as net interfaces or location

darobin: open issues on these points

tlr: will do so

<fhirsch> +1 to opening issues

tlr: singing ...

<wonsuk> thanks

closing call...

<paddy> thanks

## Summary of Action Items

**[NEW]** **ACTION:** fjh fix Seoul time in agenda to be 24:00 [recorded in

**[NEW]** **ACTION:** maxf to write to list of properties to drop or simplify
[recorded in [http://www.w3.org/2010/01/06-dap-minutes.html#action03][23]]

**[NEW]** **ACTION:** Paddy to integrate his use cases in policy requirements
[recorded in [http://www.w3.org/2010/01/06-dap-minutes.html#action02][21]]

[End of minutes]

* * *

Minutes formatted by David Booth's [scribe.perl][25] 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/01/06-dap-irc

   [5]: #agenda

   [6]: #item01

   [7]: #item02

   [8]: #item03

   [9]: #item04

   [10]: #ActionSummary

   [11]: http://www.w3.org/2010/01/06-dap-minutes.html#action01

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

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

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

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

   [16]: http://www.w3.org/2009/dap/track/actions/63

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

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

   [19]: http://www.w3.org/2009/dap/track/actions/69

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

   [21]: http://www.w3.org/2010/01/06-dap-minutes.html#action02

   [22]: http://www.w3.org/2009/dap/track/actions/77

   [23]: http://www.w3.org/2010/01/06-dap-minutes.html#action03

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

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

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

Received on Wednesday, 6 January 2010 15:56:41 UTC

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