See also: IRC log
<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
yes
<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
RESOLUTION: minutes from 16-dec approved
<fhirsch> ReSpec, added refNote and additionalCopyrightHolders
who?
<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
<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
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
schittur:
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
storage
<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
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