Device APIs and Policy Working Group Teleconference

06 Jan 2010


See also: IRC log


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




<trackbot> Date: 06 January 2010

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

<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 http://www.w3.org/2010/01/06-dap-minutes.html#action01]

<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-apis/2009Dec/att-0231/minutes-2009-12-16.html

minutes approval

resolution: minutes from 16-dec approved


<fhirsch> ReSpec, added refNote and additionalCopyrightHolders


<fhirsch> http://lists.w3.org/Archives/Public/public-device-apis/2009Dec/0293.html

<fhirsch> http://lists.w3.org/Archives/Public/public-device-apis/2009Dec/0295.html

some discussion of document on list

<fhirsch> action-63?

<trackbot> ACTION-63 -- Laura Arribas to review http://lists.w3.org/Archives/Public/public-device-apis/2009Nov/0044.html -- due 2009-11-25 -- CLOSED

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

<fhirsch> TAG response

TAG response

<fhirsch> http://lists.w3.org/Archives/Public/public-device-apis/2009Dec/0297.htm

<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-apis/2009Dec/0297.html

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

<dom> Policy Use cases from Paddy

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 environments

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]

<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

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 case]

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

<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

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

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 - http://lists.w3.org/Archives/Public/public-device-apis/2009Dec/0241.html

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 http://www.w3.org/2010/01/06-dap-minutes.html#action01]
[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]
[NEW] ACTION: Paddy to integrate his use cases in policy requirements [recorded in http://www.w3.org/2010/01/06-dap-minutes.html#action02]
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.135 (CVS log)
$Date: 2010/01/06 15:48:46 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.135  of Date: 2009/03/02 03:52:20  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/DOM/Dom/
Succeeded: s/DOM/Dom/
Succeeded: s/nextr/next/
Succeeded: s/interna/internal/
Succeeded: s/list of/list on/
Found Scribe: John Morris
Found ScribeNick: jmorris
Present: Robin_Berjon Frederick_Hirsch ThomasRoessler Dzung_Tran Wonsuk_Lee Paddy_Byers Suresh_Chitturi Laura_Arribas Dominique_Hazael-Massieux John_Morris Marcin_Hanclik
Regrets: Anssi_Kostiainen Marco_Marengo DavidRogers
Agenda: http://lists.w3.org/Archives/Public/public-device-apis/2009Dec/0298.html
Found Date: 06 Jan 2010
Guessing minutes URL: http://www.w3.org/2010/01/06-dap-minutes.html
People with action items: fjh maxf paddy

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.

[End of scribe.perl diagnostic output]