W3C

[PROPOSED] Second Screen Working Group Charter

Warning: This charter document has been replaced by no official status. It is a newer version . draft charter for discussion within the Second Screen WG and the W3C Advisory Committee.

The mission of the Second Screen Working Group is to provide specifications that enable web pages to use secondary screens (presentation displays) to display web content.

Join the Second Screen Working Group

Start date 3 November 2016 1 January 2020
End date 31 January 2018 December 2021
Charter extension See Change History
Confidentiality Proceedings are Public Initial Chairs Anssi Kostiainen
Initial Team Contacts (FTE %: 20) François Daoust (0.1 FTE)
Usual Meeting Schedule Teleconferences: topic-specific calls may be held
Face-to-face: we will meet during the W3C's annual Technical Plenary week; other additional F2F meetings may be scheduled (up to 2 per year)
IRC: active participants, particularly editors, regularly participants use the #webscreens W3C IRC channel during F2F meetings and teleconferences.

Goals

Web content is applications are available on an ever expanding array of devices including ebook e-book readers, phones, tablets, laptops, auto displays, and electronic billboards. These devices have a variety of display screens. There are also a signs. A variety of mechanisms that allow these devices to use secondary display screens audio and video presentation devices available in the local environment, attached by wired connections or remotely with wireless, peer-to-peer media.

Common attachment methods include video ports like VGA, DisplayPort or HDMI, or wirelessly through via wireless protocols such as Miracast, WiDi, or AirPlay. AirPlay, Bluetooth, and Google Cast. Wireless screens presentation displays may be available on a local area network network, or over the Internet, brokered Internet (brokered by a cloud service. A device service). In addition to displays like a laptop could provide a screen monitors and TVs, wireless speakers can serve as secondary devices for a smaller device like a phone. rendering Web content. General purpose PCs and laptops can also serve as secondary presentation displays.

For many of these techniques displays, the operating system hides how the screen display is attached and provides ways for native applications to use the screens. render media on them. Native applications on an operating system can easily use these additional screens presentation displays without having to know how they are attached to the device. At this point, however, there is no way for a web page to take advantage details of these available secondary displays. the connection technology.

The Second Screen Working Group aims at defining simple APIs and an open suite of network protocols (specified as an application of existing IETF protocols) that allow web applications to show present and control web content on one or more secondary displays. presentation displays and speakers.

Scope

The scope of this Working Group is to define an API define:

Pages may become authorized to control the displayed web content by virtue of sharing an origin with the originating page, through explicit user permission, a token provided by the API, or other facilities provided by the user agent. The API APIs will hide the details of the underlying connection technologies and use familiar, common web technologies APIs for messaging between the among authorized pages and the web content shown on the secondary presentation display. The web Web content may comprise an HTML documents, document; parts of an HTML document; web media types such as images, audio, video, video; or application-specific media, depending on the capabilities of the secondary display for rendering the media. Application-specific The presentation of application-specific media includes that whose type is known to the controlling page user agent and the connected presentation display, but not necessarily to a generic HTML user agent.

For a requested piece of web content, the user agent is responsible for determining which presentation displays are compatible with that content. The API will provide a the means for the web application to identify whether requesting display on second screens rendering the web content is likely to be successful, i.e. whether at least one secondary screen presentation display is available for display. that is capable of rendering the web content.

The API is agnostic with regard to the display connection used, and also works with technology used. The user agent may ask the presentation display connections that support video only, for example, a TV connected to a laptop with an HDMI connection. In such a usage scenario, render the web content displayed on a connected display must be rendered and converted to video before it is sent to a second screen. The content, or the user agent may use whatever means render the operating system provides to prepare web content itself and send the resulting audio and video to a second screen. Any interaction between the authorized web pages and presentation display using whatever means the content displayed on a secondary screen would happen within operating system provides. From the bounds web application's point of the initiating view, which device since both the pages and is responsible for rendering the web content are rendered on that same device, and only a video representation is sent to the second screen. an implementation detail.

Alternatively, if the second screen device understands some other means of transmitting Presenting web content to on a presentation display and creates a means of two-way message passing, presentation connection between the web content can be rendered by the remote device. In this scenario, a URL to application and the content to web content. Web applications should be displayed is sent able to the secondary display create multiple presentation connections to be rendered there. Because the control web content is rendered separately shown on multiple presentation displays. Some web content, such as HTML5 documents, can be controlled from the initiating user agent, pages hosted by other user agents multiple web applications simultaneously. Synchronization of web content among multiple connections may be authorized to control the remotely rendered content at possible, but is not defined by the same time. specifications in this group.

