W3C

- DRAFT -

SysApps Face to face
30 Oct 2014

See also: IRC log

Attendees

Present
Jonghong_Jeon, JeanClaude_Dufourd, Johannes_Hund, Wonsuk_Lee, Hiroyuki_Aizu, Laszlo_Gombos, Sakari_Poussa, Jungkee_Song, Anssi_Kostiainen, Terri_Oda, Kenneth_Christiansen, Claes_Nilsson, Tomoyuki_Shimizu
Regrets
Chair
SV_MEETING_CHAIR
Scribe
Claes

Contents


<tomoyuki> +Present Tomoyuki_Shimizu

<JonathanJ1> Topic - Agenda bashing

<JonathanJ1> https://www.w3.org/wiki/System_Applications:_5th_F2F_Meeting_Agenda

<dsr> scribe: Claes

<dsr> scribenick: Claes

Lazlo: Updated to integrate with Service Workers

Consensus to publish all SysApps specifications as Public Working Drafts

Jungkee: Basically an alarms API and allows scedulign tasks
... Events through Service Wroker
... Partial interface under ServiceWorkerRegistration
... Registers events to occur after a certain time period trough ServiceWorker

<JonathanJ1> Task Scheduler API - http://www.w3.org/2012/sysapps/web-alarms/

Jungkee: Client application uses the ServiceWorkerClinet interface to getbthe event

s /ServiceWorkerClinet/ServiceWorkerClient

s /trough/through/

Wonzuk: One issue is status of the Service Worker specification

jungkee: We don't have to wait to go to last call. Task Scheduler do not have to be updated

s /so/does/

We don't yet have an implementation of the Task Scheduler API

<anssik> [in the 2014 Process the Last Call and Candidate Recommendation have been collapsed together]

Kenneth: Waiting for Service Worker prior to implementation

WHAT WG is also integrating with Service Worker in Notification API

<wonsuk_> https://notifications.spec.whatwg.org/

Same kind of integration as Task Scheduler

<JonathanJ1> W3C Process 2014 - http://www.w3.org/2014/Process-20140801

Discussion when go to last call

<JonathanJ1> http://www.w3.org/2014/Process-20140801/#Reports

<lgombos> .. discussion about which process to use for the spec

<anssik> the 2014 Process omits LC http://www.w3.org/2014/Process-20140801/#recs-and-notes so if we opt-in for the 2014 Process then we should publish WDs until we satisfy this requirement: "must document how adequate implementation experience will be demonstrated"

Proposed to republish updated WD after TPAC. Then we will have discussion on e-mail whether we will bring to last call/CR.

<anssik> the definition of adequate impl experience is up to the group to decide AFAIK, often it is two independent impls

RESOLUTION: Adapt new process. republish updated WD after TPAC. Then we will have discussion on e-mail whether we will bring to last call/CR.

s /republish/Republish/

<anssik> the editor should add this boilerplate to the Status of the Document: "This document is governed by the 1 August 2014 W3C Process Document."

