See also: IRC log
<richt__> <meeting starting with a round of introductions>
<tomoyuki> +Present Tomoyuki_Shimizu
<richt__> anssik: Switch ServiceWorker topics the other way around?
<richt__> wonsuk: Need to discuss this with Alex. Has a TAG meeting this morning.
<richt__> wonsuk: Anssi, you could introduce ServiceWorker before App Lifecycle and Events and we'll go from there.
<richt__> wonsuk: We need to discuss some issues with Alex but later on.
<richt__> wonsuk: Any comments on other agenda items?
<Zakim> manu, you wanted to ask if we can introduce a brief 5 minute discussion about coordination w/ Web Payments group.
<richt__> manu: Want to ensure there is a good amount of collaboration between Web Payments and this group. Can we add that to the agenda?
<anssik> +1 to add Manu's proposed topic to the agenda
<richt__> wonsuk: Yes. Let's add that before the SE discussion?
<wonsuk> ?
<Zakim> richt, you wanted to demonstrate the queue
<anssik> http://lists.w3.org/Archives/Public/public-sysapps/2013Nov/0036.html
<richt__> <anssik introduces ServiceWorker>
<anssik> https://gist.github.com/slightlyoff/7fae65a908ac318f69a3
<gmandyam> +q
<richt__> richt: Any idea where this ServiceWorkers work will take place in W3C?
<richt__> anssik: We don't know yet and we need to coordinate with Alex on that.
<richt__> anssik: There's not really a spec yet.
<richt__> anssik: Seems like a good fit for WebApps? HTML?
<richt__> anssik: Extensions could be specified elsewhere e.g. this group.
<richt__> wonsuk: It's in scope for the WebApps WG.
<richt__> gmandyam: Is ServiceWorkers applicable to device APIs as well?
<richt__> anssik: I think it's a good fit for many device-related events.
<richt__> anssik: Could be good for e.g. alarms.
<richt__> kenneth_: It's on a case-by-case basis.
<richt__> kenneth_: Should look in to what Google did for Apps.
<richt__> gmandyam: In terms of Device APIs what can ServiceWorker provide that WebWorkers cannot provide today?
<richt__> anssik: Key thing is that ServiceWorkers can stay alive even if associated window is closed.
<richt__> anssik: We should ask Alex for full details on that.
<richt__> gmandyam: So it's a persistent background worker?
<richt__> anssik: Yes. e.g. Gmail client. Close the tab. You can be notified and brought back to Gmail.
<richt__> anssik: Not the same but have additional capabilities
<richt__> kenneth_: Events can restart the worker.
<richt__> anssik: This is behind a feature flag in Chromium. Nothing production quality at this point but you can check it out.
<richt__> anssik: Also experimental implementation happening in FF.
<anssik> chrome://flags/#enable-service-worker
<richt__> anssik: Building on experimental foundations. Share richt's concern here.
<richt__> anssik: But there is also some momentum and relatively confident this will end up shipping in all major browsers.
<richt__> gmandyam: When we implemented Persistent Workers we ended up putting up a UI so the user could see what was active, close things down, etc...
<richt__> gmandyam: ...Are you seeing any special types of permissions needed relating to ServiceWorkers.
<anssik> re ServiceWorker impl status: http://code.google.com/p/chromium/issues/detail?id=285976
<richt__> anssik: Good questions gmandyam. That's something that needs to be fixed on the platform.
<richt__> anssik: Permissioning is broken on the web and now we are opening up more powerful capable APIs. In the context of SysApps this permissioning model is yet to be decided.
<richt__> mounir_: We should not try to define APIs on when and how the permission will be set. e.g. FFOS - no permission up-front. If you mandate that type of model then they cannot implement it.
<jungkees_> Hi SysApps, i'm in WebApps now doing agenda bashing and i mentioned SysApps invites Alex this afternoon to get introduction about ServerWorker
<kenneth_> One way to make installable apps is reusing the service worker infra. Like on a webpage you could click on an install link which would basically make the service worker cache the whole app. Now that could be done with upfront permission granding, that would reask when an update requires further permissions
<richt__> anssik: So you're saying we should be agnostic on how and when permissioning works?
<jungkees_> And WebApps is sort of interested in talking about ServiceWorker together if time permits
<richt__> mounir_: Yes. The details will need to be thought out a bit more. Dev feedback - devs want to know when permission prompting is going to happen.
<jungkees_> 15:00 - 15:30 seems to be the prospective time slot WebApps can use
<richt__> mounir_: Maybe the API should be generic. Agnostic to user permission model.
<richt__> anssik: there's been some pushback on e.g. the Web Notifications permission opt-in model.
<richt__> gmandyam: You have X number of processes taking up resources in the background. An up-front permission model or permissions API is probably not going to work for that.
<richt__> Anders: sometimes you would like to disable certain permissions when you 'install'. Is that in scope here.
<richt__> anssik: I think it's an important point. If something is not available it would be good if we could gracefully degrade.
<richt__> anssik: Would like to see that built in to the platform.
<richt__> mounir_: If all APIs do not have permission up-front or whether they are all approved up-front should be an implementation detail.
<richt__> mounir_: If you want to give an option for the user to revoke access at a later point then the API should be ready for that / designed to handle that e.g. revocation.
<richt__> anssik: I agree.
<anssik> http://www.w3.org/2012/sysapps/app-lifecycle/
<gmandyam> Clarification: If there are webpages (X1, X2, ...} with associated number of service workers {Y1, Y2, ...}, then the number of service workers running could be Y1 * Y2 * ... The user may need to actively manage (i.e. shut down specific workers) when running on an e.g. FF OS device.
<anssik> http://lists.w3.org/Archives/Public/public-sysapps/2013Nov/0014.html
<richt__> anssik: The major change is that we use ServiceWorker as the base.
<richt__> anssik: There's also hooks in to the Task Scheduler proposal.
<richt__> anssik: We would like a normative dependency to ServiceWorker. Need to talk to Alex about that.
<richt__> anssik: currently 4 open issues.
<richt__> anssik: 1. Remove features without strong use cases.
<richt__> Open issues on App Lifecycle and Events available in email link above
<richt__> anssik: Would be good to have some discussion now on Lifecycle Events.
<richt__> anssik: Do we have consensus on the lifecycle events we want to expose?
<richt__> mounir_: still believe we can get rid of anything non-essential here.
<richt__> anssik: So what do people want to see the lifecycle events look like?
<richt__> mounir_: Probably implementor specific. Probably good to see what people do and standardize from there.
<richt__> anssik: In ServiceWorker you have 'on install time' events.
<richt__> anssik: When it's upgraded other events are provided. So only after install and after upgrade events in ServiceWorkers.
<richt__> mounir_: Agree with that approach.
<richt__> kenneth_: Another idea, if you don't get the permission up-front then you could get it when it wakes up?
<richt__> anssik: Interesting. e.g. Web Notifications are not time-sensitive. We could allow some delay in that permission opt-in.
<richt__> anssik: So it could try again at a later time perhaps.
<richt__> anssik: Agree with mounir_. Let's see what gets implemented and then tighten up from there.
<richt__> anssik: Another issue, the ServiceWorker could be killed at any time. Should we let the app know that is happening?
<richt__> gmandyam: if termination is resulting from an end-user action then it may not be desirable to allow it to persist until permission is obtained to kill it.
<richt__> gmandyam: There are likely valid reasons for end users to kill e.g. ServiceWorkers.
<anssik> chrome://inspect/
<richt__> anssik: There are a number of tools available in e.g. Chromium.
<richt__> gmandyam: There's a difference between a browser and an app installed in an OS.
<richt__> anssik: There was some work around Web Activities/Intents but not sure what's happening there.
<mounir_> ack
<Zakim> mounir_, you wanted to ask for UC for terminate event
<richt__> mounir_: One of the main issues with App Lifecycle and Events would seem to be on cleaning up
<gmandyam> Summary: The current def.'n for App LifeCycle events seems to sandbox the Service Worker to only rcv. events related to the app that created it. I asked Anssi if the intention is that this model could be extended to listen to other app's lifecycle events. He said no - this would have to be handled through inter-app messaging.
<richt__> mounir_: Sometimes the app could die before the system tells it it is dead.
<richt__> mounir_: therefore it may not be a good idea to add such clean up events.
<richt__> anssik: I agree with mounir_.
<wonsuk1> +1 for Mounir
<mounir_> mounir_ sometimes apps will not have enough time to save things between the terminate event and the app being actually killed
<richt__> anssik: Let's simplify and have a single event called 'launch' or something.
<richt__> anssik: Next issue, looking for a mechanism to pass data from the application that launch it.
<richt__> anssik: WeB Intents/Activities was promising for this.
<richt__> mounir_: Web Intents stopped due to UI issues.
<richt__> mounir_: Web activities and web intents were for different devices. They were designed with different UIs in mind.
<richt__> mounir_: unclear whether e.g. Web Activities works well on Desktop.
<richt__> mounir_: Google closed Web Intents because the UI was not working well there (on Desktop).
<richt__> mounir_: assuming we have web intents/activities at some point. The hook would be on the launch event. Data can be passed on events.
<richt__> mounir_: this is probably not a big issue for the work we're doing here.
<mounir_> mounir_: the hook would be on the launch event or on a specific event but anyway, the data will very likely end up in the event object
<richt__> anssik: issue 4 in my email (linked above) will likely be resolved at the ServiceWorkers level.
<richt__> anssik: Let's summarize the open issues now.
<richt__> anssik: issue 1: drop terminate/cancelled events.
<richt__> anssik: issue 2: get rid of reasons.
<richt__> anssik: issue 3: let's create LaunchEvent and later we can pass data to that implicitly.
<richt__> anssik: let's close issue 3 down.
<richt__> anssik: issue 4: defer to ServiceWorker spec.
<richt__> mounir_: let's take a break?
<richt__> <break time. meeting resumes at 11:10>
<dsr> scribenick: dsr
Mounir: we will move as a group to Shenzhen Hall at 3pm for a short discussion with webapps on service workers.
Next steps:
- Continue track ServiceWorker, align Application Events with the model
- Flesh out System Event delivery and registration (and/or defer to the ServiceWorker proper?)
<anssik> e.services = ["fetch"];
Anssi: may want to do registration in the manifest
- Permission control, need a consistent model that works for ServiceWorkers
Following discussion before the break, we may want to give implementations some freedom in his permission requests are handled (when apps are installed, or later at time of use)
Wonsuk: we tried to set a joint
meeting with WebApps about manifest, but it was
cancelled.
... some discussion via email, e.g. on use of meta tag, but no
consensus as yet.
Anssi: we continue with the App Life Cycle, simplifying it and aligning it with the Service Worker spec as that evolves.
Kaz: interested in possible relationship to W3C work on multimodal interaction architecture model
<kaz> MMI Architecture
Kaz: I've invited Anssi to join the MMI meeting this week.
<kaz> mmi f2f schedule
Anssi: Kaz can you please introduce the MMI WG?
Kaz: MMI Architecture is actually quite simple and defines life cycle events for loosely coupled multimodal applications
Anssi: what are the main use cases for that?
Kaz presents the MMI architecture spec http://www.w3.org/TR/mmi-arch/
The MMI WG will hold an introductory session on the MMI Arch this Thursday morning and you are all welcome if you're interested.
Mounir: does anyone have questions on service workers and relation to SysApps at this time?
Anssi: asks Rich about Opera's interest in this topic
Rich: we've moved the opera
browser over to Chromium, and want to add some opera specific
APIs on top of Chrome.
... We've looked at extending the Chrome CRX extension
APIs
... We looked at what is being done for Firefox as well as
Chrome and think there is value in standards around the
manifest format.
... There are lots of different views, but it is interesting to
see what level of consensus can be reached around the manifest
and SysApps APIs
Anssi: manifest and app packaging?
Rich: we're starting from Chrome CRX but want to move towards a standards based solution
Mounir: I was speaking with some Mozilla guys. Moving the manifest format spec to WebApps, but slow progress.
Rich: meta headers ...
Mounir: the full requirements for apps is too large to standardize all at once
Rich: we're currently considering adding hosted apps to the device's home screen, and meta headers are effective for that
Anssi: it is likely that both meta headers and manifest will need to be supported to handle legacy and future
Mounir: meta headers are not that efficient and don't scale as requirements grow
<anssik> +1 on Mounir
Rich: I can agree with that sentiment, but let's focus on simple requirements as a starting point, i.e adding apps to home screen
Mounir: let's say you want to a link to facebook, but we need to worry about refresh
Wonsuk: manifest looks like a better long term solution
<mounir_> mounir_: in that case, you might want to have a property to define the bits of UI your website wants to use even if "bookmarked"
Anssi: Rich you seem to be describing an install API which includes a reference to the manifest.
Rich: install can pull data from
the page or manifest ...
... does WebApps have manifest on their agenda this week?
Mounir: no
If you guys want to continue to discuss manifest here and now, we have time
Kenneth: there is no standard around how to use the meta tag content
Mounir: concerned that if we follow the meta tag route we risk a repeat of the problem's seen with app cache
Rich: even a simple meta tag to indicate that this is a web app is complicated as seen by the differences in current implementations
<mounir_> mounir_: (concerned because trying to specify a too simple solution because it is easy to implement and ship might prove itself limited later)
<kenneth_> kenneth_, the problem with meta tags is that the page has to be refeched with extensions disabled to make sure that extensions etc didn't modify the dom (ie. add extra permissions etc)
Rich: apps can update the meta
tag up to the point that the user adds the app to the home
screen
... we can take a snapshot at install time
<JonathanJ> web manifest - http://www.w3.org/2008/webapps/manifest/
Anssi describes risks around attacks that confuse user into installing a malicious app
Mounir: solution is to use CSP (content security policy) forbidding this
Rich: CSP gives us the control we need
Anssi: I would like to revisit app packaging formats.
Mounir: are developers willing to change their implementation around packaging? If not we are wasting our time discussing packaging.
Anssi: we are focusing on API interoperabiity, but not around packaging right now
Kenneth: but what about the future?
Anssi: can this working group resolve that we aren't working on interop around packaging?
Mounir: packaging is not out of scope, but also it is not a priority
Anssi: zipping is easy, but signing is hard
Anssi invites Anders as an expert on signing to state his view
Anders: best to adopt existing solution where possible
Rich: unfortunately, different vendors handle signing differently, so the ship has sailed on that
Mounir: if we use the same APIs that developers only have to deal with packaging for each app store
Anssi: on the list we raised whether the existing SysApps charter reflects the current reality? Should we revise the charter, or should we update the home page to clarify the group's priorities for people coming from the outside
<virginie> +1 on anssi proposal to clarify priority and deliverables scope
Mounir: we need to establish a consensus before any consideration of changing the charter
Giri: rechartering would help to set clear expectations on priorities
Rich: we need to foster APIs with strong implementation support
<richt> richt: how do we get people excited about the _idea_ of implementing standard APIs across runtimes?
Anssi: SysApps focuses on
privileged APIs
... we need an environment to expose such APIs safely
Rich: executing the same code base in different environments should be our objective
Virginie: I would support work on clarifying this group's expectations. A Working Group Note would be valuable
<richt> re: 'executing the same code base in different environments'. That's why the web itself is so successful. Everyone is standardizing APIs because the same code base runs everywhere. That's not the case yet in SysApps.
Virginie: we would like to help, but need others to join in
Mounir: it seems like the consensus has shifted on privileged vs web APIs, e.g. focus on service worker. Interested in changing charter to allow us to work on web apis as well as privileged environments.
Rich: good that SysApps is working on privileged APIs
<Kenneth> Kenneth, we have raw sockets implemented in our new runtime (privileged)
Giri: there are some things like dialer that you want to avoid every tom, dick and harry re-implementing.
Dave: we have further time on this topic tomorrow afternoon. We need a short but clear statement of a consensus on the group's goals
<gmandyam> Summary of what I was trying to say: the current charter has lumped very different types of deliverables into Phase 1 which has bogged down the group. For instance, telephony has proven difficult and is probably not an API that should be exposed to arbitrary 3rd-party developers.
Rich: agreement on the execution environment is hard but a higher priority that say the contacts API
<mounir_> mounir_: to follow-up on Giri's comment, I would be happy to see Messaging, Telephony and maybe Contacts being de-prioritezed
<gmandyam> Summary (cont.): Raw Sockets would be required for 3rd-party developers to provide them equivalent capability to what they have in native programming environments.
Mounir: we should get a consensus on goals before discussing specific APIs
<gmandyam> Summary (cont.): Yet Raw Sockets and Telephony are both considered high-priority API's in the current charter.
Anssi: we may not need to recharter, but we certainly need a document setting out the priorities, perhaps just updating the home page and wiki
Mounir: we can continue this
discussion tomorrow afternoon including the charter.
... We will now break for lunch at resume at 2pm, and then walk
over to WebApps at 3pm.
<genelian> wonsuk, could you please put the link on the Agenda for DataStore API?
<mounir_> Scribe: mounir_
<scribe> ScribeNick: mounir_
<efullea> Hi, I am having troubles to dial in. It says the conference is restricted. I see you are not bein gable either
<wonsuk> DataStore API: https://wiki.mozilla.org/WebAPI/DataStore
genelian: I will give you an
overview of the DataStore API but we did not write a full spec
yet
... <points to DataStore API link>
... the goal of the API is to improve syncing and searching
given the issues we had it Contacts and Messaging
... it was very hard to define a Messaging API that would
fulfil all the requirements of a Messaging app, for example,
having group of messages
... the solution was to have a very simple Messaging API
(send/receive) and there would be a central DataStore that
would be used sync'd with
... so the application could do its own filtering based on its
own UI requirements
<efullea> * Hi Dave, the instructions in the wiki states you should type: zakim, call Wutong_West have you tried that? I am still not able to join...
<Yudong> JINGWANG-QI: hi
genelian: <describing how
DataStore have a common name to be able to merge
DataStores>
... <describing how the sync() call synchronize the
DataStore>
... the change event will be fired when the datastore is
updated
... we are hoping to replace the our existing Messaging API and
Contacts API to use this DataStore API
... we will put our design and ideas in a git repository so
anyone can contribute to that
<efullea> * ok dsr, I will wait until you solve the issue. thanks
genelian: before switching the
Messaging API to use DataStore, we might need to fix a few
pending issues
... Zoltan and Marcos seem to be interested to have a separated
interface that would be specialized for the searching and
filtering
... that way, the DataStore API will not only help synchronize
data but also help the app adds some semantic by having some
indexes for example
... like the phone number of a message or the delivery
time
... that is pretty much it
ack
mounir_: I was wondering if you have any feedback regarding performances
genelian: we have this
implementation but we do not use it yet
... the next step is to use it to maintain the conversations
for our messaging application
... but you are right that performances are going to be a very
big issue
<efullea> Hi mounir I am interested in the overall discussion but I have no feedback on performance
genelian: the app will get an event every time there is a change which might require the app to change its index and make it slower than the current system
<efullea> * very low
efullea: there is no major issues
open
... so, unless there are new issues opened, we should go to
LC
wonsuk: what about DataStore in Contacts API?
efullea: we are doing some experimentations but it is too early to say
<gmandyam> Summary of my comment: Data Store API is a two-step op for synchronization: (1) Invoke DataChangeEvent handler, and (2) Call sync(). The developer gets the benefit of a more flexible data model w/Data Store for Contacts/Messaging, but at the expense of managing synchronization with the local store.
mounir_: so, to summarize, there
no outstanding issues except DataStore to go to LC?
... I propose that efullea takes an action which is check
whether DataStore API is okay for the Contacts API and we
should also make sure there is still some group interest in
this API given that there was no activity in the past
month
... after that, we could see whether the specification should
go to LC as is
<efullea> o
<efullea> ok
<scribe> ACTION: Eduardo will check whether DataStore matches Contacts API needs [recorded in http://www.w3.org/2013/11/11-sysapps-minutes.html#action01]
<scribe> ACTION: Mounir will check whether there is still group interest for the Contacts API [recorded in http://www.w3.org/2013/11/11-sysapps-minutes.html#action02]
efullea: the problem with
messaging is similar to Contacts API with regard to
DataStore
... I don't know of any implementation of Messaging using
DataStore, maybe someone in the room is experimenting
that?
...
... <reading the issues listed in the email he sent to the
group, listing the changes since the last F2F>
... so, unless we move to DataStore, we can go to LC very
shortly
<Zakim> mounir_, you wanted to ask if Mozilla is experimenting that in FxOS
mounir_: I was wondering if Mozilla is experimenting Messaging with DataStore
genelian: we do not for the
moment, it is complex and it will take a couple of months so it
might unlikely happen before the next F2F
... all we are discussing now is actually mostly
theoretical
mounir_: do you want to go to LC without DataStore?
efullea: yes
mounir_: I feel that going to LC without DataStore might be counter-productive if we do use DataStore
anssik: can we push out LC1 and then push out LC2 after some major changes?
mounir_: I propose to have as a resolution to not move Messaging API before we have as stronger opinion regarding the DataStore API
anssik: I agree, this specification do not look stable to me
efullea: it sounds like blocking the specification for a few months, I do not know if we should do that but I am fine either way
anssik: going to last call is an expensive step because we ask to other groups to review your work and people might end up using their time reviewing this API knowing that we might go to a totally different path in a few months
mounir_: I propose to put an action on efullea to lead the discussion regarding whether the DataStore API should be used for messaging
<efullea> ok
<scribe> ACTION: Eduardo will lead the discussion to see whether the DataStore API should be used for Messaging [recorded in http://www.w3.org/2013/11/11-sysapps-minutes.html#action03]
RESOLUTION: Messaging API will not go to LC until the DataStore situation is stable
mounir_: we have a few minutes to
wrap up and go to the other room for the joint meeting with
WebApps
... we will be back there after the Service Worker discussion,
I do not know when
<dsr> We are about to resume after a coffee break following the joint session on service workers with WebApps.
<scribe> Scribe: mounir_
<scribe> ScribeNick: mounir_
<zolkis> https://rawgithub.com/sysapps/telephony/gh-pages/index2.html
zolkis: the current spec is here:
https://rawgithub.com/sysapps/telephony/gh-pages/index2.html
... there have been a few changes, that is why it is
index2.html so people can compare to the previous
document
... <summarizing the list of changes from the email to the
list>
<zolkis> short summary on the Telephony spec
<zolkis> TelephonyManager now implements a series of interfaces:
<zolkis> services related, call management, tone management, emergency numbers, command parser
<zolkis> ServiceManager can also implement CallManager and EmergencyManager
<zolkis> in this spec navigator.telephony implements them and it is the main entry point
<zolkis> the service + command parsing support was added because issues raised asking for support
<zolkis> also, client side call merge is supported
<zolkis> which made the API very suitable also for supporting VoIP calls
<zolkis> this is the summary
<zolkis> questions?
dsr: how many of the companies here want to implement this?
<zolkis> Intel will do it for 2 telephony backends and 2 platforms
<zolkis> Mozilla implementation is close to the spec, but would require some work, to support the current split of functionality in interfaces
<zolkis> on Android and Crosswalk
hsinyi: this is close to what Mozilla does but the structure is different so it is not clear whether we have the ressources
mounir_: Google is not going to implement that anytime soon as far as I know
<zolkis> can't hear, I rely only on the chat transcript
gmandyam: it would be interesting to know if the spec is stable enough so I could get feedback internally
mounir_: it would be interesting to get some feedback from Qualcom indeed
<zolkis> yes, it is now - I will add support for constructing the events where it is missing
<zolkis> but I will do it today, and it is a small change
<wonsuk> How many outstanding issues are there in Telephony API spec?
<gmandyam> OK - will get a review from our internal telephony team.
<zolkis> I will close them one by one as this current proposal gets reviewed: most of the issues should be solved by now
<zolkis> they are not recorded to be solved, but I will make a swee[p
<zolkis> right now there are 31 open issues
<scribe> ACTION: gmandyam will send the specification internally to get some feedback from Qualcom telephony team [recorded in http://www.w3.org/2013/11/11-sysapps-minutes.html#action04]
<zolkis> thanks gmandyam! that would be helpful
mounir_: what's the next step for the specification?
<zolkis> clean up the open issues, get feedback from Qualcomm
<gmandyam> Zoltan, is CellularService going to be spec'ed or not? - Giri
<zolkis> right now that is a note that it could be spec'd - but should it be done in this document, or in a separate one?
mounir_: we will need Mozilla implementation (or another one) before going to LC
annsik: but it is not required until CR, right?
mounir_: indeed but it is a good practice to get two implementations to go to LC
gmandyam: given that this is quite linked to the modem, having two multiple implementations is even more important than usual
<zolkis> gmandyam, specifying all cellular interfaces is a huge work; it can be done, but we need to justify the effort; right now what we know is how to do it when it comes to it
<zolkis> the modems are abstracted by TelephonyService
<zolkis> mounir_: is having two implementations from the same company good enough?
<wonsuk> It would be great if Mozilla also review and give feedbacks about current Telephony spec.
zolkis: the implementatios have to be independent I believe
<zolkis> yes, but they are done by different teams
<gmandyam> To clarify:Is the "Two Implementation" rule of thumb that normally is used in W3C really applicable to telephony API? Should it be two implementations involving different modems? Or is two web runtime implementations using the same modem sufficient?
<zolkis> if you define independent by company, then we need someone else, too
<zolkis> yes, still questions
<gmandyam> Zoltan, Is Tizen implementation going to be verified with Intel modem?
<zolkis> I think we should support at least 2 different modems
<zolkis> and also, 2 different telephony middleware + os
dsr: I think that the w3c director is looking for entirely independent implementations so in this case, we might want different modems
mounir_: zolkis, anything else?
<zolkis> I agree
<zolkis> let's continue by emails and by discussing issues
<zolkis> https://github.com/sysapps/telephony/issues?state=open
mounir_: sounds good, let's move to the next topic, if we can reach Marcos
<MichaelH> Q: CamelCase for oncalladded, callremoved, activechanged?
<zolkis> not for events
<anssik> +1 to move app URI to LC
<gmandyam> See http://lists.w3.org/Archives/Public/public-sysapps/2013Oct/0042.html. RichT had asked about whether app:URI can be more broadly applied.
<gmandyam> My comment: I think it could be used for broader purposes without affecting its current functionality by relaxing the requirements in Sec. 6.4
<richt> Here's a follow up use cases for adding additional app:// URI dereferencing models without affecting 'package' dereferencing currently defined: http://lists.w3.org/Archives/Public/public-sysapps/2013Oct/0053.html
<scribe> ACTION: Mounir will reach out internally at Google to get some feedback regarding the specification [recorded in http://www.w3.org/2013/11/11-sysapps-minutes.html#action05]
MichaelH: I had a question about app lifecycle regarding the cancel event, I am not sure what is that for
anssik: it was actually dropped
<dsr> we close for the day
<Github> [13telephony] 15zolkis opened pull request #211: added constructors to events for testability (06gh-pages...06gh-pages) 02http://git.io/ku7dCQ
<Github> [13telephony] 15zolkis closed pull request #211: added constructors to events for testability (06gh-pages...06gh-pages) 02http://git.io/ku7dCQ
<Github> 01[13telephony01] 15zolkis pushed 2 new commits to 06gh-pages: 02http://git.io/UEuRuw
<Github> 13telephony/06gh-pages 14b7f5453 15Zoltan Kis: added constructors to events for testability
<Github> 13telephony/06gh-pages 1490fc613 15Zoltan Kis: Merge pull request #211 from zolkis/gh-pages...
<cdumez> Hi, I am on the line
<dsr> agenda: http://www.w3.org/wiki/System_Applications:_3rd_F2F_Meeting_Agenda_TPAC
<dsr> chair: Mounir
<dsr> scribe: Mounir
mounir_: <greetings>
... we will start with the Task Scheduler API and because
Christophe is on the phone, we will mostly use IRC
... so please, make sure to join the sysapps channel
mounir_: we are going to start with a status update from Christophe
<cdumez> This is me on the phone but I barely hear anything
<cdumez> so I can use IRC if this is OK
<jungkees> Yes!!
<cdumez> Task Scheduler API draft URL: http://www.w3.org/2012/sysapps/web-alarms/
cdumez: since the last F2F, I
made three changes to the specification
... the first one is removing the timezone support from the
API, it simplifies the API quite a bit
<cdumez> * http://www.w3.org/2012/sysapps/web-alarms/#taskscheduler
cdumez: especially the add() method
<cdumez> * http://www.w3.org/TR/WebIDL/#common-DOMTimeStamp
<anssik> http://lists.w3.org/Archives/Public/public-sysapps/2013Nov/0012.html
cdumez: the API is no longer using Date but DOM timestamp, defined in WebIDL
<cdumez> Date.now() + DELAY_IN_MS
cdumez: the second change is that
we no longer throw an exception if the schedule is in the
past
... instead, the new behaviour is to fire the task as soon as
possible asynchronously
... otherwise, there have been some discussions recently on the
mailing list, mostly about adding support for priority about
scheduling an alarm
... whether the time has to be exact or can be delayed
... I propose something in the mailing list and I am waiting
for feedback on this one
... This is is regarding the status of the API
mounir_: any question or comment?
dsr: the usual question: who is implementing the specification?
<anssik> +q
kenneth: because of the unknown relationship with the service worker, we can't implement that spec yet
anssik: +1
mounir_: I was going to ask Christophe about that actually
annsik: functionaly-wise I feel that it could happen in service worker
anssik: cdumez, any comment?
<cdumez> I am not familiar with service workers yet, sorry
<cdumez> Right now the API relies on system messages from Runtime specification
<anssik> https://gist.github.com/slightlyoff/7fae65a908ac318f69a3
<cdumez> But last I heard, system messages would get replaces by sometimes else more chrome-extension like
mounir_: regarding implementation status, there might be some interest at Google to implement that but if that happen, it would be on top of Service Worker I believe
anssik: I pasted a link that has
a draft about using alarms on top of service worker
... I would like to know if chris wants to keep that has
standalone or want to build it on top of service worker?
mounir_: while waiting for Chris to reply, what about Mozilla implementation status?
genelian: we have an implementation but we use System Messages for the moment
thinker: my concern is the
removal of timezone,
... there are issues with device time and local time
... <explaining issues with not having timezone
parameter>
mounir_: will you switch to Service Worker if we happen to change the spec?
genelian: it should be realisable
<Zakim> anssik, you wanted to ask if the Moz impl is still moz-prefixed
anssik: is the implementation prefixed?
<Zakim> mounir_, you wanted to ask about the relation with the spec and Service Worker
<anssik> navigator.mozAlarms
anssik: if the implementation is still prefixed, it should not be a problem to switch?
mounir_: I believe it is prefixed
genelian: yes, it is prefixed
<scribe> ACTION: cdumez will write a new Task Scheduler specification based on Service Worker [recorded in http://www.w3.org/2013/11/11-sysapps-minutes.html#action06]
<cdumez> Oh was that agreed? :)
<cdumez> Was service worker merged into the runtime specification?
<cdumez> I mean that the task scheduler API is using what is defined in the runtime specification currently.
no, we will build the app lifecycle on top of it
the runtime specification is going to be shelved
with some definition of shelved
<cdumez> Ok, well, if the group agrees, fine by me
<anssik> re http://www.w3.org/2012/sysapps/runtime/ status: "The System Applications Working Group is currently not progressing the approach outlined in this draft. Please treat this document with caution and do not reference it or use it as the basis for implementation. The domain covered by this document is still within the scope of the Working Group as defined in
<anssik> its Charter."
<renoirb> Hi everybody!
manu: the work that we are doing
in the Web Payments group is build payments in the core
architecture of the Web
... if you go to a website, you should easily be able to build
a product that you want using APIs
... As you can expect, when you are talking about Payments,
identity and security is important
... that is why the work of SysApps is important to us
... for example, being able to access a Secure Element is
important regarding security
... My goal here is to give a heads up to let every one know
that we have a Web Payment group
... How many people here believe that the web payments work is
being to affect there organization?
... would you be interested to join the Web Payments group
given your organization progress in web payments?
... We have a breakout session on Wednesday
... the second question is how to integrate the Web Payments
work with SysApps?
anssik: so you guys don't have any concrete proposal at this time?
manu: actually, we have a set of
specs (8)
... we don't need sysapps work for the moment but we might need
secure element at some point
anssik: could you briefly summarize the implementations?
manu: we have nothing
implementing in major browsers
... because we don't want to get blocked
... it is mostly working around de-centralized approach like
Mozilla Persona
... we are also working with the IETF
... (like HTTP Signature spec)
... <explain some use cases>
... we have Mozilla, Bloomberg, small security companies
... financial institutes are also interested
... because Web Payment would allow touching the 2.5 billions
people that do not have a bank account
ack
<Zakim> mounir_, you wanted to ask more details about the implementations status (who is expected to implement? and who implements? basically, is it interoperable?)
manu: Mozilla Persona is not a
requirement but we are looking for a nice identity solution and
Persona is a nice one, that is why we use that
... the idea is not to take what Mozilla has currently and
stamp it as a standard and go one
... we had a lot of discussions with Mozilla teams on
this
... what I am saying is that it would be ideal if Mozilla
Persona continues in the trajectory it is on
... if Persona work fails, they are going to need an identity
solution and we have a backup spec if that becomes
necessary
... so that is kind of where we are with Mozilla on this
... as far as who is required to implement this, there are a
couple of answers for that
... one set of implementers would be the banks
... we have been speaking with banks standard body
(SWIFT)
... they want something that is Paypal/Google Wallet that is
open so any bank can use it
... the other group that is interested in this work are the
large technology companies that could compete with the banks if
they implement the solutions
... cellphone providers and operators are in a third
basket
... if you have a mobile phone, it is very easy to associate it
with a credit card or a bank account of some kind
... and the fourth group of implementers,
... are implementers of the identity solutions like governments
so banks can digitally verify identity of their customers
<Zakim> anssik, you wanted to ask if NFC is in scope
manu: NFC is optional, there are
many things that we could add to this work
... we would love to use NFC but it is not a requirement
yet
... no one is really screaming NFC yet in the group
Fan: two questions: does web
payments have other solutions if Secure Element do not take
off?
... <not understood>
... are you considering the security issues regarding running
JS code?
manu: the secure element seems to
be our best best right now
... an alternative might be to use the Web Crypto API
... both those solutions would be related to client base
digitil signature
... all those stuff would happen in the cloud
... we do not require those mechanisms for the moment but we
would like to make this happen
... regarding running JS alongside the API we are running
... yes, we looked into it but we do not think it was good
enough
... and we would have to do many security passes
... right now, there is no client side code
... any of the standard security issues we have (click jacking,
...) exist for Web Payments
... for the moment there is no API running on the client so
there is no attack surface yet
... hopefully that answers your second question
... I will drop two links on IRC: a Mozilla Hacks blog post and
a link to join the group
<anssik> manu: now a CG, planning to create a WG, to have a workshop in ~March 2014
mounir_: we will do Secure Element and then finish the morning sessions early
<Anders> manu: https://payswarm.com/intro <--- introduction to PaySwarm
<Anders> manu: https://payswarm.com/join <-- instructions on joining Web Payments group
dsuwirya: <greetings>
<Anders> manu: if you want to contact me directly - msporny at digitalbazaar.com
dsuwirya: <presenting the
specification>
... the intention this morning is to judge the interest of the
group for the Secure Element
<MichaelH> Secure Element API:http://opoto.github.io/secure-element/
<wonsuk> Secure Element API: http://opoto.github.io/secure-element/
dsuwirya: the secure element is a
micro controller with RAM, ROM, etc.
... it offers hardware and software protections against the
attacks
... it usually have a JVM running so we can run different
applications
... the purpose of the interface is to provide an interface for
web applications to talk to the applications running in the
SE
... the SE is complying to ISO7816-4
... there are many form factors
... most commonly on a credit size card
... <showing his card>
... this one can be contact or contact-less
... the second form factor is the one we have on Mobile, we
call it ICC
... it is mostly called a SIM
... but it is actually the application responsible for the
network access but it is only on part of the SE
... finally, some SD cards have a SE inside, even some have NFC
supports
... it could also be a USB tocken or a passport
... when we are talking about applications for the SE, we are
talking about two parts:
... on card applications and off card applications, they run
respectively inside and outside the SE
<virginie> s/ICC UUICC
dsuwirya: about UC
... the first common UC is about strong authentification
... for email signature, encryption, etc.
... a second common UC is digital signature
... the strong point of the SE is that the key and the
signature computation will happen inside the card
... which prevents extracting the key and ensure the integrity
of the process
... the third UC is about payment
... for card present transactions
... the last UC is credential provisionning
... to top up credit remotely on your card for example
... that is for the most common UCs
... the next section about the relationship with the other W3C
APIs
... to underline that there is no overlap
... regarding security and privacy, the problem is similar to
the rest of API we are going to discuss with SysApps
... there are the same problems as in bluetooth api
... in order to insure integrity and security, we can use the
trusted execution environment
... or we can also use an already existing secure
messaging
... protocol
... We can also use the trusted environment here to help secure
the interface
... in a desktop environment, we can use hardware feedback - to
enter the PIN
... Usually, we are limiting the access to the secure element
to only trusted applications
... The secure element will have a list of trusted applications
that the OS will provide before the SE talks to an
application
... The last point is traceablitiy
... the last point is describing the relationship between
actors around the Secure Element
... to use SE, we need a reader, there can be one or more
reader per device
... for example, NFC, sim slot, sd card slot are all
readers
... The next entities is the container of applications that can
run multiple apps at the same time
... if you look at the flow of the diagram there, the idea is
to first get the SecureElementManager
... then, the manager will provide the methods to enumerate the
readers
... from there, we can establish a session with the SE and a
channel with the application you want to talk to
... This is the interface that we wrote to represent those
entities
... <describes the interface>
... <showing a snippet of code from the
specification>
... any question before we go to the demos?
thinker: with this API, we send
low levels commands to the SE
... with this API we do not know which features are available
in the SE
... which means that if you give access to the SE element to an
application, it will have access to everything
dsuwirya: the level you are
talking about is at the service level
... defining interfaces at the service level is not
sufficient
thinker: my question is that
wants we get a certificate, we want the application to use that
certificate to do something specific but we can't control what
the application is doing
... with this API, we can not do this kind of control
MichaelH: I think that the issue
here is a protocol communication channel
... you would have to implement that yourself in a
client/server architecture
Mohammed: when you get the authorisation to access a feature for your application, it is only available for this session
thinker: you mean that you use different channels for different features?
Mohammed: you have to reopen a new signature for new application
thinker: <repeating the question>
Fan: would the secure element be
in televisions?
... <scribe did not understood the second question>
Mohammed: we have that already
Fan: is it using micro-sd?
Mohammed: no, chipset cards, to get content from service providers
Fan: maybe not all tv will have a slot
MichaelH: the form factor is not really involved in the specification
Fan: <scribe still not understood>
dsuwirya: TEE is out of scope of this API
rsleevi: I am concerned with this
on a security and performance side
... this API is the scariest I have ever seen
... <concers about the sync aspect of the APIs>
... and this api gives access to everything or nothing
... I disagree that the PIN is enough to solve this
problem
... I think the performances implication of insertion and
removal events is scary
... this is not future-compatible
... I would like to see a way to restrict the API to specific
applications
Mohammed: we never had
performance issues so far
... and we have malware checks for security
... and did had any issues with that
<Zakim> dsr, you wanted to ask about installing new applications on the card, e.g. when installing a new payment solution provider
<m4nu> +1 to what rsleevi just said - very concerning.
Mohammed: today, there is no standard on this
<m4nu> Manu: +1 to what Ryan Sleevi said, the API needs some work wrt Promises and has some security concerns that the Web Payments group will have more input on in the future.
dsr: [...] that was the first question, the second question was about the PIN, did you consider alternatives?
MichaelH: it does not really
matter what is being used, it just needs to be some bytes that
matches what the card knows
... it could be one digit, two, a thounsand
dsuwirya: <doing demo>
<dsr> I was asking about alternative means to support user presence authentication such as finger print scanners, and the implications for SysApps.
<dsr> Some kind of trusted computing environment is needed to secure the user presence info.
Mohammed: <showing a video>
dsuwirya: to add a little bit about payments, there is a nation-wide payment system that will be available this year in the US to pay by tapping (card present payment authorisation)
RESOLUTION: there are some concerns about security and performance regarding Secure Element - this should be worked on, such as the implementation intent
<Claes> Yes, the passcode is not accepted
<dsr> zakim is there room for 6 at 06:10Z for 240
<Claes> Yes, sorry. Unfortunately I don't have Skype installed on my job computer now. I can fix that now but it will take some minutes or so I assume.
<Claes> Yes, move on. I'll come back
anssik: let see what I wrote
http://lists.w3.org/Archives/Public/public-sysapps/2013Oct/0010.html
anssik: the first assertion is
this thread was that it might be hard to find consensus with
sign apps
... and even if we do, it wight not be interoperable
... so, what are we doing with un-signed app then?
... we want to bring more clarity about the deliverables from
this group?
richt: how is this different from what we discussed yesterday?
anssik: it's quite the same
richt: I agree that the ship is
sailed
... and that the packaging format is different
... as I said yesterday, the focus of the group should be
running the same code base
... that's what I would like the objective to be
anssik: I would like to wake
Jonas
... what do you think?
sicking: it appears to be that we
are not in a position where we actually can get implementations
to change
... I think that neither Chrome OS or Firefox OS will implement
Widgets
... we should focus on hosted apps via the manifest
specification
... I got very positive signals from various browser
vendors
... It won't be a complete runtime but a start
... and hopefully we could evolve that to a real runtime
overtime
... We might have issues with APIs that require trusted
code
... Marcos thinks that we can just leave the security aside but
I am not sure
... it might work for TCP Sockets though
... probably not for Telephony
mounir_: I quite agree with
Marcos that we can ignore how the permission is granted to an
API as long as APIs are able to handle the different cases (as
we discussed yesterday)
... even for telephony I am not sure why this is needed
sicking: for telephony, I am not that optimistic because depending on your service provider, you might have different security levels
<Claes> I have installed skype now. Can you give me a skype adress to call.
<Claes> Ok, I'll call you
<Claes> I got about 10 hits on that address. Could you try to call me. claes.nilsson90
<Claes> Is someone writing MoM
<Claes> ?
<dsr> scribenick: dsr
Jonas discusses signed apps as basis for access to trusted APIs
Rich: apps without access to the Internet could be granted permission to access trusted APIs with minimal risk of problems
<richt> http://richt.me/2013/05/exposing-privileged-apis-to-web-content/
Jonas: I don't know how I would create APIs that work in all 3 contexts (browser, disconnected and signed/trusted)
Anssi: asks Rich if developers are happy with the very restricted model proposed by Rich
Rich: anything written in the privileged state can only be read in the privileged state
Anssi: how will we sell this to developers?
Rich: let's focus on manifest for hosted apps, and installing apps on the home screen
Anssi: an installed app would sit between privileged and the drive by web
Rich: elevating an app's privileges is hard and is not how the web works.
Jonas: for each API we're
designing, we need to pick the security model it runs in
... we should stick to the known security models: the regular
web, and the signed/trusted
... we don't need to pick "one" security model, but for each
API we need to be clear which security model applies
Anssi: can we open the SysApps
home page please (on the projector)
... task scheduler is okay the for the Web
... contacts, messaging, telephony, raw sockets are all for the
signed context
For phase 2, bluetooth signed?
Jonas: Mozilla doesn't even expose bluetooth to signed apps as yet, but will do so eventually
Mounir: our ideas on security models will evolve over time, and this will mean revisiting API design
<mounir_> scribenick: mounir_
<wonsuk> Slide from Claes: https://mail-attachment.googleusercontent.com/attachment/u/0/?ui=2&ik=53293ca563&view=att&th=14247edd8d03c71d&attid=0.1&disp=inline&safe=1&zw&saduie=AG9B_P_9ZyqSId_uZvO2K-Bes8iX&sadet=1384236110159&sads=PJAmCpe6b_QcGc9CubXtjoytRgE&sadssc=1
Claes: first, the name of the API
might change
... a summary of what we have been doing since the last
F2F
... <many things that the scribe did not catch>
... there are two outstanding issues
... one was raised by Marcos
... the node community said that the specification should be
based on the Stream API
... and I have made a presentation on this proposal
... slide 2, the proposal is that it should be based on the
Streams API but this would be a significant re-design of the
Raw Sockets API
... why doing that?
... we would be using a general standardize solution
... for things like buffering and backpressure
... there is also in the work with streams, a solution for
piping a source stream with a destination stream
... which is a common UC for a socket api
... slide 4, there are two activities for the Streams API
... one is a W3C Streams API and a WHATWG specification
... there is a GitHub link that I will patch in the IRC
channel
<Claes> https://github.com/whatwg/streams
Claes: If you look at those
proposals, you will see that they are very different
... hopefully, they will align
... slide 5, the Streams API deals with similar issues than the
Raw Sockets API
... it is trying to keep a simple API for developers that do
not lose data or overflow buffers
... slide 6, we talked about stream producers
... slide 7, stream consumers, that read and act on a stream
object
... example or that is Web Audio
... next slide is the push based data sources requirements for
a stream api
... now, requirements for write
... it includes buffering
... <reading slides>
sicking: we also need to deal
with the fact that TCP Socket can be upgraded to SSL
... and the interaction that has with Stream
< Claes' Skype got disconnected >
sicking: <repeats the question>
Claes: we do not have a solution,
it is good that you pointed that problem so we can try to find
a solution
... so... slide 10, piping
... slides 11, 12, 13 - they show extremely preliminary
interfaces
... questions?
anssik: I am looking at the
status of the Streams proposal
... there is a GitHub readme file but what is the other
one?
<Claes> https://dvcs.w3.org/hg/streams-api/raw-file/tip/Overview.htm
anssik: is the W3C spec at LC now?
Claes: the proposal gots many
comments
... so I think they will postpone the LC
anssik: do you know what's the implementation status of those proposals?
Claes: I do not know
sicking: stream is going to take a long time
anssik: I guess the question is whether we want to base our work on top of W3C experimental work?
Claes: I agree with Jonas,
Streams will take a long time
... but it seems to have a strong potential
... I do not know if we have made a strong decision whether we
would be using the Stream API but we should investigate
... they are working on the same problems
anssik: I think we (Intel) have
an implementation
... there were issues but there were already addressed by the
Mozilla Network folks
... I think since then you addressed them
Claes: it is very nice to hear
that you have an implementation
... I would like to see that
anssik: I will talk to you more in the following weeks
<dsr> jonas: streams might take a year to stabilize
<dsr> Anssi
<dsr> Anssi: for Tizen we may need something sooner, but we are probably happy to follow the streams approach
<dsr> ... we should keep a stable snapshot on the current approach as a precaution.
<dsr> Jonas: streams are complicated and it will take a long time for people to reach a consensus.
<dsr> Anssi: I propose we progress both approaches.
<spoussa_> +1
RESOLUTION: the
group will continue investigating using Stream for the Raw
Sockets API
... the current state of the API (without Stream) should be
published as another WD
<scribe> ACTION: Claes will publish another WD for the Raw Sockets API that is not based on Streams [recorded in http://www.w3.org/2013/11/11-sysapps-minutes.html#action07]
<Claes> Could you call me again on Skype claes.nilsson90
<Claes> Dave, Could you call me again on Skype claes.nilsson90
<Claes> Ok
<Claes> Dave is no longer in the SysApps meeting. Could anyone else call me on Skype, claes.nilsson90?
<scribe> scribenick: mounir_
mounir_: I propose that we do not
schedule a F2F for the moment
... we have work to do before having a new F2F so lets do that
work and decide when we meet when it is on its way
anssik: I agree, unless some
people prefer 3 months notice, something like 1-2 months should
be enough
... what about doing a F2F with another group? like
WebApps?
<zolkis> what are the next steps? any tentative deadlines on actions?
<zolkis> anssik: +1
wonsuk: we could see if we could
meet with WebApps, it could be good for us as well
... I could check that with the chair of WebApps
<scribe> ACTION: wonsuk will ask the chairs of WebApps regarding their next F2F [recorded in http://www.w3.org/2013/11/11-sysapps-minutes.html#action08]
mounir_: regarding the actions, I
will send an email with a summary and open bugs
... but I do not think it is useful to have deadlines, people
miss deadlines anyway
rssagent, generate minutes
mounir_: F2F closed, thank you everyone
This is scribe.perl Revision: 1.138 of Date: 2013-04-25 13:59:11 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/[XX]/Anders/ Succeeded: s/Chrom/Chrome/ Succeeded: s/same as the Contacts API, there was no activity since a while// Succeeded: s/is not stable/is stable/ WARNING: Bad s/// command: s/ICC UICC Succeeded: s/ICC/UICC/ Succeeded: s/and did/... and did/ Succeeded: s/the the/to the/ Succeeded: s/potentieal/potential/ Found ScribeNick: dsr Found Scribe: mounir_ Inferring ScribeNick: mounir_ Found ScribeNick: mounir_ Found Scribe: mounir_ Inferring ScribeNick: mounir_ Found ScribeNick: mounir_ Found Scribe: Mounir Found ScribeNick: dsr Found ScribeNick: mounir_ Found ScribeNick: mounir_ Scribes: mounir_, Mounir ScribeNicks: dsr, mounir_ WARNING: Replacing list of attendees. Old list: [IPcaller] Wuzhou_west New list: Wuzhou_west WARNING: Replacing list of attendees. Old list: Wuzhou_west New list: Wuzhou_West WARNING: Replacing list of attendees. Old list: Wuzhou_West +34.91.432.aaaa +358.986.aabb +358.986.aacc +34.91.432.aadd +358.986.aaee New list: +1.617.840.aaaa WuZhou_West +1.503.712.aabb Default Present: +1.617.840.aaaa, WuZhou_West, +1.503.712.aabb WARNING: Replacing previous Present list. (Old list: Kaz_Ashimura(observer), Manu_Sporny, Jinsong_Wang, Virginie_Galindo, Gene_Lian, Michael_Hutchinson, Thinker_Lee, Jonathan_Jeon, Jungkee_Song, Tomoyuki_Shimizu) Use 'Present+ ... ' if you meant to add people without replacing the list, such as: <dbooth> Present+ Dave, Mounir, Wonsuk Present: Dave Mounir Wonsuk Anssi_Kostiainen Jungkee_Song Christophe_Dumez Thinker_Lee Jonathan_Jeon Claes_Nilsson Agenda: http://www.w3.org/wiki/System_Applications:_3rd_F2F_Meeting_Agenda_TPAC#Agenda Got date from IRC log name: 11 Nov 2013 Guessing minutes URL: http://www.w3.org/2013/11/11-sysapps-minutes.html People with action items: at cdumez claes eduardo gmandyam google internally mounir out reach will wonsuk[End of scribe.perl diagnostic output]