For a requested piece The suite of web content, how and by which device network protocols will cover required steps for two user agents to implement the content is rendered is an implementation detail. APIs: discovery, authentication, transport, and messaging (including API control messages and messages for streaming media between agents). The user agent is responsible suite will reuse and configure existing IETF protocols for determining which secondary displays are compatible each of these steps. This Working Group will work with the content IETF to assess whether parts of the protocol suite may apply to broader scenarios than the ones envisioned for the APIs. If that is requested to the case, those parts may be shown through further developed in the API. IETF.

Sending This Working Group will not mandate network protocols for sharing web content to a connected display creates a presentation session. Applications can create multiple presentation sessions to control multiple displays, although synchronization between them is not currently supported by user agents and presentation displays. The APIs will informatively reference the API. protocol suite.

The specifications produced by this Working Group will include security and privacy considerations. Specifically, In particular, the user must always be in control of privacy-sensitive information that may be conveyed through the APIs, such as the visibility or access to secondary displays. presentation displays, or the URLs of the web content to be presented.

Members of the Working Group should review other Working Groups' deliverables that are identified as being relevant to the Working Group's mission.

Success Criteria To advance to Proposed Recommendation , each specification is expected to have two independent implementations of each feature defined in the specification. To advance to Proposed Recommendation, interoperability between the independent implementations should be demonstrated. Interoperable user agents hosting the same Presentation API web application should be able to render the same content with the same functionality on supported secondary displays that are compatible with the content to render.

Out of Scope

The specifications defined by this Working Group abstract away the means of connecting and different connection technologies. For example, the following are out of scope:

This Working Group will not define or mandate reuse and configure existing network protocols to create an open suite of network protocols suitable for sharing content between user agents and secondary displays. For example, the APIs. As such, the following are out of scope: scope for the Working Group:

Content mirroring, whereby Input methods, such as using a web application requests display of the content shown in its own browsing context (i.e., page) on TV remote as a secondary display, is pointer or clicker, are out of scope. If a web application requests display scope of itself (same URL) on a connected display, a new browsing context will be created with that URL and rendered on the connected display. Working Group.

This Working Group will not define or mandate any video or audio codecs.

Deliverables

Draft state indicates the state of the deliverable at the time of the call for participation. Expected completion indicates when the deliverable is projected to become a Recommendation, or otherwise reach a stable state.

Normative Specifications

The Working Group will deliver at least the following specifications:

Presentation API

An API that allows a web application to request display of web content on a connected display, with a means to communicate with and control the web content from the initiating page and other authorized pages.

Draft state: CR / Stable

Expected completion: Q2 Q4 2021 — The Working Group is awaiting satisfaction of the Success Criteria , which require two interoperable implementations of the Presentation API. The Working Group will also await demonstration of interoperability among multiple browsers and multiple presentation displays before moving the specification to Proposed Recommendation.

Reference Draft: https://www.w3.org/TR/2017/CR-presentation-api-20170601/
Associated Call for Exclusion on 19 October 2017 ended on 31 July 2017
Produced under Working Group Charter: https://www.w3.org/2014/secondscreen/charter-2016.html

The Open Screen Protocol will be the basis for demonstrating interoperability between browsers and devices. Two implementations based on it would satisfy those criteria. The charter timeline provides additional time for Open Screen Protocol implementations to be completed and the Success Criteria to be met.

Presentation API Level 2

A second version of the Presentation API that integrates features which the Working Group resolved not to include in the first version in the interest of time, and also feedback from Web developers on the first version, as well as stable features will first be incubated and matured in the Second Screen an appropriate Community Group , provided they fall within the scope of this Working Group. The This Working Group's issue tracker lists examples Group expects to bring such features out of incubation through rechartering, when the criteria for moving the current Presentation API to Proposed Recommendation have been met.

Additional features that may will be integrated. Draft state: No draft (builds on considered for the CR) / Exploring Expected completion: Progress on this specification depends on Presentation API to align it with the adoption of work on the first version of Open Screen Protocol, based on implementation experience with that protocol.

Additional features will also be considered to improve compatibility with the Presentation Remote Playback API and on the outcomes presentation of discussions within additional media types that are supported by the Open Screen Protocol.

All API changes will be incubated in the companion Second Screen Community Group . This Working Group does not expect to complete this specification by before being considered in the end of this charter and may request to be re-chartered to finalize this work, possibly with a different scope. Working Group.

