13:27:45 RRSAgent has joined #dap 13:27:45 logging to http://www.w3.org/2012/07/11-dap-irc 13:27:47 RRSAgent, make logs world 13:27:47 Zakim has joined #dap 13:27:49 Zakim, this will be DAP 13:27:49 ok, trackbot; I see UW_DAP()9:30AM scheduled to start in 3 minutes 13:27:50 Meeting: Device APIs Working Group Teleconference 13:27:50 Date: 11 July 2012 13:27:53 zakim, code? 13:27:54 the conference code is 3279 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), fjh 13:28:33 jun has joined #dap 13:29:00 darobin has joined #dap 13:29:24 Zakim, are you busy? 13:29:24 I'm listening on #xmlsec #html-wg #eval #svg &validator #html-techs-tf &revenue #rd #kap &global &crm &wai &brazilwai #ontolex &liaison &busdev &sysreq #ab #pf-chairs #crypto &w3m 13:29:28 ... #wf #dap 13:29:28 Idle mins: #xmlsec=11488 #html-wg=18532 #eval=8548 #svg=8169 &validator=17020 #html-techs-tf=2700 &revenue=11484 #rd=10017 #kap=9179 &global=8616 &crm=8541 &wai=8598 13:29:28 ... &brazilwai=8489 #ontolex=7292 &liaison=7228 &busdev=3033 &sysreq=2779 #ab=2756 #pf-chairs=2748 #crypto=2496 &w3m=28 #wf=2 #dap=0 13:29:28 &w3m has Team_(WOODS)8:15AM with 1 participant 13:30:07 richt has joined #dap 13:30:18 UW_DAP()9:30AM has now started 13:30:25 +[Host] 13:30:28 Claes has joined #dap 13:30:30 Present+ Rich_Tibbett 13:30:58 zakim, are you happy? 13:30:58 I don't understand your question, fjh. 13:31:08 dcheng3 has joined #dap 13:31:08 shan has joined #dap 13:31:31 Milan has joined #dap 13:31:33 + +46.1.08.01.aaaa 13:31:34 + +33.6.77.84.aabb 13:31:42 Agenda: http://www.w3.org/2009/dap/wiki/F2F_Agenda_10-12_July_2012_Burlington_MA_USA 13:31:44 lgombos_ has joined #dap 13:32:05 Zakim, aaaa is Claes 13:32:05 +Claes; got it 13:32:21 Present+ Claes_Nilsson 13:32:22 Chair: Robin_Berjon, Frederick_Hirsch 13:32:30 jhawkins has joined #dap 13:32:39 Zakim, aabb is Jean-Claude_Dufourd 13:32:39 +Jean-Claude_Dufourd; got it 13:32:43 naoyuki has joined #dap 13:32:48 Present+ Robin_Berjon, Frederick_Hirsch 13:32:52 kensaku has joined #dap 13:33:05 Topic: Wecome, admin 13:33:18 Present+ Jean-Claude_Dufourd 13:34:07 youenn has joined #dap 13:34:23 Cathy has joined #dap 13:34:41 +gmandyam 13:36:01 gmandyam has joined #dap 13:36:29 a12u has joined #dap 13:36:35 Present+ jhawkins 13:37:06 Present+ James_Hawkins 13:37:12 aizu has joined #dap 13:37:12 nwidell has joined #dap 13:37:26 Present+ Soonbo_Han 13:37:30 Zakim, who is on the call? 13:37:30 On the phone I see [Host], Claes, Jean-Claude_Dufourd, gmandyam 13:37:44 Zakim, Josh_Soref has entered [host] 13:37:44 +Josh_Soref; got it 13:38:02 Zakim, James_Hawkins has entered [Host] 13:38:02 +James_Hawkins; got it 13:38:11 Zakim, nick jhawkins is James_Hawkins 13:38:11 sorry, Josh_Soref, I do not see a party named 'James_Hawkins' 13:38:29 Present- jhawkins 13:38:44 Claes: the intent of this document is to cover technologies beyond UPnP 13:38:51 ... we've been prototyping with UPnP 13:38:55 ... but it isn't limited to UPnP 13:39:48 +[Microsoft] 13:39:51 ... you could provide access to in device UPnP agents 13:39:56 nwidell has joined #dap 13:39:58 s/agents/resources/ 13:39:59 zakim, [Microsoft] is me 13:39:59 +adrianba; got it 13:40:14 zakim, who is here? 13:40:14 On the phone I see [Host], Claes, Jean-Claude_Dufourd, gmandyam, adrianba 13:40:15 ... the idea is to discover UPnP services and dynamically register them 13:40:16 [Host] has Josh_Soref, James_Hawkins 13:40:16 On IRC I see nwidell, aizu, a12u, gmandyam, Cathy, youenn, kensaku, naoyuki, jhawkins, lgombos_, Milan, shan, dcheng3, Claes, richt, darobin, jun, Zakim, RRSAgent, jgiraud, fjh, 13:40:16 ... adrianba, comus, jcdufourd, ArtB, mounir, Josh_Soref, hiroto_away, trackbot, dom 13:40:25 Zakim, fjh has entered [Host] 13:40:25 +fjh; got it 13:40:30 jmr has joined #dap 13:40:39 Claes: the assumption is that UPnP devices are web-intents enabled 13:40:47 ... there has been discussion on the list that this isn't a requirement 13:40:59 ... we have started looking at web-intents enabled UPnP devices 13:41:11 ... that doesn't mean we won't look into enabling existing UPnP devices 13:41:18 ... there are pros and cons for both approaches 13:41:23 ... the requirements for a UPnP device 13:41:44 ... it must support an intents service type 13:41:57 ... and it must have a location for the WebIntents document 13:42:05 Web Intents Addendum - Local Services http://w3c-test.org/dap/wi-addendum-local-services/ 13:42:19 ... the other header is optional and it indicates which web intents are supported 13:42:26 +nwidell 13:42:32 zakim, who is here? 13:42:32 On the phone I see [Host], Claes, Jean-Claude_Dufourd, gmandyam, adrianba, nwidell 13:42:35 [Host] has Josh_Soref, James_Hawkins, fjh 13:42:35 On IRC I see jmr, nwidell, aizu, a12u, gmandyam, Cathy, youenn, kensaku, naoyuki, jhawkins, lgombos_, Milan, shan, dcheng3, Claes, richt, darobin, jun, Zakim, RRSAgent, jgiraud, 13:42:35 ... fjh, adrianba, comus, jcdufourd, ArtB, mounir, Josh_Soref, hiroto_away, trackbot, dom 13:42:36 ... so the UA could skip fetching the webintents document for all discovered documents 13:42:48 Zakim, darobin has entered [Host] 13:42:48 +darobin; got it 13:43:07 ... for the UA, it needs to support UPnP 13:43:21 ... and discovery / advertisement / search / notify 13:43:34 ... and for UA behavior, we have decided not to make this normative 13:43:52 Zakim, lgombos has entered [Host] 13:43:52 +lgombos; got it 13:43:57 Zakim, kensaku has entered [Host] 13:43:57 +kensaku; got it 13:43:58 glenn has joined #dap 13:44:02 Zakim, Cathy has entered [Host] 13:44:02 +Cathy; got it 13:44:17 q+ to reiterate approach toward interop 13:44:24 ... there is also a statement about UAs managing UPnP devices coming/going, but that isn't normative 13:44:32 ... then we have example scenarios 13:44:37 Zakim, aizu has entered [Host] 13:44:38 +aizu; got it 13:44:42 Zakim, jgiraud has entered [Host] 13:44:42 +jgiraud; got it 13:44:55 ... there are a number of UCs 13:45:08 ... the first UC is that a service page contains a video playback 13:45:21 ... and the user can control video playback from the service page 13:45:27 ... the other UC is more complicated 13:45:38 ... where the UA continues to show the client page after the service is invoked 13:45:55 ... that requires a long lasting relation (communications channel) between the client and service page 13:46:03 ... we expect that to be channel messaging 13:46:12 ... we made the assumption that we have disposition:hidden 13:46:18 ... i know this is controversial 13:46:25 ... we discussed that in Shenzhen 13:46:39 ... i have an ACTION to propose this and cover it being secure 13:46:47 ... that's a short introduction to the specification 13:47:21 i/cover technologies/Topic: WebIntents and Local Services/ 13:47:49 [ fjh summarizes how the integration works ] 13:48:09 dsr has joined #dap 13:48:10 Claes: we try to minimize impact on UPnP devices 13:48:34 ... the requirements for UPnP devices is the two headers, the web intents registration document 13:48:47 ... there are very limited changes needed to UPnP devices to support web intents 13:48:53 fjh: are we ready to publish this? 13:48:57 richt: i have a few comments 13:49:01 ... on the mDNS side 13:49:05 ... what's the default search domain? 13:49:07 ... what is it? 13:49:31 q+ to ask whether we killed the discover action yesterday or just the stale documentation of it 13:49:32 XX: you mean how to search for it? 13:49:38 richt: one thing that would be powerful 13:49:42 ... is to change the default search domain 13:49:46 ... so i could query google.com 13:49:58 ... and it discovers them by searching that domain 13:50:02 ... it could be really powerful 13:50:10 q? 13:50:14 ack fjh 13:50:14 fjh, you wanted to reiterate approach toward interop 13:50:16 q+ 13:50:29 dsr_ has joined #dap 13:50:30 q+ fjh 13:50:48 [ richt will restate ] 13:51:01 richt: it would be nice if the mDNS part 13:51:04 ... which is still a placeholder 13:51:11 ... could go out to the web and discover services 13:51:13 ... from dns records 13:51:24 ... so i could say go and look at google.com and set up webintents through that address 13:51:29 ... that could be really nice 13:51:30 Claes: i agree 13:51:43 richt: it's called "Wide-Area Service Discovery through ZeroConf" 13:51:57 q+ 13:52:06 s/XX/naoyuki/ 13:52:37 naoyuki: i have a question about richt's question 13:52:46 ack naoyuki 13:52:49 ... what's the difference 13:53:03 richt: here the client, your browser could do a device search SD 13:53:13 ... you could change the search domain from local to google.com 13:53:20 ... so i could discover google.com services 13:53:25 ... and they're automatically discovered 13:53:37 ... and then i could use them when i go to a local page 13:53:40 naoyuki: i understand 13:53:53 q? 13:54:01 ack Cathy 13:54:01 Cathy, you wanted to ask whether we killed the discover action yesterday or just the stale documentation of it 13:54:05 One of easiest applications of Wide-Area DNS-SD is simply to add a few records to your DNS server, to automatically advertise selected services to clients, with zero configuration on the client side. When clients get a response packet from the local network's DHCP server, there's a domain in that packet, and clients running Mac OS X 10.4 (Tiger) or Bonjour for Windows automatically query that domain for advertised services. 13:54:09 q? 13:54:16 see http://www.dns-sd.org/ 13:54:18 Cathy: i think we killed the discovery action yesterday 13:54:29 ... or did we kill the documentation 13:54:37 jhawkins: i think we killed the documentation 13:54:46 ... i don't think it's used normally 13:54:51 ack gmandyman 13:54:51 ... if UPnP uses it 13:55:00 gmandyam: i just joined the group 13:55:03 ... i'm wondering 13:55:04 q- 13:55:05 q- 13:55:07 ... on the appendix, A2 13:55:11 q? 13:55:12 ... there's a diagram 13:55:15 ack gmandyam 13:55:21 ... that's supposed to show remote access in the video control scenario 13:55:31 ... it shows low level control via XHR/WebSockets 13:55:41 ... is the intention to designate a specific method for access? 13:56:01 ... or could we just create a virtual UPnP device 13:56:17 Claes: i assume that question was to me 13:56:20 gmandyam: yeah 13:56:41 Claes: the discovery action was killed 13:56:57 ... as mentioned by Cathy 13:57:22 gmandyam: your diagram in A2 has a link to the remote device via XHR/WebSockets 13:57:27 ... are you specifying a particular way 13:57:32 ... or do we allow a multitude of ways? 13:57:36 Claes: this is just an example 13:57:43 ... it's up to the implementation of the service page 13:58:11 ... there are several ways to communicate 13:58:21 gmandyam: given the "work" of the CoreMob CG 13:58:29 ... and given the behavior of networked web applications 13:58:36 ... i'd comment that the approach here is suboptimal 13:58:43 ... for cellular remote discovery/remote access 13:58:59 ... is this document going to tailor testing/conformance requirements around a preferred approach 13:59:13 ... i'd say WebSockets isn't going to be efficient over cellular transport 13:59:18 ... for things like SSDP and the like 13:59:24 Claes: that's outside the scope of this specification 13:59:31 q+ 13:59:44 gmandyam: it would be in scope of CoreMob 13:59:53 ... i'd say the example here is probably suboptimal 13:59:59 ... if the underlying access is cellular 14:00:15 darobin: whether something is optimal or not can be discussed/debated in the design spec 14:00:21 ... but it doesn't relate to CoreMob 14:00:32 gmandyam: i think CoreMob may have minimum performance specification 14:00:42 ... it'd have some sort of level of implementation in mind 14:00:55 darobin: performance consideration for CoreMob are QoI not specification 14:01:00 ... it isn't about feedback into specification 14:01:09 ... i'm clarifying it's unrelated to what CoreMob is doing 14:01:11 q? 14:01:14 ack me 14:01:16 q+ 14:02:02 Josh_Soref: The UPnP spec defines how interaction occurs. It doesn't define what services provide or how they provide those services. 14:02:16 Josh_Soref: Similarly HTTP doesn't specify whether you use GET or POST 14:02:37 Josh_Soref: Someone defining a UPnP oriented Intent will choose what a service looks like..whether it uses XHR, Web Sockets. 14:02:44 Josh_Soref: That should be a decision for the services themselves. 14:03:16 Josh_Soref: If they define a sub-optimal thing then market forces come in to play. Some win and some lose. The specs are not key makers in that. The users are the key makers. 14:03:34 gmandyam: there's been a lot of work on improving UPnP discovery over Wide-Area-Networks 14:03:45 ... for things including cellular connections 14:03:59 ... there is Spotlight activity sponsored by W3 14:04:06 ... on best practices for networked web applications 14:04:28 ... i'd say it's perfectly appropriate to talk about the best way to do UPnP discovery over Wide-Area-Networks 14:04:51 ... i'd say there could be W3C documents that could cover this 14:04:52 q? 14:06:16 Josh_Soref: For us to make a recommendation for a comms protocol between an intents client and a UPnP/mDNS service we need to have intent services that are UPnP. We need to experiement and get implementation experience. 14:06:16 ack richt 14:06:28 Josh_Soref: We need time and implementations and we don't have that yet. 14:06:49 ...and they need to be real implementations not just siloed demos. 14:06:52 gmandyam: ok, i agree with that 14:06:55 ack richt 14:07:10 richt: fjh, you were asking if we should publish this spec 14:07:15 ... i did a similar exercise 14:07:21 ... i think it's important we have feature completion 14:07:25 ... the mDNS bit isn't done yet 14:07:37 ... i'd like the mDNS stuff to be flushed out 14:07:42 ... that can have knock-on effects 14:07:48 Wonsuk has joined #dap 14:07:49 ... i think feature completion in the first draft 14:07:54 jhawkins: sounds like we should hold off 14:08:00 Present+ Wonsuk_Lee 14:08:09 richt: patent exclusion will apply to the FPWD 14:08:12 Jungkee has joined #dap 14:08:16 ... if we add something later, it waits 14:08:20 Present+ Jungkee_Song 14:08:29 Claes: i think someone should take an action to cover mDNS 14:08:32 ... i can take that action 14:09:00 fjh: what sort of time frame given vacations? 14:09:16 ACTION: Claes to add mDNS adaption to the 'Web Intents Addendum - Local Services' specification for feature completion and before FPWD 14:09:16 Created ACTION-555 - Add mDNS adaption to the 'Web Intents Addendum - Local Services' specification for feature completion and before FPWD [on Claes Nilsson - due 2012-07-18]. 14:09:19 Claes: i'll return to work in August 14:10:29 Topic: Networked Service Discovery and Messaging 14:10:44 Draft spec: http://people.opera.com/richt/release/specs/discovery/Overview.html 14:11:00 richt: this work started quite a long time ago 14:11:05 ... we have a lot of devices internally 14:11:05 dsr has joined #dap 14:11:33 ... it's a way to connect to UPnP and ZeroConf devices 14:11:38 ... restricted to the local network 14:12:03 ... we agreed to publish a FPWD 14:12:13 ... but we didn't publish because i wanted to wait for an implementation 14:12:21 ... we're ready 14:12:27 ... we're feature complete, with ZeroConf 14:12:33 ... i don't think they're trying to do the same thing 14:12:56 ... there's some subtle stuff we can do with the UI 14:13:02 ... that you can't do with WebIntents 14:13:13 ... WebIntents is about choosing a single service on a single device 14:13:24 ... with this proposal, I can select multiple services/devices at the same time 14:13:40 ... i can say i want to use both of these things in one get...() call 14:13:46 ... but the user can select more than one device 14:13:53 ... if the user selects 2 services and 2 devices 14:13:59 ... the page gets 4 service-device pairs 14:14:18 ... this doesn't require a secondary tab 14:15:08 ... with this, a service is CORS whitelisted ("same-origin") for the client 14:15:18 ... allowing for XHR/WebSockets/... 14:15:23 ... it's cool, it works very nicely 14:15:39 ... it's different enough from WebIntents 14:15:44 ... we're going to continue experimenting 14:15:51 q+ to clarify relationship to earlier work 14:15:56 ... for me, it's a way to bootstrap WebIntents over discovery 14:16:04 ... we have a separate UI 14:16:13 ... which allows for multi-pick 14:16:19 ... we hope to have an Opera Labs release 14:16:27 ... at which point anyone can come along and play with it 14:17:21 ... i'd like to get confirmation of publishing our document as an FPWD 14:17:34 ack fjh 14:17:34 fjh, you wanted to clarify relationship to earlier work 14:17:44 fjh: this is where the browser learns about devices on the network in the background 14:17:46 richt: yes 14:17:55 ... the browser does this in the background, w/o a performance hit 14:18:28 ... available resources are then immediately available when the api to select something is triggered 14:18:41 fjh: this seems to cover more of the discovery than the ui 14:18:59 richt: yes, but there is some placeholder for where a ui happens 14:19:04 q+ 14:19:09 richt: the assumption is that there's a service page 14:19:19 s/is/in WebIntents is/ 14:19:32 ... in this proposal, it's more enabling PostMessage/XHR 14:19:47 fjh: when we publish it, how do we position these two documents 14:19:57 ... your abstract seems to say something different 14:20:16 richt: the output of UPnP/ZeroConf is a URL 14:20:27 ... this specification will give you an http url 14:20:49 ... we have existing APIs for communicating with http 14:21:11 q+ 14:21:24 fjh: why was this updated july 3? 14:21:36 richt: as we were prototyping, we were tweaking it 14:21:41 fjh: so we're ready to go 14:21:52 ... our roadmap doesn't talk about how things fit together 14:21:59 richt: let's get it out 14:22:08 darobin: sounds like the same discussion as last time 14:22:16 q? 14:22:21 ack naoyuki 14:22:35 naoyuki: your approach is to expose raw SDP/mDNS to js? 14:22:37 richt: no 14:22:45 ... we hide that 14:22:55 s/SDP/SSDP 14:22:58 dsr_ has joined #dap 14:23:14 ... we just provide the service domain that the user has picked from the chooser (discovery long since occurred) 14:23:31 naoyuki: but JS knows what device is available in the local network? 14:23:34 richt: no, the UA knows that 14:23:38 ... it isn't exposed to pages 14:23:43 ... there's one method 14:23:47 ... the page requests stuff it wants 14:23:54 ... the user chooses to give something back (or not) 14:23:54 q? 14:24:07 naoyuki: if the page wants to load up available UPnP rendering devices? 14:24:14 richt: we don't expose how many devices are available 14:24:28 ... we don't tell the caller how many are available 14:24:40 ... we currently fail immediately if there's nothing available 14:24:50 q+ to ask why the editor's draft isn't linked from the wg page? 14:24:51 ... and we're considering offering a has() method 14:25:05 ... but that has security/privacy implications 14:25:20 ack me 14:25:45 I believe the spec is detailed enough to explain these questions. If there is any ambiguity then please let me know. 14:26:28 Josh_Soref: The assumption with these systems is the client understands the protocol of services that it will speak to and that the service type honors a specific protocol/messaging format? 14:26:40 richt: yes 14:26:46 ... UPnP is well defined 14:26:53 ... you have service types, each of those is very specific 14:26:59 .... XML, HTTP based, with actions/methods 14:27:04 ... very little room for deviation 14:27:07 s/..../.../ 14:27:13 ... the same applies to zeroconf based services 14:27:13 q? 14:27:25 ... although there is more flexibility of the format in zeroconf 14:27:32 ... but that's the flexibility of XHR 14:27:45 ... the service chooses if it's WebSocket/XHR based 14:27:51 ... that's what we're trying to maintain in this proposal 14:27:53 ack dsr_ 14:27:53 dsr_, you wanted to ask why the editor's draft isn't linked from the wg page? 14:28:02 ack dsr_ 14:28:19 darobin: it needs an update 14:28:30 ... gallery is Shelved even though we just issued a FPWD 14:28:39 richt: sounds like a task for Chairs 14:28:55 dsr_: UPnP/ZeroConf devices 14:29:08 ... either you get back a specific service that's independent of this 14:29:15 ... or you get something you already knew how to handle 14:29:33 ... you have to load a library about how a device works 14:29:46 richt: the net products of both UPnP/ZeroConf is a control point 14:29:58 ... you request a type and get back a URL 14:30:00 No, it's difficult to hear Dave 14:30:15 ... that you could XHR/Post/WebSocket to 14:30:20 ... we're not putting UPnP in the browser 14:30:53 ... if we take on the responsibility to maintain UPnP, we take on a lot of work 14:31:00 ... ultimately, UPnP is not ideal for the web 14:31:08 ... a ZeroConf JSON RPC system is much more webby 14:31:18 ... but the ability to do UPnP is useful 14:31:31 dsr_: Claes is talking about a new class of UPnP/Zeroconf device 14:31:43 richt: his proposal is a bootstrap mechanism to register WebIntents 14:31:47 ... and they're just web intents 14:32:04 dsr_: it's not a built in UPnP declared service 14:32:12 richt: it's really just SSDP 14:32:19 ... there's no UPnP at all 14:32:27 dsr_: if we have existing Web-ignorant devices 14:32:43 ... do you expect web page pages to be able to use those services? 14:32:46 richt: yes 14:32:54 dsr_: when you discover a service 14:33:02 ... you need to know how to use it 14:33:07 richt: you had to ask for it by that type 14:33:20 dsr_: you'll have to do separate discovery for this? 14:33:43 richt: a clarification for Claes 's is that his document is just SSDP + Intents 14:33:53 ... there's no UPnP control/messaging 14:34:08 richt: our proposal is about UPnP messaging 14:34:24 dsr_: in your case, there's potential to access existing devices 14:34:35 ... UPnP/Zeroconf 14:34:44 richt: there's a huge difference 14:34:55 q? 14:36:04 darobin: who gets the work to do the fpwd publishing? 14:36:11 richt: can we do it next week? 14:36:25 fjh: there's a publishing moratorium next week 14:36:35 ... what are we calling this? 14:36:47 richt: "Networked Service Discovery" 14:36:49 proposed RESOLUTION: publish Networked Service Discovery and Messaging as FPWD 14:37:00 The web developer would need to know about how to communicate with zeroconf/UPnP based services, unlike Claes' proposal for web intents where services are independent of mDNS/UPnP 14:37:09 RESOLUTION: publish Networked Service Discovery and Messaging as FPWD 14:37:12 [ break ] 14:38:40 -nwidell 14:39:39 proposed RESOLUTION: use shortname of 'discovery' for "Networked Service Discovery and Messaging" 14:42:06 zakim, mute me 14:42:06 adrianba should now be muted 14:43:39 -Jean-Claude_Dufourd 14:45:33 -Claes 14:52:21 youenn has joined #dap 15:01:52 Topic: UPnP Discovery Demo 15:03:22 FYI, Proposed UI for 'Networked Service Discovery and Messaging' spec: http://people.opera.com/richt/release/specs/discovery/tpac2011_servicediscovery_ui_1.png 15:03:24 [ Sony ] 15:03:27 and http://people.opera.com/richt/release/specs/discovery/tpac2011_servicediscovery_ui_2.png 15:03:43 naoyuki: WebIntents connect Browser and Services 15:03:53 ... we'd like to connect home devices 15:04:03 ... this demo will follow Claes's spec 15:05:00 ... We take a Web Browser and use SSDP to enable it to discover a TV that has a SSDP Intent header 15:05:41 GeunHyung has joined #dap 15:05:51 kensaku: simple case of demo 15:06:08 ... iPhone showing a simple page 15:06:20 ... TV case 15:06:31 ... assume left side is displayed in tv 15:06:40 Present+ GeunHyung_Kim 15:06:51 ... we control the page in the browser 15:07:00 ... in this demo, we use WebSockets 15:07:45 kensaku: this ui is coming from the tablet 15:08:07 +Jean-Claude_Dufourd 15:08:13 [ kensaku holds up tablet that naoyuki was controlling ] 15:08:45 [ naoyuki holds up a mobile phone, which discovers the tablet ] 15:08:57 [ naoyuki controls tablet from phone ] 15:08:59 [ Applause ] 15:09:06 fjh: will you share your slides? 15:09:12 richt: is the demo public? 15:09:35 kensaku: i need to negotiate with my company 15:10:20 Topic: Discovery short name 15:10:29 dsr_: i was proposing to call it Rich Discovery 15:10:43 Josh_Soref: I proposed Reverse CORS 15:11:35 darobin: we could make it Discovery-API 15:12:08 ... dsr_ was worried about it being a land grab on "discovery" 15:12:11 Josh_Soref: I was too 15:12:23 darobin: it should be lowercase 15:12:29 ... "discovery-api" 15:12:41 ... objections? 15:12:44 Wonsuk has joined #dap 15:12:47 [ None ] 15:13:10 RESOLUTION: use shortname of 'discovery-api' for "Networked Service Discovery and Messaging" 15:13:19 zakim, who is here? 15:13:20 Zakim, who is on the call? 15:13:21 On the phone I see [Host], gmandyam, adrianba (muted), Jean-Claude_Dufourd 15:13:21 [Host] has Josh_Soref, James_Hawkins, fjh, darobin, lgombos, kensaku, Cathy, aizu, jgiraud 15:13:22 On IRC I see Wonsuk, GeunHyung, youenn, dsr_, Jungkee, glenn, jmr, nwidell, aizu, a12u, gmandyam, Cathy, kensaku, jhawkins, lgombos_, Milan, shan, dcheng3, richt, darobin, jun, 15:13:25 ... Zakim, RRSAgent, jgiraud, fjh, adrianba, jcdufourd, ArtB, mounir, Josh_Soref, hiroto_away, trackbot, dom 15:13:27 On the phone I see [Host], gmandyam, adrianba (muted), Jean-Claude_Dufourd 15:13:29 [Host] has Josh_Soref, James_Hawkins, fjh, darobin, lgombos, kensaku, Cathy, aizu, jgiraud 15:13:42 Zakim, Jungkee has entered [Host] 15:13:42 +Jungkee; got it 15:14:02 Topic: Testing WebIntents 15:14:13 Zakim, dcheng3 has entered [Host] 15:14:13 +dcheng3; got it 15:14:39 Zakim, youenn has entered [Host] 15:14:39 +youenn; got it 15:14:44 Zakim, Milan has entered [Host] 15:14:44 +Milan; got it 15:14:56 darobin: have you been doing testing? 15:15:24 jhawkins: we're writing an automation api 15:15:31 darobin: based on webdriver? 15:15:37 jhawkins: based on chrome's automation system 15:15:45 ... you add an api for components to do high level things 15:15:50 ... pick nth service 15:15:52 ... close picker 15:15:54 ... cancel picker 15:16:25 ... It seems explicit intents are easier to test 15:16:31 ... no need for advanced registration 15:17:05 ... do we have predents for tests that require multiple pages? 15:17:15 s/predents/precedents/ 15:17:18 Josh_Soref: we have servers (for websockets), and multiple domains 15:17:31 jhawkins: what are the requirements 15:17:39 darobin: on testing, find all testable assertions 15:17:45 ... figure out how many tests you need 15:17:48 ... write all of them 15:18:00 ... to get there, it probably requires tuning the specification 15:18:08 ... to ensure testable assertions are testable assertions 15:18:19 http://www.w3.org/TR/test-methodology/ 15:18:21 richt: we have a spec on how to do that 15:18:31 ... there are tools that create test suites for that 15:20:12 [ darobin mentions sections from test-methodology ] 15:20:48 richt: it's really nice to be able to create managable tests 15:20:53 jhawkins: wondering about timelines 15:21:01 darobin: we need a timeline for the spec itself 15:21:11 ... nothing more painful to write 200 tests 15:21:18 ... then change the spec and dump the tests 15:21:27 richt: the basic requirement is 2 implementations 15:21:53 ... the other implementer may want to change everything 15:22:03 darobin: i'm not convinced we have the bandwidth/dire need for testing 15:22:11 ... but it would be good to have a plan for how to move forward 15:22:16 ... the spec is shaping up rather nicely 15:22:20 ... it needs a lot of polish 15:22:29 ... i'm guessing we'll need tests in early 2013 15:22:48 jhawkins: if we don't get another implementation by then, then we're not in a nice place 15:23:04 fjh: do we need to get test infrastructure in place? 15:23:05 naoyuki has joined #dap 15:23:37 darobin: we have everything for publishing/controlling suites 15:23:41 fjh: what about ui interaction? 15:24:00 darobin: not really 15:24:09 jhawkins: we could take our testing api, and abstract it 15:24:19 fjh: that might accelerate things 15:24:27 darobin: IFF other browsers provide the same thing 15:24:38 richt: we use WebDriver, all browsers use it 15:24:52 jhawkins: not for UI stuff 15:25:02 jhawkins: if we show that explicit intents covers most cases 15:25:07 ... we can test automatically that way 15:25:20 darobin: we'll need part of the test suites to cover implicit intents 15:25:58 Josh_Soref: it's possible to make most of the test suite automatable 15:26:03 ... and then have a small section that's manual 15:26:14 darobin: you can have metadata to mark manual v. automatic 15:26:53 ... so the framework could run the automatic phase first 15:27:07 darobin: the entire css test suite, or 95% of it requires human interaction 15:27:12 ... and people do it 15:27:15 ... it takes time, but 15:27:23 ... it's a good way for beginners to become involved 15:27:31 dsr: and the same person doesn't have to do all the tests 15:27:47 +1 - manual testing is fine, especially where UI might vary between implementations 15:27:54 darobin: the framework supports giving you tests with the fewest results 15:28:08 ... it's geared toward crowd-sourcing 15:28:17 ... as long as the human tests are reasonably few 15:28:20 ... i think we're good 15:28:32 jhawkins: i'd like to put together the basic infrastructure 15:28:38 microsoft doesn't want to see w3c tests require a specific automation api 15:28:53 dsr: we could also start using the markup for testable-assertions 15:28:59 richt: it's painful if you're still in flux 15:29:21 adrianba: ack 15:29:21 s/you're still in flux/the spec is still in flux/ 15:29:59 ACTION: Robin to set up test repository with example, docs, manifest generation for Web Intents 15:29:59 Created ACTION-556 - Set up test repository with example, docs, manifest generation for Web Intents [on Robin Berjon - due 2012-07-18]. 15:30:04 darobin: it would be great if there were consensus about ui automation, but i don't think that's possible 15:30:44 q 15:30:49 s/q// 15:30:51 q? 15:31:08 q? 15:31:50 darobin: i'm guessing testing specific intents 15:32:42 Josh_Soref: I would like to encourage, and I actually did in my original requirements 15:32:55 ... for service implementations and clients to provide testable instances 15:32:57 rrsagent, generate minutes 15:32:57 I have made the request to generate http://www.w3.org/2012/07/11-dap-minutes.html fjh 15:33:09 ... if that means that there is a dummy test account, that means you can work with it 15:33:26 fjh: yes, with the edge cases and all 15:34:41 http://dev.w3.org/geo/api/test-suite/ 15:35:22 fjh1 has joined #dap 15:35:27 Josh_Soref: It would be good if we could have a test setup that attempts to white-list the necessary test resources. Then tries to run the remaining tests auotmatically. 15:35:38 s/auot/auto/ 15:36:15 dsr has joined #dap 15:36:46 fjh: how do we get a headstart on testing 15:37:09 nwidell has joined #dap 15:37:48 richt: the spec needs to add testable assertions 15:37:51 ... and be less prosy 15:37:55 fjh: that could happen now 15:38:40 ... so, could darobin (Pick Contacts) and Jungkee (Pick Media) look and see if they're using testable assertions 15:38:54 ... so we wouldn't need to do new work later 15:39:10 richt: what's a good example of testable assertions? 15:39:14 darobin: widgets 15:39:25 ... any editor should read the Widgets P&C spec 15:39:27 ... at least once 15:39:34 ... it's a pleasure to implement 15:39:36 Do view source on the spec to see how they added testable assertions: http://www.w3.org/TR/widgets/ 15:39:38 ... everything is defined 15:39:42 ... and has an algorithm 15:39:50 (regardless of your opinion on the spec contents) 15:39:52 ... implementing widgets can be done in an afternoon 15:41:58 Example testable assertion from widgets spec:

