See also: IRC log
<trackbot> Date: 03 October 2013
<Josh_Soref> scribe: Josh_Soref
fjh: welcome everyone
<fjh> CR drafts of Ambient Light Events and Proximity Events published 1 Oct, http://lists.w3.org/Archives/Public/public-device-apis/2013Oct/0001.html
fjh: thanks to anssik for working on
... i wonder if we should cancel the call the week of TPAC
<dom> +1 to cancel call during TPAC week
anssik: i think we should cancel
<fjh> RESOLUTION: Cancel DAP teleconference 14 November
<fjh> (week of TPAC)
<fjh> Approve minutes from 26 September 2013
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2013Sep/att-0060/minutes-2013-09-26.html
RESOLUTION: Minutes from 26 September 2013 are approved
<fjh> CR drafts published 1 Oct,
<fjh> http://www.w3.org/TR/2013/CR-ambient-light-20131001/
<fjh> http://www.w3.org/TR/2013/CR-proximity-20131001/
<fjh> ISSUE-153?
<trackbot> ISSUE-153 -- Would interface and event name change be possible and clearer -- pending review
<trackbot> http://www.w3.org/2009/dap/track/issues/153
fjh: we got feedback asking about changing the name
... but we had feedback from Mozilla that they have shipped it and aren't willing to change
anssik: Mozilla has a point
... this is about naming (bike-shedding), not functionality
... I wonder if the person w/ the feedback had a proposal
fjh: i proposed an alternative
... the feedback was just that the name didn't match functionality
... but it isn't worth cycling around on this given Mozilla's feedback
anssik: regardless of the name, someone will be unhappy
... we have Device-prefix and User-prefix
... we have getUserMedia
... we have DeviceOrientation
... i agree they don't clearly match what the api is about but...
fjh: i agree
... i'd suggest we close the issue out
Josh_Soref: +1
fjh: i'll send a response
<fjh> ISSUE-153: feedback on list from Mozilla that too late to change naming for implementation, WG agrees to close issue with no change
<trackbot> Notes added to ISSUE-153 Would interface and event name change be possible and clearer.
<fjh> close ISSUE-153
<trackbot> Closed ISSUE-153.
<fjh> ACTION: fjh to respond regarding ISSUE-153 that it is closed [recorded in http://www.w3.org/2013/10/03-dap-minutes.html#action01]
<trackbot> Created ACTION-663 - Respond regarding issue-153 that it is closed [on Frederick Hirsch - due 2013-10-10].
fjh: we need to figure out our next steps for Proximity and Light
... later in the agenda, we can do test plan
... anything else to talk about now?
anssik: wrt Tests, iirc i've asked our QA to review them
... i'll need to refer back to the repo to find out what has been done
dom: there was a review of the existing TCs
... and i reviewed them before merging
... the existing TCs match the spec
... but they don't completely cover it
... there's very little about semantics of the event
... that there is/isn't an object
... that there is/isn't a level of light
... I understand that you guys were going to look into contributing test cases
... but i don't know if there are specific plans
anssik: i'm trying to find the initial pull-request where the comments were
fjh: i assume your team knows it's in CR now
... and i think they should review the plans
<dom> Pull Request for proximity events
anssik: i think they're informed
... QA follows the list
<dom> Pull Request for ambient light events
anssik: those are the changes
... our QA looked at them
... to look for gaps
... i tasked them to fill in the gaps
dom: i can't recall if there was a private thread or a thread on the main repo issues list
anssik: i'll follow
... up
... our QA guy said he'd like to add new tests
... let's leave this open
... we'll come back w/ more tests
fjh: any idea when that will happen?
anssik: there's a holiday period this week in China
... but definitely by the end of the year
... i'd assume w/in a couple of weeks
... i'll follow up on the thread
fjh: it'd be helpful if you could share where we're at
<fjh> ISSUE-146?
<trackbot> ISSUE-146 -- Add vibration strength control -- open
<trackbot> http://www.w3.org/2009/dap/track/issues/146
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2013Oct/0019.html
LisaDeLuca_IBM: There was feedback in cordova that iOS doesn't support vibration strength
fjh: so you support deferring it
LisaDeLuca_IBM: yes
fjh: and anssik, you were the same?
Josh_Soref: i also support deferring
fjh: and anssik was asking for other feedback
<fjh> proposed RESOLUTION: defer strength until future version
Josh_Soref: +1
RESOLUTION: defer strength until future version
<fjh> ISSUE-149?
<trackbot> ISSUE-149 -- handling of long vibration list - truncate or no vibration at all -- open
<trackbot> http://www.w3.org/2009/dap/track/issues/149
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2013Oct/0012.html
fjh: i think we should put this in the spec
<fjh> defer until next week, but proposal is to adopt resolution provided by anssi
Josh_Soref: i wonder if someone does something like: [1, 2, 3, 4, 1000, 2, 1000]
... if all you get is 1,2,3,4 then you might totally miss the goal of the thing
<fjh> ISSUE-150?
<trackbot> ISSUE-150 -- Should vibration be additive when multiple instances, e.g. iframes -- open
<trackbot> http://www.w3.org/2009/dap/track/issues/150
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2013Oct/0003.html
anssik: back to Josh_Soref 's question
<fjh> ISSUE-150: proposal related to ACTION-652 http://lists.w3.org/Archives/Public/public-device-apis/2013Oct/0003.html
<trackbot> Notes added to ISSUE-150 Should vibration be additive when multiple instances, e.g. iframes.
anssik: i don't have a position
Josh_Soref: on additive
anssik: i was still thinking about 149
fjh: let's move on to 150
Josh_Soref: on additive ... my concern is that the timing is fairly random
<fjh> this one makes sense to me, please review ,we will decide next week for ISSUE-150
Josh_Soref: so yes, i think i support anssik 's proposal
anssik: iOS is probably the most limited
Josh_Soref: i don't think the underlying system matters so much
... as long as the underlying system has a stop and insert replacement
... you can always emulate this
... but the timing of the overlapping things will be fairly inconsistent
... and impossible for a user to recognize
fjh: where you layer it might have an effect
... os/browser-engine/browser
... i think the proposal is good
Josh_Soref: me too
<fjh> ISSUE-152?
<trackbot> ISSUE-152 -- Vibration API events start/pause/resume/cancel and status listener start/pause/resume/cancel/finish -- pending review
<trackbot> http://www.w3.org/2009/dap/track/issues/152
fjh: i think i can just close this
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2013Oct/0004.html
Josh_Soref: would it tell the app when it's not-currently-vibrating-but-will-shortly
fjh: it isn't speced out
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2012Nov/0015.html
<anssik> earlier similar feedback: http://lists.w3.org/Archives/Public/public-device-apis/2012Nov/0015.html
fjh: i think we could ask for a more detailed proposal
Josh_Soref: i think we'd need UCs
fjh: do we have accurate enough timings to be able to do anything?
Josh_Soref: i doubt we could
... my guess is that you won't be able to respond fast enough to do something useful
<anssik> +1 for deferring to v2
Josh_Soref: +1 for deferring
fjh: it seems the UC would have to be specifically spelled out
... proposing a change could result in more complexity without solving the problem
RESOLUTION: Defer ISSUE-152
<fjh> ACTION: fjh to respond indicating ISSUE-152 deferred, suggesting more detailed use case/requriements for v.next [recorded in http://www.w3.org/2013/10/03-dap-minutes.html#action02]
<trackbot> Created ACTION-664 - Respond indicating issue-152 deferred, suggesting more detailed use case/requriements for v.next [on Frederick Hirsch - due 2013-10-10].
fjh: Cathy is here, richt is not
<fjh> ISSUE-154?
<trackbot> ISSUE-154 -- Security approach -- open
<trackbot> http://www.w3.org/2009/dap/track/issues/154
fjh: i added a new issue
... i'm trying to capture what we've raised and what we've resolved
... it starts w/ a good message by Youenn Fablet
<fjh> Youenn Fablet sent good summary linking to external implementer discussions
fjh: we're having the discussion on the list
... there are two conclusions that i'm drawing
... one is deciding what to do on CORS
... richt has a proposal that came out just before the call
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2013Oct/0014.html
fjh: the second topic is how much requirement do we have to support legacy devices
jcdufourd: if we don't support legacy devices
... when NSD comes up in browser
... if there are no supported devices
... no one will be interested in using it
... we need to design a standard that would be adopted
fjh: that's a question the implementers raised
... questions about security
... there's also a question about usefulness
... i sent a question about
... what if i have a router which is insecure, it supports Router and Media
... and you attack the media bit, take over the router
... and then control DNS and attack other things
... it seems to be a real case
... there's a uPNP link pointing to papers identifying insecurities
... i'm not sure CORS helps
... i'm not sure it prevents an attack post discovery phase
... maybe whitelist-blacklist will work
... i dunno
jcdufourd: the UCs i see that are useful for bootstrapping
<scribe> scribe: fjh
jcdufourd: only need to discovery services specific to your need
… permission to discover by user limits what can be discovered
… whitelist should only allow discovery of these two services by one webapp
… this could be more of a requirement for more UI
… this could be totally safe
fjh: there's the possibility that a malicious web site could pretend to be friendly
... get permission for a reasonable service
... attack the buggy part of the reasonable service
... and then having taken over the device
... abuse the more valuable services (router)
dom: we should re-use web technologies such as CORS as much as possible and also consider whitelisting to enable legacy to the extent possible
… also we cannot address all security issues ,e.g. regarding the router issue, but we can note in security considerations
fjh: agree we must address the implementer concerns re security in the security considerations section
… even if to only highlight and describe the issue and outline potential mitigations
Josh_Soref: we could propose banning all services from devices which advertise scary services
<igarashi> +q
fjh: a number of issues related to network service discovery are open, we should attempt to resolve on the list
igarashi: CORS specific to web applications due to HTTP header usage
… so CORS helps
ISSUE-130?
<trackbot> ISSUE-130 -- Enable variety of protocols (e.g. UPnP, Bonour) with protocol independent developer code -- open
<trackbot> http://www.w3.org/2009/dap/track/issues/130
ISSUE-131?
<trackbot> ISSUE-131 -- Support UPnP device discovery by Device Type? -- open
<trackbot> http://www.w3.org/2009/dap/track/issues/131
ISSUE-133?
<trackbot> ISSUE-133 -- Fix UPnP events subscription and unsubscription -- open
<trackbot> http://www.w3.org/2009/dap/track/issues/133
ISSUE-134?
<trackbot> ISSUE-134 -- Rename NetworkServices and NetworkService events -- open
<trackbot> http://www.w3.org/2009/dap/track/issues/134
close ISSUE-134
<trackbot> Closed ISSUE-134.
ISSUE-147?
<trackbot> ISSUE-147 -- Reference 'Requirements for Home Networking Scenarios' in Introduction -- open
<trackbot> http://www.w3.org/2009/dap/track/issues/147
ISSUE-148?
<trackbot> ISSUE-148 -- NetworkService.name definition in 8.2.2.4 incoherent with definition in 7.1 (a human-readable title for the service) -- open
<trackbot> http://www.w3.org/2009/dap/track/issues/148
ISSUE-151?
<trackbot> ISSUE-151 -- USN should not be used as device identifier -- open
<trackbot> http://www.w3.org/2009/dap/track/issues/151
ISSUE-154?
<trackbot> ISSUE-154 -- Security approach -- open
<trackbot> http://www.w3.org/2009/dap/track/issues/154
fjh: web and TV IG is cc'd on security discussion
... waiting on PING and Web & TV formal review given the large number of open issues, potential changes
... can ask PING informally about the Nov slot
... this spec is in WD, eventually LC and CR, not ready to consider given state of change
... can expect this draft will not go into LC until next year
... would like to see LC this year if we can
dom: need to check with Rich but would like to take advantage of current momentum
fjh: still discussing with Mounir re Mozilla offline
<anssik> we're looking at this internally and will try come back with feedback
Review plans for progressing work through year-end.
All active non-task-force specifications are in CR (Battery Status, HTML Media Capture, Ambient Light Events, Proximity Events, Vibration API) apart from Network Service Discovery (WD)
http://www.w3.org/2009/dap/#roadmap
Walk through test case status, review plans.
charter: http://www.w3.org/2011/07/DeviceAPICharter
Additional work on permissions API, privacy?
fjh: need to link to test case to HTML Media Capture from DAP home page, not sure of status
<anssik> https://github.com/w3c/web-platform-tests/pull/306
<LisaDeLuca_IBM_> FYI, here is the Apache Cordova battery events (batterycritical, batterylow, batterystatus) http://cordova.apache.org/docs/en/edge/cordova_events_events.md.html#batterystatus
dom: can anssik check the status of HTML Media Capture test cases and share status on the list
fjh: how do we get the pull request for HTML Media Capture approved, who is reviewing it?
dom: bring attention to the pull request on the DAP list
… seek reviewers
… then we can go from there
… I'll put the link on the home page
<anssik> Lisa, those events are as per an earlier version of the spec
<LisaDeLuca_IBM_> @anssik, can you email me to see how I can help you with action-523 ... even if it's just testing. ldeluca@us.ibm.com
<anssik> Lisa, the tests are here: https://github.com/w3c/web-platform-tests/tree/master/battery-status
<anssik> ... but I assume your impl is not following the latest spec
ACTION-654?
<trackbot> ACTION-654 -- Jean-Claude Dufourd to Propose text for network service discovery to define wildcard api and feature detection -- due 2013-09-11 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/654
jcdufourd: will have some time to work on it shortly
ACTION-658?
<trackbot> ACTION-658 -- Dominique Hazaël-Massieux to Review issue-149 get input on tradeoff of either failing or offering partial result (not all of request) -- due 2013-10-03 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/658
ISSUE-149?
<trackbot> ISSUE-149 -- handling of long vibration list - truncate or no vibration at all -- open
<trackbot> http://www.w3.org/2009/dap/track/issues/149
close ACTION-652
<trackbot> Closed ACTION-652.
close ACTION-661
<trackbot> Closed ACTION-661.
close ACTION-662
<trackbot> Closed ACTION-662.
none
fjh: please review the issues we discussed today (as well as other open issues) so we can resolve on list and close next week if possible
… also any help reviewing or working on test cases or implementation to progress CR drafts would be helpful
… thanks