Remote Playback API

An API that allows a web application to request display of media content on a connected display, with a means to control the remote playback from the initiating page and other authorized pages.

Draft state: FPWD CR / Refining Stable

Expected completion: Q3 Q4 2020 — The Working Group plans to publish the Remote Playback API as a final Recommendation when the Success Criteria are met.

Reference Draft: https://www.w3.org/TR/2017/CR-remote-playback-20171019/
Associated Call for Exclusion on 19 October 2017 ended on 18 December 2017
Produced under Working Group Charter: https://www.w3.org/2014/secondscreen/charter-2016.html

Additional features will be considered for the Remote Playback API to align it with the work on the Open Screen Protocol, based on implementation experience with that protocol.

Additional features will also be considered to improve compatibility with the Presentation API and remote playback of additional media types that are supported by the Open Screen Protocol.

All API changes will be incubated in the Second Screen Community Group before being considered in the Working Group.

Open Screen Protocol

A suite of network protocols that allow user agents to implement the Presentation API and the Remote Playback API in an interoperable fashion for browsers and presentation displays connected via the same local area network.

Draft state: Adopted from the Second Screen Community Group

Expected completion: Q2 2021

The Working Group may decide to group the API functions and protocol suite in one or more specifications.

Other Deliverables

Test suite

A comprehensive test suite for all features of a specification is necessary to assess 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 before transition to Candidate Recommendation, and which must be completed with an implementation report before transition to Proposed Recommendation. Additional tests may be added to the test suite at any stage of the Recommendation track, and the maintenance of a an implementation report is encouraged.

Additionally, this Working Group will improve test automation for the Presentation API and Remote Playback API test suites. This will be done through the adoption of a Testing API, incubated in an appropriate Community Group. The Testing API will also allow developers to use automation to test their own Web applications that make use of the above-mentioned APIs.

Use cases and requirements

The Working Group is strongly encouraging the participants to create and maintain a use cases and requirements document for each specification.

Implementation guidelines

To facilitate interoperability among user agents and display devices and encourage adoption of the API, the group may provide informative guidelines for implementors, either directly as informative notes within the Presentation API or in a separate non-normative group Note.

Other non-normative documents may be created for each specification, for example:

Milestones

Milestones
Note: See changes from this initial schedule on the group home page .
Specification FPWD CR PR Rec
Presentation API - - Q2 2017 Q4 2021 Q2 2017 Q4 2021
Presentation Remote Playback API Level 2 Q3 2017 - - - Q4 2020 - Q4 2020
Remote Playback API Open Screen Protocol - Q1 2020 Q2 2017 Q4 2020 Q3 2017 Q2 2021 Q4 2017 Q2 2021

Success Criteria

To advance to Proposed Recommendation , each specification is expected to have two independent implementations of each feature defined in the specification.

To advance to Proposed Recommendation, interoperability between the independent implementations should be demonstrated. Interoperable user agents hosting the same Presentation API web application should be able to render the same content with the same functionality on supported presentation displays that are compatible with the content to render.

The specifications produced by this Working Group will include security and privacy considerations. Specifically, the user must always be in control of privacy-sensitive information that may be conveyed through the APIs, such as the visibility or access to presentation displays, or the URLs of the web content to be presented. Specifications should also avoid unnecessary or severe increases to fingerprinting surface, especially for passive fingerprinting .

This Working Group will follow a test as you commit approach to specification development, for specifications in CR or above.

Dependencies and Liaisons

Dependencies

The initial draft drafts of the Presentation API was and of the Open Screen Protocol were prepared by the Second Screen Community Group . Upon approval of the Working Group, the Community Group will cease ceased its work on the Presentation API specification. It is expected that and the core Open Screen Protocol specifications. The Community Group will recharter to may work on other related deliverables where it is not clear enough how to proceed for it to be a work item for a Working Group. Group, including on extensions to the Open Screen Protocol. The Community Group is only one possible source for work under future Working Group charters, but can serve to do initial exploration for some future work items.

The specifications produced by this Working Group adhere to the web's origin-based security model defined in the HTML specification published by the Web Platform Working Group. model.

Common web technologies that this Working Group could refer to for messaging include Web Messaging and the Web Socket API defined by the Web Platform Working Group. Even though the scopes of the APIs are different, some of the use cases that the Presentation API aims to address, in particular projection of web content on second screens connected to the local area network, are also in scope of the Network Service Discovery API worked upon by the Device and Sensors Working Group. This Working Group will liaise with the Device and Sensors Working Group, in particular to help ensure consistency of supported service discovery mechanisms when a user agent implements both APIs. API.

