14:46:15 RRSAgent has joined #dap 14:46:15 logging to http://www.w3.org/2013/01/09-dap-irc 14:46:17 RRSAgent, make logs world 14:46:17 Zakim has joined #dap 14:46:19 Zakim, this will be DAP 14:46:19 ok, trackbot; I see UW_DAP()10:00AM scheduled to start in 14 minutes 14:46:20 Meeting: Device APIs Working Group Teleconference 14:46:20 Date: 09 January 2013 14:46:37 Agenda: http://lists.w3.org/Archives/Public/public-device-apis/2013Jan/0009.html 14:46:56 fjh has changed the topic to: dap 3279 ; agenda http://lists.w3.org/Archives/Public/public-device-apis/2013Jan/0009.html 14:47:12 Chair: Frederick_Hirsch 14:47:21 Present+ Frederick_Hirsch 14:58:40 UW_DAP()10:00AM has now started 14:58:47 + +1.289.261.aaaa 14:58:53 bryan has joined #dap 14:59:20 +Bryan_Sullivan 14:59:21 +[IPcaller] 14:59:28 zakim, [IPcaller] is me 14:59:28 +fjh; got it 14:59:35 Zakim, aaaa is me 14:59:35 +Josh_Soref; got it 14:59:53 dtran has joined #dap 15:00:02 Present+ Dzung_Tran 15:00:08 zakim, who is here> 15:00:09 I don't understand 'who is here>', fjh 15:00:15 + +1.781.534.aabb 15:00:20 s/zakim, who is here>// 15:00:24 Zakim, aabb is me 15:00:24 +lgombos; got it 15:00:28 zakim, who is here? 15:00:28 On the phone I see Josh_Soref, Bryan_Sullivan, fjh, lgombos 15:00:29 On IRC I see dtran, bryan, Zakim, RRSAgent, fjh, lgombos, hiroto_, richt, dom, mounir, tobie, slightlyoff_, trackbot, Josh_Soref 15:00:33 Present+ Laszlo_Gombos 15:00:46 Cathy has joined #dap 15:01:00 scribe: Josh_Soref 15:01:10 Milan_Patel has joined #dap 15:01:10 dcheng3 has joined #dap 15:01:21 + +25686aacc 15:01:36 Present+ Milan_Patel 15:02:05 Topic: Announcements 15:02:07 + +49.173.537.aadd 15:02:11 +Cathy 15:02:15 Present+ Diana_Cheng 15:02:17 +??P22 15:02:18 Zakim, ??P22 is me 15:02:18 +dom; got it 15:02:20 Happy New Year all. 15:02:20 Welcome Sunghan - http://lists.w3.org/Archives/Public/public-device-apis/2013Jan/0007.html 15:02:30 zakim, aadd is dcheng3 15:02:30 +dcheng3; got it 15:02:36 rrsagent, generate minutes 15:02:36 I have made the request to generate http://www.w3.org/2013/01/09-dap-minutes.html fjh 15:02:46 AnssiK has joined #dap 15:02:47 zakim, who is here? 15:02:47 On the phone I see Josh_Soref, Bryan_Sullivan, fjh, lgombos, +25686aacc, dcheng3, Cathy, dom 15:02:49 On IRC I see AnssiK, dcheng3, Milan_Patel, Cathy, dtran, bryan, Zakim, RRSAgent, fjh, lgombos, hiroto_, richt, dom, mounir, tobie, slightlyoff_, trackbot, Josh_Soref 15:02:56 +??P25 15:03:03 zakim, ??P25 is me 15:03:03 +AnssiK; got it 15:03:14 Present+ Anssi_Kostiainen 15:03:23 Zakim, aacc is Milan 15:03:23 +Milan; got it 15:03:43 Zakim, Milan is really Milan_Patel 15:03:44 +Milan_Patel; got it 15:03:46 Zakim, mute me 15:03:47 Josh_Soref should now be muted 15:03:55 Topic: Minutes Approval 15:03:58 12 December 2012 - http://lists.w3.org/Archives/Public/public-device-apis/2012Dec/att-0073/minutes-2012-12-12.html 15:04:23 RESOLUTION: Draft minutes from 12 December 2012 are approved. 15:04:30 Topic: HTML Media Capture 15:04:40 working draft published 13 December 2012: http://www.w3.org/TR/2012/WD-html-media-capture-20121213/ 15:04:49 fjh: ... with the change to the boolean 15:04:50 previous LC Draft Comments https://www.w3.org/2006/02/lc-comments-tracker/43696/WD-html-media-capture-20120712/doc/ 15:05:02 await Doug Scheper's confirmation: http://lists.w3.org/Archives/Public/public-device-apis/2013Jan/0008.html 15:05:18 fjh: dom, when you see shepazu... 15:05:28 dom: i'll try to ping him, i should see him next week 15:05:37 fjh: i think we've done a good job, but i'd like his confirmation 15:05:55 ... once that's done, i think we've addressed all the LC comments 15:06:02 ... AnssiK did you want to say anything? 15:06:21 AnssiK: we got positive feedback from Facebook (tobie) and Mozilla (mounir) 15:06:28 ... we should try to ping the Google guys 15:07:28 fjh: Anssi can you please send an email 15:07:32 Anssi: yes, I ca 15:07:41 s/fjh/scribe/ 15:07:42 s/fjh/scribe/ 15:07:43 s/fjh/scribe/ 15:07:53 s/scribe: Anssi/fjh: AnssiK 15:07:58 fjh: I think we are on the right track, given that the LC comments were resolved with our recent changes 15:07:58 s/Anssi:/AnssiK:/ 15:08:06 s/fjh/scribe/ 15:08:12 RRSAgent, draft minutes 15:08:12 I have made the request to generate http://www.w3.org/2013/01/09-dap-minutes.html Josh_Soref 15:08:16 topic: Ambient Light - LC 15:08:33 LC published 13 December 2012, http://www.w3.org/TR/2012/WD-ambient-light-20121213/ 15:08:40 LC ends 26 January. 15:08:49 LC comments (3 specific + 1 general comment so far) https://www.w3.org/2006/02/lc-comments-tracker/43696/WD-ambient-light-20121213/ 15:09:17 fjh: there's comments about default values 15:09:20 ... i think AnssiK replied there 15:09:27 ... there are specific comments from tabatkins 15:09:35 q+ 15:09:43 ack AnssiK 15:09:51 AnssiK: dougt is editing the spec 15:10:00 ... i've asked if he'd like me to help him 15:11:40 action: anssiK to update Ambient Light specification for LC-2737 , bringing queueing order update from Proximity to Ambient Light 15:11:40 Created ACTION-605 - Update Ambient Light specification for LC-2737 , bringing queueing order update from Proximity to Ambient Light [on Anssi Kostiainen - due 2013-01-16]. 15:11:57 fjh: will you also deal w/ event-member? 15:12:05 ... that seems to be a general comment 15:12:09 https://www.w3.org/2006/02/lc-comments-tracker/43696/WD-ambient-light-20121213/2738 15:12:09 ... for other specs too 15:12:17 general comment to Proximity and Ambient Light 15:12:33 AnssiK: that's part of this 15:12:37 https://dvcs.w3.org/hg/dap/log/4a9ad5688160/proximity/Overview.html 15:12:39 ... i'll cherrypick anne's comments 15:12:48 ... from proximity and backport them into ambient light 15:13:07 action: anssik to update Proximity and Ambient Light to define events, per LC-2738 15:13:08 Created ACTION-606 - Update Proximity and Ambient Light to define events, per LC-2738 [on Anssi Kostiainen - due 2013-01-16]. 15:13:08 ... that should be fairly straightforward 15:13:33 action-2736? 15:13:40 trackbot has joined #dap 15:13:53 s/action-2736?// 15:13:55 https://www.w3.org/2006/02/lc-comments-tracker/43696/WD-ambient-light-20121213/2738 15:14:14 fjh: will you do this as well? 15:14:18 AnssiK: this will be handled 15:15:09 fjh: send me a pointer if there's anything else i haven't recorded 15:15:23 AnssiK: you've probably updated it already, but i'll double check 15:15:43 action: anssik to update Ambient Light per LC-2737, bringing any questions to the list 15:15:43 Created ACTION-607 - Update Ambient Light per LC-2737, bringing any questions to the list [on Anssi Kostiainen - due 2013-01-16]. 15:16:36 Topic: Proximity API - LC 15:16:39 LC published 6 December 2012. LC ends 24 January. 15:16:50 LC comments (2 specific comments , 1 general comment so far) : https://www.w3.org/2006/02/lc-comments-tracker/43696/WD-proximity-20121206/ 15:17:21 AnssiK: that's already addressed 15:17:34 https://www.w3.org/2006/02/lc-comments-tracker/43696/WD-proximity-20121206/2731 15:17:49 https://dvcs.w3.org/hg/dap/raw-rev/52acb4877e86: https://dvcs.w3.org/hg/dap/rev/52acb4877e86 15:18:06 action: fjh to update LC-2731 as completed 15:18:07 specify the interface name in the definition of default values i.e. 'The XXX attribute of the YYY interface MUST […]': https://dvcs.w3.org/hg/dap/rev/6507cb51ce47 15:18:07 Created ACTION-608 - Update LC-2731 as completed [on Frederick Hirsch - due 2013-01-16]. 15:18:16 fjh: so both of these are done? 15:18:20 AnssiK: yes, you can close them 15:18:30 ... i'll need to update ambient accordingly, but for proximity, they're done 15:18:55 Topic: General LC comment (putting Ambient Light/Proximity into single document) 15:19:13 fjh: earlier, we had a generic sensor api 15:19:21 ... i think the comments here are asking for something else 15:19:29 ... i think rick is proposing 15:19:42 q+ 15:19:45 ... is to have a spec for ambient/proximity as one spec 15:19:49 q+ 15:19:58 ... but for a bunch of things that have the same api shape 15:20:08 ... there's some positives and negatives to making such a change 15:20:24 ... it's good to avoid duplication when you can 15:20:43 ... advantage of splitting up is you can go forward on individual timelines 15:20:58 http://lists.w3.org/Archives/Public/public-device-apis/2012Dec/0052.html (Anne) 15:20:58 http://lists.w3.org/Archives/Public/public-device-apis/2012Dec/0059.html (detailed, Rick) 15:20:59 http://lists.w3.org/Archives/Public/public-device-apis/2012Dec/0066.html - device namespace 15:20:59 15:20:59 editing offer: http://lists.w3.org/Archives/Public/public-device-apis/2012Dec/0060.html (Rick) 15:21:08 ... it depends on what implementers think/want 15:22:00 fjh: previously we discussed a generic sensor API that was broad and extensible, I believe this proposal has narrower scope to those well-defined items that have common mechanism such as Ambient Light, Proximiity 15:22:09 originally we have many of these sensors in one spec; the group want to split them 15:22:27 fjh: in general agree it is good to avoid repetition of material, express common material once 15:22:42 s/fjh/scribe/ 15:22:43 s/fjh/scribe/ 15:22:43 s/fjh/scribe/ 15:22:45 s/fjh/scribe/ 15:22:52 s/scribe:/fjh:/ 15:22:53 s/scribe:/fjh:/ 15:22:55 fjh: however from process perspective advantages to having separate tracks 15:23:00 s/fjh/scribe/ 15:23:02 s/fjh/scribe/ 15:23:04 s/scribe:/fjh:/ 15:23:09 would like to avoid backtracking in process, e.g. back to FPWD etc 15:23:19 RRSAgent, draft minutes 15:23:19 I have made the request to generate http://www.w3.org/2013/01/09-dap-minutes.html Josh_Soref 15:23:19 ack AnssiK 15:23:22 s/fjh/scribe/ 15:23:30 s/fjh/scribe/ 15:23:41 s/scribe/fjh/ 15:23:43 s/would/... would/ 15:23:59 AnssiK: what anne said is it would be easier to review if the specs were merged together 15:24:04 anssiK notes two issues - how to organize specs versus different design 15:24:07 ... and there was less boilerplate 15:24:16 ... if other factors make things worse 15:24:24 s/fjh/scribe/ 15:24:29 s/anssiK/AnssiK:/ 15:24:55 fjh: maybe we should first deal w/ the issue of whether we have the right design 15:25:31 ... i'd like to hear if there's a problem we need to address 15:25:42 ack me 15:26:49 josh_soref: one concern - if we have something with an API that is abstracted, what does it mean to have two implementations. 15:27:07 josh_soref: clear for proximity but not in generic case 15:27:30 ... fantasi publishes annual compendiums of CSS specs, likewise for WHATWG specs 15:27:56 ... compendium is spec that is implemented 15:27:58 q+ 15:28:22 josh_soref: still allows them to move forward 15:28:32 hiroto has joined #dap 15:28:53 need to be clear what is authoritative 15:29:18 AnssiK: i could easily hack that in 15:29:30 ... we could easily product such a document out of what we have today 15:29:40 q+ to Josh 15:29:40 ack fjh 15:29:46 [that seems to be still orthogonal to fjh's question about design rather than packaging] 15:29:57 https://dvcs.w3.org/hg/dap/raw-file/tip/sensor-api/Overview.html 15:30:04 fjh: you were concerned about how do you know if you've implemented it 15:30:16 ... if each thing is defined in the spec individually, then it's still line items 15:30:19 this was originally the package of all the sensors 15:30:37 ... we define them together 15:30:49 ... you're right, that otherwise it's untestable 15:30:53 ... on your second point 15:30:56 q- 15:31:00 ... we could do that 15:31:04 ... as a compendium 15:31:10 ... as AnssiK says, a NOTE 15:31:13 ... that might be a good solution 15:31:33 q+ 15:31:46 ack dom 15:31:54 dom: before we worry about packaging 15:32:11 ... there's a high level design question 15:32:25 ... what rick was asking for is a change from what we have today 15:32:26 ... Constructors 15:32:35 ... how you access them, how they're exposed 15:32:44 ... that's a fairly strong departure from what we've been doing 15:32:59 to be concrete, is this the correct design discussion reference, http://lists.w3.org/Archives/Public/public-device-apis/2012Dec/0060.html 15:33:04 ... the main question before we worry about how we package them together 15:33:15 ... is whether we should change the current, widely deployed, api 15:33:29 dom: yes, that link 15:33:52 fjh: there's a tension between what's implemented, and what could be better/not 15:33:57 q+ 15:33:57 zakim, who is here? 15:33:58 On the phone I see Josh_Soref, Bryan_Sullivan, fjh, lgombos, Milan_Patel, dcheng3, Cathy, dom, AnssiK 15:33:58 On IRC I see hiroto, trackbot, AnssiK, dcheng3, Milan_Patel, Cathy, dtran, bryan, Zakim, RRSAgent, fjh, lgombos, richt, dom, mounir, tobie, slightlyoff_, Josh_Soref 15:34:02 ack AnssiK 15:34:13 AnssiK: the current designs are implementer driven 15:34:15 we experimented with constructor in some early Battery Status API drafts, e.g.: http://www.w3.org/TR/2011/WD-battery-status-20110915/ 15:34:23 ... we experimented with structured patterns 15:34:32 ... and that was shot down based on implementers' feedback 15:34:33 q+ 15:34:43 ... it had something to do with making the api as simple as possible 15:34:59 question is whether there are essential use cases not addressed in current approach 15:35:07 q+ to say we need to document our design and hopefully reply to the thread 15:35:07 ... we've been there, done that, it didn't work with battery 15:35:21 ack lgombos 15:35:36 ... it has something to do with defining default state 15:35:41 ... how do you measure state changes 15:35:52 ... if you have a constructor, you start monitoring state when you construct it 15:36:24 lgombos: there's a consistency 15:36:39 ... if things are apis in a certain way, libraries can always provide that 15:36:48 ... i think the issue is any functional change 15:37:32 s/there's a consistency/question of whether it is just consistency and syntactic sugar or whether there is a fundamental change, if just consistency a library could be built on top of what we have defined/ 15:37:40 q? 15:37:43 ack dom 15:37:43 dom, you wanted to say we need to document our design and hopefully reply to the thread 15:37:57 dom: i don't have an answer on whether we should change this 15:38:16 ... going to implementers and telling them we're getting input from developers 15:38:30 ... that developers think the current approach is wrong/not easy to track 15:39:04 we need to make a clear decision with agreement from implementers 15:39:07 ... XXX 15:39:16 ... we should go back to the implementers/developers 15:39:47 AnssiK: we have 2 implementations 15:39:53 ... afaik, we have no shipping implementations 15:39:55 s/XXX/we need to make an explanation of our current approach and well as a justification of why a change might be desired, so a decision can be made and agreed/ 15:40:02 ... you can probably build firefox with proximity on 15:40:10 ... some webkit ports have implemented proximity 15:40:18 naomi has joined #dap 15:40:23 ... from this perspective, it would be possible to change th design 15:40:27 s/th d/the d/ 15:40:32 ... without breaking the web 15:40:34 q+ Josh_Soref 15:40:47 ... the other question is whether implementers will get upset 15:40:59 ... what is the problem that the new design fixes that the old design doesn't 15:41:13 ... default-state is solved by constructor 15:41:13 we need to find the focus point of the advantages of each approach 15:41:21 .... dougt is a proponent of simplicity 15:41:24 s/find/summarize/ 15:41:31 ... i'd love to hear dougt's reasoning 15:41:36 q+ 15:41:40 ack Josh_Soref 15:42:25 josh_soref: in theory it might be possible to change API before it ships, but implementers would prefer not to change code that is already written, due to amount of work before shipping 15:42:37 josh_soref: everyone is trying to move fast without rework 15:43:07 josh_soref: whether the changes are good or not, it still might be hard to obtain implementation. need a very convincing argument 15:43:22 s/fjh/scribe/ 15:43:23 s/fjh/scribe/ 15:43:23 s/fjh/scribe/ 15:43:36 fjh: we need to make a good case about what the proposal really means 15:43:41 ... rick offered to write a spec 15:43:49 ... maybe someone could write a summary of why it's important 15:44:04 ... what exactly is the defficiency 15:44:09 q+ 15:44:14 s/defficiency/deficiency 15:44:17 ack fjh 15:44:30 ... we need a proposal about why it's necessary 15:44:51 ... i'm not sure i understand, apart from the surface change, what we get 15:44:55 ack AnssiK 15:45:06 ... i'll ask rick 15:45:12 ack AnssiK 15:45:33 AnssiK: i'm assuming mozilla is working on this api because they need it for their os 15:45:38 ... and for their UC, it's working 15:45:44 action: fjh to ask Rick to make proposal for change, summarizing use cases and benefits of change 15:45:44 Created ACTION-609 - Ask Rick to make proposal for change, summarizing use cases and benefits of change [on Frederick Hirsch - due 2013-01-16]. 15:45:54 ... you should question the UCs this current api doesn't address 15:46:04 ... it'd be better if rick tries to build his stuff on B2G 15:46:22 ... to show how his concerns aren't just a stylistic thing, but are a functional gap 15:46:26 fjh: agreed 15:47:03 ... AnssiK, if you want to summarize to the list 15:47:13 AnssiK: for the record, i'm indifferent on the design 15:47:21 ... i'm mostly interested in consensus 15:47:37 topic: Network Service Discovery 15:47:43 http://www.w3.org/TR/2012/WD-discovery-api-20121004/ 15:47:55 fjh: i think we need richt for this 15:48:03 ... not sure if Cathy has thoughts on this 15:48:17 Cathy: i think there are questions/comments for richt 15:48:26 ... i think he said that he was working on the mDNS section 15:48:36 ... i think we need to wait for him to come back to us 15:48:39 action: fjh to contact Richt offline re network service discovery 15:48:39 Created ACTION-610 - Contact Richt offline re network service discovery [on Frederick Hirsch - due 2013-01-16]. 15:49:05 topic: Magnetic Field Events 15:49:07 richt has joined #dap 15:49:11 https://wiki.mozilla.org/Magnetic_Field_Events 15:50:10 fjh: question of whether we should be doing this in this group 15:50:14 ... anyone have any comment on it? 15:50:36 sounds OK to me, can we start a wiki for use cases at least? 15:50:50 dom: my reading of the charter says that it's in scope 15:51:04 ... but it'd be useful to have UCs and Reqs 15:51:09 +1 to start with UCs 15:51:16 fjh: next step is to determine what this is for 15:51:22 I'll respond on the list asking for use cases 15:51:24 fjh: i'll respond on the list 15:51:37 topic: Upcoming meetings 15:51:44 F2F - 9-10 April, Location to be determined. Please indicate offers to host. 15:51:58 fjh: i mentioned Burlington, MA 15:52:06 ... bryan mentioned Seattle or Redmond 15:52:18 ... if people are considering being able to ohst 15:52:21 s/ohst/host/ 15:52:30 ... they could indicate on the list fairly soon 15:52:54 [ F2F - 9-10 April ] 15:53:09 fjh: probably need to pick a spot by next week to give organizers lead time 15:53:09 [should you re-send a call for hosts to member-device-apis, fjh?] 15:53:17 bryan: let me confirm i can get a large enough room 15:53:29 dcheng3: i can probably get an answer by next week 15:53:42 ... 20-30 people? 15:53:46 ... any other requirements? 15:54:50 RESOLUTION: Meeting Jan 30 is canceled 15:55:08 topic: Action Review 15:55:18 http://www.w3.org/2009/dap/track/actions/open 15:55:19 http://www.w3.org/2009/dap/track/actions/pendingreview 15:55:26 topic: AOB 15:55:41 fjh: thanks all, happy new year 15:55:56 ... AnssiK has actions for ambient light/proximity 15:55:58 q+ 15:56:09 ack Josh_Soref 15:56:19 ... i have actions to update proposals 15:57:12 Josh_Soref: RTCWeb/WebRTC/MC has a working week 15:57:16 there will be considerable discussion of media capture in that meeting 15:57:25 fjh: it's in the burlington area (?) 15:57:31 ... Feb 5-7 (?) 15:57:36 We will attend (Dan Druta) 15:57:37 ... i think MC is on the 5th (?) 15:57:48 dom: MC will be a main topic for the WebRTC part of the meeting 15:57:52 ... probably on 5-6 15:58:00 ... chairs are still refining 15:58:21 fjh: Josh_Soref, thanks for mentioning that 15:58:25 Bedford 15:58:26 dom: it's Bedford, MA 15:58:30 hosted by ACME Packet 15:59:37 AnssiK has left #dap 15:59:44 -Milan_Patel 15:59:47 -lgombos 15:59:54 bye 15:59:57 -Bryan_Sullivan 16:00:03 -dom 16:00:07 s/bye// 16:00:11 Actions on Anssi to update specs, fjh to reply on list and ask for proposal from Rick, potential f2f hosts to check on hosting 16:00:19 -Cathy 16:00:40 -> http://lists.w3.org/Archives/Public/public-media-capture/2012Nov/0091.html Media Capture F2F during WebRTC/RTCWeb meetings 16:00:41 http://lists.w3.org/Archives/Public/public-media-capture/2012Nov/0091.html <-- WebRTC meeting info 16:00:56 s|http://lists.w3.org/Archives/Public/public-media-capture/2012Nov/0091.html <-- WebRTC meeting info|| 16:01:06 Topic: Adjourn 16:01:36 trackbot, end meeting 16:01:36 Zakim, list attendees 16:01:36 As of this point the attendees have been +1.289.261.aaaa, Bryan_Sullivan, fjh, Josh_Soref, +1.781.534.aabb, lgombos, +25686aacc, +49.173.537.aadd, Cathy, dom, dcheng3, AnssiK, 16:01:36 ... Milan_Patel 16:01:44 RRSAgent, please draft minutes 16:01:44 I have made the request to generate http://www.w3.org/2013/01/09-dap-minutes.html trackbot 16:01:45 RRSAgent, bye 16:01:45 I see 6 open action items saved in http://www.w3.org/2013/01/09-dap-actions.rdf : 16:01:45 ACTION: anssiK to update Ambient Light specification for LC-2737 , bringing queueing order update from Proximity to Ambient Light [1] 16:01:45 recorded in http://www.w3.org/2013/01/09-dap-irc#T15-11-40 16:01:45 ACTION: anssik to update Proximity and Ambient Light to define events, per LC-2738 [2] 16:01:45 recorded in http://www.w3.org/2013/01/09-dap-irc#T15-13-07 16:01:45 ACTION: anssik to update Ambient Light per LC-2737, bringing any questions to the list [3] 16:01:45 recorded in http://www.w3.org/2013/01/09-dap-irc#T15-15-43 16:01:45 ACTION: fjh to update LC-2731 as completed [4] 16:01:45 recorded in http://www.w3.org/2013/01/09-dap-irc#T15-18-06 16:01:45 ACTION: fjh to ask Rick to make proposal for change, summarizing use cases and benefits of change [5] 16:01:45 recorded in http://www.w3.org/2013/01/09-dap-irc#T15-45-44 16:01:45 ACTION: fjh to contact Richt offline re network service discovery [6] 16:01:45 recorded in http://www.w3.org/2013/01/09-dap-irc#T15-48-39 16:01:46 -Josh_Soref 16:01:47 -fjh 16:01:52 -dcheng3 18:34:33 RRSAgent has joined #dap 18:34:33 logging to http://www.w3.org/2013/01/09-dap-irc 18:34:36 s/scribe: I think we are on the right track/fjh: I think we are on the right track/ 18:34:40 RRSAgent, draft mintues 18:34:40 I'm logging. I don't understand 'draft mintues', redactor. Try /msg RRSAgent help 18:34:43 RRSAgent, draft minutes 18:34:43 I have made the request to generate http://www.w3.org/2013/01/09-dap-minutes.html redactor 18:35:45 RRSAgent, bye 18:35:53 RRSAgent, make logs world 18:35:57 RRSAgent, bye 18:35:57 I see no action items