IRC log of dap on 2009-12-16

Timestamps are in UTC.

14:27:39 [RRSAgent]
RRSAgent has joined #dap
14:27:39 [RRSAgent]
logging to
14:27:41 [trackbot]
RRSAgent, make logs world
14:27:41 [Zakim]
Zakim has joined #dap
14:27:43 [trackbot]
Zakim, this will be DAP
14:27:43 [Zakim]
ok, trackbot; I see UW_DAP()10:00AM scheduled to start in 33 minutes
14:27:44 [trackbot]
Meeting: Device APIs and Policy Working Group Teleconference
14:27:44 [trackbot]
Date: 16 December 2009
14:27:53 [dom]
14:29:54 [fjh]
Chair: Robin_Berjon, Frederick_Hirsch
14:30:03 [fjh]
Present: Robin_Berjon, Frederick_Hirsch
14:30:56 [fjh]
Regrets: Paddy_Byers, Marcin Hanclik, Marengo Marco
14:36:14 [fhirsch]
fhirsch has joined #dap
14:46:18 [AnssiK]
AnssiK has joined #dap
14:48:33 [Dzung_Tran]
Dzung_Tran has joined #dap
14:48:43 [Dzung_Tran]
Present+ Dzung_Tran
14:56:26 [Zakim]
UW_DAP()10:00AM has now started
14:56:33 [Zakim]
14:56:40 [fhirsch]
zakim, [IPcaller] is fjh
14:56:40 [Zakim]
+fjh; got it
14:57:32 [Suresh]
Suresh has joined #dap
14:57:38 [ilkka]
Present+ Ilkka_Oksanen
14:58:21 [Zakim]
+ +1.972.373.aaaa
14:59:15 [Suresh]
Present+ Suresh_Chitturi
14:59:41 [Zakim]
14:59:47 [AnssiK]
Present+ Anssi_Kostiainen
14:59:53 [fhirsch]
zakim, aaaa is Suresh
14:59:53 [Zakim]
+Suresh; got it
15:00:43 [Suresh]
zakim, aaa is Suresh
15:00:43 [Zakim]
sorry, Suresh, I do not recognize a party named 'aaa'
15:01:04 [Zakim]
15:01:47 [Zakim]
15:01:49 [tlr]
zakim, call thomas-781
15:01:49 [Zakim]
ok, tlr; the call is being made
15:01:50 [Claes]
Claes has joined #dap
15:01:50 [Zakim]
15:01:55 [tlr]
zakim, I am thomas
15:01:55 [Zakim]
ok, tlr, I now associate you with Thomas
15:01:57 [Zakim]
15:01:57 [tlr]
zakim, mute me
15:01:59 [Zakim]
Thomas should now be muted
15:02:04 [dom]
zakim, mute me
15:02:04 [Zakim]
Dom should now be muted
15:02:23 [dom]
Present+ Dominique_Hazael_Massieux
15:02:36 [darobin]
Present+ Robin_Berjon
15:02:48 [Zakim]
15:02:56 [maxf]
Present+ Max_Froumentin
15:03:59 [Zakim]
+ +04610801aabb
15:04:20 [dom]
zakim, aabb is Claes
15:04:20 [Zakim]
+Claes; got it
15:04:32 [Claes]
Present+ Claes_Nilsson
15:04:51 [maxf]
Scribe: maxf
15:05:06 [maxf]
ScribeNick: maxf
15:05:30 [fhirsch]
Next meeting is 6 January 2010
15:05:42 [fhirsch]
Mobile Security barcamp - 19th January 2010, Sophia Antipolis
15:06:03 [fhirsch]
15:06:12 [maxf]
Topic: Administration
15:06:25 [dom]
-> Mobile Security Barcamp in Sophia, January 19
15:06:51 [maxf]
Topic: Minutes approval
15:07:02 [jmorris]
jmorris has joined #dap
15:07:03 [maxf]
fjh: approval?
15:07:07 [fhirsch]
15:07:14 [maxf]
no objection
15:07:23 [maxf]
RESOLUTION: minutes from 9 dec approved
15:07:33 [maxf]
TOPIC: policy
15:07:37 [jmorris]
Present+ John_Morris
15:07:44 [fhirsch]
15:07:44 [trackbot]
ACTION-63 -- Laura Arribas to review -- due 2009-11-25 -- OPEN
15:07:44 [trackbot]
15:07:59 [maxf]
fjh: action 63 is deferred until Laura is back
15:08:12 [Zakim]
+ +1.301.581.aacc
15:08:16 [fhirsch]
File granularity access policy, Secure Cred Manager
15:08:32 [fhirsch]
15:08:35 [maxf]
fjh: Klaus you sent a proposal?
15:08:55 [maxf]
15:08:56 [jmorris]
zakim, aacc is jmorris
15:08:57 [Zakim]
+jmorris; got it
15:09:18 [maxf]
claes: typical uses case is storing keys for social web applications
15:09:31 [fhirsch]
I may have some comments on Secure Cred Manager later, but believe this is for future work
15:09:35 [maxf]
… there's a problem today about where to store those keys
15:09:47 [maxf]
… so I propose a JS api to store those keys on the device.
15:10:10 [maxf]
… 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 [fhirsch]
q+ to ask what an application is
15:10:34 [maxf]
… the conclusion was that taking the proposal from Steve is a good starts and that I should build from that
15:10:55 [maxf]
… restraining certain parts of the API to certain applications.
15:10:56 [Suresh]
15:11:13 [fhirsch]
ack fhirsch
15:11:13 [Zakim]
fhirsch, you wanted to ask what an application is
15:11:20 [maxf]
… the main use case is allowing an application to access this application's data through that API
15:11:49 [maxf]
… 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 [maxf]
… which restricts what you get out of that API
15:12:58 [maxf]
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 [maxf]
… 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 [maxf]
… my inclination is to sibject it should be future work, cause it requires more thought
15:14:06 [maxf]
… we might want to figure out the extensibility model.
15:14:30 [maxf]
Claes: I think that my credential manager is more realistically put into future work
15:14:51 [maxf]
… but a possibility to have a granularity of applications should be in this version of the specification.
15:15:09 [maxf]
… I'll reply to your questions on how to secure identified aplications, on the mailing list.
15:15:38 [maxf]
… we can just consider the possibility of having the granularity of application IDs in this version.
15:15:54 [maxf]
fhirsch: I'd like to make a decision today about the future work, if that's ok.
15:16:12 [maxf]
… about the application ID, I'd like to understand how it work in the various use cases.
15:16:26 [maxf]
Claes: I can reply to that and elaborate a little more on the mailing list.
15:16:31 [fhirsch]
ack suresh
15:16:54 [fhirsch]
q+ to ask for resolution re security credential manager for future work
15:16:55 [maxf]
Suresh: I'd like to echo fhirsch's comment on the secure credential manager
15:17:16 [maxf]
… I don't know if it's a deviceAPI-specific problem or a secure storage problem.
15:17:31 [maxf]
… so I would recommend talking to the web/offline storage guys
15:17:48 [maxf]
… Can you clarify what the proposal in terms of granulatiry?
15:18:07 [maxf]
… seems that it's used when evaluating the policy framework, is that right?
15:18:33 [maxf]
… it might be relevant to the WARP spec, something we discussed in the widgets group.
15:18:33 [fhirsch]
15:18:53 [fjh]
q+ to discuss TAG issue
15:19:06 [darobin]
q+ about WARP
15:19:22 [darobin]
ack about
15:19:23 [maxf]
Claes: I will consider this. I thought it would be part of the policy framework...
15:19:26 [darobin]
ack warp
15:19:36 [darobin]
q+ to talk about WARP
15:19:36 [maxf]
… and I also think it shouldn't be restricted to widgets, like the WARP specification
15:19:47 [maxf]
… I'll think about it and come back.
15:19:52 [darobin]
ack me
15:19:52 [fhirsch]
ack darobin
15:19:53 [Zakim]
darobin, you wanted to talk about WARP
15:20:34 [maxf]
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 [maxf]
… this may mean it should included in DAP and this WG could take over WARP
15:20:53 [Suresh]
15:21:04 [fhirsch]
ack Suresh
15:21:35 [maxf]
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 [maxf]
fhirsch: my question too.
15:22:17 [Suresh]
15:22:26 [maxf]
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 [maxf]
… I'm extending that concept to applications within a domain
15:23:25 [maxf]
… The application is sort of a finer granularity
15:23:26 [Zakim]
15:23:38 [Suresh]
sounds like the apporach BONDI has taken?
15:23:43 [richt]
richt has joined #dap
15:23:46 [maxf]
fjh: we're verging into the management aspects
15:23:53 [richt]
Present+ Richard_Tibbett
15:24:30 [maxf]
… 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 [maxf]
… just need to see more use cases.
15:24:46 [maxf]
… hard to tell what's going on right now.
15:25:15 [maxf]
Claes: I will elaborate on the mailing list.
15:25:25 [fhirsch]
15:25:28 [fhirsch]
ack fhirsch
15:25:28 [Zakim]
fhirsch, you wanted to ask for resolution re security credential manager for future work
15:26:03 [maxf]
RESOLUTION: security credential manager proposal is a possible item for future work.
15:26:11 [fhirsch]
ack fjh
15:26:11 [Zakim]
fjh, you wanted to discuss TAG issue
15:26:27 [maxf]
TOPIC: new TAG issue
15:26:28 [dom]
15:26:28 [trackbot]
ACTION-73 -- Frederick Hirsch to draft a response TAG issue on privacy and policy -- due 2009-12-16 -- PENDINGREVIEW
15:26:28 [trackbot]
15:26:31 [fhirsch]
15:26:38 [maxf]
fjh: I haven't responded to the message yet
15:27:08 [maxf]
… as some may know there was a discussion between geolocaiton and geopriv, about data retention, etc.
15:27:34 [maxf]
… the geolocation spec include statements to that effect, but no mechanism defined.
15:27:44 [maxf]
… disagreement ensued, which escalated to the TAG
15:27:57 [jmorris]
15:28:08 [maxf]
… I'm not sure, but they probably are asking us to include retention policy text in our documents.
15:28:20 [maxf]
… How are we going to work with the tag?
15:28:21 [fhirsch]
ack jmorris
15:28:51 [dom]
zakim, who's noisy?
15:28:54 [maxf]
jmorris: I am one of the participants of the geolocation WG. And the cause of some of the controversy
15:29:01 [Zakim]
dom, listening for 10 seconds I heard sound from the following: fjh (90%), jmorris (80%)
15:29:07 [dom]
zakim, mute fjh
15:29:07 [Zakim]
fjh should now be muted
15:29:22 [maxf]
15:29:49 [maxf]
… 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 [maxf]
… 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 [maxf]
… we have urged the W3C to adopt that aproach, but the WG rejected that approach
15:31:30 [dom]
q+ to discuss whether "let's not do it about Geo-only" was really the feedback from geolocation
15:31:30 [maxf]
… 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 [fhirsch]
question - how can user privacy information be included in DAP apis without requiring additional user queries?
15:31:37 [maxf]
… in other words: "go talk to DAP"
15:31:45 [fhirsch]
15:31:54 [dom]
q+ to ask the TAG their opinion on the objections from Geolocation WG to including policy in API
15:31:57 [fhirsch]
ack dom
15:31:58 [Zakim]
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 [Zakim]
... to including policy in API
15:32:02 [maxf]
… So we claim that privacy is something that should be sent along with data.
15:32:05 [fhirsch]
zakim, who is here?
15:32:05 [Zakim]
On the phone I see fjh (muted), Suresh, AnssiK, ilkka, darobin (muted), Thomas (muted), Dom, maxf, Claes, jmorris, richt
15:32:07 [Zakim]
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 [fhirsch]
15:32:51 [maxf]
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 [maxf]
… that it would also entail complex UIs.
15:33:47 [maxf]
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 [maxf]
… 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 [fhirsch]
zakim, unmute me
15:34:34 [Zakim]
sorry, fhirsch, I do not know which phone connection belongs to you
15:34:40 [fhirsch]
zakim, unmute fjh
15:34:40 [Zakim]
fjh should no longer be muted
15:35:17 [maxf]
dom: that has 2 consequences: how does that affect work in DAP. DAP might want to consider sending policy with data
15:36:50 [dom]
zakim, mute me
15:36:50 [Zakim]
Dom should now be muted
15:37:01 [maxf]
… I don't think it makes much sense to have the exact same debate
15:37:30 [dom]
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 [dom]
ack me
15:37:54 [maxf]
fhirsch: if we do something in DAP, how's that going to apply to geolocation
15:38:14 [maxf]
jmorris: the WG doing geolocation are not envisaging anything more than what's there now.
15:38:34 [tlr]
DAP is the group that has the topic within its charter.
15:39:00 [dom]
-> 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 [dom]
“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 [dom]
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.”
15:39:34 [maxf]
…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 [maxf]
… the IETF was trying to change that model, with geopriv
15:40:18 [maxf]
… if DAP were to change the model, if would perhaps put pressure to go back to geolocation and fix it
15:40:45 [maxf]
fhirsch: I see a situation where both parties could be right
15:41:02 [maxf]
… provacy is an important concern, but it can also be complicated and confusing
15:41:10 [dom]
15:41:42 [maxf]
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 [maxf]
… so in most cases it would be simple, but others not so.
15:42:04 [dom]
q+ to note Geolocation WG resolution on that topic
15:42:20 [jmorris]
agreed on thinking more broadly than geopriv
15:42:22 [maxf]
fhirsch: we should perhaps not lock ourselves into geopriv for now, but look elsewhere, too
15:43:05 [maxf]
… We're focusing our work on access controls, which is separate. So we don't have requirements for policies.
15:43:47 [maxf]
… so we need something to work with. Any volunteers to write something up about models and requirements, choices, options?
15:43:59 [maxf]
… it could lead to a constructive discussion
15:44:48 [dom]
ack fh
15:44:54 [maxf]
… 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 [dom]
ack me
15:44:58 [Zakim]
dom, you wanted to note Geolocation WG resolution on that topic
15:45:01 [fhirsch]
ack dom
15:45:21 [fhirsch]
15:46:00 [fhirsch]
I think geolocation focused on using geopriv specifically
15:46:30 [maxf]
fhirsch: maybe dom you could respond. I'll talk to you offline
15:46:38 [dom]
ACTION: Dom to propose input to TAG response
15:46:38 [trackbot]
Created ACTION-76 - Propose input to TAG response [on Dominique Hazaël-Massieux - due 2009-12-23].
15:46:44 [jmorris]
15:46:57 [fhirsch]
ack jmorris
15:46:58 [dom]
Dom: would be useful to ask feedback from the TAG on the Geolocation WG issue resolution
15:48:05 [maxf]
jmorris: to dom, the argument in geolocation was that the browser cannot guarantee that the rules are enforced
15:48:12 [maxf]
… but law can guarantee that.
15:48:53 [maxf]
… So this WG cannot create a mechanism to enforce rules
15:49:13 [maxf]
… but law can penalise anyway
15:49:21 [fhirsch]
q+ to talk about charter
15:50:03 [maxf]
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 [maxf]
… which would fool the user into claiming to enforce something they can't
15:50:22 [fhirsch]
we should correct misperception of TAG that we are necessarily going to address this issue
15:50:53 [fhirsch]
it will depend on the proposals made by WG participants
15:51:02 [fhirsch]
ack fhirsch
15:51:02 [Zakim]
fhirsch, you wanted to talk about charter
15:51:03 [maxf]
jmorris: I disagree that the user would assume that the browser would ensure their privacy rules
15:51:03 [Claes1]
Claes1 has joined #dap
15:51:30 [maxf]
fhirsch: our charter talks about security policy and access controls. Maybe I'm wrong I'm not seeing privacy mentioned.
15:51:48 [maxf]
… I'm not hearing any volunteers to help with it, either.
15:52:25 [maxf]
… 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 [jmorris]
fwiw, many would argue that privacy is a subset of security
15:52:59 [maxf]
… I think privacy is important but we need help to address it, and I'd like the TAG to understand that.
15:53:03 [tlr]
ack thomas
15:53:15 [fhirsch]
ack Thomas
15:53:38 [maxf]
Thomas: I'm extremely suprised that it says security policy and not privacy policy
15:53:51 [maxf]
dom: probably an omission from the editors
15:53:52 [darobin]
"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 [tlr]
+1 to "we need editors", btw
15:54:02 [tlr]
darobin, right, that's the one place where we mention it.
15:54:05 [tlr]
zakim, mute me
15:54:05 [Zakim]
Thomas should now be muted
15:54:23 [maxf]
dom: is there any chance that john or someone from CDT to take the lead on that?
15:54:23 [dom]
s/from the editors/from the charter editors/
15:54:37 [maxf]
jmorris: I'm happy to be deeply involved in that effort
15:55:02 [maxf]
… My efforts will be more productive if there are people not from the same policy background as me.
15:55:37 [maxf]
… I would make the same plea as frederic that we need people to help.
15:55:51 [maxf]
… I'll ne working with Alissa Cooper and we could do it alone, but...
15:56:43 [maxf]
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 [fhirsch]
15:57:03 [maxf]
… we need to find the obstacles first and the geo WG would be something to dive into.
15:57:50 [maxf]
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 [maxf]
… would be good to be made aware of the legal/policy aspects so that we don't do needless tachnical work
15:58:33 [dom]
ACTION: John to provide a discussion of requirements for privacy
15:58:34 [trackbot]
Created ACTION-77 - Provide a discussion of requirements for privacy [on John Morris - due 2009-12-23].
15:58:54 [Claes]
Claes has joined #dap
15:59:14 [maxf]
jmorris: realistically, the 2nd week in Jan is the earliest.
16:00:28 [maxf]
fhirsch: do we have an extensibility mechanism to allow passing policies?
16:00:42 [maxf]
darobin: there is, in Javascript, but we haven't added anything at this point
16:01:08 [maxf]
… there certainly are technical solutions, and we need to figure out what we need before deciding which.
16:01:14 [Zakim]
16:01:17 [dom]
zakim, mute me
16:01:17 [Zakim]
Dom should now be muted
16:01:19 [maxf]
16:01:21 [darobin]
16:01:27 [fhirsch]
16:01:27 [darobin]
ack fhirsch
16:01:38 [fhirsch]
zakim, mute me
16:01:45 [Zakim]
sorry, fhirsch, I do not know which phone connection belongs to you
16:01:50 [fhirsch]
zakim, mute fjh
16:01:50 [Zakim]
fjh should now be muted
16:01:53 [maxf]
darobin: let's go over the progress made
16:02:12 [dom]
-> Contacts API update
16:02:20 [maxf]
richt: about Contacts, I produced an update in CVS
16:02:25 [maxf]
… base on mailing list feedback
16:02:34 [dom]
-> Contacts API editors draft
16:02:50 [fjh]
zakim, who is here?
16:02:51 [Zakim]
On the phone I see fjh (muted), Suresh, AnssiK, ilkka, darobin, Dom (muted), maxf, Claes, jmorris, richt
16:02:53 [maxf]
… planning to continue updates this week, and call for review on Friday
16:02:54 [Zakim]
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 [maxf]
… simplified things a great deal
16:03:20 [maxf]
… based on input by potential implementers like phonegap
16:03:30 [Suresh]
16:03:51 [maxf]
darobin: how close are we to FPWD?
16:04:35 [darobin]
ack Suresh
16:04:36 [dom]
q+ to say we probably ought to make a Call for Consensus on FPWD publication (for publication probably early Jan)
16:04:38 [maxf]
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 [maxf]
Suresh: I'm very happy with the current version, it's reasonably specified and it'll be useful.
16:06:15 [maxf]
richt: the filtering is perhaps the least stable part of the specification
16:06:31 [maxf]
… there's a current proposal, but it's hard to see where it needs ot go in the short term
16:06:47 [dom]
richt, I suggest marking the fact that Search is very unstable as an editors note
16:06:53 [maxf]
darobin: what do you think about putting out a call for consensus for publication at the beginning of january?
16:07:01 [dom]
ack me
16:07:02 [Zakim]
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 [maxf]
Suresh: ok for me to have FPWD, even including editor's notes.
16:07:39 [maxf]
dom: I support making a call for consensus
16:08:06 [maxf]
… I suggest adding more editor notes, like about the hook where the API hangs off of
16:08:17 [maxf]
richt: I'll put an update on Friday
16:08:36 [maxf]
darobin: that would be listing the issues?
16:08:39 [maxf]
richt: yes
16:09:12 [maxf]
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 [maxf]
dom: earliest would be January 6
16:09:32 [dom]
16:09:34 [Suresh]
16:09:37 [dom]
zakim, mute me
16:09:37 [Zakim]
Dom should now be muted
16:09:38 [AnssiK]
16:09:56 [maxf]
richt: FPWD is also to get patent exclusions, right?
16:10:06 [maxf]
darobin: yes, and it's automatic
16:10:18 [darobin]
RESOLUTION: Richard will include changes in Contacts by Friday, Robin to follow up Monday with a CfC for FPWD
16:10:44 [fjh]
Regrets+ Laura_Arribas
16:10:46 [maxf]
darobin: no progress with Calendar...
16:11:04 [maxf]
Suresh: I worked with Richard on that, and we have requirements to submit the the WG
16:11:15 [maxf]
… should be modeled closely after the contacts API
16:11:25 [fhirsch]
zakim, who is making noise?
16:11:27 [maxf]
darobin: agreed
16:11:36 [Zakim]
fhirsch, listening for 10 seconds I heard sound from the following: Suresh (9%), darobin (75%)
16:11:40 [maxf]
… if you could send something soon, it'd be great.
16:11:51 [fhirsch]
zakim, who is making noise?
16:12:02 [Zakim]
fhirsch, listening for 10 seconds I heard sound from the following: darobin (70%)
16:12:12 [Suresh]
Will send out an initial list of Calender use cases and requirements later today..
16:12:13 [maxf]
darobin: next is filesystem/filewriter
16:12:25 [dom]
-> File Systems and Directories proposal
16:12:37 [maxf]
… expecting feedback, and i'll update proposal before the end of the week.
16:12:45 [dom]
-> Thread on FileWriter
16:13:02 [dom]
16:13:02 [trackbot]
ACTION-74 -- Robin Berjon to send an email to list summarising the options for <input> or not in Capture -- due 2009-12-16 -- OPEN
16:13:02 [trackbot]
16:13:04 [maxf]
… next is capture: we need to discuss a bunch of items still.
16:13:18 [dom]
-> Hixie's <device> proposal
16:13:19 [maxf]
… in particular the new <device> thing, which we should talk about on the list, still
16:13:24 [Dzung_Tran]
About Ian's proposal on <device>, what should we do with Capture API?
16:13:44 [maxf]
… people are invited to check the proposal to see if it breaks anything. Do we need a new element, etc.
16:13:55 [darobin]
Zakim, who's here?
16:13:56 [Zakim]
On the phone I see fjh (muted), Suresh, AnssiK, ilkka, darobin, Dom (muted), maxf, Claes, jmorris, richt
16:13:59 [dom]
16:13:59 [trackbot]
ACTION-65 -- Niklas Widell to provide an editors draft of the Messaging API -- due 2009-12-28 -- OPEN
16:13:59 [trackbot]
16:14:00 [Zakim]
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 [maxf]
… messaging: daniel and niklas aren't here, so no input there
16:14:10 [dom]
(they said end of December for an editors draft)
16:14:43 [dom]
-> SysInfo API updates
16:16:55 [maxf]
max: I'll be sending a call for review by the end of the week
16:17:11 [maxf]
darobin: ok, and we can then talk about publish in January
16:17:40 [dom]
-> Hanging the APIs off navigator.device
16:17:40 [maxf]
… next topic is the hook for device objects.
16:17:46 [maxf]
… we have 2 proposals
16:17:53 [darobin]
16:18:07 [maxf]
… and it would be useful if people would participate in the thread and express there views.
16:18:16 [dom]
16:18:16 [trackbot]
ISSUE-44 -- What do APIs hang off of? -- RAISED
16:18:16 [trackbot]
16:18:16 [Suresh]
I like to keep the "*.device.* concept
16:18:20 [maxf]
… not 2 proposals, 3 proposals
16:18:55 [maxf]
… to me Doug's proposal makes sense, but people should express opinions, ideally before next week.
16:19:59 [maxf]
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 [AnssiK]
one advantage is that the device enables to enumerate its properties
16:20:24 [maxf]
… and let us extend it, and avoid namespace conflicts.
16:20:24 [Dzung_Tran]
I thought we had this discussion before. We also had a poll and it seems that the concessus was "navigator.device.*"
16:21:20 [fhirsch]
zakim, unmute fjh
16:21:20 [Zakim]
fjh should no longer be muted
16:21:28 [maxf]
darobin: AOB?
16:21:29 [AnssiK]
one thing on APIs
16:21:30 [AnssiK]
16:21:31 [richt]
Dzung_Tran, the question is on the consistency of that '*' which is currently ambiguous.
16:21:34 [dom]
(note on risks of clash from hixie:
16:21:41 [AnssiK]
16:21:43 [darobin]
ack AnssiK
16:22:13 [maxf]
Anssi: some dojo contributor is along the line of using objects as parameters, as opposed to arguments list.
16:22:17 [dom]
(Wolfram is indeed a DoJo contributor)
16:22:31 [maxf]
… maybe we shoudl reply to send goodwill to the JS developer community
16:23:17 [maxf]
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 [maxf]
… I'm not sure how to move it forwards. Would editors be interested in discussing it?
16:24:00 [dom]
+1 on raising an issue
16:24:10 [Zakim]
16:24:19 [darobin]
ISSUE: Should we use object literals in place of positional parameters and if so when?
16:24:19 [trackbot]
Created ISSUE-55 - Should we use object literals in place of positional parameters and if so when? ; please complete additional details at .
16:24:31 [maxf]
darobin: anything else?
16:24:45 [maxf]
… then call adjourned
16:24:50 [maxf]
… next call: next year
16:24:54 [Zakim]
16:24:56 [Zakim]
16:24:56 [Suresh]
happy holiday all
16:24:57 [Zakim]
16:24:58 [richt]
16:25:00 [Zakim]
16:25:01 [Zakim]
16:25:03 [Zakim]
16:25:03 [Zakim]
16:25:04 [Zakim]
16:25:07 [Zakim]
16:25:07 [Zakim]
UW_DAP()10:00AM has ended
16:25:07 [fhirsch]
rrsagent, generate minutes
16:25:07 [RRSAgent]
I have made the request to generate fhirsch
16:25:08 [Zakim]
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 [dom]
Zakim, bye
16:25:35 [Zakim]
Zakim has left #dap
16:25:35 [AnssiK]
AnssiK has left #dap
16:27:17 [AnssiK]
AnssiK has joined #dap
16:28:12 [AnssiK]
re the Dojo contributor request, it seems to be covered by ISSUE-1 already
16:28:40 [AnssiK]
should check the issue tracker more carefully ..
16:28:47 [AnssiK]
16:31:30 [darobin]
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 [AnssiK]
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 [darobin]
yes, it was certainly helpful
16:35:53 [darobin]
though Wolfram was on the list before
16:36:06 [darobin]
at least I'm pretty sure he was, though he may not have been paying attention
16:36:37 [darobin]
we talked about taking Wolfram in as an invited expert at some point, I'm not sure where that went
16:36:51 [dom]
I don't think wolfram followed up with that
16:37:06 [darobin]
that's quite possible indeed
16:37:29 [darobin]
I wonder if we should also invite Peter Ussuri
16:37:42 [darobin]
RRSAgent, stop loggin
16:37:42 [RRSAgent]
I'm logging. I don't understand 'stop loggin', darobin. Try /msg RRSAgent help
16:37:44 [darobin]
RRSAgent, stop logging
16:37:44 [RRSAgent]
I'm logging. I don't understand 'stop logging', darobin. Try /msg RRSAgent help
16:37:48 [darobin]
RRSAgent, stop