13:46:11 RRSAgent has joined #dap 13:46:11 logging to http://www.w3.org/2010/04/28-dap-irc 13:46:13 RRSAgent, make logs world 13:46:13 Zakim has joined #dap 13:46:15 Zakim, this will be DAP 13:46:15 ok, trackbot; I see UW_DAP()10:00AM scheduled to start in 14 minutes 13:46:16 Meeting: Device APIs and Policy Working Group Teleconference 13:46:16 Date: 28 April 2010 13:46:26 Regrets: John_Morris 13:46:37 Chair: Robin_Berjon, Frederick_Hirsch 13:46:46 Present: Robin_Berjon, Frederick_Hirsch 13:47:28 Agenda: http://lists.w3.org/Archives/Public/public-device-apis/2010Apr/0093.html 13:48:56 Regrets+ WonSuk Lee 13:49:15 Regrets- WonSuk Lee 13:49:25 Regrets+ WonSuk_Lee 13:54:26 ericanewland has joined #dap 13:55:32 UW_DAP()10:00AM has now started 13:55:39 +alissa 13:55:52 Suresh has joined #dap 13:56:54 marengo has joined #dap 13:57:35 alissa has joined #dap 13:57:39 zakim, alissa is enewland 13:57:42 +enewland; got it 13:59:07 AnssiK has joined #dap 13:59:10 +??P0 13:59:17 zakim, ??P0 is me 13:59:17 +fjh; got it 13:59:27 LauraA has joined #dap 13:59:29 Present+ Erica_Newland 13:59:34 zakim, who is here? 13:59:34 On the phone I see enewland, fjh 13:59:35 On IRC I see LauraA, AnssiK, alissa, marengo, Suresh, ericanewland, Zakim, RRSAgent, Marcos, darobin, maxf, arve, fjh, ingmar, ilkka, lgombos, dom, trackbot 13:59:46 +AnssiK 13:59:48 Present+ LauraA 13:59:53 + +1.202.436.aaaa 13:59:56 Present+ Anssi_Kostiainen 14:00:01 Present+ Alissa_Cooper 14:00:02 +??P1 14:00:18 drogersuk has joined #dap 14:00:27 present+ David_Rogers 14:00:43 +Dom 14:00:43 +ilkka 14:00:53 Present+ Dominique_Hazael-Massieux 14:00:55 zakim, who is making noise? 14:00:55 zakim, mute me 14:00:55 Dom should now be muted 14:00:57 +suresh 14:01:05 fjh, listening for 10 seconds I heard sound from the following: fjh (34%), ??P6 (7%) 14:01:14 zakim, who is here? 14:01:14 On the phone I see enewland, fjh, AnssiK, +1.202.436.aaaa, ??P1, Dom (muted), ilkka, suresh 14:01:14 Present+ Ilkka_Oksanen 14:01:17 On IRC I see drogersuk, LauraA, AnssiK, alissa, marengo, Suresh, enewland, Zakim, RRSAgent, Marcos, darobin, maxf, arve, fjh, ingmar, ilkka, lgombos, dom, trackbot 14:01:19 +darobin 14:01:32 Present+ Suresh_Chitturi 14:02:30 + +0777541aabb 14:02:30 zakim, +1.202.436.aaaa is alissa 14:02:31 +alissa; got it 14:02:54 zakim, who is here? 14:02:54 On the phone I see enewland, fjh, AnssiK, alissa, ??P1, Dom (muted), ilkka, suresh, darobin, +0777541aabb 14:02:57 On IRC I see drogersuk, LauraA, AnssiK, alissa, marengo, Suresh, enewland, Zakim, RRSAgent, Marcos, darobin, maxf, arve, fjh, ingmar, ilkka, lgombos, dom, trackbot 14:03:01 + +1.425.214.aacc 14:03:17 zakim, +07775441aabb is LauraA 14:03:17 sorry, LauraA, I do not recognize a party named '+07775441aabb' 14:03:18 zakim, aacc is Bryan 14:03:19 +Bryan; got it 14:03:32 zakim, +0777541aabb is LauraA 14:03:32 +LauraA; got it 14:03:39 zakim, ??P1 is drogers 14:03:39 +drogers; got it 14:03:41 Claes has joined #dap 14:03:43 zakim, who is here? 14:03:43 On the phone I see enewland, fjh, AnssiK, alissa, drogers, Dom (muted), ilkka, suresh, darobin, LauraA, Bryan 14:03:45 On IRC I see Claes, drogersuk, LauraA, AnssiK, alissa, marengo, Suresh, enewland, Zakim, RRSAgent, Marcos, darobin, maxf, arve, fjh, ingmar, ilkka, lgombos, dom, trackbot 14:03:58 Present+ Claes_Nilsson 14:04:35 ok 14:04:49 nwidell has joined #dap 14:04:53 scribenick: alissa 14:05:11 topic: Admin 14:05:27 Privacy workshop, Mon/Tue 12-13 July 2010, London 14:05:27 Privacy workshop, Mon/Tue 12-13 July 2010, London 14:05:32 +Claes 14:05:41 http://www.w3.org/2010/api-privacy-ws/ 14:06:06 fjh: our F2F is now starting Weds, July 14 14:06:11 maoteo has joined #dap 14:06:13 +[T-Systems] 14:06:29 + +39.011.228.aadd 14:06:34 Present+ Niklas_Widell 14:06:42 drogersuk: OMTP is flexible with hosting 14:06:44 Zakim, aadd is me 14:06:44 +marengo; got it 14:06:49 Zakim, mute me 14:06:49 marengo should now be muted 14:06:54 http://www.ceop.gov.uk/ 14:07:06 ... also arranging a visit to CEOP one evening of F2F 14:07:08 present+ Maria_Oteo 14:07:08 Present+ Marco_Marengo 14:07:09 (will be IRC only first 30 minutes of this call 14:07:47 potentially we could setup two separate visits, but these will not infringe directly on the meetings - they would be after 14:08:05 frederick: not sure if we should have a 2 or 3 days meeting 14:08:23 -alissa 14:08:26 ... probably won't need to discuss privacy given that we'll have discussed it for two days during the workshop before 14:08:31 Bryan: I suggest going for 3 days 14:08:39 ... our F2F meetings are fairly productive 14:08:48 personally I'm not avail for Fri 14:08:51 Robin: suggests 2.5 days to allow for people to leave early on Friday 14:08:57 + +34.68.697.aaee 14:09:06 +alissa 14:09:10 present+ Ingmar_Kliche 14:09:15 ... re privacy, I'm hoping we'll get new input from the workshop that will be worth processing 14:09:27 Frederick: does anybody have a problem with 2.5 days? 14:09:52 David: we can accommodate for that one way or another re hosting 14:10:57 i/frederick:/ScribeNick: dom/ 14:11:10 RESOLUTION: Next F2F on July 14 to 16 in London 14:11:11 does it end at 12:00noon on the 3rd day? 14:11:43 RESOLUTION: Next F2F on July 14 to 16 in London, ending at 2 or 3pm on Friday 14:11:56 RRSAgent, draft minutes 14:11:56 I have made the request to generate http://www.w3.org/2010/04/28-dap-minutes.html dom 14:12:18 rrsagent, where am i? 14:12:18 See http://www.w3.org/2010/04/28-dap-irc#T14-12-18 14:12:55 frederick: our hosts will need to look into lunch & logistics 14:13:18 (note that attendance at the workshop requires sending a position paper) 14:13:31 Topic: Minutes approval 14:13:35 http://lists.w3.org/Archives/Public/public-device-apis/2010Apr/att-0080/minutes-2010-04-21.html 14:13:43 21 April 2010 14:13:50 RESOLUTION: Minutes of April 21st approved 14:13:59 alissa has joined #dap 14:14:06 ScribeNick: alissa 14:14:14 sorry my Internet crapped out 14:14:33 Policy requirements and framework 14:14:50 http://dev.w3.org/2009/dap/policy-reqs/ 14:15:07 action: fjh to review policy requirements and propose changes 14:15:07 Created ACTION-166 - Review policy requirements and propose changes [on Frederick Hirsch - due 2010-05-05]. 14:15:11 soonho has joined #dap 14:15:19 http://dev.w3.org/2009/dap/policy/ 14:15:24 will resume scribing now 14:15:48 layering model considerations can move to requirements doc? 14:16:07 fjh: Laura still needs to add trust domain stuff from Nokia 14:16:37 Laura: still working on it 14:17:01 ... maybe done early next week 14:17:31 fjh: two different things in document 14:17:38 ... 1 model of how security works 14:17:44 ... 2 detailed XACML profile 14:17:55 ... 1 very tied to 2 14:18:06 +maxf 14:18:25 ... XACML could be its own doc 14:18:27 Claes has joined #dap 14:18:32 zakim, mute me 14:18:32 maxf should now be muted 14:18:44 ... but issues still lie in model piece 14:18:54 q+ 14:19:08 ... maybe need some layering to separate out XACML 14:19:17 ack me 14:19:21 ack dom 14:19:40 dom: no problem with the length, but perhaps the scope 14:19:58 we might want to split framework into model and separate xacml profile document 14:20:06 do you hear a strange sound? 14:20:57 -Dom 14:21:31 +Dom 14:22:09 ... rules lang, ID model, model for environment, capacities model,policy decision model -- lots of stuff 14:22:27 ... makes it harder to get reviews, to get browsers to look at it, etc. 14:22:28 Present+ Soonho_Lee 14:22:48 -> http://lists.w3.org/Archives/Public/public-device-apis/2010Apr/0030.html Dom's comment on policy framework 14:23:03 fjh: could make XACML part separate pretty easily 14:23:12 ... not a whole lot in the rest of the doc 14:23:23 ... need suggestions on way forward 14:23:50 ACTION: Dom to make a concrete proposal for policy framework based on his comments http://lists.w3.org/Archives/Public/public-device-apis/2010Apr/0030.html 14:23:50 Created ACTION-167 - Make a concrete proposal for policy framework based on his comments http://lists.w3.org/Archives/Public/public-device-apis/2010Apr/0030.html [on Dominique Hazaël-Massieux - due 2010-05-05]. 14:23:52 zakim, mute me 14:23:52 Dom should now be muted 14:23:56 ... next step: Laura to finish, others to think about way forward 14:24:09 comment from Claes 14:24:10 Claes: tables defining the subject attributes -- didn't understand 14:25:36 http://dev.w3.org/2009/dap/policy/#subject-attributes 14:26:11 q+ 14:26:26 Laura: have not had time to respond yet 14:26:59 Claes: important to be able to identify a unique web application, not just domain 14:27:12 (this is an example of why identity in itself is probably worth a spec on its own :) 14:27:30 fjh: will take this to the list 14:27:30 identity is one area to call out 14:27:54 ack Suresh 14:28:28 Suresh: sent an email awhile ago asking how the warp (?) spec in widgets group is relevant to policy 14:28:55 ... if you run this against widget environment, widget config will come into effect 14:28:56 http://www.w3.org/TR/2010/CR-widgets-access-20100420/ 14:29:32 fjh: old answer was that warp was an intermediate thing, but we should look at it 14:29:51 darobin: warp is in CR 14:30:06 ... it's one use case, so if policy doesn't cover what warp does, that's a problem 14:30:18 Suresh: couldn't we just reference it? 14:30:31 darobin: it's fine to redefine it 14:30:52 ... otherwise might have to caveat warp out 14:31:02 s/thing/specification/ 14:31:14 s/, but/- / 14:31:23 Suresh: if we can reference it, we should 14:31:26 s/old answer/answer/ 14:31:41 darobin: not sure how reusable warp is, not certain 14:31:56 issue: note relationship of WARP to DAP policy work 14:31:56 Created ISSUE-83 - Note relationship of WARP to DAP policy work ; please complete additional details at http://www.w3.org/2009/dap/track/issues/83/edit . 14:32:11 topic: Privacy 14:32:13 q- 14:32:23 privacy requirements 14:32:24 http://dev.w3.org/2009/dap/privacy-reqs/ 14:32:38 http://lists.w3.org/Archives/Public/public-device-apis/2010Apr/0088.html 14:34:12 this draft fills in details, removes ambiguous language and adds new requirements 14:34:19 this could impact API work 14:35:52 q+ 14:35:55 ack me 14:35:57 ack dom 14:36:38 zakim, mute me 14:36:38 Dom should now be muted 14:37:03 ACTION: Alissa to incorporate edits into Privacy Requirements. 14:37:03 Created ACTION-168 - Incorporate edits into Privacy Requirements. [on Alissa Cooper - due 2010-05-05]. 14:37:21 q+ 14:37:37 q? 14:37:41 ack alissa 14:37:45 ack alissa 14:41:12 (I had trouble with the interpretation of "mutually exclusive" in Alissa's response; I think we should talk about subsetting relationships rather) 14:41:20 fjh: had some placeholder text for APIs 14:41:24 ACTION-116? 14:41:24 ACTION-116 -- Bryan Sullivan to provide input on DCO mapping for SysInfo -- due 2010-03-24 -- OPEN 14:41:24 http://www.w3.org/2009/dap/track/actions/116 14:41:35 http://lists.w3.org/Archives/Public/public-device-apis/2010Apr/0086.html 14:41:44 ACTION-114? 14:41:44 ACTION-114 -- Alissa Cooper to phrase the temporary privacy section -- due 2010-03-23 -- PENDINGREVIEW 14:41:44 http://www.w3.org/2009/dap/track/actions/114 14:41:46 ACTION-114? 14:41:46 ACTION-114 -- Alissa Cooper to phrase the temporary privacy section -- due 2010-03-23 -- PENDINGREVIEW 14:41:46 http://www.w3.org/2009/dap/track/actions/114 14:41:58 [yeah, that's part of what I was thinking about — but I need to ground those ideas in examples to see if it would make sense] 14:42:02 ... can editors put in the text? 14:42:23 (I am attending this conference call only via IRC.) 14:43:23 ACTION: Frederick to insert temporary privacy language into the APIs. 14:43:24 Created ACTION-169 - Insert temporary privacy language into the APIs. [on Frederick Hirsch - due 2010-05-05]. 14:43:41 topic: API discussion 14:43:51 ACTION-142? 14:43:51 ACTION-142 -- Max Froumentin to propose two interfaces Outgoing and Incoming messages for messaging API -- due 2010-03-25 -- PENDINGREVIEW 14:43:51 http://www.w3.org/2009/dap/track/actions/142 14:44:14 darobin: hasn't been much feedback on this -- should we go ahead with it? 14:44:24 -> http://lists.w3.org/Archives/Public/public-device-apis/2010Apr/0079.html 14:44:39 Suresh: don't see why we want to split into incoming and outgoing 14:45:02 ... only distinguished by send 14:45:25 ... if we split will need interface for draft message, e.g. 14:45:55 zakim, unmute me 14:45:55 maxf should no longer be muted 14:46:19 -> http://www.w3.org/2010/03/18-dap-minutes#item01 Messaging API discussions at the F2F 14:46:36 maxf: I don't have insight into which way we're going, just need to make a choice 14:46:41 q+ 14:46:42 ... don't have a strong opinion 14:46:44 ack me 14:47:19 dom: we had the distinction because incoming should be read-only 14:47:31 ... send on incoming doesn't make any sense 14:47:53 + +04610715aaff 14:48:11 ... maybe incoming/outgoing is misleading; it should be about whether it will be sent 14:48:20 ... distinction has value 14:48:27 Claes has joined #dap 14:48:38 darobin: same intf with different rules? 14:48:41 zakim, aaff is nwidell 14:48:41 +nwidell; got it 14:48:51 Suresh: have exception on send for incoming 14:49:07 the proposal I had: http://www.w3.org/mid/4BD04FAA.2010107@opera.com 14:49:07 ... can address use case with what we have 14:49:29 ah, no. 14:49:40 darobin: might want to filter received messages to make them readable 14:49:56 bryan: messages should be editable in the inbox 14:49:59 http://www.w3.org/mid/4BCF032E.9050900@opera.com 14:50:16 ... once you've stored a message, you need an ID to edit 14:50:40 ... the attributes end up becoming similar between the two 14:50:47 ... although there are exceptions 14:51:26 darobin: hearing more arguments in favor of single interface 14:51:45 Suresh: once we have folder management, we can come back to this 14:52:15 darobin: not strongly tied to folders 14:52:32 ... sent mail folder is more of an implementation detail 14:52:48 Suresh: can tag msgs as sent or received 14:53:27 darobin: if object fields are similar, it's a small decision between object type and type flag 14:53:41 ... hearing stronger consensus for single interface 14:54:38 dom: already have a type flag 14:54:45 ... need to disambiguate names 14:54:57 'status' 14:55:09 RESOLUTION: Messages have a single interface irrespective of their type. Need a better name for type (status?). 14:55:14 q+ 14:55:26 q+ to bring up numerical constants 14:55:45 close ACTION-142 14:55:46 ACTION-142 Propose two interfaces Outgoing and Incoming messages for messaging API closed 14:55:48 maxf: so we're not keeping a per-type (MMS, SMS) interface then? 14:56:05 ack maxf 14:56:39 zakim, mute me 14:56:39 Dom should now be muted 14:56:46 Suresh: should separate interfaces based on messaging type 14:57:03 ... BONDI separates the interfaces 14:57:33 [actually these two are half-orthogonal — if we have separate for incoming/ougoing *and* for types we get IncomingSMS, OutgoingSMS, IncomingEmail, ...] 14:57:51 ... right now we create a superset interface and we're silent for what doesn't apply 14:58:00 [given a unified in/out interface, if we split we just get Email, SMS, MMS] 14:58:16 ... implementations might have separate modules for different messaging technologies 14:58:33 darobin: some implementations might only support email 14:58:47 Suresh: separation lets implementations pick 14:59:19 bryan: extension to specific message types is a useful approach (attachments aren't relevant for SMS, e.g.) 14:59:45 ... defining message types is a better approach 14:59:49 +1 with Bryan: different interfaces handles the attribute errors automatically 15:00:50 Suresh: makes spec longer 15:01:03 (which we'll have to do for incoming/outgoing :) ) 15:01:16 ... will miss exception cases 15:01:32 RESOLUTION: Have multiple interfaces for different messaging technologies (i.e., message types). 15:01:36 ack me 15:01:36 darobin, you wanted to bring up numerical constants 15:01:48 q+ 15:02:08 (this relations to ACTION-139) 15:02:11 ACTION-139? 15:02:11 ACTION-139 -- Max Froumentin to fix section 5 "supported messaging types" in Messaging API to clarify handling of non-supported attributes -- due 2010-03-25 -- OPEN 15:02:11 http://www.w3.org/2009/dap/track/actions/139 15:02:24 q+ 15:02:59 maxf: will wait to update until receiving something from Suresh 15:03:22 Zakim, mute anssik 15:03:22 AnssiK should now be muted 15:03:25 zakim, mute drogers 15:03:25 drogers should now be muted 15:03:30 zakim, mute me 15:03:30 fjh should now be muted 15:03:57 I was asking about a resolution on the priority attribute 15:04:02 zakim, drop me 15:04:02 maxf is being disconnected 15:04:03 -maxf 15:04:35 +maxf 15:04:38 Suresh: priority attribute is not applicable for SMS and MMS, but it is for email 15:04:49 ... since we're separating, we should add it to email 15:05:10 bryan: why isn't priority applicable to MMS? 15:05:21 Suresh: it's not defined in the MMS spec 15:05:32 ... user-defined priority 15:05:52 (another item that my MUA lets me set at writing time: reply-to) 15:06:17 q+ 15:06:23 q- 15:06:24 ack me 15:06:40 dom: could have generic getheader and setheader? 15:06:58 darobin: concerned about security issues (in XHR had to jump hoops re headers) 15:07:05 (at least getHeader() should exist?) 15:07:23 [yeah, getHeader() makes sense — note that it can return an array] 15:07:35 Suresh: list of headers is not long right now 15:07:44 darobin: there are many email headers 15:08:12 dom: PHP lets you write any header 15:08:39 bryan: could deal with security issues separately from API functionality 15:08:48 (maybe we should decide on abstraction level of Messaging API) 15:09:02 ... could define specific attributes for most common message fields, but use others by name through generic mechanism 15:09:10 [we could WebIDL setter/getter? not sure if it's worth it, though] 15:09:20 [email from Suresh: X-Original-To, Delivered-To, Received, X-AuditID, X-MimeOLE, Content-class, MIME-Version....] 15:09:39 q? 15:10:07 ACTION: Robin to review the options for headers on emails 15:10:07 Created ACTION-170 - Review the options for headers on emails [on Robin Berjon - due 2010-05-05]. 15:11:06 ISSUE: which headers to support setting/getting in Messaging API? 15:11:06 Created ISSUE-84 - Which headers to support setting/getting in Messaging API? ; please complete additional details at http://www.w3.org/2009/dap/track/issues/84/edit . 15:11:10 darobin: lots of different headers that might need support 15:11:58 ... will draft an email with use cases, review XHR 15:11:58 ack nwidell 15:12:42 nwidell: question of size and scope of API 15:12:53 ... do we really have a use case for replacing outlook? 15:13:03 q? 15:13:22 go for 80/20 15:13:25 bryan: providing a message where you can get/set fields by name, keeps API small 15:14:03 ... if we have something generic, market will find useful ways to leverage it 15:15:12 ScribeNick: maxf 15:15:53 Suresh: we didn't talk about ability to identify messages by Service, like in Contacts 15:16:06 … people have different email accounts. 15:16:07 +1 15:16:16 … retrieving by service is useful. 15:16:46 … e.g. different mailboxes 15:16:59 [you get some emails from Opera, others from GMail, etc. different accounts] 15:17:02 … different accounts 15:17:30 +1 (was thinking about same thing before going AWOL ;-) 15:17:41 darobin: account-ID sounds better than service-ID 15:17:54 -> http://www.w3.org/mid/n2n708552fb1004071110x6d98c6e6t85e83eef0eef52de@mail.gmail.com 15:17:57 Topic: parameter style 15:18:08 ack me 15:18:10 darobin: seems to be heading towards using object literals 15:18:13 … objections? 15:18:24 dom: I'm not sure I would call it a consensus 15:18:34 -alissa 15:18:34 … about half and half 15:19:03 darobin: happy to keep discussion alive 15:19:18 dom: perhaps we need to wait a bit, see if anybody reacts further 15:19:24 darobin: ok 15:19:43 Topic: editor for tasks 15:19:48 (this was about ISSUE-55) 15:19:57 darobin: david suggested he might be able to find someone 15:19:58 ACTION-147? 15:19:58 ACTION-147 -- David Rogers to look for an editor for the Tasks API -- due 2010-03-25 -- OPEN 15:19:58 http://www.w3.org/2009/dap/track/actions/147 15:20:09 Zakim, seen drogersuk? 15:20:09 dom, I do not see Drogersuk anywhere 15:20:13 Zakim, seen david? 15:20:13 dom, I do not see David anywhere 15:20:31 Hello? 15:20:32 Suresh: is Tasks among the priority APIs? 15:20:38 zakim, seen ??P1? 15:20:38 dom, I do not see ??P1 anywhere 15:20:38 Can you hear me? 15:20:46 Zakim, unmute drogersuk 15:20:46 sorry, dom, I do not know which phone connection belongs to drogersuk 15:20:47 darobin: not necessarily, but editors would be welcome 15:20:52 Zakim, unmute drogers 15:20:52 drogers should no longer be muted 15:21:03 zakim, mute me 15:21:03 Dom should now be muted 15:21:16 zakim, unmute me 15:21:16