Second Screen Community Group Charter

This Charter:
https://webscreens.github.io/cg-charter/
Start Date:
2 September 2016
Last Modified:
20 June 2018

Goals

The Second Screen Community Group (CG) explores the use of secondary screens from Web pages. This Community Group incubates and develops specifications of network protocols that implement the Presentation API and the Remote Playback API. In addition, this Community Group incubates new additions to the APIs defined in the Second Screen WG.

This work has three primary purposes:

The scope of work proposed here goes beyond the current scope of the Second Screen Working Group (WG). Given wider support and adequate stability, we plan to migrate the proposals generated in this Community Group to an appropriate standards track, for example the IETF Standards Track or a W3C Working Group, for further contributions and formal standardization.

Membership of the group is open to everybody. Upon joining the group, participants agree to the terms of the W3C Community Contributor License Agreement (CLA).

Background

Under the previous charter, the Second Screen Community Group (CG) delivered the Presentation API Community Group Final Report Specification that provides an API for a Web page to display and control content on a secondary screen. The work was migrated to the W3C Second Screen Working Group (WG) and the Community Group Final Report was provided as input to the Presentation API that is now being developed in the WG.

The Presentation API allows web applications to use secondary screens to display Web content. The initiating HTML page can request display of an HTML page on the second screen with a messaging channel between the two pages to enable communication and control. The two pages can both be rendered on the controlling user agent with just the video display sent to the second device ("1-UA mode"), or the second page can be rendered independently on the receiving user agent ("2-UA mode").

The Presentation API abstracts away the means of connecting as well as the underlying communication and video streaming technologies.

Scope of Work

The following tasks are in scope for the work of the community group.

Specifications of network protocols

  1. The specification of a set of network protocols that allows one user agent to use the Presentation API to discover and present Web content on another user agent, when both user agents are connected to the same Local Area Network (LAN).
  2. Protocols that implement all of the interfaces, attributes, methods, algorithms, and implementation requirements of the Presentation API are in scope. This includes protocols that preserve the privacy and security of data exchanged between the controlling and receiving user agents.
  3. The 2-UA mode of the Presentation API is in scope, so the focus will be on establishing presentations on a distinct receiving user agent. In 2-UA mode, the receiving user agent renders the presented document independently and messages between documents are exchanged via the network.
  4. Protocols that implement all of the interfaces, attributes, methods, algorithms, and implementation requirements of the Remote Playback API are also in scope, for the specific case of remotely playing a <video> or <audio> element with a src or sources URL media source on a presentation display. (In the Remote Playback API, this is referred to as the "media flinging" case.)
  5. Extension points for protocols developed are in scope, to make it possible to add new features via future specifications produced outside of this community group. For example, features such as 1-UA mode that are out of scope for this community group may be supported through future protocol extensions.

New additions to the APIs

  1. An addition to the Presentation API called "local presentation mode" is in scope to facilitate 1-UA mode use cases that involve e.g. offline usage, cookie-based authentication, and sharing of application state across the controller and presentation.

Where possible, the group will use established normative standards as a basis for specifications to reduce the scope of work. For example, local area discovery could be implemented via Multicast DNS.

Out of Scope

For this community group, the following tasks are out of scope.

Deliverables

The group will only produce Specifications listed in this section.

The Community Group will deliver specifications designed to meet the functional and security requirements of the Presentation API and the Remote Playback API.

  1. A specification for controlling and receiving user agents that describes how the controlling user agent will find available presentation displays on the local area network and establish two-way communication with one of them. It also describes how the controlling user agent will authenticate the receiving user agent and establish a confidential communication channel.
  2. A specification for controlling and receiving user agents that describes how a controlling user agent may start, connect, stop and exchange messages with a presentation on a receiving user agent via the Presentation API.
  3. A specification for controlling and receiving user agents that describes how a controlling user agent may start and control remote playback via the Remote Playback API.
  4. A specification extension to the Presentation API called "local presentation mode" that removes the restriction on presentations to use a separate storage area and allows the controlling browsing context and the receiving browsing context have access to each other's document context similarly to the window.open API.

To add any additional specifications, this Charter must be amended by the process described in the Amendments to the Charter section. All deliverables for which the CLA Patents section applies must be designated as such here.

Non-Normative Reports

The group may produce other Community Group Reports within the scope of this charter but that are not Specifications, for instance use cases, requirements, or white papers.

Dependencies or Liaisons

It is anticipated that the group will collaborate with appropriate W3C Working Groups in order to transition specification proposals to the Recommendation Track.

