IRC log of dap on 2010-08-11

Timestamps are in UTC.

13:39:40 [RRSAgent]
RRSAgent has joined #dap
13:39:40 [RRSAgent]
logging to
13:39:42 [trackbot]
RRSAgent, make logs world
13:39:42 [Zakim]
Zakim has joined #dap
13:39:44 [trackbot]
Zakim, this will be DAP
13:39:44 [Zakim]
ok, trackbot; I see UW_DAP()10:00AM scheduled to start in 21 minutes
13:39:45 [trackbot]
Meeting: Device APIs and Policy Working Group Teleconference
13:39:45 [trackbot]
Date: 11 August 2010
13:39:54 [fjh]
Chair: Robin_Berjon, Frederick_Hirsch
13:40:06 [fjh]
Present+ Robin_Berjon, Frederick_Hirsch
13:40:12 [fjh]
Regrets+ James_Salsman
13:48:51 [fjh]
13:49:47 [fjh]
Regrets+ Dominique_Hazael-Massieux, Marco_Marengo, John_Morris
13:50:03 [fjh]
Topic: Administrative
13:52:23 [wmaslowski]
wmaslowski has joined #dap
13:55:22 [nstratford]
nstratford has joined #dap
13:56:23 [fjh]
ACTION-241 due next week
13:56:23 [trackbot]
ACTION-241 Review and update policy requirements due date now next week
13:57:14 [Fan_HU]
Fan_HU has joined #dap
13:57:29 [Zakim]
UW_DAP()10:00AM has now started
13:57:36 [Zakim]
13:57:42 [fjh]
zakim, [IPcaller] is me
13:57:42 [Zakim]
+fjh; got it
13:57:55 [Fan_HU]
Present+ Fan_HU
13:58:01 [Claes]
Claes has joined #dap
13:58:19 [nstratford]
Present+ Neil_Stratford
13:58:56 [enewland]
enewland has joined #dap
13:59:14 [Zakim]
+ +1.202.637.aaaa - is perhaps enewland
13:59:21 [enewland]
present+ erica_newland
13:59:34 [enewland]
zakim, aaaa is enewland
13:59:34 [Zakim]
sorry, enewland, I do not recognize a party named 'aaaa'
13:59:34 [fjh]
ScribeNick: enewland
13:59:37 [Zakim]
13:59:49 [fjh]
zakim, who is here?
13:59:49 [Zakim]
On the phone I see fjh, enewland, [IPcaller]
13:59:50 [Zakim]
On IRC I see enewland, Claes, Fan_HU, nstratford, wmaslowski, Zakim, RRSAgent, Marcos, fjh, tlr, lgombos, shepazu, ingmar, ilkka, dom, trackbot
14:00:01 [tlr]
zakim, call thomas-781
14:00:01 [Zakim]
ok, tlr; the call is being made
14:00:02 [Zakim]
14:00:07 [nstratford]
zakim, [IPcaller] is nstratford
14:00:11 [Zakim]
+nstratford; got it
14:00:11 [richt]
richt has joined #dap
14:00:18 [tlr]
zakim, I am thomas
14:00:21 [Zakim]
ok, tlr, I now associate you with Thomas
14:00:22 [tlr]
Present+ thomas
14:00:25 [tlr]
zakim, mute me
14:00:28 [Zakim]
Thomas should now be muted
14:00:41 [Zakim]
+ +44.757.091.aabb
14:01:02 [fjh]
zakim, aabb is richt
14:01:03 [richt]
Present+ Richard_Tibbett
14:01:04 [Suresh]
Suresh has joined #dap
14:01:07 [Zakim]
+richt; got it
14:01:09 [fjh]
zakim, who is here?
14:01:17 [Zakim]
On the phone I see fjh, enewland, nstratford, Thomas (muted), richt
14:01:18 [Suresh]
Present+ Suresh_Chitturi
14:01:30 [Zakim]
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 [Zakim]
14:02:22 [Zakim]
14:02:23 [LauraA]
LauraA has joined #dap
14:02:47 [ingmar]
present+ Ingmar_Kliche
14:02:54 [LauraA]
Present+ LauraA
14:03:02 [fjh]
zakim, who is here?
14:03:02 [Zakim]
On the phone I see fjh, enewland, nstratford, Thomas (muted), richt, Suresh, Ingmar_Kliche
14:03:04 [Zakim]
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 [Zakim]
+ +
14:03:59 [richt]
zakim, aacc is Fan_HU
14:03:59 [Zakim]
+Fan_HU; got it
14:05:05 [Zakim]
+ +44.777.541.aadd
14:05:15 [LauraA]
zakim, aadd is LauraA
14:05:15 [Zakim]
+LauraA; got it
14:06:11 [enewland]
TOPIC: Announcements
14:06:15 [bryan_sullivan]
bryan_sullivan has joined #dap
14:06:15 [darobin]
darobin has joined #dap
14:06:22 [fjh]
next F2F WG questionnaire and TPAC registration and information
14:06:25 [Zakim]
14:06:30 [fjh]
WG questionnaire (for all),
14:06:46 [fjh]
TPAC registration (for in-person attendees)
14:06:46 [bryan_sullivan]
present+ bryan_sullivan
14:06:55 [enewland]
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 [Zakim]
14:07:03 [enewland] TPAC registration as soon as possible
14:07:03 [fjh]
March F2F questionnaire (Seoul, Korea)
14:07:09 [darobin]
Zakim, [IPCaller] is me
14:07:09 [Zakim]
+darobin; got it
14:07:14 [fjh]
14:07:24 [tlr]
zakim, mute darobin
14:07:24 [Zakim]
darobin should now be muted
14:07:27 [Zakim]
+ +4871719aaee
14:07:33 [fjh]
Messaging API FPWD published 10 August
14:07:39 [enewland]
...March F2F in Seoul, Korea.
14:07:41 [fjh]
14:07:45 [wonsuk]
wonsuk has joined #dap
14:07:50 [fjh]
Web Notifications charter under review
14:07:55 [richt]
zakim, who's making noise?
14:07:59 [fjh]
14:07:59 [enewland]
....In the last call there was a discussion that the web notification charter was under review. So flagging that.
14:08:02 [wmaslowski]
14:08:04 [tlr]
ack thomas
14:08:06 [Zakim]
richt, listening for 10 seconds I heard sound from the following: fjh (100%), richt (29%), Suresh (5%), +4871719aaee (5%)
14:08:20 [wmaslowski]
Present+ Wojciech_Maslowski
14:08:29 [enewland]
TOPIC: minutes approval
14:08:50 [enewland]
Frederick: We need to approve F2F minutes. Should we wait another week?
14:09:03 [darobin]
14:09:13 [enewland]
....let's approve them today if no objection. One modification made yesterday. Cleaned up topics and made resolutions clear.
14:09:20 [fjh]
14:09:20 [fjh]
14:09:20 [fjh]
14:09:24 [enewland]
...any objections to approving London F2F minutes? 14th - 16th
14:09:33 [enewland]
RESOLUTION: 14th-16th July minutes approved
14:09:40 [fjh]
Approve 4 August minutes
14:09:47 [fjh]
14:09:49 [Zakim]
14:09:50 [enewland]
Frederick: August 4 minutes. Approve those as well?
14:10:01 [enewland]
RESOLUTION: 4th August minutes are approved
14:10:07 [enewland]
TOPIC: Privacy and policy
14:10:14 [fjh]
Updated draft, see
14:10:31 [wonsuk]
Present+ Wonsuk_Lee
14:10:54 [enewland]
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 [enewland]
....Like Robin's suggestion about forming URI by pre-fixing a set string.
14:11:11 [fjh]
14:11:23 [enewland]
....still an open action out for features. Could use help moving this forward
14:11:37 [Zakim]
+ +
14:11:39 [enewland]
....on policy requirements actions remain open on Paddy and myself [Frederick]
14:11:50 [enewland]
....Privacy, waiting on action from John and Erica
14:12:06 [Claes]
zakim, aaff is Claes
14:12:06 [Zakim]
+Claes; got it
14:12:18 [Claes]
Present+ Claes_Nilsson
14:12:19 [enewland]
Erica: Still working with John on that
14:12:24 [enewland]
TOPIC: Calendar
14:13:03 [fjh]
14:13:12 [wmaslowski]
+4871719aaee is me probably me btw
14:13:59 [enewland]
Thomas: [Static during first part] Looking for people to be part of conversation
14:14:08 [Zakim]
14:14:09 [richt]
I've already indicated to tlr that I'll be available for such a teleconf.
14:14:37 [enewland] 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 [fjh]
14:15:18 [darobin]
q+ to ask about picking a time that works for people who use lunisolar
14:15:30 [richt]
I think Kangchan Lee should probably join that call also as he raised the original discussion (I believe).
14:15:31 [enewland]
Thomas: having information discussion on what would have to happen to get lunis supported
14:15:39 [Zakim]
14:15:50 [fjh]
14:15:52 [fjh]
14:16:06 [fjh]
ack darobin
14:16:06 [Zakim]
darobin, you wanted to ask about picking a time that works for people who use lunisolar
14:16:08 [enewland]
Thomas: If those interested are willing to push it, there is an opportunity here.
14:16:53 [enewland]
....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 [enewland]
Thomas: Just make sure you let me know if you are interested in having the conversation
14:17:49 [enewland]
Frederick: Suresh and Robin had planned to attend
14:17:55 [enewland]
Richard: I plan to attend
14:19:02 [enewland]
Wonsuk: the time may be a problem, though I'd like to attend
14:19:22 [enewland]
Thomas: We know that Korean time is a constraint, will put that into planning email
14:19:34 [enewland]
TOPIC: Contacts
14:19:53 [fjh]
Updates planned for next week (see )
14:20:39 [tlr]
q+ to ask about coordination item with Contacts
14:21:04 [enewland]
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 [fjh]
14:21:18 [fjh]
14:21:22 [darobin]
ack thomas
14:21:22 [Zakim]
Thomas, you wanted to ask about coordination item with Contacts
14:21:30 [fjh]
14:22:09 [Suresh]
14:22:11 [enewland]
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 [darobin]
ack Suresh
14:22:33 [fjh]
ack suresh
14:22:42 [darobin]
[+1 on helping coordination move faster with a heartbeat]
14:22:45 [richt]
agree to publish a heartbeat working draft...significant changes (i.e. seperation of read and write) since the last working draft.
14:22:48 [enewland]
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 [enewland]
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 [enewland]
Suresh: I don't believe we will get a login for accessing the documents that require one
14:24:10 [enewland]
Bryan: Every draft specification is public. Only meeting minutes and things of that nature are not public
14:24:42 [enewland]
Suresh: We can have links to documents input into IRC
14:24:55 [fjh]
14:25:01 [darobin]
ack fjh
14:25:25 [enewland]
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 [enewland]
Richard: A few clarifications but major updates were mitigated by separating specs. Write-access still needs significant work.
14:26:00 [Suresh]
OMA CAB Contacts format:
14:26:06 [enewland]
...Proposing we publish contacts API, as there have been significant changes since last working draft was published.
14:26:31 [Suresh]
Look under sub clauses and
14:26:33 [enewland]
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 [enewland]
Richard: There is a note in the introduction. But we are still working out the write draft
14:27:54 [enewland]
Suresh: Has content changed since last publication? Aside from separating out write spec
14:28:06 [enewland]
...any change in terms of functionality
14:28:20 [enewland]
Richard: change in contact properties
14:28:47 [fjh]
contacts editors draft ->
14:29:11 [enewland]
Richard: By splitting documents we ended up with empty contacts object. So flattened and refashioned
14:29:23 [richt]
14:29:40 [darobin]
PROPOSED RESOLUTION: publish a heartbeat of readonly Contacts
14:29:48 [darobin]
RESOLUTION: publish a heartbeat of readonly Contacts
14:29:53 [Marcos]
Marcos has joined #dap
14:30:22 [darobin]
ACTION: Robin to handle publishing Contacts
14:30:23 [trackbot]
Created ACTION-252 - Handle publishing Contacts [on Robin Berjon - due 2010-08-18].
14:30:40 [enewland]
TOPIC: Wojciech's informal proposal
14:30:53 [fjh]
Informal proposal for integration of Contacts API with HTML forms
14:30:53 [fjh]
14:31:24 [enewland]
darobin: Does it need more discussion?
14:32:26 [enewland]
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 [wmaslowski]
14:32:41 [darobin]
ack wmaslowski
14:33:35 [richt]
some of the issues with using <input> are explained here:
14:33:41 [enewland]
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 [enewland]
robin: we will wait a little bit and give people more time
14:33:58 [richt]
alternative proposal I mentioned with <device> is here:
14:34:07 [enewland]
TOPIC: Messaging API
14:34:21 [fjh]
thomas review,,
14:34:24 [fjh]
14:34:24 [trackbot]
ACTION-222 -- Thomas Roessler to review the Messaging security section -- due 2010-08-15 -- PENDINGREVIEW
14:34:24 [trackbot]
14:34:41 [fjh]
14:34:58 [richt]
14:35:19 [darobin]
ack richt
14:35:25 [enewland]
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 [enewland]
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 [bryan_sullivan]
14:36:27 [enewland]'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 [darobin]
ack bryan_sullivan
14:37:08 [enewland]
Bryan: What is it that we are proposing in particular? The notification aspect only?
14:37:20 [richt]
in addition there are SMS URIs in draft at IETF:
14:37:28 [enewland]
Richard: Is this a widgets only API or are there usecases for Web pages interacting with this
14:37:53 [richt]
s/Richard: Is this a widgets/Robin: Is this a widgets/
14:38:08 [enewland]
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 [Suresh]
+1 to Bryan
14:38:38 [enewland] with regard to gateways that exist on network, those are partial solutions b/c they support nothing with regard to notification
14:39:15 [enewland]
Robin: We might then have something that only handles notifications
14:39:31 [richt]
14:39:44 [richt]
14:39:45 [richt]
that is true, there is a lack of a notification message for incoming messages. Though could this be covered in Web Notifications?
14:39:56 [enewland]
....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 [Suresh]
14:40:35 [enewland]
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 [darobin]
ack Suresh
14:41:02 [enewland]
...we need to make these available in both contacts b/c that's what developers are going to want
14:41:04 [richt]
I guess not. I guess I'm saying there may be more generic notification mechanisms available for incoming messages.
14:41:12 [bryan_sullivan]
14:41:16 [enewland]
Suresh: second what Bryan was saying.
14:42:15 [enewland]
....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 [enewland]
...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 [enewland]
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 [tlr]
14:44:05 [enewland]
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 [darobin]
ack thoma
14:44:43 [enewland]
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]
wonsuk has left #dap
14:46:17 [enewland]
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 [bryan_sullivan]
14:46:49 [Suresh]
14:47:18 [enewland]
....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 [fjh]
tlr notes task specific form to limit risk
14:47:33 [enewland] explicit use case for that should be on the table. And security considerations should be discussed
14:47:38 [darobin]
ack bryan_sullivan
14:47:39 [fjh]
s/usecases/use cases
14:48:13 [enewland]
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]
wonsuk has joined #dap
14:48:41 [tlr]
14:48:44 [enewland]
...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 [darobin]
[I can only point out that with AppCache there is an installation step — it's not an arbitrary website]
14:49:04 [enewland]
...You may download the app using AppCache and it is on the device
14:49:15 [bryan_sullivan]
14:49:20 [darobin]
ack thom
14:49:39 [enewland]
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 [enewland]
....with widget you have that boundary
14:49:51 [darobin]
s/robin: /tlr: /
14:50:23 [enewland]
....look at security domain and how many parties have access
14:50:24 [darobin]
+1 on thinking about security domains instead of installation, the latter is just a mental shortcut
14:50:30 [darobin]
ack Suresh
14:51:23 [darobin]
14:51:36 [richt]
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 [enewland]
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 [fjh]
14:53:09 [enewland]
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 [darobin]
ack Suresh
14:54:23 [enewland]
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 [darobin]
ack darobin
14:55:19 [enewland]
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 [tlr]
14:55:51 [darobin]
ack fjh
14:55:51 [enewland]
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 [enewland]
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 [darobin]
[the default policy gives you this API, more trusted policy gives you these extras]
14:56:39 [enewland] this begs a question of what will happen with policy framework
14:57:44 [enewland]
suresh: This discussion should not affect the policy work that we are doing
14:57:48 [darobin]
14:57:52 [darobin]
ack tho
14:57:54 [fjh]
14:58:41 [enewland]
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 [darobin]
14:59:07 [enewland] 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 [richt]
+1 to tlr
14:59:23 [fjh]
in widget case can have additional functionality in conjunction with policy framework
14:59:25 [enewland] in this case, we should focus on widget case.
14:59:38 [darobin]
[I think we should write up tlr's summary as policy]
14:59:50 [fjh]
am I hearing that we might decide to limit policy framework to widget case?
14:59:53 [Dong-Young]
Dong-Young has joined #dap
14:59:59 [Zakim]
15:00:05 [bryan_sullivan]
15:00:07 [Dong-Young]
Presence+ Dong-Young_Lee
15:00:49 [enewland]
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 [darobin]
ack bryan_sullivan
15:01:38 [enewland]
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 [enewland]'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 [enewland] BONDi we have a clear policy framework that works in browsers and widgets
15:02:52 [enewland]
....we can apply policy in both contexts, it's just a matter of which implementations are going to embrace it.
15:03:12 [enewland]
robin: if we don't try, we can't succeed
15:03:22 [fjh]
15:03:49 [Zakim]
15:03:59 [enewland]
Bryan: If we succeed in mobile space, that is success.
15:04:08 [fjh]
zakim, who is here?
15:04:09 [Zakim]
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 [Zakim]
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 [enewland]
robin: but we don't want more fragmentation
15:04:19 [Zakim]
... ingmar, ilkka, dom, trackbot
15:04:31 [darobin]
15:04:50 [enewland]
bryan: we shouldn't be looking at this focusing on desktop browsers.
15:05:59 [enewland]
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 [Suresh]
15:06:22 [darobin]
ack Suresh
15:08:27 [enewland]
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 [fjh]
suresh suggests plan to review specs for additional functionality suitable for widgets case (but not web case)
15:08:45 [enewland]
Suresh: Would these drafts say these are only for widgets and not for browser
15:08:54 [richt]
agree with robin. something rough is better than nothing. and a good rough draft is good enough to discuss further.
15:09:32 [enewland]
robin: Yes, we can find some kind of phrasing.
15:09:39 [enewland] separating reading and writing file APIs
15:10:58 [Marcos_]
Marcos_ has joined #dap
15:11:10 [richt]
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 [darobin]
ACTION: Suresh to make proposals for Contacts and Messaging features in a trusted context due in three weeks
15:11:46 [trackbot]
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 [darobin]
15:12:00 [trackbot]
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 [trackbot]
15:12:04 [Zakim]
15:12:08 [fjh]
ACTION-253 due +2 weeks
15:12:08 [trackbot]
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 [fjh]
15:12:17 [trackbot]
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 [trackbot]
15:12:39 [enewland]
robin: We need use cases around what works in browser
15:12:39 [fjh]
action-253 due +3 weeks
15:12:39 [trackbot]
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 [fjh]
15:12:45 [trackbot]
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 [trackbot]
15:13:19 [enewland]
Robin: this leaves us without a resolution for messaging. We will return to messaging next week. Proposals are welcome in email
15:13:41 [enewland]
TOPIC: Capture
15:14:12 [enewland]
Robin: Shall we keep working based on feedback we received after publication?
15:14:23 [enewland]
...we should publish the API as soon as it's ready
15:15:00 [enewland]
Ingmar: we will wait one week and then discuss again.
15:15:15 [enewland]
TOPIC: SysInfo
15:15:25 [enewland]
Robin: Bryan sent a new draft
15:15:26 [fjh]
15:15:26 [trackbot]
ACTION-211 -- Alissa Cooper to make proposal on list for sysinfo privacy section -- due 2010-07-21 -- CLOSED
15:15:26 [trackbot]
15:15:34 [fjh]
15:15:34 [trackbot]
ACTION-213 -- Richard Tibbett to review sysinfo draft after edits made -- due 2010-07-21 -- OPEN
15:15:34 [trackbot]
15:15:42 [fjh]
15:15:42 [trackbot]
ACTION-243 -- Dong-Young Lee to review sysinfo draft after edits made -- due 2010-08-09 -- OPEN
15:15:42 [trackbot]
15:15:53 [fjh]
15:15:53 [trackbot]
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 [trackbot]
15:16:08 [fjh]
is sysinfo ready now for reviewers to review?
15:16:24 [enewland]
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 [enewland]
....edits that were captured during F2F - for privacy section - that have been included
15:16:46 [enewland]
....seem that most of outstanding comments have been addressed
15:16:52 [richt]
I believe the CVS DIFF is a good place to review the changes made to system-info by Bryan:
15:16:56 [enewland]
Frederick: Is it ready for review?
15:17:01 [enewland]
Bryan: As far as I can tell, yes
15:18:04 [darobin]
Zakim, [IPCaller] is Dong-Young
15:18:04 [Zakim]
+Dong-Young; got it
15:18:05 [Dong-Young]
Sorry for the noise.
15:18:14 [Dong-Young]
I said I will review it within 1-2 weeks.
15:18:16 [fjh]
q+ to ask to close ACTION-169 during action review section
15:18:23 [darobin]
ack fjh
15:18:23 [Zakim]
fjh, you wanted to ask to close ACTION-169 during action review section
15:18:37 [fjh]
15:18:37 [trackbot]
ACTION-169 -- Frederick Hirsch to insert temporary privacy language into the APIs. -- due 2010-05-05 -- OPEN
15:18:37 [trackbot]
15:19:04 [darobin]
close action-169
15:19:05 [trackbot]
ACTION-169 Insert temporary privacy language into the APIs. closed
15:19:06 [enewland]
Frederick: We should close action to insert temporary privacy language into APIs.
15:19:24 [fjh]
ACTION-169 closed
15:19:24 [trackbot]
ACTION-169 Insert temporary privacy language into the APIs. closed
15:19:37 [bryan_sullivan]
15:19:41 [darobin]
ack bryan_sullivan
15:19:48 [darobin]
15:19:48 [trackbot]
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 [trackbot]
15:19:52 [fjh]
15:19:52 [trackbot]
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 [trackbot]
15:19:56 [enewland]
Bryan: On SysInfo, ACTION-248, to address get versus watch may have been addressed
15:20:09 [darobin]
15:20:09 [trackbot]
ISSUE-92 -- Sysinfo, permissions for get vs monitor; -- open
15:20:09 [trackbot]
15:20:09 [enewland]
....statements in privacy section now.
15:20:19 [fjh]
ACTION-248: recent editorial action added warning re get vs watch
15:20:19 [trackbot]
ACTION-248 Provide a proposal relevant to ISSUE-92, sysinfo privacy prompts for operators get vs watch notes added
15:20:53 [darobin]
action-248 closed
15:20:53 [trackbot]
ACTION-248 Provide a proposal relevant to ISSUE-92, sysinfo privacy prompts for operators get vs watch closed
15:21:00 [darobin]
15:21:00 [trackbot]
ACTION-238 -- Bryan Sullivan to inform OMA groups of our status -- due 2010-07-23 -- OPEN
15:21:00 [trackbot]
15:21:04 [enewland]
Frederick: Is ACTION-238 still relevant?
15:21:38 [Dong-Young]
OMA CAB has been informed.
15:21:39 [fjh]
action-238 closed
15:21:39 [trackbot]
ACTION-238 Inform OMA groups of our status closed
15:22:00 [Zakim]
15:22:03 [Zakim]
15:22:10 [Zakim]
15:22:11 [Zakim]
15:22:11 [Zakim]
15:22:12 [Zakim]
15:22:13 [Zakim]
15:22:14 [Zakim]
15:22:16 [Zakim]
15:22:16 [fjh]
rrsagent, generate minutes
15:22:16 [RRSAgent]
I have made the request to generate fjh
15:22:16 [wonsuk]
wonsuk has left #dap
15:22:18 [Zakim]
- +4871719aaee
15:22:19 [Zakim]
15:22:21 [Zakim]
15:22:26 [Zakim]
15:22:27 [Zakim]
UW_DAP()10:00AM has ended
15:22:28 [Zakim]
Attendees were fjh, +1.202.637.aaaa, Thomas, nstratford, +44.757.091.aabb, richt, Suresh, Ingmar_Kliche, +, Fan_HU, +44.777.541.aadd, LauraA, bryan_sullivan,
15:22:30 [Zakim]
... darobin, +4871719aaee, wonsuk, +, Claes, Dong-Young
15:31:03 [MoZ]
MoZ has joined #dap
15:34:37 [Marcos]
Marcos has joined #dap
16:03:24 [shepazu]
shepazu has joined #dap
16:03:53 [shepazu]
shepazu has joined #dap
16:15:24 [shepazu]
shepazu has joined #dap
17:40:01 [Zakim]
Zakim has left #dap