See also: IRC log
<trackbot> Date: 30 June 2010
<darobin> FYI: there is no Team contact today, please be nice and stick to the rules (or else...)
<AnssiK> ScribeNick: AnssiK
<fjh> F2F in London
<fjh> http://www.w3.org/2002/09/wbs/43696/london2010/
fjh: any thought on the f2f agenda, please speak up on the mailing list
... f2f is Wed-Fri, some people are not avail on Fri
... proposal to start early Wed & Thu, finish early on Fri
<fjh> PAC registration and information available (F2F after London F2F, 4-5 November )
<fjh> http://lists.w3.org/Archives/Member/member-device-apis/2010Jun/0001.html
<fjh> Policy and Privacy requirements published
<fjh> http://www.w3.org/News/2010#entry-8845
fjh: remember that the TPAC 2010 is coming, beginning of November
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2010Jun/att-0266/minutes-2010-06-23.html
RESOLUTION: Minutes from 23 June 2010 approved
fjh: is this just a check to see if an API is available, unclear how this related to policy
darobin: checkPermission checks if permissions already granted, requestPermission allows grouping items like calendar, geoloc etc into a single request check
... allow scripts to know permissions granted
... requestPermission() example: instead of asking multiple times group to ask user only once
fjh: so requestPermission is similar to features. All this makes clear we need to clarify the model
darobin: idea came from a need to augment existing WebIDL
... problem is WebIDL is not under control of this WG, also REST bindings require something similar
... infrastructure building block to use if people like it
<fjh> robin notes WICDA is needed for REST work but may be useful for policy as well
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2010Jun/0322.html
<fjh> sysinfo - device characteristics, sensors, network
jmorris: (1) device characteristics (2) environmental elements, sensing the ext environment around the device (3) network elements
<fjh> bryan notes that buckets are similar to features in policy framework
<jmorris> I can scribe for a few minutes
<richt> ScribeNick: jmorris
robin: not sure how far we can go without James
<fjh> I think it is useful to put the various categories in the document and then later tie to policy
fjh: not sure James's concern was with the bucket idea
robin: seems unlikely to reach consensus about publication without more conversation with James
bryan: working on draft now, trying to address outstanding issues
... if there are outstanding issues, we need to get input on the list
... thinks there may be misunderstanding re intent of SysInfo API
<fjh> proposal: add to sysinfo privacy section, subcategory of privacy categories, use text from John email
bryan: but we need to be proactive
robin: agree it should not drift, but we need to loop james in to conversation
... we can move forward later today or tomorrow on list conversation
... I only read bucket proposal quickly before call... but it matches discussion of last week
fjh: could use some text from jmorris e-mail re buckets, e.g. from the paragraph after "Using the 16" through paragraph before "Especially..."
... bryan, can you add that to draft
<fjh> ACTION: bryan to add proposal from John Morris re buckets to sysinfo [recorded in http://www.w3.org/2010/06/30-dap-minutes.html#action01]
<trackbot> Created ACTION-203 - Add proposal from John Morris re buckets to sysinfo,http://lists.w3.org/Archives/Public/public-device-apis/2010Jun/0322.html [on Bryan Sullivan - due 2010-07-07].
fjh: Bryan, you have some non-controversial edits, plus debate with James
<AnssiK> ScribeNick: AnssiK
<darobin> ACTION: Robin to step into the Bryan/James thread in the hope of helping find consensus [recorded in http://www.w3.org/2010/06/30-dap-minutes.html#action02]
<trackbot> Created ACTION-204 - Step into the Bryan/James thread in the hope of helping find consensus [on Robin Berjon - due 2010-07-07].
<fjh> bryan summarizes - characteristics of the connection can indicate preferred connection, active connection
<jmorris> okay, thanks
<fjh> anssi asks for use cases regarding active connections
<fjh> sounds like a layering problem
<richt> I would rather like to speak in technical WebIDL proposals on the mailing list where possible.
<fjh> robin notes that all should comment on email list, including use cases
bryan_sullivan: relationship to onLine attribute of HTML5?
... one potential UC is to allow the developer to choose the best bearer for the task
richt: filtering added
<richt> http://www.w3.org/2009/dap/track/actions/198
<fjh> ACTION-198?
<trackbot> ACTION-198 -- Richard Tibbett to prepare Contacts for publications, with pubrules -- due 2010-06-29 -- PENDINGREVIEW
<trackbot> http://www.w3.org/2009/dap/track/actions/198
<darobin> Contacts intermediate draft in the publication pipeline
richt: hoping to publish a new version immediately following the upcoming f2f
<darobin> close action-198
<trackbot> ACTION-198 Prepare Contacts for publications, with pubrules closed
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2010Jun/0318.html
darobin: how to handle serviceId discussion without Suresh, perhaps a f2f topic
<fjh> re serviceId and the use of PoCo schema
richt: f2f is ok
fjh: how about PoCo?
darobin: any updates from Mike/Mozilla?
richt: follow up
darobin: aligning with the Moz impl would be very helpful
... let's keep Mike in the loop
<darobin> Capture thread
darobin: not that much new stuff, levels, splitting, v1 vs. v2 split
... browser vendors would like to see simpler v1
... wait for more input, or go split it
<richt> IMO, we should create a simpler v1 for browser vendors if that is their implementation plan - it seems like Mozilla and Google are persuing a simpler version and we should support that effort.
darobin: Level 1: using <input>, Level 2: programmatic capture
<fjh> level 3 discovery of available devices etc
darobin: Prague f2f decision was to do L1 and L2 in the same doc, however browser vendors would like to see the spec split
robin: if split means faster implementations then this is a Good Thing
darobin: hearing split would be preferred, any objections to that?
ilkka: how would the schedule look like re v1 and v2?
robin: we can work on parallel
<richt> However, I wonder whether the browser's implementation plans on <input> are not already covered in HTML5 ? It seems the only addition is a source attribute. That probably doesn't require a separate spec right?
ilkka: would like to see the programmatic API worked on in parallel to <input> based approach
<darobin> PROPOSED RESOLUTION: Capture is split into levels; those may progress in parallel
RESOLUTION: Capture is split into levels; those may progress in parallel
darobin: any other API topics?