Second Screen Presentation Working Group Charter

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

Join the Second Screen Presentation Working Group

End date	31 October 2016
Confidentiality	Proceedings are Public
Initial Chairs	Anssi Kostiainen
Initial Team Contacts (FTE %: 20)	François Daoust
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 use the #webscreens W3C IRC channel

Goals

Web content is available on an ever expanding array of devices including ebook readers, phones, tablets, laptops, auto displays, and electronic billboards. These devices have a variety of display screens. There are also a variety of mechanisms that allow these devices to use secondary display screens 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 Miracast, WiDi, or AirPlay. Wireless screens may be available on a local area network or over the Internet, brokered by a cloud service. A device like a laptop could provide a screen for a smaller device like a phone.

For many of these techniques the operating system hides how the screen is attached and provides ways for native applications to use the screens. Native applications on an operating system can easily use these additional screens 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 of these available secondary displays.

The Second Screen Presentation Working Group aims at defining simple APIs that allow web applications to show and control web content on one or more secondary displays.

Scope

The scope of this Working Group is to define 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. Pages may become authorized to control the web content by virtue of sharing an origin with the originating page, explicit user permission, or other facilities provided by the user agent. The API will hide the details of the underlying connection technologies and use familiar, common web technologies for messaging between the authorized pages and the web content shown on the secondary display. The web content may comprise HTML documents, web media types such as images, audio, video, or application-specific media, depending on the capabilities of the secondary display for rendering the media. Application-specific media includes that whose type is known to the controlling page and the connected display, but not necessarily a generic HTML User Agent.

The API will provide a means to identify whether requesting display on second screens is likely to be successful, i.e. whether at least one secondary screen is available for display.

The API is agnostic with regard to the display connection used, and also works with display connections that support video only, for example, a TV connected to a laptop with an HDMI connection. In such a usage scenario, the web content displayed on a connected display must be rendered and converted to video before it is sent to a second screen. The User Agent may use whatever means the operating system provides to prepare and send the video to a second screen. Any interaction between the authorized web pages and the content displayed on a secondary screen would happen within the bounds of the initiating device since both the pages and the content are rendered on that same device, and only a video representation is sent to the second screen.

Alternatively, if the second screen device understands some other means of transmitting content to a display and a means of two-way message passing, the web content can be rendered by the remote device. In this scenario, a URL to the content to be displayed is sent to the secondary display to be rendered there. Because the content is rendered separately from the initiating user agent, pages hosted by other user agents may be authorized to control the remotely rendered content at the same time.

For a requested piece of web content, how and by which device the content is rendered is an implementation detail. The user agent is responsible for determining which secondary displays are compatible with the content that is requested to be shown through the API.

Sending 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 the API.

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 secondary displays.

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:

Lower level APIs that expose features of different connection technologies
How second screens are connected to the primary device (e.g. Video Port, HDMI, WiDi, Miracast, AirPlay)
How the User Agent prepares and sends the screen contents to the second screen

This Working Group will not define or mandate network protocols for sharing content between user agents and secondary displays. For example, the following are out of scope:

Discovery of wireless secondary displays by the primary user agent
Establishment of a messaging channel between the two parties, including message addressing, security and authentication
Negotiation of a media streaming session between devices
Network transport of media data

To facilitate interoperability among user agents and display devices and encourage adoption of the API, the group may informatively reference existing suites of protocols, either directly in the Presentation API deliverable or in a non-normative companion Note.

Content mirroring, whereby a web application requests display of the content shown in its own browsing context (i.e., page) on a secondary display, is out of scope. If a web application requests display of itself (same URL) on a connected display, a new browsing context will be created with that URL and rendered on the connected display.

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

Deliverables

Recommendation-Track Deliverables

The working group will deliver at least the following specification:

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. The initial version of this document will be copied from the Presentation API W3C Community Group Final Report produced by the W3C Second Screen Presentation Community Group. Further modifications (if any) will be decided upon by this Working Group.

The working group may decide to group the API functions in one or more specifications.

Other Deliverables

Test suite: 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 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 implementation report is encouraged.
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:

Primers
Non-normative schemas for language formats
Non-normative group notes

Milestones

Milestones
Specification	FPWD	LC	CR	PR	Rec
Note: The group will document significant changes from this initial schedule on the group home page.
Presentation API	Q4 2014	Q2 2015	Q4 2015	Q2 2016	Q2 2016

Dependencies and Liaisons

Dependencies

