See also: IRC log
<trackbot> Date: 23 February 2011
<scribe> ScribeNick: Suresh
<fjh> Seoul F2F , please complete registration page, http://www.w3.org/2002/09/wbs/43696/seoul-f2f-reg/
fjh: what about dial-in?
Dom: Will look into to it
<fjh> ACTION: dom to reserve zakim line for f2f [recorded in http://www.w3.org/2011/02/23-dap-minutes.html#action01]
<trackbot> Created ACTION-341 - Reserve zakim line for f2f [on Dominique Hazaël-Massieux - due 2011-03-02].
<dom> ACTION: Dom to reserve zakim bridge for DAP F2F [recorded in http://www.w3.org/2011/02/23-dap-minutes.html#action02]
<trackbot> Created ACTION-342 - Reserve zakim bridge for DAP F2F [on Dominique Hazaël-Massieux - due 2011-03-02].
<dom> close ACTION-342
<trackbot> ACTION-342 Reserve zakim bridge for DAP F2F closed
<fjh> http://www.w3.or.kr/DAP2011/
workshop planning: http://lists.w3.org/Archives/Public/public-device-apis/2011Feb/0099.html
fjh: F2F after Seoul will be possibly June or July. We were planning on Europe, but need a host. If you can offer please let us know.
<fjh> Approve 16 February minutes
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2011Feb/att-0097/minutes-2011-02-16.html
RESOLUTION: Minutes from 16 February 2011 approved
<dom> fjh: we need hosting offers in Europe for our next F2F, in June/July timeframe
<fjh> http://www.w3.org/2010/11/DeviceAPICharter.html
<fjh> Privacy, security deliverables?
fjh: reminder to everyone to provide comments to the charter
http://lists.w3.org/Archives/Public/public-device-apis/2011Feb/0091.html
<fjh> how should this be chartered?
<dom> +1 on need to rework sysinfo
richt: the feedback is that is not ideal for implementers
<dom> http://www.w3.org/2010/11/DeviceAPICharter.html
richt: it needs to be simpler than the current model
<fjh> richt: need clarity that won't deliver specification as is, but simpler approach, in charter
dom: sys info needs to more work e.g. define how network information is made available
<fjh> richt: not able to edit, would need an editor for a new spec
Suresh: It is not clear what needs to be changed, is it the set of the properties or the model
richt: it is deep, and more complex...probably making it small for easy implementations
Suresh: one way is to cut down the properties that are non-controversial such as battery, codecs, etc..
<fjh> summary - rather than create a framework for all possibilities, start with simpler spec for specific purposes, then grow as needed
<fjh> this approach makes privacy concern easier
<dom> ACTION: Richard to propose better wording for System information and events api [recorded in http://www.w3.org/2011/02/23-dap-minutes.html#action03]
<trackbot> Created ACTION-343 - Propose better wording for System information and events api [on Richard Tibbett - due 2011-03-02].
<fjh> should the charter be more specific than "System Information"
Suresh: we need to be explicit if we believe something should not be in scope, but not sure if we should be too specific on the supported properties
Bryan: not against generic property access
<fjh> bryan agrees that if change in approach should have different new spec with different name
fjh: should we have a new spec instead of the current spec, to be clear on scope etc?
Suresh: We had the timezone issue?
<dom> ACTION-333?
<trackbot> ACTION-333 -- Richard Tibbett to draft a proposal for utcOffset based on mailing list feedback (re ISSUE-106) -- due 2011-02-16 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/333
Richt: prefer to talk about it over the list
<Dzung_Tran> Wait, I sent a message asking Rich about System Info, but I got no response
<Dzung_Tran> I rather discuss System Info, before doing anything drastic to it
<Dzung_Tran> I don't mind editing it, if I know what are the specifics
<Dzung_Tran> No, I am not on the call - only on IRC today
<bryan_sullivan> To clarify my earlier comments on sysinfo: if the intent is to focus on discrete APIs for sensors and property access than that is fine, but I would propose to drop the current sysinfo spec so that as it evolves, it does not conflict with similar implementations in the market, i.e. we need to avoid fragmentation in APIs for the same purpose, which will br brought to W3C as work in the near future.
<richt> +1 from me bryan
fjh: we should probably discuss this on the list
... we should try to reuse the work already done
hta: do we have defintion of success?
fjh: adoption and implementation
<dom> the draft new charter says "To advance to Proposed Recommendation, each specification is expected to have two independent implementations of all features defined in the specification.
<dom> APIs that cannot be demonstrated to be implementable securely within the default browser context will not be released."
<dom> as part of the success criteria
I guess we need to define "default browser context" ....