See also: IRC log
<trackbot> Date: 20 April 2011
<scribe> ScribeNick: Suresh
No call next week (April 27th)
<fjh> 19-21 July F2F logistics, http://lists.w3.org/Archives/Member/member-device-apis/2011Apr/0000.html
<fjh> messaging published, http://www.w3.org/TR/2011/WD-messaging-api-20110414/
<fjh> HTML Media Capture, new approach published, http://www.w3.org/TR/2011/WD-html-media-capture-20110414/
<fjh> calendar FPWD published, http://www.w3.org/TR/2011/WD-calendar-api-20110419/
<fjh> powerbox/introducer, http://lists.w3.org/Archives/Public/public-device-apis/2011Apr/0087.html (Tyler)
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2011Apr/att-0077/minutes-2011-04-13.html
RESOLUTION: Minutes from 13 April 2011 are approved
<fjh> Last request for review and proposed changes, http://lists.w3.org/Archives/Public/public-device-apis/2011Apr/0085.html
<fjh> Proposed charter (revised) http://www.w3.org/2010/11/DeviceAPICharter.html
Suresh: are we looking at getting members to join the DAP, given that we have it in the charter?
Dom: If we do not have them in the group, we will have to revise the charter
fjh: on the process, is there caught during the AC review?
Dom: yes, I would bring this up during the reveiw
Suresh: i would prefer that we resolve this before we approve the charter
dom: Claes, do you have any update on your co-editors?
Claes: They are aware of the problem
bryan: we are going to have similar concerns with other API, such as sensors API, if we don't get Google hre are we going to get blocked?
fjh: it is legitimate...the members need to be aware of this
dom: web intents/introducer can be done in a number of ways, but if we couldn't due to IPR issues....we have to look into it
... re sensors, i don't believe there is a risk, but having google is good
fjh: what you are saying is charter is general enough...and doesn't commit the group to work on them
bryan: the point is that we have changed the charter to get a broad membership....i'm not sure on the IPR implications
... if they don't get involved not sure how far we can go...
fjh: should be make a formal decision on the charter?
dom: i think we should take a resolution
<fjh> WG can approve draft charter with resolution and understanding that AC will review and discuss IPR/membership issues
Suresh: it is subject to the discussion we just had...do we take these issues at the AC level or at the group level
robin: we should take it at the AC level
... from the group's view, we are proposing the topics and the legal issues should be handled at the AC level
<darobin> kyungtak, there's a lot of noise when you're not muted
<bryan_sullivan> On the earlier point re Web Introducer: In the rechartering we are trying to create an environment attractive to participation of the browser vendors. Hopefully actions are taking place in the background to make that happen. Basing DAP APIs on APIs of non-members is problematic, maybe even if just based upon patterns (but hopefully not). This goes for Web Introducer and Sensor as well. At this point there is an available API draft
<bryan_sullivan> (http://bondi.omtp.org/1.5/PWD-2/sensor.htm) which is RF (as part of the BONDI project). I would like to consider the Google APIs as patterns or baselines but we need Google's involvement in the group to move forward on that, IMO.
kyungtak: have some comments
dom: it might be better to take the comments at the AC review
kyungtak: will submit the comments on the mailing list
<fjh> share any comment on the public mailing list, but at this point to be treated as part of AC review
<dom> PROPOSED RESOLUTION: The Working Group requests to be rechartered under the new draft charter at http://www.w3.org/2010/11/DeviceAPICharter.html
fjh: not sure how we want to raise the concerns in the group in additon to this resolution
dom: the charter will accompany a "activity proposal" where i can state the concerns
<dom> ACTION: Dom to start DAP rechartering process [recorded in http://www.w3.org/2011/04/20-dap-minutes.html#action01]
<trackbot> Created ACTION-388 - Start DAP rechartering process [on Dominique Hazaël-Massieux - due 2011-04-27].
RESOLUTION: The Working Group requests to be rechartered under the new drfat charter at http://www.w3.org/2010/11/DeviceAPICharter.html
robin: The CfC ends today, any concerns?
<fjh> Minor edit could be handled during publication
fjh: there was comment on the list....
<dom> +1
<fjh> +1
<darobin> PROPOSED RESOLUTION: Publish Battery
robin: this can be handled later
<darobin> ACTION: Robin to handle FPWD of Battery [recorded in http://www.w3.org/2011/04/20-dap-minutes.html#action02]
<trackbot> Created ACTION-389 - Handle FPWD of Battery [on Robin Berjon - due 2011-04-27].
RESOLUTION: Publish FPWD of Battery Status specification
robin: we have a draft in CVS
<darobin> http://dev.w3.org/2009/dap/netinfo/
<fjh> update, http://lists.w3.org/Archives/Public/public-device-apis/2011Apr/0064.html (Suresh)
<fjh> feedback, http://lists.w3.org/Archives/Public/public-device-apis/2011Apr/0086.html
robin: there are a few comments
Suresh: 3 open issues, roaming, 'online' vs 'networkChange' event, and changing "unsigned short" to 'short"
robin: is roaming a real concern?
dom: does it create a privacy concern/phishing attack?
... it may be sufficient to note that it is under discussion
Suresh: 'online' is totally different from the semantics, we should not resue it becasue an implementation uses it
bryan: agree
... we should tell what network you are on, and determination of roaming is implementation specific
suresh: this is exactly the proposal in the draft, i.e not to have roaming
but instead just have fields to indicate the current and home n/w
<darobin> proposed idea from bryan_sullivan: use a single networkName field that gives the mobile network identifier on mobile networks, the SSID on wifi, etc.
<bryan_sullivan> +1
<bryan_sullivan> mnc, mcc are important for PLMN
<bryan_sullivan> ssid for WIFI
<dom> (I would have strong privacy concerns in providing freely WIFI SSIDs)
<darobin> (me too, but if we have a working technical solution we can at least agree on what we'll drop over privacy concerns :)
<fjh> sharing SSID is a bad idea from privacy perspective, isn't it
dom: raises concerns on exposing SSID
bryan: generally WiFi is a flat rate service...and may not be as important
<darobin> [can we 1) agree to a few changes to make, 2) to flag a number of issues, and 3) ship a CfC for that?]
<dom> +1 to darobin
+1
robin: document issues, (type: short vs srting), add event, and a flag to note the network name
<darobin> ACTION: Robin to make the mentioned changes and push out a CfC [recorded in http://www.w3.org/2011/04/20-dap-minutes.html#action03]
<trackbot> Created ACTION-390 - Make the mentioned changes and push out a CfC [on Robin Berjon - due 2011-04-27].
We published the draft and sent a msg to HTML for feedback, response from Ian Hickson questioning the new addition
dom: Mozilla provided comments as well....some work under way
robin: re Ian, we can point to previous discussion on this
<dom> ACTION: Dom to look at overlap between MediaFileData and HTMLVideoElement [recorded in http://www.w3.org/2011/04/20-dap-minutes.html#action04]
<trackbot> Created ACTION-391 - Look at overlap between MediaFileData and HTMLVideoElement [on Dominique Hazaël-Massieux - due 2011-04-27].
<fjh> comments on publication, http://lists.w3.org/Archives/Public/public-device-apis/2011Apr/0096.html
robin: take them offline
dom: a comment that prefers the previous version of the API
no call next week
<fjh> Next call in 2 weeks, 4 May.
<dom> ACTION: Dom to create F2F registration for Paris meeting [recorded in http://www.w3.org/2011/04/20-dap-minutes.html#action05]
<trackbot> Created ACTION-392 - Create F2F registration for Paris meeting [on Dominique Hazaël-Massieux - due 2011-04-27].