[DRAFT] System Applications Working Group Charter

Recommendation-Track Deliverables

The working group will deliver the specifications listed below. In a number of cases, pointers have been provided to existing documents that address requirements similar to those of given deliverables. These are provided solely as aids to the reviewing process and should not presume that the cited documents will be submitted to W3C or that the deliverable developed by the group will take one of these for its starting point. In some cases, links are not provided. This should not be taken to entail that there is no prior work on this item, but simply that it may not be available in a form suitable for linking (in some of those cases further information can be obtained through the B2G WebAPI document).

Security Model for Platform Applications

A description of the security model for platform applications, particularly how the security model differs from the traditional browser-based security model.

Execution Model for Platform Applications

A description of the execution model for platform applications, particularly how the execution model differs from the traditional browser-based execution model.

System Services

• Alarm API. An API to manage the system's alarm daemon. Example: Tizen Alarm.
• Application API. An API to launch other applications and communicate with them. Example: Tizen Application
• Calendar API. An API that enables complete management of the device's calendars. Examples: B2G Calendar, Tizen Calendar.
• Contacts API. An API that enables complete management of the device's address books. Examples: Tizen Contacts, B2G Contacts
• File System API. An API that bridges the existing “File: Directories & System” API to the actual file systems known to the device. Examples: Tizen FileSystem, B2G Device Storage.
• Messaging API. An API to send and receive messages (e.g. SMS, MMS, Email, IM) as well as manage messages stored on the device. Examples: Tizen Messaging, B2G Web SMS.
• Device Capabilities API. An API the discover the capabilities available to the device. Example: Tizen System Info
• Raw Sockets API. An API to manipulate low-level connections (e.g. TCP, UDP), including the ability to listen for incoming connections. Example: Chrome Sockets
• DNS Resolution API. An API for resolving DNS names.
• System Settings API. An API to manage the system's settings (including notably time/clock settings). Example: B2G Settings.
• Accounts API. An API to use existing, configured accounts and services, and for creating accounts of existing types.
• Media Storage API. An API to manage the device's storage of specific content types (e.g. pictures). Example: Tizen Media Content.
• Browser API. An API that provides all the necessary items to build a Web browser. Most notably, this provides all that is needed in order to safely instantiate a viewport onto the open Web, pretend that such a viewport is the top level window even if the browser's chrome is itself written using Web technology, etc. Example: B2G BrowserAPI
• Web Intent Registration API. An API that makes it possible for Web Intent services to register themselves out-of-band (i.e without visiting a page declaring the Intent) with the browser and system.
• Keyboard/IME API. An API to support implementing virtual keyboards. Example: Chrome IME
• Idle API. An API to be notified when the user is idle. Example: B2G Idle
• Spellcheck API. An API to perform spell checking, including dictionary and suggestions access.
• Background Services API. An API that enables a Web application to run in the background as a daemon. Example: B2G Background Services.

Hardware Capabilities

• Bluetooth API. A low-level API to interact with the Bluetooth hardware available on some devices. Examples: Tizen Bluetooth, B2G Web Bluetooth.
• Telephony API. An API to interact with the phone system, for instance to dial a number, pick up a call, route to voicemail, access the call log, etc. Examples: B2G Web Telephony, Tizen Call.
• Sensors API. A low-level API to provide access to the device's sensors. Prior work from the Device APIs WG that was put on hold there will be transitioned to this group.
• Resource Lock API. Prevent resources from being turned off (e.g. screen dimming, internet connection, CPU or GPU going to sleep mode). Example: B2G Resource Lock.
• Network Interface API. An API to manipulate the 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.) Examples: B2G Mobile Connection, B2G WiFi Information.
• USB API. An API to interact with USB and USB storage devices. Example: B2G Web USB.
• Power Management API. An API to manage the power consumption of the device, for instance by turning the screen on or off, putting the CPU in sleep mode, etc. Example: B2G Power Management
• Contentious: NFC API. Before there is sufficient consensus on this item, please discuss it only on the public-nfc mailing list. Examples: B2G Web NFC, Tizen NFC.
• Secure Elements API. An API enabling the discovery, introspection, and interaction with hardware tokens (Secure Elements) that offer secure services such as tamper-proof storage, cryptographic operations, etc.

Note that where applicable, the group is free to split the above deliverables into several smaller specifications that collectively address the same space, or conversely to join some of the above into a single specification.

Where practical, the API specifications should use the Web IDL formalism.

Each specification must contain a section detailing any known security and privacy implications for implementors, authors, and end users. The Working Group will actively seek security and privacy review on all its specifications.

The Working Group may also enter into joint Task Forces with other groups (in particular with the Web Applications and Device APIs Working Groups), to collaborate on the deliverables above if specifications cross group boundaries.

Other Deliverables

A comprehensive test suite for all features of a specification is necessary to ensure the specification’s robustness, consistency, and implementability, and to promote interoperability between User Agents. Therefore, each specification must have a companion test suite, which should be completed by the end of the Last Call phase, and must be completed, with an implementation report, before transition from Candidate Recommendation to Proposed Recommendation. Additional tests may be added to the test suite at any stage of the Recommendation track, and the maintenance of a implementation report is encouraged.

The Working Group may also document in a Working Group Note the useful design patterns shared by the APIs it is developing.

Other non-normative documents may be created such as:

• Primers for each specification
• Requirements and use case document for specifications
• Schemas for languages developed by the group (if any)
• Non-normative group notes

Given sufficient resources, this Working Group should review other working groups’ deliverables that are identified as being relevant to the Working Group’s mission.

Milestones

The Working Group will maintain an updated timeline of its deliverables on its home page.

The group will begin by reaching consensus and producing a rough FPWD draft of the Security Model and Execution Model documents inside of its first quarter. While the other deliverables should by no means wait for these two documents to be final and polished before proceeding, given that the design of the APIs will depend on the environment to which they are tailored it will be necessary to have a “checklist” consensus on the primary aspects of this environment that these two documents define.

Most of the API deliverables in this charter already benefit from at least one and often several existing implementations. As such, once the preceding step is executed it is expected that the production of specifications building on strong implementation experience and existing documentation can proceed at the pace of five FPWDs per quarter (until Q2 of the second year). Each of these specifications is then expected to reach CR inside of three quarters, with transition to Recommendation status supported by the adaptation of tests from existing platforms to these specifications.