Device APIs and Policy Working Group Teleconference -- 01 Sep 2010

<trackbot> Date: 01 September 2010

<Claes> s /Claes /Claes_Nilsson

<fjh> ScribeNick: AnssiK

Administrative, Meetings

<fjh> next F2F WG questionnaire and TPAC registration and information

<fjh> WG questionnaire (for all), http://www.w3.org/2002/09/wbs/43696/tpac2010dap/

<fjh> TPAC registration (for in-person attendees) http://www.w3.org/2002/09/wbs/35125/TPAC2010reg/

<fjh> March F2F (Seoul, Korea)

<fjh> http://www.w3.org/2002/09/wbs/43696/seoul-f2f-dates/

<dom> March Seoul F2F dates results

fjh: 2nd week for March F2F seems to work the best

<fjh> 15—18 March 2011

fjh: when people are ready for a decision on the date?

PROPOSED RESOLUTION: F2F will be 15-18 March 2011

RESOLUTION: DAP F2F will be on 15-18 March 2011

Minutes approval

<fjh> Approve 25 August minutes

<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2010Aug/att-0082/minutes-2010-08-25.html

<fjh> proposed RESOLUTION: 25 August minutes are approved

RESOLUTION: Minutes from 25th August are approved

Device API Access Control Use Cases and Requirements

<fjh> Clarify normativeness

<fjh> proposal : http://lists.w3.org/Archives/Public/public-device-apis/2010Aug/0107.html (Thomas)

<fjh> and mark sections as informative

<dom> (they are requirements for specs, rather than implementations)

Claes: has looked at other W3C req docs
... the doc should be purely informative
... using uppercase keywords would be confusing

dom: W3C has quite many informative docs with RFC keywords

<fjh> having the keywords adds to clarity of the document

Claes: the doc is stating what we should do

<fjh> when corresponding document goes to Rec then need to show we have met requirements, indicated by MUST, SHOULDs in requirements document

<jsalsman> which section of http://dev.w3.org/2009/dap/policy-reqs/ are we discussing? the whole thing?

Claes: must decide what we want to spec re access control

<fjh> we are discussing the requirements and how they should be stated

Claes: UC is tricky, must be user friendly, secure

fjh: highlighting the difficulties in the doc is valuable
... the doc will change based on the direction the WG will take
... I'm open to all proposals

Claes: agrees, the doc is in a better shape now

<jsalsman> http://lists.w3.org/Archives/Public/public-device-apis/2010Aug/0107.html refers to section 3, "Trusted Widget or Application"

Claes: and it should be published

<fjh> approach is to publish early and often

fjh: mark sections as informative but leave keywords

Claes: would like to hear Google's view

fjh: would prefer to publish early and often
... people will understand it's a draft

<fjh> proposed RESOLUTION: Publish updated WD of Device API Access Control Use Cases and Requirements on 2 September 2010

fjh: anyone having concerns with publishing?

<fjh> proposed RESOLUTION: Publish updated WD of Device API Access Control Use Cases and Requirements on 7 September 2010

RESOLUTION: Publish updated WD of Device API Access Control Use Cases and Requirements on 7 September 2010

Features

<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2010Aug/0084.html

Device API Features and Capabilities

<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2010Aug/0084.html

fjh: involved people are not on the call so let's move on

Privacy

<fjh> ACTION-210?

<trackbot> ACTION-210 -- Alissa Cooper to summarize and add issues to ruleset doc -- due 2010-07-21 -- OPEN

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

<fjh> ACTION-251?

<trackbot> ACTION-251 -- John Morris to review privacy text related to ISSUE-78 for capture -- due 2010-08-11 -- OPEN

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

<fjh> s/member:jsalsman speaking?//

jmorris: will complete the action later

Contacts

<fjh> IETF/OMA/PoCo/W3C convergence

<richt> Contacts Formats Comparison: http://www.w3.org/2009/dap/wiki/ContactFormatsComparison (work in progress)

<fjh> call scheduled for Friday this week

<fjh> I18N review http://lists.w3.org/Archives/Public/public-device-apis/2010Aug/0094.html

richt: Adison Philips(?) suggested i18n WG to look into Contacts API