No external dependencies against the specifications of this Working Group have been identified.

Liaisons

The For all specifications, this Working Group expects to maintain contacts will seek horizontal review for accessibility, internationalization, performance, privacy, and security with at least the following groups relevant Working and Activities within W3C (in alphabetical order) Interest Groups, and ask with the TAG . Invitation for wide reviews of its deliverables before publication as Candidate Recommendation, and where appropriate: Device and Sensors Working Group review must be issued during each major standards-track document transition, including FPWD The Device and Sensors Working Group defines the Network Service Discovery API that addresses some of the use cases that are in scope of the Second Screen Working Group. HTML Media Extensions Working Group The Second Screen Working Group may interact with the HTML Media Extensions Working Group on the interaction between media extensions at least 3 months before CR , and the Remote Playback API should be issued when major changes occur in a specification. Privacy Interest Group The Second Screen Working Group intends to secure reviews on its deliverables from

Additional technical coordination with the Privacy Interest Group to help ensure they offer following Groups will be made, per the right level of protection to users. W3C Process Document :

Second Screen Community Group
This group developed the initial version of the Presentation API and of the Open Screen Protocol, and focuses on enabling interoperability among implementations of the Presentation API, second screen APIs, encouraging implementation of the Presentation API the APIs by browser vendors and establishing complementary specifications for the Presentation API. The Community Group will specify a set of network protocols that may warrant changes in the Presentation API. APIs.
Accessible Platform Architectures (APA) Working Group
To help ensure deliverables support accessibility requirements, particularly with regard to interoperability with assistive technologies, and inclusion in the deliverable of guidance for implementing the group’s deliverables in ways that support accessibility requirements.
Web Media and TV Entertainment Interest Group
This group provides use cases and requirements for second screen scenarios and thus important input on the deliverables developed by the Second Screen Working Group.
Web Platform Working Group The Web Platform Working Group’s deliverables cover the security model implemented in Web Browsers; as well as other relevant specifications such as Web IDL , HTML5 Web Messaging , The Web Socket API and the HTML specification that contain the definition of the HTMLMediaElement interface that the Remote Playback API specification extends. Web Real-Time Communications Working Group
This group defines relevant or potentially relevant specifications for establishing peer-to-peer communication channels and for extending the Presentation API to support out-of-scope features such as content mirroring. Web Security Interest Group The Second Screen Working Group intends to secure reviews on its deliverables from the Web Security Interest Group to help ensure they offer the right level of security. between web applications.

External Groups

The While the Presentation API does not have strong dependencies a direct dependency on any given set of protocols. The protocols, the following is a tentative list of external bodies the Working Group should collaborate with to develop the Open Screen Protocol and allow the Presentation API and Remote Playback API to be implemented on top of widely deployed attachment methods for connected displays:

DLNA IETF
The Digital Living Network Alliance references home IETF develops network protocols that secondary presentation displays may support. support, and that form the core of the Open Screen Protocol. The Second Screen Working Group will liaise with relevant groups at IETF to assure proper and secure application of IETF protocols within the Open Screen Protocol. These groups include Extensions for Scalable DNS Service Discovery , QUIC , Transport Layer Security (TLS), Crypto Forum Research Group , and Concise Binary Object Representation Maintenance and Extensions . The Second Screen Working Group will also liaise with IETF to assess whether parts of the Open Screen Protocol apply to broader scenarios than the ones envisioned for the APIs. Those parts may be developed further in the IETF.
IETF Open Connectivity Foundation
The IETF Open Connectivity Foundation develops home network protocols that secondary presentation displays may support. support, including the UPnP suite of protocols.
UPnP Forum Web Hypertext Application Technology Working Group (WHATWG)
The UPnP Forum WHATWG develops home network protocols the HTML specification that secondary displays may support. contains the definition of the HTMLMediaElement interface that the Remote Playback API specification extends; as well as the Web sockets and the cross-document messaging interfaces after which the communication channel of the Presentation API is modeled.
Wi-Fi Alliance
The Wi-Fi Alliance develops home network protocols that secondary presentation displays may support.

Participation

To be successful, the Second Screen Working Group is expected to have 10 6 or more active participants for its duration, and to have the participation of industry leaders in fields relevant to the specifications it produces.