A user agent must treat any file in an arbitrary folder or locale folders that uses the file name config.xml as an arbitrary file.

15:42:04 Topic: Web Intents stuff 15:42:10 jhawkins: a lot of what needs to happen 15:42:21 ... fjh posted to the list feedback about the spec itself 15:42:26 ... good thorough, in depth 15:42:31 ... we need more people to do that 15:42:47 fjh: it'd be good if people experimented 15:43:04 jhawkins: it'd be good to get people w/ contacts at other browsers to get people talking 15:43:21 darobin: do you know if your implementation will be picked up by Safari 15:43:25 jhawkins: i don't know 15:43:49 richt: we have a situation where browsers aren't engaging on web inents 15:43:52 s/inents/intents/ 15:43:59 ... not sure how to change it 15:44:22 fjh: we can progress a little with Mozilla 15:44:45 richt: there was confusion w/ RPC/RPH 15:44:54 ... Google's proposal, hixie's 15:44:58 ... not sure where to go 15:45:02 +nwidell 15:45:59 jhawkins: the last proposal hixie said on the list was that he liked the tag 15:46:18 ... and he wanted to see a registerIntent handler similar to RPC/RPH 15:46:24 ... we didn't really want to add it 15:46:35 ... but if we have to, we will 15:46:48 richt: it'd be good to get hixie involved in the spec 15:47:04 s/registerIntent handler/registerIntentHandler/ 15:47:35 jhawkins: it'd be good if you could go in as Opera saying what's holding you back from implementing intents 15:48:53 topic: Network Information 15:49:33 dcheng3: how do you guys feel like proceeding with that spec? 15:49:53 -Jean-Claude_Dufourd 15:49:53 ... i understand your concern about the second one 15:49:58 http://dvcs.w3.org/hg/dap/raw-file/tip/network-api/Overview.html 15:50:07 ... mozilla/mounir's proposal 15:50:12 ... you register for onChange 15:50:16 ... what's changing is bandwidth 15:50:21 http://dvcs.w3.org/hg/dap/raw-file/tip/network-api/Overview.html 15:50:23 ... you have to constantly measure bandwidth 15:50:29 ... that gives the user no control over data consumption 15:50:35 ... and it will drain battery 15:50:39 ... and there's an issue w/ .metered 15:50:45 ... there's no reliable way to obtain that 15:50:56 ... not sure the user will understand that 15:51:00 ... you can't rely on the user for that 15:51:02 q+ 15:51:14 ... i'd be happy reverting to the previous iteration and working from there 15:51:19 fjh: i don't understand 15:51:30 ... i thought we agreed not to go on with the previous version 15:51:35 darobin: i wasn't in the group then 15:51:48 s/darobin/dcheng3/ 15:52:03 q+ 15:52:07 darobin: the reason we dropped it was we didn't have convincing UCs 15:52:26 Opera feedback on Network Information API on the WHATWG mailing list: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-May/036116.html 15:52:27 q- 15:52:29 q+ 15:53:08 http://www.w3.org/mid/2E8CF18B8D02DF469D2EDBBCCA0B5D33F2BA79@VF-MBX39.internal.vodafone.com 15:53:25 doesn't Android 4 has a metered information in it's SDK? 15:53:35 might be interesting to know how they get that info 15:54:35 zakim, who is here? 15:54:35 On the phone I see [Host], gmandyam, adrianba (muted), nwidell 15:54:37 [Host] has Josh_Soref, James_Hawkins, fjh, darobin, lgombos, kensaku, Cathy, aizu, jgiraud, Jungkee, dcheng3, youenn, Milan 15:54:37 On IRC I see nwidell, dsr, naoyuki, Wonsuk, GeunHyung, youenn, Jungkee, glenn, jmr, aizu, a12u, gmandyam, Cathy, kensaku, jhawkins, lgombos_, Milan, shan, dcheng3, richt, darobin, 15:54:39 ... jun, Zakim, RRSAgent, jgiraud, fjh, adrianba, jcdufourd, ArtB, mounir, Josh_Soref, hiroto_away, trackbot, dom 15:56:21 Josh_Soref: There are bunch of problems with 'metered'. It's mostly broken and can never really work well. 15:56:56 Josh_Soref: Your average smartphone will be on cellular and wifi concurrently. Which connection is used is unknown. 15:57:01 Josh_Soref: I really can't unfortunately 15:57:07 ...if you're roaming it may cost less or more than any other network. 15:57:10 I will gladely discuss that in the mailing list though 15:57:22 ...the real question is "Will this data cost a lot more than usual?" 15:58:09 dcheng3: we can't make a strong recommendation about what a UA will put into the UI and how a user will respond 15:58:21 ... the metered api is hard to implement in a meaningful/reliable way 15:59:02 Josh_Soref: everyone except Mounir thinks that metered can't be implemented well. 15:59:18 ...everyone else in DAP who has made comments has raised the same concerns. 15:59:24 darobin: and in CoreMob. 15:59:36 fjh: there's consensus in the WG that it can't be done 15:59:48 darobin: if you can't do anything useful with the information reliably 15:59:59 dcheng3: if you can get more UCs 16:00:06 we have implemented an API in Windows 8 that provides information about metered networks 16:00:10 darobin: what we've done in the past was Shelve specs 16:00:18 ... like Gallery 16:01:46 ack adrianba 16:01:46 q+ adrianba 16:01:46 ack adrianba 16:01:47 zakim, unmute me 16:01:47 zakim, who is here? 16:02:02 from Android 4.1 documentation - http://developer.android.com/about/versions/jelly-bean.html 16:02:05 ... Android 4.1 helps apps manage data usage appropriately when the device is connected to a metered network, including tethering to a mobile hotspot. Apps can query whether the current network is metered before beginning a large download that might otherwise be relatively expensive to the user. Through the API, you can now get a clear picture of which networks are sensitive to data usage and manage your network activity accordingly. 16:02:24 adrianba should no longer be muted 16:02:26 On the phone I see [Host], gmandyam, adrianba (muted), nwidell 16:02:28 [Host] has Josh_Soref, James_Hawkins, fjh, darobin, lgombos, kensaku, Cathy, aizu, jgiraud, Jungkee, dcheng3, youenn, Milan 16:02:44 adrianba: we do have a network information api as part of windows 8 for applications 16:02:45 On IRC I see nwidell, dsr, naoyuki, Wonsuk, GeunHyung, youenn, Jungkee, glenn, jmr, aizu, a12u, gmandyam, Cathy, kensaku, jhawkins, lgombos_, Milan, shan, dcheng3, richt, darobin, 16:02:52 ... jun, Zakim, RRSAgent, jgiraud, fjh, adrianba, ArtB, mounir, Josh_Soref, hiroto_away, trackbot, dom 16:02:58 ... i'm not suggesting it's the right api to expose through the browser 16:03:06 ... it allows you to request a list of "network profiles" 16:03:14 ... that allows you to see the different types of connections you have 16:03:21 ... a "wifi connection", a "cellular connection" 16:03:27 ... information about which networks are "metered" 16:03:32 ... and whether they're "expensive" 16:03:38 ... or whether they're "relatively low cost" 16:03:43 ... we have a way of asking 16:03:56 ... Josh_Soref is right, you don't know which network a packet is going to go over 16:04:20 ... but we have a way to ask which connection will be used for data that goes over the "internet" 16:04:42 ... it's not fair to say that no one here has implemented apis for metered 16:04:55 ... it's probably something that may change too fast for a web application to deal with 16:05:00 s/there's consensus in the WG that it can't be done/consensus in W3C does not require everyone to agree, do we have consensus here?/ 16:05:15 ... a web application may not notice the network changing from wifi to mobile 16:05:26 ... we're more interested in solving things that the UA can handle 16:05:31 ... such as responsive images 16:05:40 ... originally proposed in the Responsive Images CG 16:05:47 ... and now taken up by HTML W 16:05:51 s/W/WG/ 16:06:03 ... and the browser makes available a high quality image 16:06:09 ... if you have high resolution screen + fast network 16:06:17 ... and the browser+os do the heavy lifting 16:06:22 ... rather than the web application dealing with 16:06:25 darobin: I agree 16:06:31 ... that's something we discussed in CoreMob 16:06:43 ... in talking w/ developers, the reason they wanted it was to Shim Responsive Images themselves 16:06:51 ... i think they're going to get it wrong at *LEAST* half the time 16:06:57 ... i tend to agree that's something the UA should handle 16:07:00 ... rather than scripting 16:07:19 ... adrianba, you were giving us background 16:07:30 ... in general, in terms of the group persuing this api or not 16:07:33 ... do you have an opinion? 16:07:41 adrianba: it isn't something that's a high priority for us 16:07:52 ... we discussed it internally for W8/IE10 planning 16:07:58 ... we think there are some UCs for knowing this information 16:08:06 ... what we chose for MS, was to focus on UA things first 16:08:18 ... they'd have much more impact than we felt developers could make by using a JS api 16:08:26 ... we don't see it as a high priority right now 16:08:27 ACTION-474? 16:08:27 ACTION-474 -- Travis Leithead to make a proposal for Network Information API -- due 2011-11-11 -- OPEN 16:08:27 http://www.w3.org/2009/dap/track/actions/474 16:08:39 ... it's something we might return to once we've done the more UA based scenarios 16:08:48 darobin: if we were to leave that spec in a corner, and not touch it 16:09:02 adrianba: I'm not sure why that action was on travis 16:09:12 Josh_Soref: I think that's because adrianba wasn't targetable 16:09:36 darobin: i'll assign it to you with a deadline of Oct 15 (before TPAC) 16:09:40 adrianba: sure 16:09:46 darobin: thank you very much 16:09:57 ... i'm hearing a low level of interest, nothing urgent 16:10:03 ... we might see some movement towards the end of the year 16:10:10 ... so we can not touch it and go to lunch 16:10:22 [ Lunch until 1:10 pm ] 16:10:48 -nwidell 16:10:51 -adrianba 16:11:27 kensaku__ has joined #dap 16:12:55 -GeunHyung_Kim 16:13:21 +GeunHyung 16:13:41 -GeunHyung 16:13:49 GeunHyung has left #dap 16:18:53 adrianba has left #dap 17:04:04 sicking has joined #dap 17:04:59 adrianba has joined #dap 17:14:38 jgiraud has joined #dap 17:14:44 present+ jerome_giraud 17:14:47 zakim, where is here? 17:14:47 sorry, fjh, I do not understand your question 17:14:54 zakim, who is here? 17:14:54 On the phone I see [Host], gmandyam 17:14:55 [Host] has Josh_Soref, James_Hawkins, fjh, darobin, lgombos, kensaku, Cathy, aizu, jgiraud, Jungkee, dcheng3, youenn, Milan 17:14:55 On IRC I see jgiraud, adrianba, sicking, kensaku__, Jungkee, glenn, gmandyam, Cathy, jhawkins, lgombos_, shan, dcheng3, richt, darobin, Zakim, RRSAgent, fjh, ArtB, mounir, 17:14:56 ... Josh_Soref, hiroto_away, trackbot, dom 17:14:58 Wonsuk has joined #dap 17:15:46 naoyuki has joined #dap 17:16:08 aizu has joined #dap 17:16:27 a12u has joined #dap 17:16:42 RRSAgent, draft minutes 17:16:42 I have made the request to generate http://www.w3.org/2012/07/11-dap-minutes.html Josh_Soref 17:17:00 RRSAgent, make minutes public 17:17:00 I'm logging. I don't understand 'make minutes public', Josh_Soref. Try /msg RRSAgent help 17:17:08 RRSAgent, make logs public 17:17:14 RRSAgent, draft minutes 17:17:14 I have made the request to generate http://www.w3.org/2012/07/11-dap-minutes.html Josh_Soref 17:17:42 s/-GeunHyung_Kim// 17:17:43 dsr has joined #dap 17:17:53 s/+GeunHyung// 17:17:57 s/-GeunHyung// 17:18:09 Zakim, who is on the bridge? 17:18:09 I don't understand your question, Josh_Soref. 17:18:19 Zakim, who is on the call? 17:18:19 On the phone I see [Host], gmandyam 17:18:20 [Host] has Josh_Soref, James_Hawkins, fjh, darobin, lgombos, kensaku, Cathy, aizu, jgiraud, Jungkee, dcheng3, youenn, Milan 17:18:50 RRSAgent, draft minutes 17:18:50 I have made the request to generate http://www.w3.org/2012/07/11-dap-minutes.html Josh_Soref 17:20:11 Topic: Sensors 17:20:19 fjh: anyone have anything to say about sensors? 17:20:35 jun has joined #dap 17:21:11 +[Microsoft] 17:21:18 zakim, [Microsoft] is me 17:21:18 +adrianba; got it 17:22:39 darobin: temperature is probably an Intent 17:22:43 ... pressure similarly 17:22:46 ... humidity 17:22:53 ... we already did proximity 17:23:02 ... we had a proposal to do light as a media query 17:23:14 fjh: dougt had a proposal to do light as a sensor 17:23:35 http://dougturner.wordpress.com/2012/03/26/device-light-sensor/ 17:23:53 darobin: i'm happy to talk to dougt to know if he wants to take this further 17:24:00 http://dvcs.w3.org/hg/dap/raw-file/tip/sensor-api/Overview.html 17:25:00 dsr: we're a standards body 17:25:58 Josh_Soref: light sensors should just be done by the OS/UA 17:26:11 Milan has joined #dap 17:26:19 ACTION: Robin to ping DougT about light sensor to see if there's interest 17:26:19 ... instead of making each web page try to respond and have them mess up 17:26:19 Created ACTION-557 - Ping DougT about light sensor to see if there's interest [on Robin Berjon - due 2012-07-18]. 17:26:48 Topic: Media Capture 17:27:58 fjh: this is a document produced in the Media Capture TF 17:28:05 ... this isn't the TF 17:28:18 Updates to MediaStream Capture Scenarios document, http://dvcs.w3.org/hg/dap/raw-file/tip/media-stream-capture/scenarios.html 17:28:18 Media Capture and Streams WD, http://www.w3.org/TR/2012/WD-mediacapture-streams-20120628/ 17:28:19 darobin: there's stuff going on in the TF, which the group implicitly backs 17:29:06 ... i believe we have multiple parties in the room who are interested in this topic 17:29:14 Cathy: did travis say he'd participate in this? 17:29:50 "Travis Leithead I will attend remotely as noted below Plan on calling in for the Media Capture discussions." 17:33:32 Travis has joined #dap 17:33:56 close ISSUE-121 17:33:56 ISSUE-121 Scope of sensor API and sensor discovery closed 17:34:08 close ISSUE-105 17:34:08 ISSUE-105 Should the capture hint in HTML Media Capture be specified through a MIME parameter? closed 17:34:34 +[Microsoft] 17:34:58 Zakim, Travis is [Microsoft] 17:34:58 sorry, Josh_Soref, I do not recognize a party named 'Travis' 17:35:05 Zakim, [Microsoft] is Travis 17:35:05 +Travis; got it 17:35:42 fjh: we know that there were updates to the Scenarios document 17:35:54 ... and to the Specification 17:36:03 RRSAgent, draft minutes 17:36:03 I have made the request to generate http://www.w3.org/2012/07/11-dap-minutes.html Josh_Soref 17:36:04 +nwidell 17:36:58 darobin, Travis: since you've been involved w/ the TF 17:37:04 ... could we get your feeling on where it's going? 17:37:14 Travis: high level, it's moving in the right direction 17:37:18 ... albeit slowly 17:37:29 ... the scenarios document was stalled 17:37:38 ... until i got help from the chairs, and I believe Jim made edits 17:37:53 ... the current document has a set of requirements in 4 areas 17:37:58 s/areas/categories/ 17:38:14 ... Permissions, Local Media, Remote Media, Media Capture 17:38:18 jmr has joined #dap 17:38:22 darobin: you mentioned it moving slowly 17:38:27 ... that's also my perception 17:38:48 ... i remember @TPAC people said "yeah yeah, we want to wrap this up, in 2 months" 17:38:52 ... we're 2 months before TPAC 17:39:07 ... i'm not sure if there's anything we should do, or just leave the TF to its own devices 17:39:15 Travis: what i'm looking for at this point 17:39:26 ... is a revised way to do a recording from GetUserMedia 17:39:31 http://dev.w3.org/2011/webrtc/editor/getusermedia.html 17:39:35 darobin: "Media Capture and Streams" 17:39:46 Travis: we pulled in the definition of media stream 17:39:50 ... which is a good deal 17:39:57 ... and pull in changes on Tracks 17:40:17 ... the missing piece here 17:40:36 ... is a definition for recording the stream 17:40:42 ... there was a proposal made on the list 17:40:45 ... which excited me 17:40:56 ... i think it was richt, from Opera? 17:41:08 ... i'd love to see the recorder api integrated into the api 17:41:16 ... instead of just having an email thread 17:41:41 ... then we could compare it against the Media Capture Requirements which are in the Requirements Doc 17:41:52 ... producing the Scenarios doc is one of the criteria for the TF 17:41:59 ... i'm not sure what else it needs 17:42:20 ... if we can get that accomplished, maybe we can wind down the TF 17:42:30 ... and move back to doing work in DAP/WebRTC 17:42:47 Travis: the TF is joint ownership, what happens when the TF is done? 17:42:58 darobin: once we have joint ownership, we have joint ownership for life 17:43:05 GeunHyung has joined #dap 17:43:05 ... TF is just a medium for coordination 17:43:28 richt: i'm not sure it's my name on the proposal 17:43:35 ... i support Travis, i want to see that come to the spec 17:43:41 ... it's the next logical step for us as well 17:44:34 darobin: could Stream Recorder be a separate spec? 17:44:37 richt: it could be 17:44:42 darobin: ... to avoid excessive coordination 17:44:53 richt: MS had a Stream API with that capability 17:45:02 ... i don't know what they want to do 17:45:08 darobin: i think that's in WebApps 17:45:13 adrianba: yes, it's in Web Apps 17:45:17 ... it hasn't made progress 17:45:19 ... we haven't pushed it 17:45:30 darobin: that supports recording, right? 17:45:30 q+ 17:45:46 adrianba: it supports pipes 17:45:53 ... it's an abstract stream api 17:46:01 richt: i'm willing to jump in as an editor 17:46:27 richt: there's interesting stuff there: Codecs and Constraints 17:46:34 ACTION: Rich to produce a proposal draft for a StreamRecorder API 17:46:34 Sorry, couldn't find user - Rich 17:46:41 Travis: where did constraints end up? 17:46:44 ... is it in an ED? 17:46:46 Josh_Soref: i think so 17:47:03 q+ to talk about pictures 17:47:13 ackme 17:47:16 s/ackme// 17:47:17 ack me 17:47:27 ack richt 17:47:28 q- richt 17:47:35 ack gmandyam 17:47:59 gmandyam: was there more discussion in the group beyond the Still Image capture in the docs 17:48:16 ... for instance still image requires higher camera quality 17:48:24 s/there's interesting stuff there: Codecs and Constraints/there's interesting stuff there: Codecs and Constraints. Those aspects complicate things considerably./ 17:48:42 Travis: we could use the existing Media Capture and Stream spec 17:48:53 ... and then start working on the Capture spec 17:48:56 darobin: the problem is 17:49:05 ... if you have a stream coming from the device 17:49:12 ... you often have to interrupt it to capture a proper still 17:49:32 gmandyam: that's why a preview from a device would be different for Video and Snapshot 17:49:41 s/Video/Video Telephony/ 17:49:58 Travis: that was my original concern about the original api 17:50:04 gmandyam: so you're looking for a proposal? 17:50:06 Travis: yes 17:50:27 darobin: i'd expect StreamRecorder to be completely independent as to where the stream comes from 17:50:35 ... i don't understand how it'd be a view-finder stream 17:50:49 ... and somehow tell the camera that it should stop producing a video feed and make a proper still capture 17:51:02 ... it seems solving that at the stream recorder level is architecturally wrong 17:51:12 Travis: i haven't thought about that in detail, but that's a good question 17:51:24 ... there hasn't been a way to make a snapshot 17:51:53 richt: the way to take a high quality snapshot is with HTML Media Capture 17:51:55 q? 17:51:59 ... you get a native controls view finder 17:52:02 ack me 17:52:02 darobin, you wanted to talk about pictures 17:52:31 Travis: there's some sort of signalling mechanism that could send a signal to configure a Photo frame 17:52:36 darobin: that sounds scary 17:52:49 ... maybe i should try to draft a proposal, and see if it sticks 17:53:02 Travis: the concept i'm remembering is a constructable object that takes a mediastream/track 17:53:26 ... and could let you export out a stream/bitstream or be notified the stream/blob when it has ended 17:53:33 ... you put in the constraints you want 17:53:38 ... and it tries its best 17:53:44 darobin: it seems rather complicated 17:54:01 ACTION: Robin to draft a proposal for stills capture for gUM 17:54:01 Created ACTION-558 - Draft a proposal for stills capture for gUM [on Robin Berjon - due 2012-07-18]. 17:54:20 Josh_Soref: ahm... do we have heavy use cases for actually switching from video streaming to taking a picture 17:54:28 q+ 17:54:38 ... that aren't cases where it makes sense to interrupt the stream and restart it 17:54:40 ack adrianba 17:54:41 ... ? 17:54:51 adrianba: at the risk of sounding like a broken record 17:54:57 ... we implemented an api like this in windows 17:55:07 ... that allows for you to set up the video capture stream 17:55:10 ... from the device camera 17:55:13 ... into a preview window 17:55:21 ... and then the ability to call a method to say 17:55:27 ... at this point i want to capture a photo 17:55:32 ... from that same device 17:55:40 ... and it asynchronously goes to figure out where to get the data 17:55:49 ... we leave it as an implementation decision 17:55:53 ... whether it's a frame grab 17:56:01 ... or it does something more sophisticated 17:56:07 ... changing the decoding mode of the sensor 17:56:14 ... the key reason we care about this 17:56:25 ... is to support building capture applications where the ui is determined by the application 17:56:33 ... in the browser, or something using the web platform 17:56:42 ... let the application control where the preview is 17:56:47 ... and where the controls are 17:56:55 ... rather than delegating to the UA 17:57:15 ... avoiding click-click-click for a single action 17:57:23 ... so you can capture multiple frames quickly 17:57:26 darobin: i agree 17:57:34 ... typical UC is a realtime Instagram 17:57:40 ... so you could show a preview 17:57:52 ... and then also take and immediately apply the filter to the output 17:58:08 adrianba: we wanted to be able to wire up a preview to a canvas 17:58:12 ... do manipulations 17:58:19 ... frame grab/applying filters 17:58:45 ... that doesn't account for the case where you want the higher resolution still image 17:58:48 http://msdn.microsoft.com/en-us/library/windows/apps/windows.media.capture.mediacapture.aspx 18:00:24 q? 18:00:33 darobin: we have an overview of the situation 18:00:38 ... at least one or two Action Items 18:00:44 ... do we need anything else? 18:00:58 richt: do you want to talk about recording? 18:01:01 ... two issues 18:01:04 ... first is Codecs 18:01:15 ... if you're going to record something, it's going to be in some codec 18:01:19 ... second thing is constraints 18:01:28 ... i've argued against constraints 18:01:34 ... at initial request 18:01:58 ... i want them at secondary usage 18:02:05 ... recording/(p2p)streaming 18:02:19 ... constraints have way too many moving parts 18:02:26 ... i'd love for a way to simplify that 18:02:34 ... i'd like for thoughts on these 18:02:45 adrianba: we've maintained a position that the api should be codec-agnostic 18:02:51 s/adrianba/Travis/ 18:02:57 ... we don't want to get into that argument 18:03:02 q+ 18:03:14 s/argument/discussion/ 18:03:19 ... we do want to understand that various implementations want to capture streams in a form convenient for their platform 18:03:34 ... it passes the buck a little bit 18:03:45 ... if you want to do really low level work on a recorded bit 18:03:51 ... you need to understand the underlying structure 18:03:58 ... you'd have to dig into the underlying format 18:04:04 fjh: i agree w/ Travis 18:04:10 ... if it's pluggable 18:04:16 ... you can add new things w/o changing the spec 18:04:21 ... i assume you're worried about interop 18:04:31 richt: exactly, we should have some selection ability 18:04:48 darobin: it isn't a problem we can solve 18:05:00 q+ 18:05:11 agree that we cannot solve the codec problem 18:05:12 ack fjh 18:05:29 youenn has joined #dap 18:06:00 richt: there was feedback on the mailinglist about constraints 18:06:05 ... which was ignored 18:06:14 ... and i've pulled out a bit 18:06:23 Travis: we should reopen that for discussion 18:06:43 ... at least to the point that there was silence on the TF 18:07:21 ... and so that we could at least agree to disagree 18:07:30 darobin: it'd be nice if richt could make the point about privacy 18:07:43 richt: the spec says you can choose media constraints at the time you request a media stream 18:07:47 ... e.g. minimum width/height 18:08:05 ... if you combine those constraints 18:08:12 ... you exclude 80-90% of the users of the web 18:08:20 darobin: so you could fingerprint them 18:08:25 richt: privacy is another thing 18:08:34 ... you understand who they are even before the log in 18:08:35 q+ 18:08:39 ... and you know who they are later 18:09:07 richt: but most likely the form you use when developing 18:09:14 ... will not match the devices that people have on the web 18:09:23 ... and will thus exclude most of the web 18:09:37 ... there are so many constraints 18:09:48 ... and it's easy to combine them to exclude many users 18:09:55 ... and that's why opera won't implement them 18:10:00 q? 18:10:41 ack adrianba 18:11:01 adrianba: back to the codec problem 18:11:08 ... i think we probably all agree 18:11:12 ... that this isn't a problem that we can solve 18:11:22 ... as Travis said, from our perspective 18:11:32 ... we don't want to do things from a mandatory thing 18:11:48 ... in practice, there will be very few natively supported formats 18:12:01 ... i think what will be important are ways to discover native capabilities of the device 18:12:17 ... i think there will be some way to have a selection and make it discoverable 18:12:24 +1 18:12:28 ... possibly the best thing, and possibly the preferred approach anyway 18:12:32 ack fjh 18:12:49 fjh: i share richt 's concern about capabilities constraints 18:12:55 ... not sure how we'd test all the combinations 18:13:08 ... the argument for this 18:13:15 ... is that if you're trying to provide an application 18:13:23 q? 18:13:32 ... you're trying to ... 18:13:38 ... 1. there's a privacy concern re: Fingerprinting 18:13:49 ... 2. there's a complexity thing for testing which will make it hard to readch REC 18:13:58 ... 3. i'm concerned about the strength of the UC 18:14:02 q+ 18:14:07 q+ 18:14:19 ... i understand there's a UC but i don't know that it justifies that much complexity 18:14:25 s/readch/reach/ 18:14:32 ack dsr 18:14:33 ack dsr 18:14:34 q+ to say something that travis might get to before me 18:14:37 dsr: instead of constraints 18:14:46 ... an application might provide human readable hints 18:14:52 ... and let the user select something 18:14:57 richt: hints has a bad wrap 18:15:07 dsr: an application gives the user hints about what it's looking for 18:15:12 ... and let the user use their own common sense 18:15:16 richt: i like hints a lot 18:15:21 ... if the UA can do it, it'll work 18:15:26 ... if not, it'll give you best effort 18:15:39 ... at least everyone on the web can use that web page 18:15:41 s/the UC/he use case to support this/ 18:15:45 q? 18:15:53 dsr: you're advertising machine interpretable hints 18:15:58 richt: yes 18:16:05 ack Travis 18:16:06 ... if you define an application that requires high-def 18:16:11 ... you've excluded most of the world 18:16:17 Travis: on record, i support richt 's argument 18:16:19 s/advertising/advocating/ 18:16:30 ... it seems like the API could be better served by "best effort" and "upgrade" 18:16:35 ... like WebSockets 18:16:43 ... HTTP + Upgrade => WebSockets 18:16:47 ... in this case, give me a video 18:16:51 ... and then i try to upgrade it 18:17:04 ... it imposes more of a requirement to the stream interaction model 18:17:07 q+ to mention that best effort may mitigate privacy concern 18:17:10 ... but it allows for more users to consume the api 18:17:15 ack adrianba 18:17:15 adrianba, you wanted to say something that travis might get to before me 18:17:24 q+ to note that the api in MC TF was headed that way 18:17:35 adrianba: the good way to do this 18:17:39 ... is start simple and add enhancements 18:17:44 ... from an implementer perspective 18:17:48 ... we don't need constraints 18:17:52 ... to have useful scenarios 18:18:03 ... it's likely something we'd have implementations without that to begin with 18:18:06 +1 18:18:14 ... we'd have to discuss whether to include it before we ship 18:18:27 ... starting simple is a principle i think that's important 18:18:28 +1, start as simple as needed for success, push rest to v.next 18:18:34 ... in the end, it'll be down to implementations 18:18:41 ... it might be a feature marked AT-RISK 18:18:52 ... so when it goes to CR, it could be pulled from the spec 18:18:53 ack fjh 18:18:53 fjh, you wanted to mention that best effort may mitigate privacy concern 18:19:06 fjh: i think Travis has a good point 18:19:12 ... best effort may get around privacy concerns 18:19:16 ... wrt TF 18:19:22 ... my take is that some people promoting this work 18:19:26 ... felt very strongly about it 18:19:32 ... not sure how to deal w/ the politics 18:19:40 ... i'm a little concerned with marking things at-risk 18:19:52 ... it's better to try to enter CR w/ stuff you think is going to make REC 18:20:00 q+ 18:20:04 ... i'm not excited about marking things AT-RISK from the beginning 18:20:14 ... i'd rather do things like that using v.Next 18:20:29 ... i think doing it that way is confusing for testing and resources 18:20:35 nwidell has joined #dap 18:20:39 darobin: i tend to agree w/ fjh 18:20:52 ... if it's a feature a lot of people/implementers think isn't useful for this version 18:21:02 ... if it's something implementers don't want 18:21:05 ... it should be dropped now 18:21:12 richt: it isn't unanimous, which is a confusing factor 18:21:18 a? 18:21:22 s/a?// 18:21:24 q? 18:21:34 fjh: next step is to raise this issue to the TF 18:21:39 ... to make it clear that there's an issue 18:21:46 ... and make an explicit decision now 18:21:49 s/richt: it isn't unanimous, which is a confusing factor/richt: it isn't unanimous, which is a confusing factor. But there isn't consensus either./ 18:21:52 ... we don't really vote 18:21:57 ... we can do it, but we haven't 18:22:02 ... i know paul knows all about this 18:22:40 darobin: the mechanism open to people who don't like to it is a Formal Objection 18:22:46 fjh: either we formally object 18:22:56 ... or do a poll who can live w/ it / who can't 18:23:02 q? 18:23:16 fjh: we have a mechanism for dealing w/ a think where people can't reach a consensus 18:23:18 ack me 18:23:18 Josh_Soref, you wanted to note that the api in MC TF was headed that way 18:23:18 ack Josh_Soref 18:23:44 Josh_Soref: So constraints, a background story. 18:24:03 ...the task force is being driven by, essentially, device vendors e.g. media conferencing solution providers. 18:24:11 ..their preference is for hard-coded preference styles. 18:24:22 ...browser vendors don't find these particularly great. 18:24:44 ...we've been talking about moving contraints further down the pipeline / switch constraints at those points. 18:25:06 ...what happens when the input stream is a peer stream and you want to change the quality of the peer's stream? 18:25:22 ...this is really renegotiation which happens at the point of streaming. 18:25:50 ...There's definitely the possible to move constraints in to its own spec. 18:26:01 s/the possible to move/the possibility to move/ 18:26:24 ...there's also the caveat where implementors are allowed to opt-out of implementation requirements. 18:26:43 ...they have the ability to ignore things where they need to. 18:26:59 ...in my opinion, they're not vocal enough and they don't exercise this option enough. 18:27:18 fjh: i'd hate to ask about compliance 18:27:20 s/things where/implementation requirements where/ 18:27:23 Josh_Soref: that came up in CoreMob 18:27:27 ... we don't do Compliance 18:27:32 darobin: right, we do Interop 18:27:41 ... there's no reason to do Red if you're only b/w 18:27:58 richt: we're exercising our right not to follow the spec at this point 18:28:11 fjh: Josh_Soref is pointing out that the spec is moving to moving to later along the line 18:28:42 fjh: it's hard to keep up 18:28:58 ... the TF should make clear if they're moving constraints to relaxed 18:29:03 ... and renogatiable 18:29:10 ... Travis, does that make sense to you? 18:30:33 q? 18:30:40 ack adrianba 18:30:42 ack adrianba 18:31:12 adrianba: i wasn't suggesting marking something as AT-RISK as a way not to make a decision 18:31:29 ... i was assuming that we'd do a LC process where we mark things AT-RISK 18:31:38 ... but CR is a call for implementations 18:31:47 ... if there's a consensus that it's a feature worth having 18:31:55 ... but it isn't a clear that people will ship such a feature 18:32:01 ... then i think it's fair to mark something at risk 18:32:04 fjh: that makes sense 18:32:12 richt: that's exactly what we're saying 18:32:18 ... we don't want to wait until that 18:32:24 ... CR is our best intentions 18:32:33 ... but we can't endorse something we think is patently wrong 18:32:42 adrianba: things don't land in the spec by accident 18:32:47 s/that makes sense/that makes sense, but we should try to resolve earlier if we can/ 18:33:04 Travis: i'm glad things landed in the spec so we can discuss 18:33:09 ... we have a chance to make the right changes 18:34:33 Travis: i think richt has an action 18:34:40 ... i'll bring up a concern about constraints to the TF 18:34:57 ... i'll bring up next steps about a recording proposal 18:35:00 darobin: thanks 18:35:03 [ Break ] 18:35:09 -Travis 18:35:10 -nwidell 18:35:13 [15 min break] 18:35:21 zakim, mute me 18:35:21 adrianba should now be muted 18:55:09 Zakim, room for two 18:55:09 I don't understand 'room for two', darobin 18:55:11 Zakim, room for 2 18:55:11 I don't understand 'room for 2', darobin 18:55:14 Zakim, room for 2? 18:55:16 ok, darobin; conference Team_(dap)18:55Z scheduled with code 26631 (CONF1) for 60 minutes until 1955Z 18:56:03 Zakim, cancel conf1 18:56:03 I don't understand 'cancel conf1', darobin 18:56:06 Zakim, end conf1 18:56:06 I don't understand 'end conf1', darobin 18:56:27 Zakim, this is conf1 18:56:27 darobin, I see Team_(dap)18:55Z in the schedule but not yet started. Perhaps you mean "this will be conf1". 18:56:37 Zakim, end conf1 18:56:37 I don't understand 'end conf1', darobin 18:58:29 gmandyam has joined #dap 18:58:36 Wonsuk has joined #dap 19:02:25 Zakim, this is dap 19:02:25 darobin, this was already UW_DAP()9:30AM 19:02:26 ok, darobin; that matches UW_DAP()9:30AM 19:04:30 Topic: Agenda Bashing 19:04:36 fjh: i don't think there's anything to do tomorrow 19:05:19 ... the agenda has Issues, action review 19:05:28 Topic: Issue Review 19:05:33 issue-116? 19:05:33 ISSUE-116 -- HTML Media Capture doesn't make sense if accept=image and capture=microphone -- open 19:05:33 http://www.w3.org/2009/dap/track/issues/116 19:06:13 "The HTMLInputElement interface's accept attribute takes precedence over the capture attribute. That is, if the accept attribute's value is set to a MIME type that is not accepted in a defined capture state, the user agent must act as if there was no capture attribute. " 19:06:21 There is no reason to continue a meeting when it is finished with its work - so we will conclude today and not meet tomorrow given that we progressed quickly through the agenda. 19:06:34 This will give time back to people for other work, travel, etc 19:06:37 darobin: any objection? 19:06:59 Josh_Soref: i agree w/ the spec and agree that the issue can be closed 19:07:16 issue-116: "The HTMLInputElement interface's accept attribute takes precedence over the capture attribute. That is, if the accept attribute's value is set to a MIME type that is not accepted in a defined capture state, the user agent must act as if there was no capture attribute." 19:07:16 ISSUE-116 HTML Media Capture doesn't make sense if accept=image and capture=microphone notes added 19:07:26 close issue-116 19:07:26 ISSUE-116 HTML Media Capture doesn't make sense if accept=image and capture=microphone closed 19:07:37 ISSUE-116: addressed this issue in the spec as noted above 19:07:37 ISSUE-116 HTML Media Capture doesn't make sense if accept=image and capture=microphone notes added 19:07:38 issue-117? 19:07:38 ISSUE-117 -- Should HTML Media Capture have options for front/user camera as in getUserMedia -- open 19:07:38 http://www.w3.org/2009/dap/track/issues/117 19:09:15 RRSAgentm, draft minutes 19:09:24 RRSAgent, draft minutes 19:09:24 I have made the request to generate http://www.w3.org/2012/07/11-dap-minutes.html Josh_Soref 19:09:37 s/RRSAgentm, draft minutes// 19:09:39 user/environment features is not in gUM. We would like to see that make a reappearance. 19:09:42 more: Josh_Soref: 19:09:54 s/more: Josh_Soref:/more: Josh_Soref:/ 19:09:59 more: http://www.brucelawson.co.uk/2012/specifying-which-camera-in-getusermedia/ 19:10:43 close issue-117 19:10:43 ISSUE-117 Should HTML Media Capture have options for front/user camera as in getUserMedia closed 19:10:56 ISSUE-117: group agrees that this is not needed, handled by the UA 19:10:56 ISSUE-117 Should HTML Media Capture have options for front/user camera as in getUserMedia notes added 19:11:59 a picture taking app might favour back camera, a video chat might favour front camera 19:12:57 Josh_Soref: if i have a playbook using HDMI to display the video chat or camera app 19:13:09 ... the front and back cameras are no longer tied to the "Front/Back" of my display 19:13:18 ... and thus the hint is wrong/useless 19:13:39 ... I'd rather just have UAs do sane things, including at least a frame preview from all sources 19:14:02 ... The user always needs to pick something (or not), so let them have a preview from the sources, and they can window shop just like real people. 19:14:11 ... although that's a UA QoI 19:14:23 darobin: we've run out of issues 19:14:27 Topic: Action Review 19:15:13 http://www.w3.org/2009/dap/track/actions/open 19:15:46 Topic: Issue Review 19:15:56 http://www.w3.org/2009/dap/track/issues/raised 19:16:38 darobin: We always forget about Raised issues 19:16:44 fjh: I've moved them to open 19:16:54 issue-120? 19:16:54 ISSUE-120 -- How to handle exposing single vs multiple sensors of the same type -- open 19:16:54 http://www.w3.org/2009/dap/track/issues/120 19:17:09 close issue-120 19:17:09 ISSUE-120 How to handle exposing single vs multiple sensors of the same type closed 19:17:16 ISSUE-120: form an old Sensor API 19:17:16 ISSUE-120 How to handle exposing single vs multiple sensors of the same type notes added 19:17:28 ISSUE-122? 19:17:28 ISSUE-122 -- Is low level data necessary for all sensor APIs, which ones have use cases and which not -- open 19:17:28 http://www.w3.org/2009/dap/track/issues/122 19:17:30 naoyuki has joined #dap 19:17:43 ISSUE-122: this is already handled 19:17:43 ISSUE-122 Is low level data necessary for all sensor APIs, which ones have use cases and which not notes added 19:17:57 close 122 19:18:05 close issue-122 19:18:05 ISSUE-122 Is low level data necessary for all sensor APIs, which ones have use cases and which not closed 19:18:10 s/close 122/ 19:18:20 ISSUE-123? 19:18:20 ISSUE-123 -- Low level discovery API security and privacy issues -- open 19:18:20 http://www.w3.org/2009/dap/track/issues/123 19:19:50 ISSUE-123: we consider security and privacy for all specs 19:19:50 ISSUE-123 Low level discovery API security and privacy issues notes added 19:20:00 close issue-123 19:20:00 ISSUE-123 Low level discovery API security and privacy issues closed 19:20:19 ISSUE-124? 19:20:19 ISSUE-124 -- Concern on exposing raw sensor data -- open 19:20:19 http://www.w3.org/2009/dap/track/issues/124 19:20:39 ISSUE-124: solved by shelving 19:20:39 ISSUE-124 Concern on exposing raw sensor data notes added 19:20:42 close issue-124 19:20:43 ISSUE-124 Concern on exposing raw sensor data closed 19:21:45 issue-125: This applies to GetUserMedia Constraints 19:21:45 ISSUE-125 Capabilities API compatibility with web privacy and security, assuming untrusted, fingerprinting risk notes added 19:22:14 Topic: Action Review 19:22:37 ACTION-391? 19:22:37 ACTION-391 -- Dominique Hazaël-Massieux to look at overlap between MediaFileData and HTMLVideoElement -- due 2011-04-27 -- OPEN 19:22:37 http://www.w3.org/2009/dap/track/actions/391 19:22:45 https://www.w3.org/2009/dap/track/actions/open 19:22:52 darobin: should i email dom if he still wants to do it? 19:22:54 fjh: sure 19:24:03 ACTION-422? 19:24:03 ACTION-422 -- Robin Berjon to draft the design decision motivating using a new input type=foo or not for a given feature -- due 2011-07-26 -- OPEN 19:24:03 http://www.w3.org/2009/dap/track/actions/422 19:24:26 close ACTION-422 19:24:26 ACTION-422 Draft the design decision motivating using a new input type=foo or not for a given feature closed 19:24:36 ACTION-459? 19:24:36 ACTION-459 -- Sakari Poussa to draft a proposal for a threshold parameter for Battery events -- due 2011-11-10 -- CLOSED 19:24:36 http://www.w3.org/2009/dap/track/actions/459 19:24:43 ACTION-439? 19:24:44 ACTION-439 -- Bryan Sullivan to draft use cases for proximity, ambient light, and ambient sound sensors. -- due 2011-07-27 -- OPEN 19:24:44 http://www.w3.org/2009/dap/track/actions/439 19:25:09 close ACTION-439 19:25:09 ACTION-439 Draft use cases for proximity, ambient light, and ambient sound sensors. closed 19:25:52 action-446? 19:25:52 ACTION-446 -- Frederick Hirsch to review security issue http://lists.w3.org/Archives/Public/public-device-apis/2011Aug/0006.html -- due 2011-08-24 -- OPEN 19:25:52 http://www.w3.org/2009/dap/track/actions/446 19:26:21 action-464? 19:26:21 ACTION-464 -- Robin Berjon to follow up with Alex Russell on getting an example of sensors on Intents. -- due 2011-11-10 -- OPEN 19:26:21 http://www.w3.org/2009/dap/track/actions/464 19:26:41 action-464: we have examples of sensors on intents 19:26:41 ACTION-464 Follow up with Alex Russell on getting an example of sensors on Intents. notes added 19:26:51 close action-464 19:26:51 ACTION-464 Follow up with Alex Russell on getting an example of sensors on Intents. closed 19:27:02 action-465? 19:27:02 ACTION-465 -- Jose Manuel Cantera Fonseca to present use cases for the Sensors API -- due 2011-11-10 -- OPEN 19:27:02 http://www.w3.org/2009/dap/track/actions/465 19:27:31 close action-465 19:27:31 ACTION-465 Present use cases for the Sensors API closed 19:27:55 ACTION-464: thermometer / temperatture 19:27:55 ACTION-464 Follow up with Alex Russell on getting an example of sensors on Intents. notes added 19:28:03 action-468? 19:28:03 ACTION-468 -- Robin Berjon to look as Mozilla Labs Sharing experimentation re Messaging API -- due 2011-11-10 -- OPEN 19:28:03 http://www.w3.org/2009/dap/track/actions/468 19:28:19 darobin: it doesn't seem like even by using an intent 19:28:30 ... there's any value beyond what uri schemes provide 19:28:40 ... we discussed this at length w/ Jungkee 19:28:47 ... the only thing extra you can do is attachments 19:29:05 ... that doesn't seem to justify a Spec 19:29:37 close action-468 19:29:37 ACTION-468 Look as Mozilla Labs Sharing experimentation re Messaging API closed 19:30:03 action-468: it's shelved 19:30:03 ACTION-468 Look as Mozilla Labs Sharing experimentation re Messaging API notes added 19:30:09 action-472? 19:30:10 ACTION-472 -- Frederick Hirsch to update policy requirements for security requirements -- due 2011-11-11 -- OPEN 19:30:10 http://www.w3.org/2009/dap/track/actions/472 19:30:24 close action-472 19:30:25 ACTION-472 Update policy requirements for security requirements closed 19:30:38 ACTION-472: policy requirements are gone 19:30:38 ACTION-472 Update policy requirements for security requirements notes added 19:30:54 action-473? 19:30:54 ACTION-473 -- Robin Berjon to coordinate with fjh on the production of a "General Security Principles in Web APIs Design" Note -- due 2011-11-11 -- OPEN 19:30:54 http://www.w3.org/2009/dap/track/actions/473 19:32:00 action-474? 19:32:00 ACTION-474 -- Adrian Bateman to make a proposal for Network Information API -- due 2012-10-15 -- OPEN 19:32:00 http://www.w3.org/2009/dap/track/actions/474 19:32:13 Zakim, who is on the call? 19:32:13 On the phone I see [Host], gmandyam, adrianba (muted) 19:32:14 [Host] has Josh_Soref, James_Hawkins, fjh, darobin, lgombos, kensaku, Cathy, aizu, jgiraud, Jungkee, dcheng3, youenn, Milan 19:32:59 fjh: darobin and i just coordinated 19:33:11 http://darobin.github.com/api-design-privacy/api-design-privacy.html 19:33:41 fjh: we just gave it to adrianba 19:33:49 action-483? 19:33:49 ACTION-483 -- Josh Soref to send proposal to list for how Contacts will move forward -- due 2011-11-11 -- OPEN 19:33:49 http://www.w3.org/2009/dap/track/actions/483 19:34:00 ACTION-483: moot, we now have Pick Intents as way forward 19:34:00 ACTION-483 Send proposal to list for how Contacts will move forward notes added 19:34:17 close action-483 19:34:18 ACTION-483 Send proposal to list for how Contacts will move forward closed 19:34:22 ACTION-485? 19:34:22 ACTION-485 -- Sakari Poussa to ask Phonegap users to send feedback on find() -- due 2011-11-11 -- OPEN 19:34:22 http://www.w3.org/2009/dap/track/actions/485 19:34:27 action-485? 19:34:27 ACTION-485 -- Sakari Poussa to ask Phonegap users to send feedback on find() -- due 2011-11-11 -- OPEN 19:34:27 http://www.w3.org/2009/dap/track/actions/485 19:34:37 close action-485 19:34:37 ACTION-485 Ask Phonegap users to send feedback on find() closed 19:34:42 action-510? 19:34:42 ACTION-510 -- Claes Nilsson to create new spec how WebIntents UPnP registration -- due 2012-03-27 -- OPEN 19:34:42 http://www.w3.org/2009/dap/track/actions/510 19:35:00 ACTION-485: moot, have pick intents 19:35:00 ACTION-485 Ask Phonegap users to send feedback on find() notes added 19:35:02 action-510: Claes did this 19:35:02 ACTION-510 Create new spec how WebIntents UPnP registration notes added 19:35:09 close action-510 19:35:09 ACTION-510 Create new spec how WebIntents UPnP registration closed 19:35:14 action-511? 19:35:14 ACTION-511 -- Giuseppe Pascale to figure out how to put together a document describing how to do Intents with existing UPnP (himself or by finding someone who does it) -- due 2012-03-27 -- OPEN 19:35:14 http://www.w3.org/2009/dap/track/actions/511 19:36:16 fjh: i'll assign it to claes, he volunteered to do it today 19:36:21 action-512? 19:36:21 ACTION-512 -- Robin Berjon to propose linking to "Privacy by Design in APIs" from Web Intents draft when it's ready -- due 2012-03-27 -- OPEN 19:36:21 http://www.w3.org/2009/dap/track/actions/512 19:37:38 action-512: jhawkins notes there's a section "privacy considerations" and a link to "dap privacy requirements" 19:37:38 ACTION-512 Propose linking to "Privacy by Design in APIs" from Web Intents draft when it's ready notes added 19:37:57 http://darobin.github.com/api-design-privacy/api-design-privacy.html 19:38:02 close action-512 19:38:02 ACTION-512 Propose linking to "Privacy by Design in APIs" from Web Intents draft when it's ready closed 19:38:26 Josh_Soref: darobin has proposed linking to jhawkins (url above) 19:38:32 action-514? 19:38:32 ACTION-514 -- Robin Berjon to talk to the Web Schema group about using schema.org nouns for Intents -- due 2012-03-27 -- OPEN 19:38:32 http://www.w3.org/2009/dap/track/actions/514 19:38:45 darobin: i have an open channel to danbri 19:38:57 action-516? 19:38:57 ACTION-516 -- Josh Soref to propose Security Considerations section on SSL for Intents sepc -- due 2012-03-27 -- OPEN 19:38:57 http://www.w3.org/2009/dap/track/actions/516 19:39:55 ACTION-516 due 2012-07-18 19:39:55 ACTION-516 Propose Security Considerations section on SSL for Intents sepc due date now 2012-07-18 19:40:12 the tools are cool 19:40:28 action-519? 19:40:28 ACTION-519 -- Claes Nilsson to add a proposal for hidden disposition. -- due 2012-03-28 -- OPEN 19:40:28 http://www.w3.org/2009/dap/track/actions/519 19:40:49 action-519 due 2012-08-15 19:40:49 ACTION-519 Add a proposal for hidden disposition. due date now 2012-08-15 19:40:58 action-520? 19:40:58 ACTION-520 -- Frederick Hirsch to look at WS* to see what might be relevant -- due 2012-03-28 -- OPEN 19:40:58 http://www.w3.org/2009/dap/track/actions/520 19:41:54 close action-520 19:41:54 ACTION-520 Look at WS* to see what might be relevant closed 19:41:58 ACTION-520: overtaken by progress in WebIntents 19:41:58 ACTION-520 Look at WS* to see what might be relevant notes added 19:42:06 action-521? 19:42:06 ACTION-521 -- Claes Nilsson to coordinate with UPnP forum about extensions required for Intents -- due 2012-03-28 -- OPEN 19:42:06 http://www.w3.org/2009/dap/track/actions/521 19:42:15 close action-521 19:42:15 ACTION-521 Coordinate with UPnP forum about extensions required for Intents closed 19:42:34 ACTION-522 due 2012-08-31 19:42:34 ACTION-522 Write tests for Battery due date now 2012-08-31 19:42:40 action-522? 19:42:40 ACTION-522 -- Robin Berjon to write tests for Battery -- due 2012-08-31 -- OPEN 19:42:40 http://www.w3.org/2009/dap/track/actions/522 19:42:43 ACTION-521: completed ln latest Addendum, minimized need for extensions 19:42:43 ACTION-521 Coordinate with UPnP forum about extensions required for Intents notes added 19:42:49 ACTION-523 due 2012-08-31 19:42:49 ACTION-523 Work on test cases for battery and vibration due date now 2012-08-31 19:42:51 darobin: i'm still doing that 19:43:00 action-524? 19:43:00 ACTION-524 -- Robin Berjon to prepare charter for system level APIs -- due 2012-03-28 -- OPEN 19:43:00 http://www.w3.org/2009/dap/track/actions/524 19:43:07 ACTION-524: done 19:43:07 ACTION-524 Prepare charter for system level APIs notes added 19:43:07 close action-524 19:43:07 ACTION-524 Prepare charter for system level APIs closed 19:43:15 action-528? 19:43:15 ACTION-528 -- Richard Tibbett to provide more use cases for Networked Service Discovery -- due 2012-05-04 -- OPEN 19:43:15 http://www.w3.org/2009/dap/track/actions/528 19:43:27 close action-528 19:43:27 ACTION-528 Provide more use cases for Networked Service Discovery closed 19:43:59 rrsagent, generate minutes 19:43:59 I have made the request to generate http://www.w3.org/2012/07/11-dap-minutes.html fjh 19:44:26 ACTION-528: see http://people.opera.com/richt/release/specs/discovery/Overview.html#use-cases-and-requirements 19:44:26 ACTION-528 Provide more use cases for Networked Service Discovery notes added 19:44:34 action-529? 19:44:34 ACTION-529 -- Claes Nilsson to work with greg and bryan on investigating white list/CORS for networked services -- due 2012-03-29 -- OPEN 19:44:34 http://www.w3.org/2009/dap/track/actions/529 19:45:21 ACTION-529: solved in spec in different way 19:45:21 ACTION-529 Work with greg and bryan on investigating white list/CORS for networked services notes added 19:45:23 close action-529 19:45:23 ACTION-529 Work with greg and bryan on investigating white list/CORS for networked services closed 19:45:27 action-532? 19:45:27 ACTION-532 -- Dave Raggett to collect use cases for qrcodes in web context -- due 2012-03-29 -- OPEN 19:45:27 http://www.w3.org/2009/dap/track/actions/532 19:45:40 close action-532 19:45:41 ACTION-532 Collect use cases for qrcodes in web context closed 19:45:50 ACTION-532: QR codes not in DAP 19:45:50 ACTION-532 Collect use cases for qrcodes in web context notes added 19:45:58 action-533? 19:45:58 ACTION-533 -- Jungkee Song to gather use cases for Gallery API -- due 2012-03-29 -- OPEN 19:45:58 http://www.w3.org/2009/dap/track/actions/533 19:46:06 close action-533 19:46:06 ACTION-533 Gather use cases for Gallery API closed 19:46:46 ACTION-533: spec unshelved, see demo http://www.w3.org/2009/dap/wiki/images/2/2e/20120711-WebIntentsLocalServiceDemo.pdf 19:46:46 ACTION-533 Gather use cases for Gallery API notes added 19:46:49 action-535? 19:46:49 ACTION-535 -- Robin Berjon to ask Intents TF if they want to join our f2f -- due 2012-05-02 -- OPEN 19:46:49 http://www.w3.org/2009/dap/track/actions/535 19:47:00 close action-535 19:47:00 ACTION-535 Ask Intents TF if they want to join our f2f closed 19:47:02 close action-536 19:47:02 ACTION-536 Ask gUM TF if they want to join our f2f closed 19:47:04 ACTION-535: done 19:47:04 ACTION-535 Ask Intents TF if they want to join our f2f notes added 19:47:10 ACTION-536: done 19:47:10 ACTION-536 Ask gUM TF if they want to join our f2f notes added 19:47:11 action-535: they joined 19:47:11 ACTION-535 Ask Intents TF if they want to join our f2f notes added 19:47:16 action-536: they didn't join 19:47:16 ACTION-536 Ask gUM TF if they want to join our f2f notes added 19:47:26 ACTION-536: done 19:47:26 ACTION-536 Ask gUM TF if they want to join our f2f notes added 19:47:32 action-544? 19:47:32 ACTION-544 -- Dave Raggett to widen editing privileges for editing webIntents -- due 2012-06-27 -- OPEN 19:47:32 http://www.w3.org/2009/dap/track/actions/544 19:47:44 close action-544 19:47:44 ACTION-544 Widen editing privileges for editing webIntents closed 19:47:51 action-544: dsr did this 19:47:51 ACTION-544 Widen editing privileges for editing webIntents notes added 19:49:05 ACTION-552 product WebIntents 19:49:19 ACTION-552 associated with WebIntents 19:49:23 ACTION-552 is associated with WebIntents 19:50:09 ACTION-553: is related to ACTION-516 19:50:09 ACTION-553 Summarize issue and rationale regarding SSL for inlined webintents content notes added 19:50:42 ACTION-555 due 2012-08-15 19:50:42 ACTION-555 Add mDNS adaption to the 'Web Intents Addendum - Local Services' specification for feature completion and before FPWD due date now 2012-08-15 19:52:39 Josh_Soref: Team needs to force DVCS to force only one head allowed, mozilla does this for mozilla-central 19:52:39 ACTION: Robin to ask team if they can set up Mercurial so that only one head is allowed 19:52:40 Created ACTION-559 - Ask team if they can set up Mercurial so that only one head is allowed [on Robin Berjon - due 2012-07-18]. 19:53:59 Topic: TPAC 19:54:04 http://mercurial.selenic.com/wiki/TipsAndTricks#Prevent_a_push_that_would_create_multiple_heads 19:55:10 http://www.w3.org/2012/10/TPAC/ 19:58:57 Josh_Soref: yay! 19:59:00 fjh: what's the requirement for when an agenda should be published 19:59:02 ACTION-555: http://mercurial.selenic.com/wiki/TipsAndTricks#Prevent_a_push_that_would_create_multiple_heads 19:59:02 ACTION-555 Add mDNS adaption to the 'Web Intents Addendum - Local Services' specification for feature completion and before FPWD notes added 19:59:21 ACTION-559: http://mercurial.selenic.com/wiki/TipsAndTricks#Prevent_a_push_that_would_create_multiple_heads 19:59:21 ACTION-559 Ask team if they can set up Mercurial so that only one head is allowed notes added 19:59:34 fjh: we need to plan for joint slots 19:59:55 Josh_Soref: can we start w/ a plan to do a joint slot w/ WebRTC 20:00:11 ACTION-555: for reference previous comment was added to the wrong action. 20:00:11 ACTION-555 Add mDNS adaption to the 'Web Intents Addendum - Local Services' specification for feature completion and before FPWD notes added 20:02:12 Josh_Soref: so, we plan to do WebIntents in DAP 20:05:34 Josh_Soref: the 35 pencilled in for us for TPAC seems too low 20:05:39 darobin: last year we were 60+ 20:05:45 Josh_Soref: we should ask for a bigger number 20:06:01 darobin: we had more people than HTML 20:06:09 ... and with webintents, we'll be big 20:09:01 Topic: AOB 20:09:14 RESOLUTION: We thank our hosts for the wonderful hosting 20:09:20 thanks! 20:09:24 [ Applause ] 20:09:46 RESOLUTION: We thank the scribe 20:09:47 [ Applause ] 20:10:10 -gmandyam 20:10:14 darobin: thanks to everyone on the phone 20:10:21 -adrianba 20:10:29 RESOLUTION: No meeting tomorrow 20:10:51 [ Adjourned ] 20:11:03 trackbot, end meeting 20:11:03 Zakim, list attendees 20:11:03 As of this point the attendees have been [Host], +46.1.08.01.aaaa, +33.6.77.84.aabb, Claes, Jean-Claude_Dufourd, gmandyam, Josh_Soref, James_Hawkins, adrianba, fjh, nwidell, 20:11:07 ... darobin, lgombos, kensaku, Cathy, aizu, jgiraud, Jungkee, dcheng3, youenn, Milan, Travis 20:11:10 adrianba has left #dap 20:11:11 RRSAgent, please draft minutes 20:11:11 I have made the request to generate http://www.w3.org/2012/07/11-dap-minutes.html trackbot 20:11:12 RRSAgent, bye 20:11:12 I see 6 open action items saved in http://www.w3.org/2012/07/11-dap-actions.rdf : 20:11:12 ACTION: Claes to add mDNS adaption to the 'Web Intents Addendum - Local Services' specification for feature completion and before FPWD [1] 20:11:12 recorded in http://www.w3.org/2012/07/11-dap-irc#T14-09-16 20:11:12 ACTION: Robin to set up test repository with example, docs, manifest generation for Web Intents [2] 20:11:12 recorded in http://www.w3.org/2012/07/11-dap-irc#T15-29-59 20:11:12 ACTION: Robin to ping DougT about light sensor to see if there's interest [3] 20:11:12 recorded in http://www.w3.org/2012/07/11-dap-irc#T17-26-19 20:11:12 ACTION: Rich to produce a proposal draft for a StreamRecorder API [4] 20:11:12 recorded in http://www.w3.org/2012/07/11-dap-irc#T17-46-34 20:11:12 ACTION: Robin to draft a proposal for stills capture for gUM [5] 20:11:12 recorded in http://www.w3.org/2012/07/11-dap-irc#T17-54-01 20:11:12 ACTION: Robin to ask team if they can set up Mercurial so that only one head is allowed [6] 20:11:12 recorded in http://www.w3.org/2012/07/11-dap-irc#T19-52-39-1