<fjh> ACTION: fjh to prepare Access Control use cases and requirements for publication [recorded in http://www.w3.org/2010/09/01-dap-minutes.html#action01]

<trackbot> Created ACTION-266 - Prepare Access Control use cases and requirements for publication [on Frederick Hirsch - due 2010-09-08].

https://spreadsheets.google.com/ccc?key=0ApaQz5_5IF2OdFIxVmxmdlA0YzhUVU1Sc1k1WnNXTHc&hl=en

<fjh> Anssi notes copy of google spreadsheet similar

<fjh> Anssi suggests creating a link from the wiki to the google document

<dom> ACTION-264: http://www.w3.org/2009/dap/wiki/ContactFormatsComparison

<trackbot> ACTION-264 Produce a spreadsheet of sorts showing overlap/mapping/correspondance between vcard4, poco, cab, and us notes added

<fjh> Rich: wiki allows modification by DAP group

<Zakim> dom, you wanted to comment on I18N request

<dom> dom: would probably useful to point to the I18N guys that the properties in use in Contacts are still in flux, given the coordination needs

<dom> ... given that these properties are likely to be a focus of the I18N review

nwidell: how to make a decision, vote?

<richt> richt: we have abstract terms for addresses, names, etc. e.g. the ability to represent my first name in japanese characters with a translation to Western characters would apply to any contact format we end up with.

fjh: approach is to look at the facts, do a comparison and it goes from there
... try to avoid voting, cleaner solution preferred

<richt> richt: therefore i18n feedback on the spec at this stage may flush out these details.

Capture

<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2010Aug/0095.html

<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2010Aug/0100.html

jsalsman: any objections to spec default audio capture type?

<fjh> msg from james -> http://lists.w3.org/Archives/Public/public-device-apis/2010Aug/0110.html

ilkka: complicated issue, would like to note there are many other audio formats in the use so not sure if we can agree on a specific codec
... would mean all the implementation should include support for that codec

<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2010Aug/0102.html

dom: we should highlight that as an issue in the doc, even if we don't go further with other changes
... what are the audio codecs browsers support today

jsalsman: Speex is open source

fjh: do we want to require a specific codec?

<dom> [let's raise an issue about it, maybe?]

jsalsman: there has not been enough encouragement to do decisions around this issue

<dom> ISSUE: should we define a default audio (video?) codec for capture? if so, which?

<trackbot> Created ISSUE-101 - Should we define a default audio (video?) codec for capture? if so, which? ; please complete additional details at http://www.w3.org/2009/dap/track/issues/101/edit .

fjh: thinks we should raise an issue and add a note in the doc

<dom> ISSUE-101: would need a royaltee-free codec, already widely deployed in browsers

<trackbot> ISSUE-101 Should we define a default audio (video?) codec for capture? if so, which? notes added

jsalsman: why not wait a bit before the decision is made?

fjh: proposes jsalsman to send an email to the list

jsalsman: will follow up with an email on ISSUE-101

<fjh> ISSUE-101: http://lists.w3.org/Archives/Public/public-device-apis/2010Aug/0102.html

<trackbot> ISSUE-101 Should we define a default audio (video?) codec for capture? if so, which? notes added

fjh: add a note to the draft, ok?

ilkka: can do that before publishing

jsalsman: anyone having concerns in specing max duration?
... for audio

<fjh> ACTION: ilkka to add note to capture draft regarding ISSUE-101 [recorded in http://www.w3.org/2010/09/01-dap-minutes.html#action02]

<trackbot> Created ACTION-267 - Add note to capture draft regarding ISSUE-101 [on Ilkka Oksanen - due 2010-09-08].

jsalsman: we have that for video already

<jsalsman> I agree with dom that we should have maximum duration specified too

<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2010Aug/0097.html

<fjh> ilkka: media capture API - need working draft

<dom> +1 to send a CfC for media capture API

ilkka: no pending actions, ready for CfC

<fjh_clone> ACTION: fjh to send CfC for media capture API, for next week [recorded in http://www.w3.org/2010/09/01-dap-minutes.html#action03]

<trackbot> Created ACTION-268 - Send CfC for media capture API, for next week [on Frederick Hirsch - due 2010-09-08].

dom: one week for CfC

Calendar

<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2010Aug/0097.html

SysInfo

<fjh> Outstanding editorial and review items - planned completion mid august (see http://lists.w3.org/Archives/Public/public-device-apis/2010Aug/att-0017/minutes-2010-08-04.html#item05 )

<fjh> ACTION-213?

<trackbot> ACTION-213 -- Richard Tibbett to review sysinfo draft after edits made -- due 2010-07-21 -- OPEN

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

<fjh> ACTION-243?

<trackbot> ACTION-243 -- Dong-Young Lee to review sysinfo draft after edits made -- due 2010-08-09 -- OPEN

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

<fjh> ACTION-214?

<trackbot> ACTION-214 -- Thomas Roessler to request IETF community review of sysinfo API Last Call WD through W3C/IETF liaison channel -- due 2010-09-21 -- OPEN

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

jsalsman: only remaining things were typos and such

<dom> http://dev.w3.org/geo/api/spec-source-orientation.html

<fjh> anssiK: what happened move of material to geoloc from sysinfo?

<Dzung_Tran> That was forwarded to geolocation group quite a bit back

<fjh> anssi: do we know when to expect FPWD of this?

Other API status

fjh: any issues?

<fjh> ACTION-216?

<trackbot> ACTION-216 -- WonSuk Lee to reformulate gallery API to look like contacts API -- due 2010-07-21 -- OPEN

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

fjh: anything more to add?

<Claes> Device Orientation spec draft is being discussed at the WG list. Two DOM events defined: Orientation data as angles in an x, y, z coordination system and raw accelerometer and gyra data event.

Adjourn

<fjh> member:rrsagent, generate minutes

- DRAFT -

Device APIs and Policy Working Group Teleconference

01 Sep 2010

Attendees

Contents