The Chairs and specification Editors are expected to contribute half a working day per week towards the Working Group. There is no minimum requirement for other Participants. This Working Group will also allocate the necessary resources for building Test Suites for each specification.

The group also welcomes non-Members to contribute technical submissions for consideration, with the agreement from each participant to Royalty-Free licensing of those submissions under the W3C Patent Policy.

Communication

Teleconferences will be conducted on an as-needed basis.

This group primarily conducts its technical work on the GitHub. The public mailing list public-secondscreen@w3.org . is used for calls for consensus. Administrative tasks may be conducted in Member-only communications.

Information about the group (deliverables, participants, face-to-face meetings, teleconferences, etc.) is available from the Second Screen Working Group home page.

Decision Policy

As explained in the W3C Process Document ( section 3.3 ), this This group will seek to make decisions when there is through consensus and with due process. The expectation is that typically, process, per the W3C Process Document (section 3.3) . Typically, an editor or other participant makes an initial proposal, which is then refined in discussion with members of the group and other reviewers, and consensus emerges with little formal voting being required.

However, if a decision is necessary for timely progress, but consensus is not achieved after careful consideration of the range of views presented, the Chairs should put a question out may call for voting within the a group (allowing for remote asynchronous participation -- using, for example, email and/or web-based survey techniques) vote, and record a decision, decision along with any objections. The matter should then be considered resolved unless and until new information becomes available.

Any To afford asynchronous decisions and organizational deliberation, any resolution (including publication decisions) taken in a face-to-face meeting or teleconference is to will be considered provisional until provisional.

A call for consensus (CfC) will be issued for all resolutions (for example, via email and/or web-based survey), with a response period from one week to 10 working days after days, depending on the publication chair's evaluation of the resolution in draft minutes sent to group consensus on the working groups mailing list. issue.

If no objections are raised on the mailing list within that time, by the end of the response period, the resolution will be considered to have consensus as a resolution of the Working Group.

All decisions made by the group should be considered resolved unless and until new information becomes available, or unless reopened at the discretion of the Chairs or the Director.

This charter is written in accordance with Section 3.4, Votes of the W3C Process Document (Section 3.4, Votes) , and includes no voting procedures beyond what the Process Document requires.

Patent Policy

This Working Group operates under the W3C Patent Policy (5 (Version of 5 February 2004 Version). updated 1 August 2017). To promote the widest adoption of Web standards, W3C seeks to issue Recommendations that can be implemented, according to this policy, on a Royalty-Free basis.

For more information about disclosure obligations for this group, please see the W3C Patent Policy Implementation .

Licensing

This Working Group will use the W3C Software and Document license for all its deliverables.

About this Charter

This charter for the Second Screen Working Group has been created according to section 5 5.2 of the Process Document . In the event of a conflict between this document or the provisions of any charter and the W3C Process, the W3C Process shall take precedence.

Charter History

The following table lists details of all changes from the initial charter, per the W3C Process Document (section 5.2.3) :

Charter Period Start Date End Date Changes
Initial Charter 13 October 2014 31 October 2016 none
Rechartered 3 November 2016 31 October 2017
  • Group name adjusted to reflect practice
  • Deliverables updated to reflect current status
  • New Presentation API Level 2 deliverable mentioned
  • On-going efforts on protocols in Second Screen Community Group noted
  • Other adjustments: liaisons, licensing text
Extended 17 October 2017 31 December 2017 End date adjusted
Extended 1 December 2017 31 January 2018 End date adjusted
Rechartered 2 February 2018 31 December 2019
  • Completion dates updated to reflect current implementation plans, dependency on Open Screen Protocol noted
  • Dropped second version of the Presentation API. Intent to re-include it later on after incubation and completion of current version noted
  • Intent to work on testing APIs after incubation in a Community Group noted in Test suite section
  • Dropped reference to the discontinued Network Service Discovery API which was developed by the Device and Sensors Working Group
  • Updated boilerplate text using current charter template
  • Added "test as you commit" approach
  • Adjusted group names in liaisons section accordingly
Rechartered 1 January 2020 31 December 2021
  • Replaced the term "screen" by "presentation display" for consistency with the APIs
  • Put presentation of parts of an HTML document in scope of the Working Group
  • Put the standardization of a protocol suite for the APIs in scope of the Working Group
  • Added the Open Screen Protocol deliverable accordingly
  • Listed relevant IETF group for the Open Screen Protocol in the liaisons section
  • A few editorial updates