Community and Business Group Process

The group operates under the Community and Business Group Process. Terms in this Charter that conflict with those of the Community and Business Group Process are void.

As with other Community Groups, W3C seeks organizational licensing commitments under the W3C Community Contributor License Agreement (CLA). When people request to participate without representing their organization's legal interests, W3C will in general approve those requests for this group with the following understanding: W3C will seek and expect an organizational commitment under the CLA starting with the individual's first request to make a contribution to a group Deliverable. The section on Contribution Mechanics describes how W3C expects to monitor these contribution requests.

Work Limited to Charter Scope

The group will not publish Specifications on topics other than those listed under Specifications above. See below for how to modify the charter.

Contribution Mechanics

Substantive Contributions to Specifications can only be made by Community Group Participants who have agreed to the W3C Community Contributor License Agreement (CLA).

Specifications created in the Community Group must use the W3C Software and Document License. All other documents produced by the group should use that License where possible.

Community Group participants agree to make all contributions in the GitHub repo the group is using for the particular document. This may be in the form of a pull request (preferred), by raising an issue, or by adding a comment to an existing issue.

All Github repositories attached to the Community Group must contain a copy of the CONTRIBUTING and LICENSE files.

Transparency

The group will conduct all of its technical work in public. All technical work will occur in its GitHub repositories (and not in mailing list discussions). This is to ensure contributions can be tracked through a software tool.

Meetings may be restricted to Community Group participants, but a public summary or minutes must be posted to the group's public mailing list and Wiki.

Decision Process

This group will seek to make decisions where there is consensus. Groups are free to decide how to make decisions (e.g. Participants who have earned Committer status for a history of useful contributions assess consensus, or the Chair assesses consensus, or where consensus isn't clear there is a Call for Consensus [CfC] to allow multi-day online feedback for a proposed course of action). It is expected that participants can earn Committer status through a history of valuable contributions as is common in open source projects. After discussion and due consideration of different opinions, a decision should be publicly recorded (where GitHub is used as the resolution of an Issue).

If substantial disagreement remains (e.g. the group is divided) and the group needs to decide an Issue in order to continue to make progress, the Committers will choose an alternative that had substantial support (with a vote of Committers if necessary). Individuals who disagree with the choice are strongly encouraged to take ownership of their objection by taking ownership of an alternative fork. This is explicitly allowed (and preferred to blocking progress) with a goal of letting implementation experience inform which spec is ultimately chosen by the group to move ahead with.

Any decisions reached at any meeting are tentative and should be recorded in a GitHub Issue for groups that use GitHub and otherwise on the group's public mail list. Any group participant may object to a decision reached at an online or in-person meeting within 10 days of publication of the decision provided that they include clear technical reasons for their objection. The Chairs will facilitate discussion to try to resolve the objection according to the decision process.

It is the Chairs' responsibility to ensure that the decision process is fair, respects the consensus of the CG, and does not unreasonably favour or discriminate against any group participant or their employer.

Chair Selection

Participants in this group choose their Chair(s) and can replace their Chair(s) at any time using whatever means they prefer. However, if 5 participants, no two from the same organisation, call for an election, the group must use the following process to replace any current Chair(s) with a new Chair, consulting the Community Development Lead on election operations.

  1. Participants announce their candidacies. Participants have 14 days to announce their candidacies, but this period ends as soon as all participants have announced their intentions. If there is only one candidate, that person becomes the Chair. If there are two or more candidates, there is a vote. Otherwise, nothing changes.
  2. Participants vote. Participants have 21 days to vote for a single candidate, but this period ends as soon as all participants have voted. The individual who receives the most votes, no two from the same organisation, is elected chair. In case of a tie, a process requested from the Community Development Lead is used to break the tie. An elected Chair may appoint co-Chairs.

Participants dissatisfied with the outcome of an election may ask the Community Development Lead to intervene. The Community Development Lead, after evaluating the election, may take any action including no action.

Amendments to this Charter

The group can decide to work on a proposed amended charter, editing the text using the Decision Process described above. The decision on whether to adopt the amended charter is made by conducting a 30-day vote on the proposed new charter. The new charter, if approved, takes effect on either the proposed date in the charter itself, or 7 days after the result of the election is announced, whichever is later. A new charter must receive 2/3 of the votes cast in the approval vote to pass. The group may make simple corrections to the charter such as deliverable dates by the simpler group decision process rather than this charter amendment process. The group will use the amendment process for any substantive changes to the goals, scope, deliverables, decision process or rules for amending the charter.