See also: IRC log
<trackbot> Date: 21 August 2013
<scribe> scribenick: fjh
Reminder: No DAP F2F at TPAC.
Publishing moratoria (26 Aug, 11 Nov, 18 Dec) https://lists.w3.org/Archives/Member/chairs/2013JulSep/0029
Reminder (28 Aug deadline): meeting time proposal: https://lists.w3.org/Archives/Member/member-device-apis/2013Aug/0000.html
fjh: if you are attending TPAC, please consider attending the Media Capture TF meeting, as they would like attendance from members of DAP
many of those on the call indicated they are attending TPAC
fjh: please let the TF know you plan to attend, perhaps by sending mail to the TF public list
please note meeting time proposal: https://lists.w3.org/Archives/Member/member-device-apis/2013Aug/0000.html
fjh: and respond if any issue, otherwise we will shift to Thursdays at same time starting 12 Sept (unless objection heard on the list)
Approve minutes from 14 August 2013
http://lists.w3.org/Archives/Public/public-device-apis/2013Aug/att-0027/minutes-2013-08-14.html
RESOLUTION: Minutes from 14 August 2013 are approved
fjh: additional comment, Cathy: http://lists.w3.org/Archives/Public/public-device-apis/2013Aug/0028.html
richt: some of the issues can be closed
ISSUE-129?
<trackbot> ISSUE-129 -- Simplify Network Service Discovery API -- open
<trackbot> http://www.w3.org/2009/dap/track/issues/129
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
<richt> ISSUE-129, we talked about this at some length in a previous conf call: http://lists.w3.org/Archives/Public/public-device-apis/2013Aug/att-0002/minutes-2013-07-24.html#item03
fjh: I think we need to seriously consider extension points, pulling Dial out etc
cathy: this is a separate issue
richt: these two should be closed
... re ISSUE-129 jean claude has different model in mind, specification allows different interaction mechanisms, levels so events allow different models
<richt> Regarding ISSUE-129, JCD is looking at this from one implementation perspective: return zero services then use the onserviceavailable event to then re-call getNetworkServices....
<richt> a user agent MAY return 1 or more services on the first call, making the onserviceavailable event useful for monitoring changes on the network.
<richt> Allowing that kind of flexibility is good.
<richt> Therefore we don't want to change the specification as suggested in ISSUE-129.
<richt> we also discussed this in http://lists.w3.org/Archives/Public/public-device-apis/2013Aug/att-0002/minutes-2013-07-24.html#item03
<richt> ISSUE-130: http://lists.w3.org/Archives/Public/public-device-apis/2013Aug/att-0002/minutes-2013-07-24.html#item05
<trackbot> Notes added to ISSUE-130 Enable variety of protocols (e.g. UPnP, Bonour) with protocol independent developer code.
richt: sent mail to list, introduces more problems to do this, especially since no commonality among the various protocols
<Cathy> +1 on closing ISSUE-129 and ISSUE-130
richt: so that proposal is not mature
close ISSUE-129
<trackbot> Closed ISSUE-129.
close ISSUE-130
<trackbot> Closed ISSUE-130.
ISSUE-131?
<trackbot> ISSUE-131 -- Support UPnP device discovery by Device Type? -- open
<trackbot> http://www.w3.org/2009/dap/track/issues/131
<richt> FYI, my email to the list RE: ISSUE-130 is @ http://lists.w3.org/Archives/Public/public-device-apis/2013Jul/0032.html
cathy: still open, Rich noted want to be able to group by device not device type, agree with this, but need to work through the details
<richt> FYI, response to ISSUE-131: http://lists.w3.org/Archives/Public/public-device-apis/2013Jul/0034.html
cathy: up to UA to group by device, but what if UA does not do grouping
... how can UA handle permissions in that case
... I am working on defining the issue, then we can consider a proposal
ISSUE-132?
<trackbot> ISSUE-132 -- Announce a webapp as a Network Services Discovery -- open
<trackbot> http://www.w3.org/2009/dap/track/issues/132
fjh: this is a separate issue, announcing self on network
cathy: yes, agreed that this could be a separate spec at some point if needed, so can close
ISSUE-132: WG agreed that this could be a separate spec at some point if needed
<trackbot> Notes added to ISSUE-132 Announce a webapp as a Network Services Discovery.
close ISSUE-132
<trackbot> Closed ISSUE-132.
ISSUE-133?
<trackbot> ISSUE-133 -- Fix UPnP events subscription and unsubscription -- open
<trackbot> http://www.w3.org/2009/dap/track/issues/133
cathy: came up much earlier comments, UPnP event subscription issue
... spec has some bugs, so needs to be cleaned up, processing model is currently unclear, so the spec needs revision
... jean claude raised issue as to why we do this at all
richt: these are good and helpful comments, need to review
... should we be handling event subscriptions is an issue, have heard question from others
... it is in there so we can get pushed messages
... it is quite useful
... do we need it in the spec, maybe we don't , but it is there to have bi-directional communication channel and to allow publish subscribe, not offered by browsers
... it is a UPnP only feature, so for that reason it might make sense to remove
fjh: is this a feature we need, is it nice to have but not needed?
richt: removing it would remove capability from UPnP services
... fixing it would be significant work
fjh: I'm wondering if it makes sense to remove, to err on the side of simplicity, simplify testing etc
... maybe send message saying will remove see who complains
cathy: goal was to have full UPnP experience, if removed, can web application still accomplish this
richt: maybe could accomplish in other more modular way
... like idea of keeping it simple
... there may be other places in platform to solve it in better
fjh: perhaps remove, simplify testing
richt: not much coupling since specific to UPnP
... will try to fix ISSUE-133 before we publish WD
ISSUE-134?
<trackbot> ISSUE-134 -- Rename NetworkServices and NetworkService events -- open
<trackbot> http://www.w3.org/2009/dap/track/issues/134
cathy: suggestion to rename events, proposal in ISSUE
fjh: makes sense to me
richt: makes sense to me
... will make this change
ISSUE-135?
<trackbot> ISSUE-135 -- Add security and privacy considerations section -- open
<trackbot> http://www.w3.org/2009/dap/track/issues/135
fjh: done
close ISSUE-135
<trackbot> Closed ISSUE-135.
ISSUE-136?
<trackbot> ISSUE-136 -- Issues related to garbage collection -- open
<trackbot> http://www.w3.org/2009/dap/track/issues/136
close ISSUE-136
<trackbot> Closed ISSUE-136.
fjh: we should respond to Adam regarding ISSUE-135 and ISSUE-136 once we have new WD
... shall we plan to publish an updated WD on the 5 Sept
... would need publication ready draft by Wed 4th
richt: that should work
fjh: others things to talk about with regards to Network Service Disovery
richt: question about security with UPnP, also dubious services
... like Access Point services
... need to talk about those in security and privacy section
... dom sent pointer related to this
<richt> some other security-related issues for NSD to think about: https://groups.google.com/a/chromium.org/d/msg/blink-dev/HT0KZKuTLxM/DG9jOw6WzwoJ
<richt> my response @ http://lists.w3.org/Archives/Public/public-device-apis/2013Aug/0004.html
richt: second item, looking for feedback from other vendors now as well
fjh: publishing WD will help us request that
richt: TPAC would be good place for that
fjh: maybe a break-out session on this would be helpful
... you can propose a session: http://www.w3.org/wiki/TPAC2013/SessionIdeas
Newly raised issues addressed in editors draft, see http://lists.w3.org/Archives/Public/public-device-apis/2013Aug/0044.html
fjh: thanks Anssi for the updates
anssik: thanks Dom for the very careful review
fjh: we do not have formal resolution of some issues, so am waiting on CfC
Proximity Event API LC-2740 requires resolution: https://www.w3.org/2006/02/lc-comments-tracker/43696/WD-proximity-20121206/2740
Ambient Light Event API LC-2739 requires resolution: https://www.w3.org/2006/02/lc-comments-tracker/43696/WD-ambient-light-20121213/2739
fjh: these are the "one document" versus separate specs
... good arguments either way, I suggest we go with our current direction
josh_soref: current approach allows to implement only one, without confusion of what it means to be conformant if only implementing Light but not Proximity for example
anssik: this is editorial
fjh: can we go to REC with two specs
josh_soref: can go forward to REC with two specifications but allow creation of consolidated version
... having a single document can still introduce errors when material from one is not appropriate to another
... talking about simply generating merge from two documents
RESOLUTION: WG agrees to keep Proximity Event API and Ambient Light Event API as separate REC Track specifications to enable clarity regarding testing and conformance
WG notes that combined version can be generated for convenience from these two documents.
No confirmations on Proximity LC-2731, LC-2742 and Light LC-2737 and LC-2738.
fjh: as with other specs, will assume confirmation unless response received during CfC period
... I believe this means that I can send the CfCs now
Question/Comment on CR draft: http://lists.w3.org/Archives/Public/public-device-apis/2013Jul/0050.html
Question Vibration and iframes, http://lists.w3.org/Archives/Public/public-device-apis/2013Jul/0055.html
Question: Vibration strength http://lists.w3.org/Archives/Public/public-device-apis/2013Aug/0040.html
fjh: I suggest you look at these and respond on the list
anssik: will look at them
fjh: if we need a clarification it would be useful to add
josh_soref: will work on the git pull requests for vibration test cases
ACTION-523?
<trackbot> ACTION-523 -- Anssi Kostiainen to Work on test cases for battery, vibration, and HTML Media Capture -- due 2012-08-31 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/523
ACTION-621?
<trackbot> ACTION-621 -- Anssi Kostiainen to Create test cases for HTML Media Capture -- due 2013-03-13 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/621
ACTION-642?
<trackbot> ACTION-642 -- Dominique Hazaël-Massieux to Review proximity and ambient light test cases -- due 2013-09-18 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/642
ACTION-643?
<trackbot> ACTION-643 -- Anssi Kostiainen to Review Ambient Light and Proximity test cases by Sept -- due 2013-07-10 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/643
ACTION-645?
<trackbot> ACTION-645 -- Frederick Hirsch to Share Network Service Discovery editors draft with PING -- due 2013-07-31 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/645
ACTION-646?
<trackbot> ACTION-646 -- Frederick Hirsch to Organize joint call with web and tv group re network service discovery -- due 2013-08-21 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/646
ACTION-647?
<trackbot> ACTION-647 -- Frederick Hirsch to Send cfc to progress light to cr, two week cfc -- due 2013-08-21 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/647
ACTION-648?
<trackbot> ACTION-648 -- Frederick Hirsch to Send cfc to progress proxmity to cr, two week cfc -- due 2013-08-21 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/648
ACTION-649?
<trackbot> ACTION-649 -- Anssi Kostiainen to Review todo items associated with battery test cases -- due 2013-08-21 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/649
ACTION-650: Frederick Hirsch to Propose changing meeting time to thur at 10 am et slot
close ACTION-650
<trackbot> Closed ACTION-650.
none