The initial draft of the Presentation API was prepared by the Second Screen Presentation Community Group. Upon approval of the Working Group, the Community Group will cease its work on the Presentation API specification. It is expected that the Community Group will recharter to 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. The Community Group is only one possible source for work under future WG 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 security model defined in the HTML specification published by the HTML Working Group.

Common web technologies that this Working Group could refer to for messaging include Web Messaging and the Web Socket API defined by the Web Applications 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 APIs Working Group. This Working Group will liaise with the Device APIs Working Group, in particular to ensure consistency of supported service discovery mechanisms when a user agent implements both APIs.

This Working Group is not aware of any dependencies other Working Groups’ specifications have on this Working Group’s specifications.

Liaisons

The Working Group expects to maintain contacts with at least the following groups and Activities within W3C (in alphabetical order) and ask for reviews of deliverables in Last Call, and where appropriate:

Device APIs Working Group: The Device APIs Working Group defines the Network Service Discovery API that addresses some of the use cases that are in scope of the Second Screen Presentation Working Group.
HTML Working Group: The HTML Working Group’s deliverables cover the security model implemented in Web Browsers; this security model imposes limitations on what an extended model for Web Applications can achieve.
Privacy Interest Group: The Second Screen Presentation Working Group intends to secure reviews on its deliverables from the Privacy Interest Group to ensure they offer the right level of protection to users.
Second Screen Presentation Community Group: This group developed the initial version of the Presentation API and will likely continue to explore new features.
Web Accessibility Initiative Protocols and Formats Working Group: To ensure the Presentation API supports 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 Applications Working Group: This group defines relevant or potentially relevant specifications including Web IDL, HTML5 Web Messaging and The Web Socket API.
Web and TV Interest Group: This group provides use cases and requirements for second screen scenarios and thus important input on the Presentation API developed by the Second Screen Presentation Working Group.
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 Presentation Working Group intends to secure reviews on its deliverables from the Web Security Interest Group to ensure they offer the right level of security.

External Groups

The Presentation API does not have strong dependencies on any given set of protocols. The following is a tentative list of external bodies the Working Group should collaborate with to ensure that the Presentation API can be implemented on top of widely deployed attachment methods for connected displays:

DLNA: The Digital Living Network Alliance references home network protocols that secondary displays may support.
IETF: The IETF develops home network protocols that secondary displays may support.
UPnP Forum: The UPnP Forum develops home network protocols that secondary displays may support.
Wi-Fi Alliance: The Wi-Fi Alliance develops home network protocols that secondary displays may support.

Participation

To be successful, the Second Screen Presentation Working Group is expected to have 10 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 one half-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 work on the public mailing list [email protected]. 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 Presentation Working Group home page.

Decision Policy

As explained in the W3C Process Document (section 3.3), this group will seek to make decisions when there is consensus and with due process. The expectation is that 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 for voting within the group (allowing for remote asynchronous participation -- using, for example, email and/or web-based survey techniques) and record a decision, along with any objections. The matter should then be considered resolved unless and until new information becomes available.

Any resolution taken in a face-to-face meeting or teleconference is to be considered provisional until 10 working days after the publication of the resolution in draft minutes sent to the working groups mailing list. If no objections are raised on the mailing list within that time, the resolution will be considered to have consensus as a resolution of the Working Group.

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

Patent Policy

This Working Group operates under the W3C Patent Policy (5 February 2004 Version). 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.

Document License

Documents produced by this group will be licensed under the W3C Document License. In addition, "Code Components" —Web IDL in sections clearly marked as Web IDL; and W3C defined markup (HTML, CSS, etc.) and computer programming language code clearly marked as code examples— will be licensed under the W3C Software License. The group should use the following copyright statement:

Copyright © 2014 W3C^® (MIT, ERCIM, Keio, Beihang), All Rights Reserved. W3C liability, trademark and document use rules apply. Additionally, all Code Components, as defined below, are made available under the W3C Software License and Notice.

For the purpose of this license, Code Components are:
Web IDL in sections clearly marked as Web IDL; and
W3C defined markup (HTML, CSS, etc.) and computer programming language code clearly marked as code examples.

About this Charter

This charter for the Second Screen Presentation Working Group has been created according to section 6.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.

Note added 13 October 2014: The Director has indicated to the Membership that, pending PSIG input on a licensing proposal raised during AC review, this charter may be updated in place if there is support for the proposal.

Note added 15 October 2014: After receiving input from PSIG, the Director has updated the charter in-place to modify the copright license as requested. See new Document License section above.