13:39:40 RRSAgent has joined #dap 13:39:40 logging to http://www.w3.org/2010/08/11-dap-irc 13:39:42 RRSAgent, make logs world 13:39:42 Zakim has joined #dap 13:39:44 Zakim, this will be DAP 13:39:44 ok, trackbot; I see UW_DAP()10:00AM scheduled to start in 21 minutes 13:39:45 Meeting: Device APIs and Policy Working Group Teleconference 13:39:45 Date: 11 August 2010 13:39:54 Chair: Robin_Berjon, Frederick_Hirsch 13:40:06 Present+ Robin_Berjon, Frederick_Hirsch 13:40:12 Regrets+ James_Salsman 13:48:51 Agenda: http://lists.w3.org/Archives/Public/public-device-apis/2010Aug/0033.html 13:49:47 Regrets+ Dominique_Hazael-Massieux, Marco_Marengo, John_Morris 13:50:03 Topic: Administrative 13:52:23 wmaslowski has joined #dap 13:55:22 nstratford has joined #dap 13:56:23 ACTION-241 due next week 13:56:23 ACTION-241 Review and update policy requirements due date now next week 13:57:14 Fan_HU has joined #dap 13:57:29 UW_DAP()10:00AM has now started 13:57:36 +[IPcaller] 13:57:42 zakim, [IPcaller] is me 13:57:42 +fjh; got it 13:57:55 Present+ Fan_HU 13:58:01 Claes has joined #dap 13:58:19 Present+ Neil_Stratford 13:58:56 enewland has joined #dap 13:59:14 + +1.202.637.aaaa - is perhaps enewland 13:59:21 present+ erica_newland 13:59:34 zakim, aaaa is enewland 13:59:34 sorry, enewland, I do not recognize a party named 'aaaa' 13:59:34 ScribeNick: enewland 13:59:37 +[IPcaller] 13:59:49 zakim, who is here? 13:59:49 On the phone I see fjh, enewland, [IPcaller] 13:59:50 On IRC I see enewland, Claes, Fan_HU, nstratford, wmaslowski, Zakim, RRSAgent, Marcos, fjh, tlr, lgombos, shepazu, ingmar, ilkka, dom, trackbot 14:00:01 zakim, call thomas-781 14:00:01 ok, tlr; the call is being made 14:00:02 +Thomas 14:00:07 zakim, [IPcaller] is nstratford 14:00:11 +nstratford; got it 14:00:11 richt has joined #dap 14:00:18 zakim, I am thomas 14:00:21 ok, tlr, I now associate you with Thomas 14:00:22 Present+ thomas 14:00:25 zakim, mute me 14:00:28 Thomas should now be muted 14:00:41 + +44.757.091.aabb 14:01:02 zakim, aabb is richt 14:01:03 Present+ Richard_Tibbett 14:01:04 Suresh has joined #dap 14:01:07 +richt; got it 14:01:09 zakim, who is here? 14:01:17 On the phone I see fjh, enewland, nstratford, Thomas (muted), richt 14:01:18 Present+ Suresh_Chitturi 14:01:30 On IRC I see Suresh, richt, enewland, Claes, Fan_HU, nstratford, wmaslowski, Zakim, RRSAgent, Marcos, fjh, tlr, lgombos, shepazu, ingmar, ilkka, dom, trackbot 14:02:20 +Suresh 14:02:22 +Ingmar_Kliche 14:02:23 LauraA has joined #dap 14:02:47 present+ Ingmar_Kliche 14:02:54 Present+ LauraA 14:03:02 zakim, who is here? 14:03:02 On the phone I see fjh, enewland, nstratford, Thomas (muted), richt, Suresh, Ingmar_Kliche 14:03:04 On IRC I see LauraA, Suresh, richt, enewland, Claes, Fan_HU, nstratford, wmaslowski, Zakim, RRSAgent, Marcos, fjh, tlr, lgombos, shepazu, ingmar, ilkka, dom, trackbot 14:03:10 + +33.4.76.61.aacc 14:03:59 zakim, aacc is Fan_HU 14:03:59 +Fan_HU; got it 14:05:05 + +44.777.541.aadd 14:05:15 zakim, aadd is LauraA 14:05:15 +LauraA; got it 14:06:11 TOPIC: Announcements 14:06:15 bryan_sullivan has joined #dap 14:06:15 darobin has joined #dap 14:06:22 next F2F WG questionnaire and TPAC registration and information 14:06:25 +bryan_sullivan 14:06:30 WG questionnaire (for all), http://www.w3.org/2002/09/wbs/43696/tpac2010dap/ 14:06:46 TPAC registration (for in-person attendees) http://www.w3.org/2002/09/wbs/35125/TPAC2010reg/ 14:06:46 present+ bryan_sullivan 14:06:55 Frederick: complete next F2F questionare and TPAC registration.Let us know if you will dial in so a bridge can be set up 14:06:58 +[IPcaller] 14:07:03 ....do TPAC registration as soon as possible 14:07:03 March F2F questionnaire (Seoul, Korea) 14:07:09 Zakim, [IPCaller] is me 14:07:09 +darobin; got it 14:07:14 http://www.w3.org/2002/09/wbs/43696/seoul-f2f-dates/ 14:07:24 zakim, mute darobin 14:07:24 darobin should now be muted 14:07:27 + +4871719aaee 14:07:33 Messaging API FPWD published 10 August 14:07:39 ...March F2F in Seoul, Korea. 14:07:41 http://www.w3.org/TR/2010/WD-messaging-api-20100810/ 14:07:45 wonsuk has joined #dap 14:07:50 Web Notifications charter under review 14:07:55 zakim, who's making noise? 14:07:59 http://lists.w3.org/Archives/Member/member-device-apis/2010Aug/0001.html 14:07:59 ....In the last call there was a discussion that the web notification charter was under review. So flagging that. 14:08:02 Present 14:08:04 ack thomas 14:08:06 richt, listening for 10 seconds I heard sound from the following: fjh (100%), richt (29%), Suresh (5%), +4871719aaee (5%) 14:08:20 Present+ Wojciech_Maslowski 14:08:29 TOPIC: minutes approval 14:08:50 Frederick: We need to approve F2F minutes. Should we wait another week? 14:09:03 +1 14:09:13 ....let's approve them today if no objection. One modification made yesterday. Cleaned up topics and made resolutions clear. 14:09:20 http://lists.w3.org/Archives/Public/public-device-apis/2010Aug/att-0032/minutes-2010-07-14.html 14:09:20 http://lists.w3.org/Archives/Public/public-device-apis/2010Aug/att-0032/minutes-2010-07-15.html 14:09:20 http://lists.w3.org/Archives/Public/public-device-apis/2010Aug/att-0032/minutes-2010-07-16.html 14:09:24 ...any objections to approving London F2F minutes? 14th - 16th 14:09:33 RESOLUTION: 14th-16th July minutes approved 14:09:40 Approve 4 August minutes 14:09:47 http://lists.w3.org/Archives/Public/public-device-apis/2010Aug/att-0022/minutes-2010-08-04.html 14:09:49 +wonsuk 14:09:50 Frederick: August 4 minutes. Approve those as well? 14:10:01 RESOLUTION: 4th August minutes are approved 14:10:07 TOPIC: Privacy and policy 14:10:14 Updated draft, see http://dev.w3.org/2009/dap/features/ 14:10:31 Present+ Wonsuk_Lee 14:10:54 Frederick: For policy, updated the features draft. With Android list of permissions. May have missed something. Went through BONDI stuff as well, and put in definitions to see how they match. Contacts and calendar are similar. Get's messy in messaging, so that may need to be looked at more carefully. 14:11:08 ....Like Robin's suggestion about forming URI by pre-fixing a set string. 14:11:11 http://lists.w3.org/Archives/Public/public-device-apis/2010Aug/0024.html 14:11:23 ....still an open action out for features. Could use help moving this forward 14:11:37 + +46.1.08.01.aaff 14:11:39 ....on policy requirements actions remain open on Paddy and myself [Frederick] 14:11:50 ....Privacy, waiting on action from John and Erica 14:12:06 zakim, aaff is Claes 14:12:06 +Claes; got it 14:12:18 Present+ Claes_Nilsson 14:12:19 Erica: Still working with John on that 14:12:24 TOPIC: Calendar 14:13:03 http://lists.w3.org/Archives/Public/public-device-apis/2010Aug/0025.html 14:13:12 +4871719aaee is me probably me btw 14:13:59 Thomas: [Static during first part] Looking for people to be part of conversation 14:14:08 -Claes 14:14:09 I've already indicated to tlr that I'll be available for such a teleconf. 14:14:37 ....call will be about usual review of deliverables and the like. If those interested in infrastructure work, may also be a long preview. Let Thomas know by COB THursday next week if you want to be part of this conversation. Call will likely be on a Tuesday around noon Eastern time 14:15:01 q+ 14:15:18 q+ to ask about picking a time that works for people who use lunisolar 14:15:30 I think Kangchan Lee should probably join that call also as he raised the original discussion (I believe). 14:15:31 Thomas: having information discussion on what would have to happen to get lunis supported 14:15:39 +Claes 14:15:50 q? 14:15:52 q- 14:16:06 ack darobin 14:16:06 darobin, you wanted to ask about picking a time that works for people who use lunisolar 14:16:08 Thomas: If those interested are willing to push it, there is an opportunity here. 14:16:53 ....we can try to find a more workable time if there are folks from Asia for whom approximately noon Eastern won't work 14:17:18 Thomas: Just make sure you let me know if you are interested in having the conversation 14:17:49 Frederick: Suresh and Robin had planned to attend 14:17:55 Richard: I plan to attend 14:19:02 Wonsuk: the time may be a problem, though I'd like to attend 14:19:22 Thomas: We know that Korean time is a constraint, will put that into planning email 14:19:34 TOPIC: Contacts 14:19:53 Updates planned for next week (see http://lists.w3.org/Archives/Public/public-device-apis/2010Aug/att-0017/minutes-2010-08-04.html#item06 ) 14:20:39 q+ to ask about coordination item with Contacts 14:21:04 Richard: Nothing to be done this week,. would like to publish a working draft at this point. A couple of bits around processing rules 14:21:06 q+ 14:21:18 q- 14:21:22 ack thomas 14:21:22 Thomas, you wanted to ask about coordination item with Contacts 14:21:30 q+ 14:22:09 q+ 14:22:11 Thomas: Reminding people that we also have an outstanding issue on contacts API concerning ecard and OMA. Last communication with OMA was request for draft. Someone mentioned last week we would be receiving a liason note from them in due course. Any way to move this forward any faster? 14:22:26 ack Suresh 14:22:33 ack suresh 14:22:42 [+1 on helping coordination move faster with a heartbeat] 14:22:45 agree to publish a heartbeat working draft...significant changes (i.e. seperation of read and write) since the last working draft. 14:22:48 Suresh: On the liaison, i did participate in an OMA meeting earlier this week. We should get a liaison to W3C sometime next week 14:23:41 Suresh: It will be very similar to the offline email that was sent to the chairs of the group, but also there will be a pointer to their work. So we can look at the format and the details. Some of the work is online. Some are public documents and some require an OMA login. 14:23:57 Suresh: I don't believe we will get a login for accessing the documents that require one 14:24:10 Bryan: Every draft specification is public. Only meeting minutes and things of that nature are not public 14:24:42 Suresh: We can have links to documents input into IRC 14:24:55 q? 14:25:01 ack fjh 14:25:25 Frederick: What edits are there outstanding that would be important before publication? Aren't there some issues that need to be flagged? Is there still anything confusing? 14:25:49 Richard: A few clarifications but major updates were mitigated by separating specs. Write-access still needs significant work. 14:26:00 OMA CAB Contacts format: http://member.openmobilealliance.org/ftp/Public_documents/COM/COM-CAB/Permanent_documents/OMA-TS-CAB_XDMS-V1_0-20100806-D.zip 14:26:06 ...Proposing we publish contacts API, as there have been significant changes since last working draft was published. 14:26:31 Look under sub clauses 5.1.1.1 and 5.2.1.1 14:26:33 Frederick: makes sense. I thought last time we had talked about publishing write as well. We should probably have a note in the draft that says write was separated out 14:27:01 Richard: There is a note in the introduction. But we are still working out the write draft 14:27:54 Suresh: Has content changed since last publication? Aside from separating out write spec 14:28:06 ...any change in terms of functionality 14:28:20 Richard: change in contact properties 14:28:47 contacts editors draft -> http://dev.w3.org/2009/dap/contacts/ 14:29:11 Richard: By splitting documents we ended up with empty contacts object. So flattened and refashioned 14:29:23 s/refashioned/refactored 14:29:40 PROPOSED RESOLUTION: publish a heartbeat of readonly Contacts 14:29:48 RESOLUTION: publish a heartbeat of readonly Contacts 14:29:53 Marcos has joined #dap 14:30:22 ACTION: Robin to handle publishing Contacts 14:30:23 Created ACTION-252 - Handle publishing Contacts [on Robin Berjon - due 2010-08-18]. 14:30:40 TOPIC: Wojciech's informal proposal 14:30:53 Informal proposal for integration of Contacts API with HTML forms 14:30:53 http://lists.w3.org/Archives/Public/public-device-apis/2010Aug/0026.html 14:31:24 darobin: Does it need more discussion? 14:32:26 Richard: We are still looking at interesting ways of doing this. certainly very interesting to have something like this. Device element is very much a candidate for integration. Input element has some issues, which have been raised on list before. So, we are still looking at the best way to do this. but we would like to integrate with xtml as an input way. and we still have device element on table, but not sure what best idea is at this point. 14:32:34 q+ 14:32:41 ack wmaslowski 14:33:35 some of the issues with using are explained here: http://lists.w3.org/Archives/Public/public-device-apis/2009Dec/0011.html 14:33:41 Wojciech: Best to wait a week for more feedback. Idea is to integrate input. Will try to make something more spec-like out of it if there is interest 14:33:50 robin: we will wait a little bit and give people more time 14:33:58 alternative proposal I mentioned with is here: http://lists.w3.org/Archives/Public/public-device-apis/2010Jul/0026.html 14:34:07 TOPIC: Messaging API 14:34:21 thomas review,, http://lists.w3.org/Archives/Public/public-device-apis/2010Aug/0019.html 14:34:24 ACTION-222? 14:34:24 ACTION-222 -- Thomas Roessler to review the Messaging security section -- due 2010-08-15 -- PENDINGREVIEW 14:34:24 http://www.w3.org/2009/dap/track/actions/222 14:34:41 http://lists.w3.org/Archives/Public/public-device-apis/2010Aug/0021.html 14:34:58 q+ 14:35:19 ack richt 14:35:25 robin: Before we delve into too many low-level details, we need to look at use-case problem here. Do we really absolutely need to have this messaging API available inside browsers. Are there actual use cases for this? The issues are difficult. There may be valuable for widgets but what about for browsers? 14:36:00 Richard: We do have other ways to send messages. SMS gateways, for example, are available on the web. So, there are a lot of people trying to tackle this problem in different ways. 14:36:21 q+ 14:36:27 ...it's difficult to say we don't need it, but there are other ways to do it already and other groups tackling this problem from different angles 14:36:42 ack bryan_sullivan 14:37:08 Bryan: What is it that we are proposing in particular? The notification aspect only? 14:37:20 in addition there are SMS URIs in draft at IETF: http://tools.ietf.org/html/draft-wilde-sms-uri-20 14:37:28 Richard: Is this a widgets only API or are there usecases for Web pages interacting with this 14:37:53 s/Richard: Is this a widgets/Robin: Is this a widgets/ 14:38:08 Bryan: So are there use cases for browsers? If you take the approach that we took in BONDI, you start with default assumption that all of these APIs are applicable to both browsers and widgets and you need a consistent framework for securing access to those APIs 14:38:35 +1 to Bryan 14:38:38 ...so with regard to gateways that exist on network, those are partial solutions b/c they support nothing with regard to notification 14:39:15 Robin: We might then have something that only handles notifications 14:39:31 q+ 14:39:44 q- 14:39:45 that is true, there is a lack of a notification message for incoming messages. Though could this be covered in Web Notifications? http://www.w3.org/2010/06/notification-charter 14:39:56 ....we need to see use cases for use directly in browser by third party website to get a better since for how to scope this api 14:40:05 q+ 14:40:35 bryan: we view web applications as the whole space. widgets are a packaging model. html5 apps with application cache are going to be in the same space as widgets with respect to what developers are going to want to do with them 14:40:59 ack Suresh 14:41:02 ...we need to make these available in both contacts b/c that's what developers are going to want 14:41:04 I guess not. I guess I'm saying there may be more generic notification mechanisms available for incoming messages. 14:41:12 q- 14:41:16 Suresh: second what Bryan was saying. 14:42:15 ....from widgets' perspective, makes sense to have messaging API. And we want to use the same API as well unless we have problems. We need to separate the API discussion from the security discussion. We have already scaled down the messaging API significantly. Just supports creation and sending of messages and subscribing to incoming messages 14:43:17 ...the URI formats that we have, SMS and MMS, don't provide the same level of granularity and efficiency as the APIs do. In those, you have to package everything in a single string. So I recommend we keep working on the current API model and try to identify issues in the context of the browser 14:43:37 Robin: But how do you safely grant a website the right to send stuff? Is it a one-shot, is it every time, etc.? 14:43:40 q+ 14:44:05 Suresh: Whatever model we come up with for widgets - user consent or policy based, etc. - we could apply same principles to browser 14:44:30 ack thoma 14:44:43 Robin: but you end up with different contexts. For widgets it's an installed application. For browser, you visit a web site today, then again six months later, and suddenly it's in an iFrame, etc. Things change 14:44:51 wonsuk has left #dap 14:46:17 Thomas: When we take this API to the web, and think through geolocation-like privacy considerations we have now. Then we are talking about giving access to these APIs to an indeterminate number of websites that the user visits. Then there is some type of consent. You risk clicking once and suddenly give this website, that website, the ability to send emails and text messages from your device. Oops. 14:46:39 q+ 14:46:49 q+ 14:47:18 ....On the sending side the security considerations need to be very very explicit. Because of risks of websites using user's device. Are there any usecases we know of where the website would subscribe to device incoming email notifications? Hard to imagine 14:47:31 tlr notes task specific form to limit risk 14:47:33 ....an explicit use case for that should be on the table. And security considerations should be discussed 14:47:38 ack bryan_sullivan 14:47:39 s/usecases/use cases 14:48:13 Bryan: As you look at security considerations case-by-case. Across these APIs we are establishing a default policy in absence of policy framework 14:48:18 wonsuk has joined #dap 14:48:41 q+ 14:48:44 ...the browser is only an environment in which apps run. The browser is a place where you can have installable applciations. Not necessarily a website. 14:48:52 [I can only point out that with AppCache there is an installation step — it's not an arbitrary website] 14:49:04 ...You may download the app using AppCache and it is on the device 14:49:15 q- 14:49:20 ack thom 14:49:39 robin: The different characteristic betweent he AppCache case and the widget case is that with AppCache I do not have a new security boundary 14:49:46 ....with widget you have that boundary 14:49:51 s/robin: /tlr: / 14:50:23 ....look at security domain and how many parties have access 14:50:24 +1 on thinking about security domains instead of installation, the latter is just a mental shortcut 14:50:30 ack Suresh 14:51:23 q+ 14:51:36 IMO, if it's not appropriate for the browser AND widgets, then we need to re-consider the specification(s). We are covering both. 14:51:36 suresh: same issue we often discuss - what is appropriate for widget and what is appropriate for browser. How you authorize the app to access this functionality. Rather than dealing with this issue one API at a time, we should think about this more comprehensively 14:51:55 q+ 14:53:09 robin: it doesn't reflect reality. there is a security boundary so we have to be careful between browser context and other contexts. but there is very little commonality between exposing contacts and allowing someone to send emails. 14:54:16 ack Suresh 14:54:23 robin: we come up with different solutions for the different issues, though they do boil down to security boundary issues, but they are different. we can't find a generic solution for all these areas. We can also spin off a separate specification that allows for full access, but scale down what's available in the browser because it's just too dangerous 14:54:24 ack darobin 14:55:19 Suresh: We talk about an API and scale down what browser can access and end up scaling down what the widgets can do. 14:55:28 q+ 14:55:51 ack fjh 14:55:51 robin: We do not have to limit our APIs to what is safe in the browser. but we do need an API that is safe in the browser and then, if we want, build on top of that for a wider API that becomes available for widgets 14:56:20 Frederick: I think Bryan said something well. We are talking about default policy in absence of policy framework. If we say there is no policy framework, we have to separate out these cases. 14:56:30 [the default policy gives you this API, more trusted policy gives you these extras] 14:56:39 ...so this begs a question of what will happen with policy framework 14:57:44 suresh: This discussion should not affect the policy work that we are doing 14:57:48 q? 14:57:52 ack tho 14:57:54 q? 14:58:41 Thomas: Often, there will be synergy to be had out of having a single API for the web and widgets. In those cases we may be better off with one API that is deployable in browser environment safely and lacks some of the features but gets deployed more broadly 14:58:57 +1 14:59:07 ....in other cases, the use case on the widget side may be so different that it needs a different approach, and on email/notification side, we may be in that situation. 14:59:07 +1 to tlr 14:59:23 in widget case can have additional functionality in conjunction with policy framework 14:59:25 ....so in this case, we should focus on widget case. 14:59:38 [I think we should write up tlr's summary as policy] 14:59:50 am I hearing that we might decide to limit policy framework to widget case? 14:59:53 Dong-Young has joined #dap 14:59:59 -Thomas 15:00:05 q+ 15:00:07 Presence+ Dong-Young_Lee 15:00:49 Frederick: So where does this leave us with policy framework? It sounds like we want to make a safe API that works in web case that can also be applicable to widgets. And if we want to extend this, then we could integrate that with policy work 15:01:11 ack bryan_sullivan 15:01:38 Bryan: The complication is not on the question of how do you design or apply a policy framework in browser/widget context 15:02:13 ...it's that we've taken the approach that it has to be a UI notification in browser context. And things have fallen by wayside b/c are not easily represented in that context 15:02:33 ....in BONDi we have a clear policy framework that works in browsers and widgets 15:02:52 ....we can apply policy in both contexts, it's just a matter of which implementations are going to embrace it. 15:03:12 robin: if we don't try, we can't succeed 15:03:22 s/robin/fjh 15:03:49 +[IPcaller] 15:03:59 Bryan: If we succeed in mobile space, that is success. 15:04:08 zakim, who is here? 15:04:09 On the phone I see fjh, enewland, nstratford, richt, Suresh, Ingmar_Kliche, Fan_HU, LauraA, bryan_sullivan, darobin, +4871719aaee, wonsuk, Claes, [IPcaller] 15:04:16 On IRC I see Dong-Young, wonsuk, Marcos, darobin, bryan_sullivan, LauraA, Suresh, richt, enewland, Claes, Fan_HU, nstratford, wmaslowski, Zakim, RRSAgent, fjh, tlr, lgombos, 15:04:18 robin: but we don't want more fragmentation 15:04:19 ... ingmar, ilkka, dom, trackbot 15:04:31 q? 15:04:50 bryan: we shouldn't be looking at this focusing on desktop browsers. 15:05:59 robin: the discussion is not about forgetting policy for browsers. I would be reluctant to revisit our idea of keeping these pieces separate. Keeping them separate helps us with implementation 15:06:14 q+ 15:06:22 ack Suresh 15:08:27 robin: Take any existing API where you think features have been limited too far, considering browser limitations, see what you would like to add on top of it. Just need proposals 15:08:32 suresh suggests plan to review specs for additional functionality suitable for widgets case (but not web case) 15:08:45 Suresh: Would these drafts say these are only for widgets and not for browser 15:08:54 agree with robin. something rough is better than nothing. and a good rough draft is good enough to discuss further. 15:09:32 robin: Yes, we can find some kind of phrasing. 15:09:39 ....like separating reading and writing file APIs 15:10:58 Marcos_ has joined #dap 15:11:10 it's certainly not scaling down. It is allowing the mature aspects to be put on a quicker track to publication while still understanding the implications of the harder stuff. 15:11:46 ACTION: Suresh to make proposals for Contacts and Messaging features in a trusted context due in three weeks 15:11:46 Created ACTION-253 - Make proposals for Contacts and Messaging features in a trusted context due in three weeks [on Suresh Chitturi - due 2010-08-18]. 15:12:00 action-253? 15:12:00 ACTION-253 -- Suresh Chitturi to make proposals for Contacts and Messaging features in a trusted context due in three weeks -- due 2010-08-18 -- OPEN 15:12:00 http://www.w3.org/2009/dap/track/actions/253 15:12:04 -Suresh 15:12:08 ACTION-253 due +2 weeks 15:12:08 ACTION-253 Make proposals for Contacts and Messaging features in a trusted context due in three weeks due date now +2 weeks 15:12:17 action-253? 15:12:17 ACTION-253 -- Suresh Chitturi to make proposals for Contacts and Messaging features in a trusted context due in three weeks -- due 2010-08-25 -- OPEN 15:12:17 http://www.w3.org/2009/dap/track/actions/253 15:12:39 robin: We need use cases around what works in browser 15:12:39 action-253 due +3 weeks 15:12:39 ACTION-253 Make proposals for Contacts and Messaging features in a trusted context due in three weeks due date now +3 weeks 15:12:45 action-253? 15:12:45 ACTION-253 -- Suresh Chitturi to make proposals for Contacts and Messaging features in a trusted context due in three weeks -- due 2010-08-31 -- OPEN 15:12:45 http://www.w3.org/2009/dap/track/actions/253 15:13:19 Robin: this leaves us without a resolution for messaging. We will return to messaging next week. Proposals are welcome in email 15:13:41 TOPIC: Capture 15:14:12 Robin: Shall we keep working based on feedback we received after publication? 15:14:23 ...we should publish the API as soon as it's ready 15:15:00 Ingmar: we will wait one week and then discuss again. 15:15:15 TOPIC: SysInfo 15:15:25 Robin: Bryan sent a new draft 15:15:26 ACTION-211? 15:15:26 ACTION-211 -- Alissa Cooper to make proposal on list for sysinfo privacy section -- due 2010-07-21 -- CLOSED 15:15:26 http://www.w3.org/2009/dap/track/actions/211 15:15:34 ACTION-213? 15:15:34 ACTION-213 -- Richard Tibbett to review sysinfo draft after edits made -- due 2010-07-21 -- OPEN 15:15:34 http://www.w3.org/2009/dap/track/actions/213 15:15:42 ACTION-243? 15:15:42 ACTION-243 -- Dong-Young Lee to review sysinfo draft after edits made -- due 2010-08-09 -- OPEN 15:15:42 http://www.w3.org/2009/dap/track/actions/243 15:15:53 ACTION-214? 15:15:53 ACTION-214 -- Thomas Roessler to request IETF community review of sysinfo API Last Call WD through W3C/IETF liaison channel -- due 2010-08-31 -- OPEN 15:15:53 http://www.w3.org/2009/dap/track/actions/214 15:16:08 is sysinfo ready now for reviewers to review? 15:16:24 Bryan: It addresses the open issues, James' comments. There are some places in which text needs to be checked. There are type attributes and name attributes that were added. Need to check how that integrates. 15:16:36 ....edits that were captured during F2F - for privacy section - that have been included 15:16:46 ....seem that most of outstanding comments have been addressed 15:16:52 I believe the CVS DIFF is a good place to review the changes made to system-info by Bryan: http://dev.w3.org/cvsweb/2009/dap/system-info/Overview.html.diff?r1=1.123&r2=1.124&f=h 15:16:56 Frederick: Is it ready for review? 15:17:01 Bryan: As far as I can tell, yes 15:18:04 Zakim, [IPCaller] is Dong-Young 15:18:04 +Dong-Young; got it 15:18:05 Sorry for the noise. 15:18:14 I said I will review it within 1-2 weeks. 15:18:16 q+ to ask to close ACTION-169 during action review section 15:18:23 ack fjh 15:18:23 fjh, you wanted to ask to close ACTION-169 during action review section 15:18:37 ACTION-169? 15:18:37 ACTION-169 -- Frederick Hirsch to insert temporary privacy language into the APIs. -- due 2010-05-05 -- OPEN 15:18:37 http://www.w3.org/2009/dap/track/actions/169 15:19:04 close action-169 15:19:05 ACTION-169 Insert temporary privacy language into the APIs. closed 15:19:06 Frederick: We should close action to insert temporary privacy language into APIs. 15:19:24 ACTION-169 closed 15:19:24 ACTION-169 Insert temporary privacy language into the APIs. closed 15:19:37 q+ 15:19:41 ack bryan_sullivan 15:19:48 action-248? 15:19:48 ACTION-248 -- John Morris to provide a proposal relevant to ISSUE-92, sysinfo privacy prompts for operators get vs watch -- due 2010-08-11 -- OPEN 15:19:48 http://www.w3.org/2009/dap/track/actions/248 15:19:52 ACTION-248? 15:19:52 ACTION-248 -- John Morris to provide a proposal relevant to ISSUE-92, sysinfo privacy prompts for operators get vs watch -- due 2010-08-11 -- OPEN 15:19:52 http://www.w3.org/2009/dap/track/actions/248 15:19:56 Bryan: On SysInfo, ACTION-248, to address get versus watch may have been addressed 15:20:09 issue-92? 15:20:09 ISSUE-92 -- Sysinfo, permissions for get vs monitor; -- open 15:20:09 http://www.w3.org/2009/dap/track/issues/92 15:20:09 ....statements in privacy section now. 15:20:19 ACTION-248: recent editorial action added warning re get vs watch 15:20:19 ACTION-248 Provide a proposal relevant to ISSUE-92, sysinfo privacy prompts for operators get vs watch notes added 15:20:53 action-248 closed 15:20:53 ACTION-248 Provide a proposal relevant to ISSUE-92, sysinfo privacy prompts for operators get vs watch closed 15:21:00 action-238? 15:21:00 ACTION-238 -- Bryan Sullivan to inform OMA groups of our status -- due 2010-07-23 -- OPEN 15:21:00 http://www.w3.org/2009/dap/track/actions/238 15:21:04 Frederick: Is ACTION-238 still relevant? 15:21:38 OMA CAB has been informed. 15:21:39 action-238 closed 15:21:39 ACTION-238 Inform OMA groups of our status closed 15:22:00 -bryan_sullivan 15:22:03 -Claes 15:22:10 -enewland 15:22:11 -richt 15:22:11 -Ingmar_Kliche 15:22:12 -darobin 15:22:13 -Fan_HU 15:22:14 -nstratford 15:22:16 -LauraA 15:22:16 rrsagent, generate minutes 15:22:16 I have made the request to generate http://www.w3.org/2010/08/11-dap-minutes.html fjh 15:22:16 wonsuk has left #dap 15:22:18 - +4871719aaee 15:22:19 -Dong-Young 15:22:21 -fjh 15:22:26 -wonsuk 15:22:27 UW_DAP()10:00AM has ended 15:22:28 Attendees were fjh, +1.202.637.aaaa, Thomas, nstratford, +44.757.091.aabb, richt, Suresh, Ingmar_Kliche, +33.4.76.61.aacc, Fan_HU, +44.777.541.aadd, LauraA, bryan_sullivan, 15:22:30 ... darobin, +4871719aaee, wonsuk, +46.1.08.01.aaff, Claes, Dong-Young 15:31:03 MoZ has joined #dap 15:34:37 Marcos has joined #dap 16:03:24 shepazu has joined #dap 16:03:53 shepazu has joined #dap 16:15:24 shepazu has joined #dap 17:40:01 Zakim has left #dap