W3C

Device APIs and Policy Working Group Teleconference

30 Jun 2010

Agenda

See also: IRC log

Attendees

Present
Frederick_Hirsch, Ilkka_Oksanen, LauraA, Niklas_Widell, Robin_Berjon, Erica_Newland, Maria_Oteo, John_Morris, Richard_Tibbett, Ingmar_Kliche, bryan_sullivan
Regrets
Dominique_Hazael-Massieux, Thomas_Roessler, Dzung_Tran, Paddy_Byers, Suresh_Chitturi, Doug_Turner, James_Salsman, Marco_Marengo
Chair
Robin_Berjon, Frederick_Hirsch
Scribe
AnssiK, jmorris

Contents


<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

Welcome, agenda review, scribe selection

<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 ML
... 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

Minutes Approval

<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

Policy - "checkPermissions"

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

WICDA

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

APIs - SysInfo and Policy buckets

<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

Contacts API

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

Capture

<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 HTmailing list5 ? 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?

Summary of Action Items

[NEW] 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]
[NEW] 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]
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.135 (CVS log)
$Date: 2009-03-02 03:52:20 $