14:27:39 RRSAgent has joined #dap 14:27:39 logging to http://www.w3.org/2009/12/16-dap-irc 14:27:41 RRSAgent, make logs world 14:27:41 Zakim has joined #dap 14:27:43 Zakim, this will be DAP 14:27:43 ok, trackbot; I see UW_DAP()10:00AM scheduled to start in 33 minutes 14:27:44 Meeting: Device APIs and Policy Working Group Teleconference 14:27:44 Date: 16 December 2009 14:27:53 Agenda: http://www.w3.org/mid/9C36793C-06B7-4B84-80F9-5E2A212FD4E3@nokia.com 14:29:54 Chair: Robin_Berjon, Frederick_Hirsch 14:30:03 Present: Robin_Berjon, Frederick_Hirsch 14:30:56 Regrets: Paddy_Byers, Marcin Hanclik, Marengo Marco 14:36:14 fhirsch has joined #dap 14:46:18 AnssiK has joined #dap 14:48:33 Dzung_Tran has joined #dap 14:48:43 Present+ Dzung_Tran 14:56:26 UW_DAP()10:00AM has now started 14:56:33 +[IPcaller] 14:56:40 zakim, [IPcaller] is fjh 14:56:40 +fjh; got it 14:57:32 Suresh has joined #dap 14:57:38 Present+ Ilkka_Oksanen 14:58:21 + +1.972.373.aaaa 14:59:15 Present+ Suresh_Chitturi 14:59:41 +AnssiK 14:59:47 Present+ Anssi_Kostiainen 14:59:53 zakim, aaaa is Suresh 14:59:53 +Suresh; got it 15:00:43 zakim, aaa is Suresh 15:00:43 sorry, Suresh, I do not recognize a party named 'aaa' 15:01:04 +ilkka 15:01:47 +??P7 15:01:49 zakim, call thomas-781 15:01:49 ok, tlr; the call is being made 15:01:50 Claes has joined #dap 15:01:50 +Thomas 15:01:55 zakim, I am thomas 15:01:55 ok, tlr, I now associate you with Thomas 15:01:57 +Dom 15:01:57 zakim, mute me 15:01:59 Thomas should now be muted 15:02:04 zakim, mute me 15:02:04 Dom should now be muted 15:02:23 Present+ Dominique_Hazael_Massieux 15:02:36 Present+ Robin_Berjon 15:02:48 +maxf 15:02:56 Present+ Max_Froumentin 15:03:59 + +04610801aabb 15:04:20 zakim, aabb is Claes 15:04:20 +Claes; got it 15:04:32 Present+ Claes_Nilsson 15:04:51 Scribe: maxf 15:05:06 ScribeNick: maxf 15:05:30 Next meeting is 6 January 2010 15:05:42 Mobile Security barcamp - 19th January 2010, Sophia Antipolis 15:06:03 http://lists.w3.org/Archives/Public/public-device-apis/2009Dec/0205.html 15:06:12 Topic: Administration 15:06:25 -> http://lists.w3.org/Archives/Public/public-device-apis/2009Dec/0205.html Mobile Security Barcamp in Sophia, January 19 15:06:51 Topic: Minutes approval 15:07:02 jmorris has joined #dap 15:07:03 fjh: approval? 15:07:07 http://lists.w3.org/Archives/Public/public-device-apis/2009Dec/att-0169/minutes-2009-12-09.html 15:07:14 no objection 15:07:23 RESOLUTION: minutes from 9 dec approved 15:07:33 TOPIC: policy 15:07:37 Present+ John_Morris 15:07:44 action-63? 15:07:44 ACTION-63 -- Laura Arribas to review http://lists.w3.org/Archives/Public/public-device-apis/2009Nov/0044.html -- due 2009-11-25 -- OPEN 15:07:44 http://www.w3.org/2009/dap/track/actions/63 15:07:59 fjh: action 63 is deferred until Laura is back 15:08:12 + +1.301.581.aacc 15:08:16 File granularity access policy, Secure Cred Manager 15:08:32 http://lists.w3.org/Archives/Public/public-device-apis/2009Dec/0213.html 15:08:35 fjh: Klaus you sent a proposal? 15:08:55 s/Klaus/Claes/ 15:08:56 zakim, aacc is jmorris 15:08:57 +jmorris; got it 15:09:18 claes: typical uses case is storing keys for social web applications 15:09:31 I may have some comments on Secure Cred Manager later, but believe this is for future work 15:09:35 … there's a problem today about where to store those keys 15:09:47 … so I propose a JS api to store those keys on the device. 15:10:10 … There was a discussion on the mailing list, about the fact that it's about restricting access to applications for an API 15:10:18 q+ to ask what an application is 15:10:34 … the conclusion was that taking the proposal from Steve is a good starts and that I should build from that 15:10:55 … restraining certain parts of the API to certain applications. 15:10:56 q+ 15:11:13 ack fhirsch 15:11:13 fhirsch, you wanted to ask what an application is 15:11:20 … the main use case is allowing an application to access this application's data through that API 15:11:49 … What I'm proposing adds the possibility to add the application ID, which you can pass to the actual device API you're calling 15:11:58 … which restricts what you get out of that API 15:12:58 fjh: how would this work on the web as opposed to widgets? Seems that there's a management issue there, and that it could be a topic for future work 15:13:30 … I'm not sure I understand it makes sense to pass application ID to API call, because there might be other ways of doing it. I'm not getting what an application is on the web. 15:13:52 … my inclination is to sibject it should be future work, cause it requires more thought 15:14:06 … we might want to figure out the extensibility model. 15:14:30 Claes: I think that my credential manager is more realistically put into future work 15:14:51 … but a possibility to have a granularity of applications should be in this version of the specification. 15:15:09 … I'll reply to your questions on how to secure identified aplications, on the mailing list. 15:15:38 … we can just consider the possibility of having the granularity of application IDs in this version. 15:15:54 fhirsch: I'd like to make a decision today about the future work, if that's ok. 15:16:12 … about the application ID, I'd like to understand how it work in the various use cases. 15:16:26 Claes: I can reply to that and elaborate a little more on the mailing list. 15:16:31 ack suresh 15:16:54 q+ to ask for resolution re security credential manager for future work 15:16:55 Suresh: I'd like to echo fhirsch's comment on the secure credential manager 15:17:16 … I don't know if it's a deviceAPI-specific problem or a secure storage problem. 15:17:31 … so I would recommend talking to the web/offline storage guys 15:17:48 … Can you clarify what the proposal in terms of granulatiry? 15:18:07 … seems that it's used when evaluating the policy framework, is that right? 15:18:33 … it might be relevant to the WARP spec, something we discussed in the widgets group. 15:18:33 s/granulatiry/granularity/ 15:18:53 q+ to discuss TAG issue 15:19:06 q+ about WARP 15:19:22 ack about 15:19:23 Claes: I will consider this. I thought it would be part of the policy framework... 15:19:26 ack warp 15:19:36 q+ to talk about WARP 15:19:36 … and I also think it shouldn't be restricted to widgets, like the WARP specification 15:19:47 … I'll think about it and come back. 15:19:52 ack me 15:19:52 ack darobin 15:19:53 darobin, you wanted to talk about WARP 15:20:34 darobin: the reason WARP is currently so simple is that when webapps were working on it, we deliberately kept it simple until there would be more policy work. 15:20:52 … this may mean it should included in DAP and this WG could take over WARP 15:20:53 q+ 15:21:04 ack Suresh 15:21:35 Suresh: I'm not clear on this particular proposal on application ID. Is it going to be used to evaluate a policy, or along the lines of WARP 15:21:45 fhirsch: my question too. 15:22:17 q- 15:22:26 Claes: we have a framework for defining access to API according to the model defined by Steve, based on trust domains of the application 15:23:01 … I'm extending that concept to applications within a domain 15:23:25 … The application is sort of a finer granularity 15:23:26 +richt 15:23:38 sounds like the apporach BONDI has taken? 15:23:43 richt has joined #dap 15:23:46 fjh: we're verging into the management aspects 15:23:53 Present+ Richard_Tibbett 15:24:30 … without understanding those issues I don't know what it means. So let's take it to the list, and relate the issue to the browser web model, that possibly doesn't have a policy. 15:24:36 … just need to see more use cases. 15:24:46 … hard to tell what's going on right now. 15:25:15 Claes: I will elaborate on the mailing list. 15:25:25 q? 15:25:28 ack fhirsch 15:25:28 fhirsch, you wanted to ask for resolution re security credential manager for future work 15:26:03 RESOLUTION: security credential manager proposal is a possible item for future work. 15:26:11 ack fjh 15:26:11 fjh, you wanted to discuss TAG issue 15:26:27 TOPIC: new TAG issue 15:26:28 ACTION-73? 15:26:28 ACTION-73 -- Frederick Hirsch to draft a response TAG issue on privacy and policy -- due 2009-12-16 -- PENDINGREVIEW 15:26:28 http://www.w3.org/2009/dap/track/actions/73 15:26:31 http://lists.w3.org/Archives/Public/public-device-apis/2009Dec/0188.html 15:26:38 fjh: I haven't responded to the message yet 15:27:08 … as some may know there was a discussion between geolocaiton and geopriv, about data retention, etc. 15:27:34 … the geolocation spec include statements to that effect, but no mechanism defined. 15:27:44 … disagreement ensued, which escalated to the TAG 15:27:57 q+ 15:28:08 … I'm not sure, but they probably are asking us to include retention policy text in our documents. 15:28:20 … How are we going to work with the tag? 15:28:21 ack jmorris 15:28:51 zakim, who's noisy? 15:28:54 jmorris: I am one of the participants of the geolocation WG. And the cause of some of the controversy 15:29:01 dom, listening for 10 seconds I heard sound from the following: fjh (90%), jmorris (80%) 15:29:07 zakim, mute fjh 15:29:07 fjh should now be muted 15:29:22 […] 15:29:49 … I am scrampbling to get up to speed on the DAP work so I don't yet have suggestion on what to say back to the TAG. 15:30:26 … the history of the geolocation battle is that the IETF developed a geolcation provacy protocol, 8 years ago, where the privacy rules are bound together with the location. 15:30:45 … we have urged the W3C to adopt that aproach, but the WG rejected that approach 15:31:30 q+ to discuss whether "let's not do it about Geo-only" was really the feedback from geolocation 15:31:30 … One of the pushback is that the policy sending should be not just done with geolocation but generally. therefore it's not to be addressed by the geolocation WG 15:31:30 question - how can user privacy information be included in DAP apis without requiring additional user queries? 15:31:37 … in other words: "go talk to DAP" 15:31:45 q+ 15:31:54 q+ to ask the TAG their opinion on the objections from Geolocation WG to including policy in API 15:31:57 ack dom 15:31:58 dom, you wanted to discuss whether "let's not do it about Geo-only" was really the feedback from geolocation and to ask the TAG their opinion on the objections from Geolocation WG 15:32:01 ... to including policy in API 15:32:02 … So we claim that privacy is something that should be sent along with data. 15:32:05 zakim, who is here? 15:32:05 On the phone I see fjh (muted), Suresh, AnssiK, ilkka, darobin (muted), Thomas (muted), Dom, maxf, Claes, jmorris, richt 15:32:07 On IRC I see richt, jmorris, Claes, Suresh, Dzung_Tran, AnssiK, fhirsch, Zakim, RRSAgent, darobin, fjh, tlr, maxf, arve, shepazu, ilkka, dom, trackbot, arg 15:32:21 q? 15:32:51 dom: john, you said that the geolocation WG refused to do it. Some people said that, but others said that the reason would be that it would create confusion with implementers 15:33:00 … that it would also entail complex UIs. 15:33:47 jmorris: yes. Primarily the browser makers are opposed to it, for a host of different reasons. They have no interest in having to manage privacy group. 15:34:14 … but some people participating in the discussion did like the idea, but said it shouldn't just be geolocation but something larger like DAP 15:34:34 zakim, unmute me 15:34:34 sorry, fhirsch, I do not know which phone connection belongs to you 15:34:40 zakim, unmute fjh 15:34:40 fjh should no longer be muted 15:35:17 dom: that has 2 consequences: how does that affect work in DAP. DAP might want to consider sending policy with data 15:36:50 zakim, mute me 15:36:50 Dom should now be muted 15:37:01 … I don't think it makes much sense to have the exact same debate 15:37:30 dom: we should also ask if the TAG has responses to the discussions/objections that the Geolocation WG already had on that topic 15:37:46 ack me 15:37:54 fhirsch: if we do something in DAP, how's that going to apply to geolocation 15:38:14 jmorris: the WG doing geolocation are not envisaging anything more than what's there now. 15:38:34 DAP is the group that has the topic within its charter. 15:39:00 -> http://www.w3.org/2008/geolocation/track/issues/10 Should the Geolocation API methods provide an optional parameter of type URI that allows the location requesting service to advertise a policy (P3P or XACML or some other) that applies to the request? 15:39:27 “The gist of the arguments against the proposal is the following: if the proposal was adopted, the browsers would end up showing the user an interface that appears to be a user-agent enforced privacy preference panel. However, since the privacy information is provided by the website, there is no way for the user-agent to ensure that the claims made by the website are actually true. This could result in the users being mislead by a user-agent prompt. This would brea 15:39:27 k the separation between the user-agent UI (which users trust) and the site content (which users don't necessarily trust) and would therefore undermine the user's trust in the user-agent, with extremely severe consequences for Web security.” http://www.w3.org/2008/geolocation/track/issues/10 15:39:34 …if you look at this more broadly is that the main objection in geolocation is "we've never done it this way, it would confuse users. It's better to read the privacy policy" 15:39:50 … the IETF was trying to change that model, with geopriv 15:40:18 … if DAP were to change the model, if would perhaps put pressure to go back to geolocation and fix it 15:40:45 fhirsch: I see a situation where both parties could be right 15:41:02 … provacy is an important concern, but it can also be complicated and confusing 15:41:10 s/provacy/privacy/ 15:41:42 jmorris: I completely agree. My view is not a simple thing, and I appreciate the evidence of browser makes, but would argue that the IETF approach has strong privacy-protecting defaults. 15:41:57 … so in most cases it would be simple, but others not so. 15:42:04 q+ to note Geolocation WG resolution on that topic 15:42:20 agreed on thinking more broadly than geopriv 15:42:22 fhirsch: we should perhaps not lock ourselves into geopriv for now, but look elsewhere, too 15:43:05 … We're focusing our work on access controls, which is separate. So we don't have requirements for policies. 15:43:47 … so we need something to work with. Any volunteers to write something up about models and requirements, choices, options? 15:43:59 … it could lead to a constructive discussion 15:44:48 ack fh 15:44:54 … meanwhile I will send a response to the TAG saying thanks, it's hard, could you please help us and explain how you reached your decision 15:44:58 ack me 15:44:58 dom, you wanted to note Geolocation WG resolution on that topic 15:45:01 ack dom 15:45:21 q? 15:46:00 I think geolocation focused on using geopriv specifically 15:46:30 fhirsch: maybe dom you could respond. I'll talk to you offline 15:46:38 ACTION: Dom to propose input to TAG response 15:46:38 Created ACTION-76 - Propose input to TAG response [on Dominique Hazaël-Massieux - due 2009-12-23]. 15:46:44 q+ 15:46:57 ack jmorris 15:46:58 Dom: would be useful to ask feedback from the TAG on the Geolocation WG issue resolution 15:48:05 jmorris: to dom, the argument in geolocation was that the browser cannot guarantee that the rules are enforced 15:48:12 … but law can guarantee that. 15:48:53 … So this WG cannot create a mechanism to enforce rules 15:49:13 … but law can penalise anyway 15:49:21 q+ to talk about charter 15:50:03 dom: I think that they idea of providing rules as part of a data is good, but the browser vendor didn't claim it was a problem with complying with the law, but it was something with the browser UI 15:50:21 … which would fool the user into claiming to enforce something they can't 15:50:22 we should correct misperception of TAG that we are necessarily going to address this issue 15:50:53 it will depend on the proposals made by WG participants 15:51:02 ack fhirsch 15:51:02 fhirsch, you wanted to talk about charter 15:51:03 jmorris: I disagree that the user would assume that the browser would ensure their privacy rules 15:51:03 Claes1 has joined #dap 15:51:30 fhirsch: our charter talks about security policy and access controls. Maybe I'm wrong I'm not seeing privacy mentioned. 15:51:48 … I'm not hearing any volunteers to help with it, either. 15:52:25 … so me might not do it, and I want the TAG to understand the actual reasons why we aren't able to do it. 15:52:57 fwiw, many would argue that privacy is a subset of security 15:52:59 … I think privacy is important but we need help to address it, and I'd like the TAG to understand that. 15:53:03 ack thomas 15:53:15 ack Thomas 15:53:38 Thomas: I'm extremely suprised that it says security policy and not privacy policy 15:53:51 dom: probably an omission from the editors 15:53:52 "During Workshop discussions, this specification was frequently cited as a prototypical example for the kinds of security and privacy considerations that are expected in future device APIs." 15:53:54 +1 to "we need editors", btw 15:54:02 darobin, right, that's the one place where we mention it. 15:54:05 zakim, mute me 15:54:05 Thomas should now be muted 15:54:23 dom: is there any chance that john or someone from CDT to take the lead on that? 15:54:23 s/from the editors/from the charter editors/ 15:54:37 jmorris: I'm happy to be deeply involved in that effort 15:55:02 … My efforts will be more productive if there are people not from the same policy background as me. 15:55:37 … I would make the same plea as frederic that we need people to help. 15:55:51 … I'll ne working with Alissa Cooper and we could do it alone, but... 15:56:43 dom: I'm interested, and not an expert. I can't take the lead on this but I'm more than happy to give feedback, establish a roadmap, avoid going into a technical solution first. 15:56:58 q+ 15:57:03 … we need to find the obstacles first and the geo WG would be something to dive into. 15:57:50 fhirsch: dom, it would be helpful to mention in the message to the TAG. John must have some ideas of the requirements, the depth of the importance of some of them, the tradeoff, etc. 15:58:32 … would be good to be made aware of the legal/policy aspects so that we don't do needless tachnical work 15:58:33 ACTION: John to provide a discussion of requirements for privacy 15:58:34 Created ACTION-77 - Provide a discussion of requirements for privacy [on John Morris - due 2009-12-23]. 15:58:54 Claes has joined #dap 15:59:14 jmorris: realistically, the 2nd week in Jan is the earliest. 16:00:28 fhirsch: do we have an extensibility mechanism to allow passing policies? 16:00:42 darobin: there is, in Javascript, but we haven't added anything at this point 16:01:08 … there certainly are technical solutions, and we need to figure out what we need before deciding which. 16:01:14 -Thomas 16:01:17 zakim, mute me 16:01:17 Dom should now be muted 16:01:19 TOPIC: APIs 16:01:21 q? 16:01:27 q- 16:01:27 ack fhirsch 16:01:38 zakim, mute me 16:01:45 sorry, fhirsch, I do not know which phone connection belongs to you 16:01:50 zakim, mute fjh 16:01:50 fjh should now be muted 16:01:53 darobin: let's go over the progress made 16:02:12 -> http://lists.w3.org/Archives/Public/public-device-apis/2009Dec/0193.html Contacts API update 16:02:20 richt: about Contacts, I produced an update in CVS 16:02:25 … base on mailing list feedback 16:02:34 -> http://dev.w3.org/2009/dap/contacts/ Contacts API editors draft 16:02:50 zakim, who is here? 16:02:51 On the phone I see fjh (muted), Suresh, AnssiK, ilkka, darobin, Dom (muted), maxf, Claes, jmorris, richt 16:02:53 … planning to continue updates this week, and call for review on Friday 16:02:54 On IRC I see Claes, Claes1, richt, jmorris, Suresh, Dzung_Tran, AnssiK, fhirsch, Zakim, RRSAgent, darobin, fjh, tlr, maxf, arve, shepazu, ilkka, dom, trackbot, arg 16:03:01 … simplified things a great deal 16:03:20 … based on input by potential implementers like phonegap 16:03:30 q+ 16:03:51 darobin: how close are we to FPWD? 16:04:35 ack Suresh 16:04:36 q+ to say we probably ought to make a Call for Consensus on FPWD publication (for publication probably early Jan) 16:04:38 richt: I think we're reado to go to FPWD. There's still a lot of feedback required, but we have something solid to put forward. 16:05:34 Suresh: I'm very happy with the current version, it's reasonably specified and it'll be useful. 16:06:15 richt: the filtering is perhaps the least stable part of the specification 16:06:31 … there's a current proposal, but it's hard to see where it needs ot go in the short term 16:06:47 richt, I suggest marking the fact that Search is very unstable as an editors note 16:06:53 darobin: what do you think about putting out a call for consensus for publication at the beginning of january? 16:07:01 ack me 16:07:02 dom, you wanted to say we probably ought to make a Call for Consensus on FPWD publication (for publication probably early Jan) 16:07:27 Suresh: ok for me to have FPWD, even including editor's notes. 16:07:39 dom: I support making a call for consensus 16:08:06 … I suggest adding more editor notes, like about the hook where the API hangs off of 16:08:17 richt: I'll put an update on Friday 16:08:36 darobin: that would be listing the issues? 16:08:39 richt: yes 16:09:12 darobin: so I could be pushing a CfC in early january. Takes a week normally, but could take longer because of the holiday 16:09:24 dom: earliest would be January 6 16:09:32 +1 16:09:34 +1 16:09:37 zakim, mute me 16:09:37 Dom should now be muted 16:09:38 +1 16:09:56 richt: FPWD is also to get patent exclusions, right? 16:10:06 darobin: yes, and it's automatic 16:10:18 RESOLUTION: Richard will include changes in Contacts by Friday, Robin to follow up Monday with a CfC for FPWD 16:10:44 Regrets+ Laura_Arribas 16:10:46 darobin: no progress with Calendar... 16:11:04 Suresh: I worked with Richard on that, and we have requirements to submit the the WG 16:11:15 … should be modeled closely after the contacts API 16:11:25 zakim, who is making noise? 16:11:27 darobin: agreed 16:11:36 fhirsch, listening for 10 seconds I heard sound from the following: Suresh (9%), darobin (75%) 16:11:40 … if you could send something soon, it'd be great. 16:11:51 zakim, who is making noise? 16:12:02 fhirsch, listening for 10 seconds I heard sound from the following: darobin (70%) 16:12:12 Will send out an initial list of Calender use cases and requirements later today.. 16:12:13 darobin: next is filesystem/filewriter 16:12:25 -> http://lists.w3.org/Archives/Public/public-device-apis/2009Dec/0171.html File Systems and Directories proposal 16:12:37 … expecting feedback, and i'll update proposal before the end of the week. 16:12:45 -> http://lists.w3.org/Archives/Public/public-device-apis/2009Dec/0113.html Thread on FileWriter 16:13:02 ACTION-74? 16:13:02 ACTION-74 -- Robin Berjon to send an email to list summarising the options for or not in Capture -- due 2009-12-16 -- OPEN 16:13:02 http://www.w3.org/2009/dap/track/actions/74 16:13:04 … next is capture: we need to discuss a bunch of items still. 16:13:18 -> http://lists.w3.org/Archives/Public/public-device-apis/2009Dec/0217.html Hixie's proposal 16:13:19 … in particular the new thing, which we should talk about on the list, still 16:13:24 About Ian's proposal on , what should we do with Capture API? 16:13:44 … people are invited to check the proposal to see if it breaks anything. Do we need a new element, etc. 16:13:55 Zakim, who's here? 16:13:56 On the phone I see fjh (muted), Suresh, AnssiK, ilkka, darobin, Dom (muted), maxf, Claes, jmorris, richt 16:13:59 ACTION-65? 16:13:59 ACTION-65 -- Niklas Widell to provide an editors draft of the Messaging API -- due 2009-12-28 -- OPEN 16:13:59 http://www.w3.org/2009/dap/track/actions/65 16:14:00 On IRC I see Claes, Claes1, richt, jmorris, Suresh, Dzung_Tran, AnssiK, fhirsch, Zakim, RRSAgent, darobin, fjh, tlr, maxf, arve, shepazu, ilkka, dom, trackbot, arg 16:14:08 … messaging: daniel and niklas aren't here, so no input there 16:14:10 (they said end of December for an editors draft) 16:14:43 -> http://lists.w3.org/Archives/Public/public-device-apis/2009Dec/0144.html SysInfo API updates 16:16:55 max: I'll be sending a call for review by the end of the week 16:17:11 darobin: ok, and we can then talk about publish in January 16:17:40 -> http://lists.w3.org/Archives/Public/public-device-apis/2009Dec/0212.html Hanging the APIs off navigator.device 16:17:40 … next topic is the hook for device objects. 16:17:46 … we have 2 proposals 16:17:53 http://www.w3.org/mid/355A518BC0575547B2A3D6773AAF8EEF73A1A0@ftrdmel1 16:18:07 … and it would be useful if people would participate in the thread and express there views. 16:18:16 ISSUE-44? 16:18:16 ISSUE-44 -- What do APIs hang off of? -- RAISED 16:18:16 http://www.w3.org/2009/dap/track/issues/44 16:18:16 I like to keep the "*.device.* concept 16:18:20 … not 2 proposals, 3 proposals 16:18:55 … to me Doug's proposal makes sense, but people should express opinions, ideally before next week. 16:19:59 Suresh: my current opinion is that hanging off device makes our work a bit more visible. And keeps us in control of our work. 16:20:18 one advantage is that the device enables to enumerate its properties 16:20:24 … and let us extend it, and avoid namespace conflicts. 16:20:24 I thought we had this discussion before. We also had a poll and it seems that the concessus was "navigator.device.*" 16:21:20 zakim, unmute fjh 16:21:20 fjh should no longer be muted 16:21:28 darobin: AOB? 16:21:29 one thing on APIs 16:21:30 q+ 16:21:31 Dzung_Tran, the question is on the consistency of that '*' which is currently ambiguous. 16:21:34 (note on risks of clash from hixie: http://lists.w3.org/Archives/Public/public-device-apis/2009Oct/0122.html) 16:21:41 http://lists.w3.org/Archives/Public/public-device-apis/2009Dec/0191.html 16:21:43 ack AnssiK 16:22:13 Anssi: some dojo contributor is along the line of using objects as parameters, as opposed to arguments list. 16:22:17 (Wolfram is indeed a DoJo contributor) 16:22:31 … maybe we shoudl reply to send goodwill to the JS developer community 16:23:17 darobin: it's more than goodwill, but also a coding style. More than 3 parameters, for instance. Or whether it's callbacks, etc. 16:23:40 … I'm not sure how to move it forwards. Would editors be interested in discussing it? 16:24:00 +1 on raising an issue 16:24:10 -Claes 16:24:19 ISSUE: Should we use object literals in place of positional parameters and if so when? 16:24:19 Created ISSUE-55 - Should we use object literals in place of positional parameters and if so when? ; please complete additional details at http://www.w3.org/2009/dap/track/issues/55/edit . 16:24:31 darobin: anything else? 16:24:45 … then call adjourned 16:24:50 … next call: next year 16:24:54 -AnssiK 16:24:56 -Dom 16:24:56 happy holiday all 16:24:57 -ilkka 16:24:58 thanks 16:25:00 -jmorris 16:25:01 -fjh 16:25:03 -darobin 16:25:03 -Suresh 16:25:04 -richt 16:25:07 -maxf 16:25:07 UW_DAP()10:00AM has ended 16:25:07 rrsagent, generate minutes 16:25:07 I have made the request to generate http://www.w3.org/2009/12/16-dap-minutes.html fhirsch 16:25:08 Attendees were fjh, +1.972.373.aaaa, AnssiK, Suresh, ilkka, Thomas, Dom, darobin, maxf, +04610801aabb, Claes, +1.301.581.aacc, jmorris, richt 16:25:32 Zakim, bye 16:25:35 Zakim has left #dap 16:25:35 AnssiK has left #dap 16:27:17 AnssiK has joined #dap 16:28:12 re the Dojo contributor request, it seems to be covered by ISSUE-1 already 16:28:40 should check the issue tracker more carefully .. 16:28:47 http://www.w3.org/2009/dap/track/issues/1 16:31:30 AnssiK: ah well, I think a new issue might make more sense in that the WG has made some mental progress since then 16:35:28 ok fine, I think that Dion's post on Ajaxian on the Capture API exposed the DAP work to the bigger web dev community -- I consider that an extremely good think 16:35:43 yes, it was certainly helpful 16:35:53 though Wolfram was on the list before 16:36:06 at least I'm pretty sure he was, though he may not have been paying attention 16:36:37 we talked about taking Wolfram in as an invited expert at some point, I'm not sure where that went 16:36:51 I don't think wolfram followed up with that 16:37:06 that's quite possible indeed 16:37:29 I wonder if we should also invite Peter Ussuri 16:37:42 RRSAgent, stop loggin 16:37:42 I'm logging. I don't understand 'stop loggin', darobin. Try /msg RRSAgent help 16:37:44 RRSAgent, stop logging 16:37:44 I'm logging. I don't understand 'stop logging', darobin. Try /msg RRSAgent help 16:37:48 RRSAgent, stop