See also: IRC log
<trackbot> Date: 11 December 2014
<scribe> ScribeNick: fjh
Media Capture Task Force CfC "Adopt new W3C process for Media Capture documents"
Battery API CR draft published: http://lists.w3.org/Archives/Public/public-device-apis/2014Dec/0004.html
"This Candidate Recommendation is expected to advance to Proposed Recommendation no earlier than 03 February 2015"
Vibration API PR draft published: http://lists.w3.org/Archives/Public/public-device-apis/2014Dec/0003.html
Comments through 20 January 2015
fjh: will any additional steps be needed to progress to REC if no concerns expressed
dom: no, it should be straightforward
Approve minutes from 13 November 2014 (v2)
RESOLUTION: Minutes from13 November 2014 are approved
fjh: a number of issues on github for follow up
fjh: follow up needed re Tim Volodine and Boris Smus joining WG?
... presumably they need to initiate request to join
... defer discussion for when we have participants, take to list
fjh: Lisa not on call. fjh: defer.
fjh: is this just happening
dom: have requested 1 year extension
... we previously discussed rechartering, but with no new work recently, extensibiiltiy mechanism not needed in short term
... simplest to extend current charter
... prefer to avoid full rechartering unless needed
fjh: is extension approved
dom: director reviews and approved, plan for review and approval next week
fjh: we will get a notice
fjh: expectation for new work?
dom: nothing firm but possibilities
see also use cases document http://w3c-webmob.github.io/wake-lock-use-cases/
gmandyam: what is permissions model
... cannot expose across 3rd parties
dom: model is that by default that all can do, but notification to user that screen is being locked
... model is ask for forgiveness model
gmandyam: do not like this model
... web sites can dramatically impact power consumption
... timely for you to disagree, but there has been a discussion
gmandyam: not sure we've agreed to bring work into the group
dom: discussed, agreed we do not need to recharter
... if and when we recharter we would add explicitly to charter, but agreed to interpret charter to include this work item
... if you disagree then we need to know so we can got throught the rechartering process
gmandyam: we only have one browser committed to this
gmandyam: will check on technical concerns regarding power consumption
dom: levels of disagreement: charter, useful for web, specifics of proposal
... need to be clear on which level of disagreement
gmandyam: are we going to progress the work or not, will got with it being in the charter and having implementer support
... need explicit decision to adopt editors draft
dom: push to FPWD would explicitly resolve decisions about progressing, considering in charter and enable call for exclusion
gmandyam: no decsions yet
dom: we have decision to get proposal in shape to enable FPWD decision
fjh: notes that FPWD triggers IPR obligations hence concern about scope, so want to know what will be in FPWD
gmandyam: would like to see dated version
dom: would want CfC for FPWD noting frozen version
fjh: how long a CfC suffices
gmandyam: a month is enough
... no need to revisit charter concerns, so now only concerned about CfC and FPWD
fjh: will ask editors if draft in github is FPWD material
<scribe> ACTION: fjh to check with wake lock editors on stability and suitability for FPWD on wake lock api [recorded in http://www.w3.org/2014/12/11-dap-minutes.html#action01]
<trackbot> Created ACTION-724 - Check with wake lock editors on stability and suitability for fpwd on wake lock api [on Frederick Hirsch - due 2014-12-18].
Network Service Discovery http://www.w3.org/TR/2014/WD-discovery-api-20140220/
fjh: any other APIs to discuss?
Network Service Discovery still under discussion, not clear it will be progressed or not
<trackbot> action-712 -- Dominique Hazaël-Massieux to Look into chartering extensibility -- due 2014-12-01 -- OPEN
dom: extending deadline for when extension expires
<gmandyam> ATSC concluded that they would adopt the HbbTV approach to local network content dist.'n (based on technologies such as DIAL), and the NSD API is not necessary
<trackbot> ACTION-723 -- Zhiqiang Zhang to Add test for user denial of captured file leading to no capture -- due 2014-10-09 -- OPEN
dom: for HTML Media Capture which is in CR; need to double check
<scribe> ACTION: fjh to follow up with Zhiquiang re ACTION-723 [recorded in http://www.w3.org/2014/12/11-dap-minutes.html#action02]
<trackbot> Created ACTION-725 - Follow up with zhiquiang re action-723 [on Frederick Hirsch - due 2014-12-18].
<trackbot> ACTION-721 -- Dominique Hazaël-Massieux to Check on call-in access to tpac plenary day breakout sessions, e.g. web api for health care sensors, next steps for web of things -- due 2014-10-09 -- PENDINGREVIEW
<trackbot> Closed ACTION-721.
<trackbot> action-722 -- Frederick Hirsch to Follow up on inviting bluetooth cg presentation at breakout -- due 2014-10-09 -- OPEN
<trackbot> Closed ACTION-722.
fjh: only one issue that is not network discovery
<trackbot> ISSUE-170 -- light levels are not retrievable until a change causes the devicelight event to fire. -- open
ISSUE-170: under discussion as part of generic sensor API discussion, http://lists.w3.org/Archives/Public/public-device-apis/2014Nov/att-0016/minutes-2014-11-13.html#item05
<trackbot> Notes added to ISSUE-170 light levels are not retrievable until a change causes the devicelight event to fire..
fjh: actually might be better to create new generic sensor api product and associate, will do that
dom: can expect more involvement in generic sensor api once we have more concrete proposals
fjh: suggest we cancel 8 Jan teleconference since we won't have much to work with after the holidays
<dom> +1 on canceling Jan 8
RESOLUTION: cancel 8 Jan teleconference, next teleconference will be 22 January
fjh: Merry Christmas, Happy New Years, Happy Holidays to all.