Requirement Document Draft

(ONLY THE EDITOR SHOULD CHANGE THIS DOCUMENT)

This section contains the draft for a requirements document as discussed by the Media Pipeline TF. This is a best-effort attempt to summarize the consensus reached so far by the TF but is still to be considered a draft subject to change at any time.

Abstract

There

Status of This Document

This document is merely a public working draft of requirement(s) for potential W3C recommendations. It has no official standing of any kind and does not represent the support or consensus of any standards organization.

Introduction

There

Conformance

As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.

The key words must, must not, required, should, should not, recommended, may, and optional in this specification are to be interpreted as described in [RFC2119].

This specification only applies to one class of product: W3C Technical Reports. A number of specifications may be created to address the requirements enumerated in this document. In some cases the union of multiple parts of different specifications may be needed to address a single requirement. Nevertheless, this document speaks only of a conforming specification.

A conforming specification is one that addresses one or more requirements listed in this document. A conforming specification should attempt to address requirements marked with the keywords "should" or "may" unless there is a technically valid reason not to do so.

Terminology

programme (program)

A programme (program) comprises a single period of audio visual content. It is usually expected to be labeled in content directories or television programme guides as a single entity. This might include an episode of a television programme, a radio programme, or a movie.

device

For the purposes of this document, a device is any piece of equipment connected to the home network. Note that this is a generic term that includes also television definition below.

television

A device that presents programme content from a variety of sources - such as received via broadcast (cable, satellite, terrestrial), on-demand streaming services, or streamed from other devices in the home (e.g. PVR). Within the scope of this document, it is presumed that a television is connected to the home network.

service

For the purposes of this document, a service is any functionality available on a device, such as the ability to playback audio/video content, record content, print documents etc.

document

An individual resource that adheres to a certain content type, ranging from short static documents to long essays or reports with rich multimedia. For simplicity, terms such as shown, displayed, and visible might sometimes be used when referring to the way a document is rendered to the user. These terms are not meant to imply a visual medium; they must be considered to apply to other media in equivalent ways.

application

For the purposes of this document, the term "Application" refers to a collection of documents (not necessarily delivered over HTTP) which use server-side or client-side processing (e.g. JavaScript) to provide an "application-like" experience within a Web browser or other kinds of Web run-time. Applications may include locally executable elements of interactivity and persistent state. Note that locally stored applications like W3C Widgets are also covered by this definition.

content item

For the purposes of this document, the term “content item” refers to metadata describing or more binary versions of media. The media described by an item may either be stored or streamed. A single content item may refer to multiple media binaries that represent different formats for the content being described.

channel item

For the purposes of this document, the term “channel item” refers to an “item” describing a streaming source. A channel item may contain metadata describing the channel source such as channel number, distribution network, etc. A channel may not be available on the home network, i.e. the “channel item” may refer to a channel that can only be locally tuned. In these cases “channel item” metadata will not provide network addressing information (URLs) to connect to the channel source.

record task (item)

For the purposes of this document, the term “record task item” refers to an item which contains metadata describing a pending or completed network recording operation. “Record task items” are created by a network recording service and allow network record service clients to control pending recording operations. Additionally, “record task items” include metadata describing the status of the recording request and the identity of “content items” that represent the results of network recording operations.

Requirements

This section enumerates the requirements that conforming specification(s) would need to address to enable content to be delivered to authorized users and reasonably withheld from unauthorized use according the the agreements between the authorized users, the content owners and the content delivery agents. These requirements are directly motivated by the #Use cases described in this document and are based on an interactive process of feedback from the discussions in the Media Pipeline Task Force of the Web & TV IG. This document and the Media Pipeline Task Force take no position on the specifics of the agreements between the authorized users, the content owners and the delivery agents except that the range of points in the agreements must be reflected in the features of the technical requirements. The technical requirements should be flexible enough to anticipate some changes in the agreements over time.

General

Compatibility with widely deployed standards

Several channel and content protection systems (e.g. DTCP-IP, HDCP, HTTPS, , M-DNS/DNS-SD) are in popular use today for enabling the legitimate use of content an preventing the illigitimate use of content through digital content storage and distribution systems. A conforming specification shall set out requirements for an API that would enable interaction with those existing protocols.

Control and Communication

Control of content players

Conforming specifications should enable applications to know what content that can be presented by a device or service on the home network and control the playback of that content presented, in such a way that the application does not have to handle:

issues of codec, container format, or transport protocol compatibility
differences in the mechanisms by which content is delivered to the rendering device (e.g. received from broadcast vs. streamed from a media server)

Use cases

This section is a non-exhaustive list of use cases that would be enabled by one (or more) specifications implementing the requirements listed above. Each use case is written according to the following template:

Ux. <TITLE>
Original Proposal: ISSUE-n

Description: 
* high level description/overview of the goals of the use case
* Schematic Illustration (devices involved, work flows, etc.) (Optional)

Motivation: 
* Explanation of benefit to ecosystem
* Why were you not able to use only existing standards to accomplish this?

Dependencies:
* other use cases, proposals or other ongoing standardization activities which this use case is dependent on or related to

Requirements:
* List of requirements implied by this Use Case.

U1. Service User Interface

Original Proposal: ISSUE-??

Description: An application ...

Possible implementation:

the application ...

Motivation: There is ...

Dependencies: In order to ...

Requirements:

Low Level	High Level
Determine list of...	#Service ...
Determine list of ...	#Service ...
Send a message to ...	#Service ...
Listen to ...	#Service ...

Security

Tracker : ISSUE-??

Enabling application access ...

This section lists possible threats that a conforming specification may have to deal with and possible solutions to reduce risks for the user. This section is not intended as an exhaustive list of problems and solutions but is intended to provide some directions for further investigation

Threats

Security

Malicious attacks
- An external server can ...

Privacy

3rd party visibility into ...

Potential solutions

The list of techniques listed in this section are not mutually exclusive but can be combined to provide more flexibility in handling user security.

Home Network access allowed only to Trusted applications

In order for ...

Categorization of Requirements and next steps

One of the deliverable of the Media Pipeline Taskforce, according to its charter, ...

This section summarizes the consensus of the TF about the desirable next steps and also to try to give an indication of relative priorities of the identified requirements.

Requirement Categorization

The MPTF has made an attempt to categorize requirements based on the priority of addressing them to enable some of the use cases that are already available via other technologies or that are felt particularly important to have an enhanced user experience. All identified requirements are considered important by the Task Force; so the criteria followed is more the degree to which each requirements enables use cases that cannot be covered today rather than a value judgment of the importance of one requirement versus another (which differs by individual). By this "enablement" criterion, a feature that enables more use cases is higher priority than a feature that enables a limited subset of use cases.

The following requirements underpin most (all) of the use cases listed in this document, so they are considered the starting point for a technical work:

...

Identified Gaps

A close analysis and discussion of the use-cases and requirements described in this document, lead the group to conclude that ...

Next Steps

The MPTF believes that ...

Open Issues

During his work, ...

Related works (informative)

This section include references to related works (prototypes, draft APIs, etc.) that have been produced by IG participants and are related to the use cases outlined in this document. Note that this section is informative and that the Web and TV IG does not endorse any of the works listed in this section. Nevertheless the Web and TV IG thinks that these related works contain useful ideas that could be discussed and expanded by a working group writing specifications addressing requirements enumerated in this document.