See also: IRC log
<trackbot> Date: 11 August 2010
<fjh> ACTION-241 due next week
<trackbot> ACTION-241 Review and update policy requirements due date now next week
<fjh> ScribeNick: enewland
<fjh> next F2F WG questionnaire and TPAC registration and information
<fjh> WG questionnaire (for all), http://www.w3.org/2002/09/wbs/43696/tpac2010dap/
<fjh> TPAC registration (for in-person attendees) http://www.w3.org/2002/09/wbs/35125/TPAC2010reg/
Frederick: complete next F2F questionare and TPAC registration.Let us know if you will dial in so a bridge can be set up
... do TPAC registration as soon as possible
<fjh> March F2F questionnaire (Seoul, Korea)
<fjh> http://www.w3.org/2002/09/wbs/43696/seoul-f2f-dates/
<fjh> Messaging API FPWD published 10 August
Frederick: March F2F in Seoul, Korea.
<fjh> http://www.w3.org/TR/2010/WD-messaging-api-20100810/
<fjh> Web Notifications charter under review
<fjh> http://lists.w3.org/Archives/Member/member-device-apis/2010Aug/0001.html
Frederick: In the last call there was a discussion that the web notification charter was under review. So flagging that.
<wmaslowski> Present
Frederick: We need to approve F2F minutes. Should we wait another week?
<darobin> +1
Frederick: let's approve them today if no objection. One modification made yesterday. Cleaned up topics and made resolutions clear.
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2010Aug/att-0032/minutes-2010-07-14.html
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2010Aug/att-0032/minutes-2010-07-15.html
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2010Aug/att-0032/minutes-2010-07-16.html
Frederick: any objections to approving London F2F minutes? 14th - 16th
RESOLUTION: 14th-16th July minutes approved
<fjh> Approve 4 August minutes
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2010Aug/att-0022/minutes-2010-08-04.html
Frederick: August 4 minutes. Approve those as well?
RESOLUTION: 4th August minutes are approved
<fjh> Updated draft, see http://dev.w3.org/2009/dap/features/
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.
... Like Robin's suggestion about forming URI by pre-fixing a set string.
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2010Aug/0024.html
Frederick: still an open action out for features. Could use help moving this forward
... on policy requirements actions remain open on Paddy and myself [Frederick]
... Privacy, waiting on action from John and Erica
Erica: Still working with John on that
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2010Aug/0025.html
<wmaslowski> +4871719aaee is me probably me btw
Thomas: [Static during first part] Looking for people to be part of conversation
<richt> I've already indicated to tlr that I'll be available for such a teleconf.
Thomas: 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
<richt> I think Kangchan Lee should probably join that call also as he raised the original discussion (I believe).
Thomas: having information discussion on what would have to happen to get lunis supported
<Zakim> darobin, you wanted to ask about picking a time that works for people who use lunisolar
Thomas: If those interested are willing to push it, there is an opportunity here.
... we can try to find a more workable time if there are folks from Asia for whom approximately noon Eastern won't work
... Just make sure you let me know if you are interested in having the conversation
Frederick: Suresh and Robin had planned to attend
Richard: I plan to attend
Wonsuk: the time may be a problem, though I'd like to attend
Thomas: We know that Korean time is a constraint, will put that into planning email
<fjh> Updates planned for next week (see http://lists.w3.org/Archives/Public/public-device-apis/2010Aug/att-0017/minutes-2010-08-04.html#item06 )
Richard: Nothing to be done this week,. would like to publish a working draft at this point. A couple of bits around processing rules
<Zakim> Thomas, you wanted to ask about coordination item with Contacts
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?
<darobin> [+1 on helping coordination move faster with a heartbeat]
<richt> agree to publish a heartbeat working draft...significant changes (i.e. seperation of read and write) since the last working draft.
Suresh: On the liaison, i did participate in an OMA meeting earlier this week. We should get a liaison to W3C sometime next week
... 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.
... I don't believe we will get a login for accessing the documents that require one
Bryan: Every draft specification is public. Only meeting minutes and things of that nature are not public
Suresh: We can have links to documents input into IRC
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?
Richard: A few clarifications but major updates were mitigated by separating specs. Write-access still needs significant work.
<Suresh> 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
Richard: Proposing we publish contacts API, as there have been significant changes since last working draft was published.
<Suresh> Look under sub clauses 5.1.1.1 and 5.2.1.1
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
Richard: There is a note in the introduction. But we are still working out the write draft
Suresh: Has content changed since last publication? Aside from separating out write spec
... any change in terms of functionality
Richard: change in contact properties
<fjh> contacts editors draft -> http://dev.w3.org/2009/dap/contacts/
Richard: By splitting documents we ended up with empty contacts object. So flattened and refactored
<darobin> PROPOSED RESOLUTION: publish a heartbeat of readonly Contacts
<darobin> RESOLUTION: publish a heartbeat of readonly Contacts
<darobin> ACTION: Robin to handle publishing Contacts [recorded in http://www.w3.org/2010/08/11-dap-minutes.html#action01]
<trackbot> Created ACTION-252 - Handle publishing Contacts [on Robin Berjon - due 2010-08-18].
<fjh> Informal proposal for integration of Contacts API with HTML forms
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2010Aug/0026.html
darobin: Does it need more discussion?
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.
<richt> some of the issues with using <input> are explained here: http://lists.w3.org/Archives/Public/public-device-apis/2009Dec/0011.html
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
robin: we will wait a little bit and give people more time
<richt> alternative proposal I mentioned with <device> is here: http://lists.w3.org/Archives/Public/public-device-apis/2010Jul/0026.html
<fjh> thomas review,, http://lists.w3.org/Archives/Public/public-device-apis/2010Aug/0019.html
<fjh> ACTION-222?
<trackbot> ACTION-222 -- Thomas Roessler to review the Messaging security section -- due 2010-08-15 -- PENDINGREVIEW
<trackbot> http://www.w3.org/2009/dap/track/actions/222
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2010Aug/0021.html
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?
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.
... 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
Bryan: What is it that we are proposing in particular? The notification aspect only?
<richt> in addition there are SMS URIs in draft at IETF: http://tools.ietf.org/html/draft-wilde-sms-uri-20
Robin: Is this a widgets only API or are there usecases for Web pages interacting with this
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
<Suresh> +1 to Bryan
Bryan: so with regard to gateways that exist on network, those are partial solutions b/c they support nothing with regard to notification
Robin: We might then have something that only handles notifications
<richt> 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
Robin: 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
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
... we need to make these available in both contacts b/c that's what developers are going to want
<richt> I guess not. I guess I'm saying there may be more generic notification mechanisms available for incoming messages.
Suresh: second what Bryan was saying.
... 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
... 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
Robin: But how do you safely grant a website the right to send stuff? Is it a one-shot, is it every time, etc.?
Suresh: Whatever model we come up with for widgets - user consent or policy based, etc. - we could apply same principles to browser
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
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.
... 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 use cases we know of where the website would subscribe to device incoming email notifications? Hard to imagine
<fjh> tlr notes task specific form to limit risk
Thomas: an explicit use case for that should be on the table. And security considerations should be discussed
Bryan: As you look at security considerations case-by-case. Across these APIs we are establishing a default policy in absence of policy framework
... 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.
<darobin> [I can only point out that with AppCache there is an installation step — it's not an arbitrary website]
Bryan: You may download the app using AppCache and it is on the device
tlr: The different characteristic betweent he AppCache case and the widget case is that with AppCache I do not have a new security boundary
... with widget you have that boundary
... look at security domain and how many parties have access
<darobin> +1 on thinking about security domains instead of installation, the latter is just a mental shortcut
<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.
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
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.
... 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
Suresh: We talk about an API and scale down what browser can access and end up scaling down what the widgets can do.
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
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.
<darobin> [the default policy gives you this API, more trusted policy gives you these extras]
Frederick: so this begs a question of what will happen with policy framework
suresh: This discussion should not affect the policy work that we are doing
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
<darobin> +1
Thomas: 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.
<richt> +1 to tlr
<fjh> in widget case can have additional functionality in conjunction with policy framework
Thomas: so in this case, we should focus on widget case.
<darobin> [I think we should write up tlr's summary as policy]
<fjh> am I hearing that we might decide to limit policy framework to widget case?
<Dong-Young> Presence+ Dong-Young_Lee
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
Bryan: The complication is not on the question of how do you design or apply a policy framework in browser/widget context
... 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
... in BONDi we have a clear policy framework that works in browsers and widgets
... we can apply policy in both contexts, it's just a matter of which implementations are going to embrace it.
fjh: if we don't try, we can't succeed
Bryan: If we succeed in mobile space, that is success.
robin: but we don't want more fragmentation
bryan: we shouldn't be looking at this focusing on desktop browsers.
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
... 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
<fjh> suresh suggests plan to review specs for additional functionality suitable for widgets case (but not web case)
Suresh: Would these drafts say these are only for widgets and not for browser
<richt> agree with robin. something rough is better than nothing. and a good rough draft is good enough to discuss further.
robin: Yes, we can find some kind of phrasing.
... like separating reading and writing file APIs
<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.
<darobin> ACTION: Suresh to make proposals for Contacts and Messaging features in a trusted context due in three weeks [recorded in http://www.w3.org/2010/08/11-dap-minutes.html#action02]
<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].
<darobin> action-253?
<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
<trackbot> http://www.w3.org/2009/dap/track/actions/253
<fjh> ACTION-253 due +2 weeks
<trackbot> ACTION-253 Make proposals for Contacts and Messaging features in a trusted context due in three weeks due date now +2 weeks
<fjh> action-253?
<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
<trackbot> http://www.w3.org/2009/dap/track/actions/253
robin: We need use cases around what works in browser
<fjh> action-253 due +3 weeks
<trackbot> ACTION-253 Make proposals for Contacts and Messaging features in a trusted context due in three weeks due date now +3 weeks
<fjh> action-253?
<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
<trackbot> http://www.w3.org/2009/dap/track/actions/253
Robin: this leaves us without a resolution for messaging. We will return to messaging next week. Proposals are welcome in email
Robin: Shall we keep working based on feedback we received after publication?
... we should publish the API as soon as it's ready
Ingmar: we will wait one week and then discuss again.
Robin: Bryan sent a new draft
<fjh> ACTION-211?
<trackbot> ACTION-211 -- Alissa Cooper to make proposal on list for sysinfo privacy section -- due 2010-07-21 -- CLOSED
<trackbot> http://www.w3.org/2009/dap/track/actions/211
<fjh> ACTION-213?
<trackbot> ACTION-213 -- Richard Tibbett to review sysinfo draft after edits made -- due 2010-07-21 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/213
<fjh> ACTION-243?
<trackbot> ACTION-243 -- Dong-Young Lee to review sysinfo draft after edits made -- due 2010-08-09 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/243
<fjh> ACTION-214?
<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
<trackbot> http://www.w3.org/2009/dap/track/actions/214
<fjh> is sysinfo ready now for reviewers to review?
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.
... edits that were captured during F2F - for privacy section - that have been included
... seem that most of outstanding comments have been addressed
<richt> 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
Frederick: Is it ready for review?
Bryan: As far as I can tell, yes
<Dong-Young> Sorry for the noise.
<Dong-Young> I said I will review it within 1-2 weeks.
<Zakim> fjh, you wanted to ask to close ACTION-169 during action review section
<fjh> ACTION-169?
<trackbot> ACTION-169 -- Frederick Hirsch to insert temporary privacy language into the APIs. -- due 2010-05-05 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/169
<darobin> close action-169
<trackbot> ACTION-169 Insert temporary privacy language into the APIs. closed
Frederick: We should close action to insert temporary privacy language into APIs.
<fjh> ACTION-169 closed
<trackbot> ACTION-169 Insert temporary privacy language into the APIs. closed
<darobin> action-248?
<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
<trackbot> http://www.w3.org/2009/dap/track/actions/248
<fjh> ACTION-248?
<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
<trackbot> http://www.w3.org/2009/dap/track/actions/248
Bryan: On SysInfo, ACTION-248, to address get versus watch may have been addressed
<darobin> issue-92?
<trackbot> ISSUE-92 -- Sysinfo, permissions for get vs monitor; -- open
<trackbot> http://www.w3.org/2009/dap/track/issues/92
Bryan: statements in privacy section now.
<fjh> ACTION-248: recent editorial action added warning re get vs watch
<trackbot> ACTION-248 Provide a proposal relevant to ISSUE-92, sysinfo privacy prompts for operators get vs watch notes added
<darobin> action-248 closed
<trackbot> ACTION-248 Provide a proposal relevant to ISSUE-92, sysinfo privacy prompts for operators get vs watch closed
<darobin> action-238?
<trackbot> ACTION-238 -- Bryan Sullivan to inform OMA groups of our status -- due 2010-07-23 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/238
Frederick: Is ACTION-238 still relevant?
<Dong-Young> OMA CAB has been informed.
<fjh> action-238 closed
<trackbot> ACTION-238 Inform OMA groups of our status closed