See also: IRC log
<trackbot> Date: 01 September 2010
<fjh> ScribeNick: AnssiK
<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
<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
<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
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2010Aug/0084.html
<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
<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
jmorris: will complete the action later
<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.
<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
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2010Aug/0097.html
<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?
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.