<scribe> ACTION: Dave to Check which groups that have adapted the new process [recorded in http://www.w3.org/2014/10/30-sysapps-minutes.html#action01]

<trackbot> Sorry, but no Tracker is associated with this channel.

<spoussa_> Crosswalk

<JonathanJ1> https://crosswalk-project.org/

Need 2 implementations. Intel may implement in Crosswalk. Should ask Mozilla on implementation in FFOS.

Contacts manager API

<scribe> ACTION: Wonsuk to Ask Mozilla on implementation in FFOS. [recorded in http://www.w3.org/2014/10/30-sysapps-minutes.html#action02]

<trackbot> Sorry, but no Tracker is associated with this channel.

<dsr> http://www.w3.org/2012/sysapps/contacts-manager-api/

Subject: Contacts Manager API

<JonathanJ1> trackbot, associate this channel with #sysapps

We don't need to consider if this APi should be based on Data Store API or not as the latter is withdrawn.

<zolkis> we need to experience with implementation. Bluetooth PBAP should be supported.

http://www.w3.org/2012/sysapps/contacts-manager-api/

Similar to FFOS Contacts Manager API

Implementation plans?

Kenneth: Lower prio than Task Scheduler. No current plan.

<JonathanJ1> trackbot, start meeting

<trackbot> Sorry, but no Tracker is associated with this channel.

<anssik> http://www.w3.org/2012/sysapps/contacts-manager-api/#security-and-privacy-considerations suggests the current API is not compatible with the Web's security model, thus no browser vendor is able to implement this API

<dsr> Christophe Dumez has left Samsung and should be dropped as an editor for Contact Manager API,

<dsr> and replaced by Mahesh Kulkarni (Samsung), see task scheduler spec

<jungkees> The API discussion has been done a lot, but we still have to discuss how this spec and the others will run in a security context which we have to clarify.

<Claes_> RESOLUTION: After revisit Security and Privacy consideration we will seek consensus for next step

<JonathanJ1> trackbot, status

<trackbot> Sorry, but no Tracker is associated with this channel.

<Claes_> Anssi: Many SysApps APIs are not implementable in normal browser context due to security issues

<Claes_> .. Should the WG spend stime on this meeting to discuss this issue?

<Claes_> s /stime/time/

<dsr> Anssi proposes we move the agenda item on trust & permissions earlier as it is important for the API discussions.

<Claes_> Wonsuk will check if we can have the discussion on Trust and permissions for Web applications earlier in the agenda.

<ArtB> -> https://www.w3.org/community/w3process/track/issues/60 https://www.w3.org/community/w3process/track/issues/60 ; status = CLOSED :-(

<ArtB> hmmm; Issue-60 is https://www.w3.org/community/w3process/track/issues/60

<ArtB> "ISSUE-60: Chapter 7 should be moved to Github to encourage and facilitate contributions to its evolution"

<ArtB> ooops; so sorry for wrong channel!

<spoussa_> ArtB: welcome!

<JonathanJ1> trackbot, init

<Claes_> 15 min break, then discussion on Trust and permissions for Web applications'

<dsr> we will break for 14 minutes

<JonathanJ1> trackbot, status

<trackbot> Sorry, but no Tracker is associated with this channel.

<zolkis> as a general comment to the Contact, Messaging and Telephony API's: we are interested not only in one system contact manager, or message store, or modem, but also want to handle the contacts, messages and calls coming from devices paired via Bluetooth PBAP, MAP and HFP profiles. We need to consider these use cases in the specifications, or otherwise make them forward compatible with these requirements.

Trust and Permissions

<dsr> Paris meeting: http://www.w3.org/2014/07/permissions/

<dsr> TPAC break out session slides: https://www.w3.org/wiki/images/7/78/29-dsr-permissions.pdf

<Claes_> Dave is showing the slides from yesterday's break-out session.

<Claes_> Dave: Resolution from Paris is to launch a Community Group. Confirmation from Google and Mozilla that they will join.

<Claes_> ... TCP and UDP Socket API is a example of an API that is too sensitive to expose to any websites

<Claes_> .. Discussions on "Trusted UI"

<Claes_> .. shared experiences native platforms, web platforms and research projects

<Claes_> .. CG will focus on best practices and emerging techniques

<Claes_> .. encourage cross WG review of permissions in W3C APIs

<Claes_> ..Agreement that we need shared standards for the Open Web Platform

<Claes_> ..The ship has already sailed for packaged apps

<Claes_> ..Innovation by browser vendors for detecting misbehaving apps

<Claes_> ..Increasing role for endorsements by trusted 3rd parties as a way for users to delegate trust decisions

<Claes_> .. Adrienne Felt's diagram on slide 8

<Claes_> .. examples in the following slides

<Claes_> .. Trusted UI: slide 10, Media Capture. Can we generalize this model?

<Claes_> Jonathan: Don't really think so. Permission API can just be used by a web app the status of permission to access an API. How to give permission is not defined here.

<Claes_> I mean "to check the status of permission to access an API."

<Claes_> .. goal is to provide a more natural way of user interaction and avoid a lot of prompting.

<Claes_> .. avoid "faked user interaction to access APIs"

<JonathanJ1> I think we need to clarify the name of API

<Claes_> discussion if browsers can differentiate between input from scripts and users

<Claes_> .. USer prompting, Geolocation API example

<Claes_> .. Install-Time consent, Android app installation example.

<Claes_> .. not possible in Android to get information on why an application needs access to a certain API but that is possible in IOS

<JonathanJ1> http://www.w3.org/2014/07/permissions/minutes.html

<Claes_> .. Trust Delegation

<Claes_> ..App stores may have rigorous processes for vetting apps before allowing users to install them. However, hosted apps could change frequently and this model does not work here

<anssik> [ http://w3c.github.io/webappsec/specs/subresourceintegrity/ ]

<anssik> dsr, great presentation, thanks!

<Claes_> .. business models for hosted apps diffferent. Use manifest to point at trusted "endorsement site?

<Claes_> .. Sony Mobile is trying a model for FFOS "Trusted Hosted web apps" that is based on using existing web security mechanisms ssl/tls, signed manifest and csp. See http://lists.w3.org/Archives/Public/public-sysapps/2014Sep/att-0000/SoMC_FFOS_Trusted_Hosted_Apps.pdf

<Claes_> Vendors, e.g. Mozilla, are already providing APIs requiring a security model to achieve trust so we are not stuck in defining sensitive APIs.

<Claes_> Anssi: Discussion on if we should have a W3C WG for APIs applicable for "web runtimes" instead of web browser

<Claes_> But Dave stated there is not so strong distinction between "web runtimes" iand "web browsers"

<Claes_> Anssi, I have some trouble capturing what you say so please put in IRC your main points.

<anssik> [ http://w3ctag.github.io/packaging-on-the-web/ ]

<Claes_> Lazlo: Take out Task Scheduler to Web Apps WG?

<Claes_> .. due to testing issues we should start to assume browser context for tests

<jungkees> to clarify service worker is running in the existing web same origin model

<Claes_> Jungkee: Integration with SW not related to the API permission level

<Claes_> .. SW has to be registered in the same domain. Need to use https.

<Zakim> anssik, you wanted to note that increasingly sensitive APIs are HTTPS only, not just SW

<Claes_> Also proposed that access to Geolocation API should require that web page is delivered over https

<anssik> [ Related Moz issue https://bugzil.la/934289 ]

<anssik> [ This meta-bug captures the work happening to expose functionality which is currently limited to certified APIs to third party web developers. This means exposing APIs (or restricted subsets of APIs) to privileged and regular web apps. ]

<anssik> [ as dsr noted, there are active efforts at moving browsers and runtimes closer together ]

<Claes_> Dave Summary: Vendors have their own solutions for trust and security but we need to check if there are any implications for distinction between packaged and trusted apps in our APIs? The long term work on a trust and security model is starting with the Community Group.

<JonathanJ1> trackbot, start telcon

<trackbot> Sorry, but no Tracker is associated with this channel.

<JonathanJ1> trackbot, start meeting

<trackbot> Sorry, but no Tracker is associated with this channel.

<JonathanJ1> trackbot, bye

<JonathanJ1> trackbot, bye

<JonathanJ1> trackbot, start telcon

<trackbot> Sorry, but no Tracker is associated with this channel.

Telephony

<dsr> editor's draft http://www.w3.org/2012/sysapps/telephony/

<dsr> Wonsuk talks us through the agenda for the rest of the day.

<dsr> scribenick: dsr

Zoltan: we have an implementation of the telephony API in Crosswalk for the current editor's draft.

<scribe> On going discussion on conference calls and CDMA. We are looking at separate namespaces for CDMA and GSM

This would involve more code from developers but cleaner semantics.

Wonsuk: what do you think about asking Mozilla to review the current spec?

Zoltan: I expect significant changes from the refactoring for GSM and CDMA

Wonsuk: we can ask Giri @ Qualcom to review the CDMA aspects.

Zoltan: yes.
... we really need the implementation experience, and I am working on a dialler app with that in mind.

<scribe> ACTION: Zoltan to forward the new refactored telephony spec to Giri for review. [recorded in http://www.w3.org/2014/10/30-sysapps-minutes.html#action03]

<trackbot> Sorry, but no Tracker is associated with this channel.

Wonsuk: what outstanding issues are there?

Zoltan: many of these are quite old and need to be cleaned up.

<scribe> ACTION: Zoltan to clean up GitHub issues for telephony API [recorded in http://www.w3.org/2014/10/30-sysapps-minutes.html#action04]

<trackbot> Sorry, but no Tracker is associated with this channel.

Wonsuk: we need to ask Mozilla as well. Are they planning on an implementation?

Wonsuk asks if Zoltan is working directly on the implementation?

<zolkis> please repeat the question

<zolkis> yes

Wonsuk: we need multiple implementations to test the interoperability.

Zoltan: Mozilla's implementation is working. We've closed the issues they raised. Let's see what comes out of the current discussion. I will summarise to the list.

Dave: is Qualcom planning on an implementation?

Wonsuk: not that I know of, but they are the experts for CDMA and can review that part of the spec.

Messaging API

editor's draft http://www.w3.org/2012/sysapps/messaging/

Zoltan: no significant changes since last face to face, but there are some requirements that it doesn't support.
... the problematic part is the messaging access.
... We should separate data access API from the messaging API

The messaging part may require further attention. We don't have an implementation yet, so this remains to be proved.

Wonsuk: do you have a plan for that?

Zoltan: yes, I have the parts and just need to put them together.

Wonsuk: You talked about bluetooth.

Zoltan: the access part is only for remote devices.
... I will send details in email.

Jungkees: this is still using system messages to receive messages, but other specs are integrating with service worker for messages, so perhaps we need to change this spec to match?

Zoltan: we already have an open issue on this.

<jungkees> Task scheduler API and Notifications API have already integrated the hook to service worker

<jungkees> and this part of the service worker is stable enough now, so Zoltan can refer to that part of the spec

<jungkees> I'll drop the links

<jungkees> https://slightlyoff.github.io/ServiceWorker/spec/service_worker/index.html#extensibility

<jungkees> Notifications API integration: https://notifications.spec.whatwg.org/#activating-a-notification

<zolkis> ok - note that I've sent a few remarks on usability of push api + notifications + service workers in Telephony API on the webapp mailing list

Wonsuk asks Zoltan to investigate the service worker issue as explained by Jungkees

<jungkees> and also see the relevant part from task scheduler api: http://www.w3.org/2012/sysapps/web-alarms/

Zoltan: I think that this would be no problem to address

<jungkees> thanks zolkis

Dave will contact Zoltan directly if there are issues in publishing an updated WD based upon the current editor's draft.

We will publish new WD's when the refactoring for CDMA/GSM is done.

TCP and UDP sockets

Claes presents some slides (to be added to minutes later)

Summary of the status for the socket API.

Claes shows us the editor's draft, see http://www.w3.org/2012/sysapps/tcp-udp-sockets/

Example use cases are listed in section 1 (Introduction)

In last month, I have rewritten the spec to be based on the Streams API

Spec is now ready for publication, and remaining actions related to secure connections.

The spec states that the API can only be exposed to trusted apps, but that is out of scope for this document.

Claes introduces the Streams API. There is a JavaScript polyfill and test suite

The W3C version of the API defines a few extensions to the WHAT WG Streams API for requirements specific to the browser environment.

Some discussion on making Streams part of the ECMAScript standard.

<scribe> ACTION: Claes to provide link to Chromium bug on adding support for Streams API [recorded in http://www.w3.org/2014/10/30-sysapps-minutes.html#action05]

<trackbot> Sorry, but no Tracker is associated with this channel.

I have chatted with Marcos and he says Mozilla are interested.

Claes lists the things that need to be addressed to add support for secure sockets.

These include certificate pinning, cipher suites, client authentication, and selection of server certificates for TCPServerSocket.

Also adding support for upgrading existing connection to a secure connection.

Some question about use cases for secure UDP sockets or not.

Alex Russell: is the concern over secure UDP sockets relating to certificates?

Claes: it is more about not including features without strong user cases.

Discussion about complementary role of webcrypto group.

They may be able to support some of the use cases.

Agreement that a simple user consent dialog isn't sufficient.

Alex: recommend avoiding including a policy in the API and instead leaving this to the user agent.

Otherwise, this looks very promising for us (Chrome)

Alex to send further background info to Claes.

Claes talks about the motivations for basing the socket API on Streams.

The Streams API https://streams.spec.whatwg.org/

Claes' slides http://lists.w3.org/Archives/Public/public-sysapps/2014Oct/att-0056/TCP_UDP_Socket_API_-_TPAC_2014.pdf

In essence the Streams API simplifies the code that developers need to write

An example is the management of buffers using high and low water marks.

Wonsuk asks about the current implementation status in Chrome.

Claes may be able to work on an implementation, but this depends on Sony.

<slightlyoff> Claes: sorry I had to leave, this is Alex, my email addr is slightlyoff@google.com

Terri: has there been any discussion on restricting sockets to particular IP addresses?

Could content security policies be extended to support that?

Claes has heard back from Mozilla who are definitely interested in the UDP and TCP Socket API.

Terri: suggest talking with webappsec WG in relation to CSP.

Jungkees: it could fit with the CSP connect-src mechanism.

Claes: Intel implemented the old version of the spec (predatingStreams) for Crosswalk.

We are expecting implementations for the new spec for both Chrome and Firefox OS.

Jungkees explains Alex's suggestion about using a user consent dialog that returns a promise that the app can then use with the API.

Claes: when you create a UDP socket you don't specify the IP address. This is given when you send a UDP packet. I will look at the push API.

Jungkees: so we will be able to proceed with this API without specifying the permissions mechanism, right?

Dave: yes

Wonsuk explains that further.

Each platform applies its own permissions model.

We take a short break for 20 minutes and will resume at 3:43 PST

<slightlyoff> dsr: for the record, I don't want to make UA's prompt users if they can avoid it. Only want an API that lets UAs make decisions that are independent of each other

<slightlyoff> so that if, in some situation, it seems reasonable to ask a user (or a network service, or a local policy broker, or all of the above) the UA can do that without requiring the API to change

Media Storage API

Claes presents his slides, see http://lists.w3.org/Archives/Public/public-sysapps/2014Oct/att-0055/Sony-MediaStorageAPI.pdf

This is a SysApps phase 2 work item, and it got a good score in Dave's questionnaire on rechartering. I would like to see if it is timely to start work on it.

Claes asks if people would like to start work on MediaStorage?

Jungkees: yes

Kenneth: is this only for packaged apps?

Claes: this is for trusted apps, and not for all web apps.

Rich Tibbet: could this work as an extension to the file picker?

Claes: I don't think so. In this case we want to list a number of available files, e.g. all albums of a certain artist.

Rich: rather than returning a file, and instead returning a token for it.

Kenneth: is some kind of trusted UI possible?

Rich: building on existing UI would simplify the work we need to do. A token would prevent the app from having access to the data in files.

Claes: how does that protect users from evil apps deleting files?

Rich: you could select files for playing, for uploading to the cloud.

Wonsuk: before we decide we should think about the use cases.
... we could consider a media player with thumbnails and metadata. We may need to provide a metadata API?

Dave asks Claes what he means by provide access to media files.

Claes shows the Chrome getMediaFileSystems API.

Dave: you could perhaps get the file as a token that can be passed to a player without the need to get the data as a blob. This could be useful for video files that are potentially several gigabytes long.

Jungkees: a Stream API might be the solution.

Claes: a request could get a promise as a way to decouple the permissioning mechanism.

Claes shows us a draft API. He can't send us a link to this right now.

Claes: can we discuss the functional requirements now or by email?

Dave: have you asked browser vendors about the use cases and scope?

Claes: not yet, I was hoping to do so today!

(Rich ducks in the corner)

Claes: okay I will take the scoping discussion to email.

Rechartering part 1

<Claes> Scribe: Claes

<scribe> Dropped Data Store, Mozilla does no longer want to persue it

Secure Elements: Interest should be evaluated within this group. If no interest API could be moved to another group

Check what new work items that could be applicable.

Generally, if existing work items in SysApps are no longer of interest for this group we should consider moving them to othe rgroups

s /rgroups/groups/

<JonathanJ1> s/othe groups/otherr groups/

<JonathanJ1> I have sent an email about the next phase item on Settings, Bluetooth - http://lists.w3.org/Archives/Public/public-sysapps/2014Oct/0059.html

Should go through the list of SysApps work items and evaluate the justification for them (use cases, etc)

Wonsuk opens the charter

Bluetooth: Low level implementing the low level BT connectivity

The W3C BT CG has been formed but it is not which WG that should take up the specification work

"not decided"

Need to call out which BT profiles that we should expose to the web platform

<zolkis> I am looking into BT use cases as well

Action on Jonathan and Zoltan to investigate BT use cases and which BT profiles that we should expose to the web platform

<trackbot> Sorry, but no Tracker is associated with this channel.

<JonathanJ1> https://webbluetoothcg.github.io/web-bluetooth/use-cases.html

Network Interface API:

<wonsuk_> Network Interface API in current charter: An API to manipulate network interfaces (mobile, WiFi, etc.), such as listing available networks, current strength, etc., as well as configuring and enabling them. It may build atop the simpler network information API that Device APIs is working on. Potential uses include offloading connections from mobile networks

<wonsuk_> to WiFi, enabling high priority mobile data connections and control of other network features

<JonathanJ1> http://www.w3.org/2012/09/sysapps-wg-charter

Old DAP API: http://www.w3.org/TR/2011/WD-netinfo-api-20110607/

Just exposed the current connection type. The value returned: unknown, ethernet, wifi, 2g, 3g, 4g, none.

<JonathanJ1> I think it's an idea similar to Network Interface API on android - http://developer.android.com/reference/java/net/NetworkInterface.html

<wonsuk_> Network Information API in DAP WG: http://w3c.github.io/netinfo/

<jungkees> /me ArtB re-charter discussion has been started

Needs to clarify the scope of the Network Interface API. Just give information on connection or ability to switch connection?

<scribe> ACTION: Jonathan to clarify the scope and use cases for the Network Interface API [recorded in http://www.w3.org/2014/10/30-sysapps-minutes.html#action06]

<trackbot> Sorry, but no Tracker is associated with this channel.

App Lifecycle: Needs Anssi

Data Store: Dropped

Device Capabilities:

Example is Tizen System Information API

https://developer.tizen.org/documentation/dev-guide/2.2.1?redirect=https://developer.tizen.org/dev-guide/2.2.1/org.tizen.web.appprogramming/html/api_reference/api_reference.htm

Need more work on use cases

<wonsuk_> direct link to Tizen system info api: https://developer.tizen.org/dev-guide/2.2.0/org.tizen.web.device.apireference/tizen/systeminfo.html

Action for Wonsuk to mail SysApps list to request someone to look at use cases for Device Capabilities API

<trackbot> Sorry, but no Tracker is associated with this channel.

Idle:

Action for Wonsuk to mail SysApps list to request input on need for Idle.

<trackbot> Sorry, but no Tracker is associated with this channel.

Secure Elements:

Jörg Heuer: Project on using web tech to create a wallet. Need to link to Secure Elements

scribe: not only credit cards
... need a generic interface
... have been doing work with Mozilla

Seems to be strng interest for this API

<scribe> Done for today. Continuing rechartering discussion tomorrow morning at 9 am

<JonathanJ1> https://appear.in/sysapps

Summary of Action Items

[NEW] ACTION: Claes to provide link to Chromium bug on adding support for Streams API [recorded in http://www.w3.org/2014/10/30-sysapps-minutes.html#action05]
[NEW] ACTION: Dave to Check which groups that have adapted the new process [recorded in http://www.w3.org/2014/10/30-sysapps-minutes.html#action01]
[NEW] ACTION: Jonathan to clarify the scope and use cases for the Network Interface API [recorded in http://www.w3.org/2014/10/30-sysapps-minutes.html#action06]
[NEW] ACTION: Wonsuk to Ask Mozilla on implementation in FFOS. [recorded in http://www.w3.org/2014/10/30-sysapps-minutes.html#action02]
[NEW] ACTION: Zoltan to clean up GitHub issues for telephony API [recorded in http://www.w3.org/2014/10/30-sysapps-minutes.html#action04]
[NEW] ACTION: Zoltan to forward the new refactored telephony spec to Giri for review. [recorded in http://www.w3.org/2014/10/30-sysapps-minutes.html#action03]
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.138 (CVS log)
$Date: 2014/10/31 00:24:34 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
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/imps/impls/
Succeeded: s/disacussion/discussion/
Succeeded: s/spec/telephony spec/
Succeeded: s/Junkkee/Jungkees/
Succeeded: s/Question/Alex Russell/
Succeeded: s/high/high and low/
Succeeded: s/connectors/connect-src/
Succeeded: s/sent/send/
FAILED: s/othe groups/other groups/
Succeeded: s/othe/other/
Found Scribe: Claes
Found ScribeNick: Claes
Found ScribeNick: dsr
Found Scribe: Claes
Inferring ScribeNick: Claes
ScribeNicks: Claes, dsr
Present: Jonghong_Jeon JeanClaude_Dufourd Johannes_Hund Wonsuk_Lee Hiroyuki_Aizu Laszlo_Gombos Sakari_Poussa Jungkee_Song Anssi_Kostiainen Terri_Oda Kenneth_Christiansen Claes_Nilsson Tomoyuki_Shimizu

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Got date from IRC log name: 30 Oct 2014
Guessing minutes URL: http://www.w3.org/2014/10/30-sysapps-minutes.html
People with action items: claes dave jonathan wonsuk zoltan

[End of scribe.perl diagnostic output]