--- a/mpreq/MPTF-CP-Requirements.html Tue May 01 16:37:09 2012 -0600
+++ b/mpreq/MPTF-CP-Requirements.html Thu May 10 06:51:33 2012 -0600
@@ -1,261 +1,264 @@
<!DOCTYPE html>
<html>
- <head>
- <title>MPTF Requirements for Content Protection</title>
- <meta http-equiv='Content-Type' content='text/html;charset=utf-8'/>
- <!--
- === NOTA BENE ===
- For the three scripts below, if your spec resides on dev.w3 you can check them
- out in the same tree and use relative links so that they'll work offline,
- -->
- <script src='http://dev.w3.org/2009/dap/ReSpec.js/js/respec.js' class='remove'></script>
- <script class='remove'>
- var respecConfig = {
- // specification status (e.g. WD, LCWD, NOTE, etc.). If in doubt use ED.
- specStatus: "WD",
-
- // the specification's short name, as in http://www.w3.org/TR/short-name/
- shortName: "mptf-cp-rq",
-
- // if your specification has a subtitle that goes below the main
- // formal title, define it here
- // subtitle : "an excellent document",
-
- // if you wish the publication date to be other than today, set this
- // publishDate: "2009-08-06",
-
- // if the specification's copyright date is a range of years, specify
- // the start date here:
- // copyrightStart: "2005"
-
- // if there is a previously published draft, uncomment this and set its YYYY-MM-DD date
- // and its maturity status
- // previousPublishDate: "1977-03-15",
- // previousMaturity: "WD",
-
- // if there a publicly available Editor's Draft, this is the link
- edDraftURI: "http://dev.w3.org/2009/dap/ReSpec.js/documentation.html",
-
- // if this is a LCWD, uncomment and set the end of its review period
- // lcEnd: "2009-08-05",
-
- // if you want to have extra CSS, append them to this list
- // it is recommended that the respec.css stylesheet be kept
- extraCSS: ["http://dev.w3.org/2009/dap/ReSpec.js/css/respec.css"],
-
- // editors, add as many as you like
- // only "name" is required
- editors: [
- { name: "Clarke Stevens", url: "http://example.org/",
- company: "CableLabs", companyURL: "http://www.cablelabs.com" },
- ],
-
- // authors, add as many as you like.
- // This is optional, uncomment if you have authors as well as editors.
- // only "name" is required. Same format as editors.
-
- //authors: [
- // { name: "Your Name", url: "http://example.org/",
- // company: "Your Company", companyURL: "http://example.com/" },
- //],
-
- // name of the WG
- wg: "Media Pipeline Task Force of the Web & TV IG",
-
- // URI of the public WG page
- wgURI: "http://www.w3.org/2011/webtv/wiki/MPTF",
-
- // name (without the @w3c.org) of the public mailing to which comments are due
- wgPublicList: "spec-writers-anonymous",
-
- // URI of the patent status for this WG, for Rec-track documents
- // !!!! IMPORTANT !!!!
- // This is important for Rec-track documents, do not copy a patent URI from a random
- // document unless you know what you're doing. If in doubt ask your friendly neighbourhood
- // Team Contact.
- wgPatentURI: "",
- };
- </script>
- </head>
- <body>
- <section id='abstract'>
- The MPTF is a subset of the Web and TV Interest Group. The goal of MPTF is to discuss requirements placed on the HTML5 video, audio and media interfaces by media formats that used for Web and TV applications. The MPTF also proposes APIs that meet these requirements.
- </section>
-
- <section id="sotd">
- Recommendations in this document...
- </section>
-
- <section>
- <h2>Introduction</h2>
- <p>A majority of Internet traffic is now streaming video.</p>
-
- <p>However, there are currently no standards or common conventions in HTML to provide the level of content protection required by some content owners. As a result, content owners must support multiple, non-interoperable private content protection solutions.</p>
- </section>
-
- <section>
- <h2>Conformance</h2>
-
- <p>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.</p>
-
- <p>The key words MUST, MUST NOT, SHALL, SHOULD and SHOULD NOT in this specification are to be interpreted as described in RFC 2119 [[RFC2119]].</p>
-
- <p>This specification only applies to one class of product: <dfn>W3C Technical Reports</dfn>. 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 <dfn>conforming specifications</dfn>.</p>
-
- <p>Conforming specifications are ones that address one or more requirements listed in this document. Conforming specifications should attempt to address SHOULD level requirements requirements unless there is a technically valid reason not to do so.</p>
- </section>
-
- <section>
- <h2>Terminology</h2>
-
- <dl>
- <dt><dfn>programme</dfn> (program)</dt>
- <dd>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.</dd>
- </dl>
- </section>
-
- <section>
- <h2>MPTF Requirements for Adaptive Bit Rate Streaming</h2>
-
- <p>This section list the requirements that conforming specification(s) would need to adopt in order to ensure a common interface and interpretation for the playback and control of adaptive bit rate media. These requirements are the result of an interactive process of feedback and discussion within the Media Pipeline Task Force of the Web and TV Interest Group</p>
-
- <section>
+ <head>
+ <title>MPTF Requirements for Content Protection</title>
+ <meta http-equiv='Content-Type' content='text/html;charset=utf-8'/>
+ <!--
+ === NOTA BENE ===
+ For the three scripts below, if your spec resides on dev.w3 you can check them
+ out in the same tree and use relative links so that they'll work offline,
+ -->
+ <script src='http://dev.w3.org/2009/dap/ReSpec.js/js/respec.js' class='remove'></script>
+ <script class='remove'>
+ var respecConfig = {
+ // specification status (e.g. WD, LCWD, NOTE, etc.). If in doubt use ED.
+ specStatus: "WD",
+
+ // the specification's short name, as in http://www.w3.org/TR/short-name/
+ shortName: "mptf-cp-rq",
+
+ // if your specification has a subtitle that goes below the main
+ // formal title, define it here
+ // subtitle : "an excellent document",
+
+ // if you wish the publication date to be other than today, set this
+ // publishDate: "2009-08-06",
+
+ // if the specification's copyright date is a range of years, specify
+ // the start date here:
+ // copyrightStart: "2005"
+
+ // if there is a previously published draft, uncomment this and set its YYYY-MM-DD date
+ // and its maturity status
+ // previousPublishDate: "1977-03-15",
+ // previousMaturity: "WD",
+
+ // if there a publicly available Editor's Draft, this is the link
+ edDraftURI: "http://dev.w3.org/2009/dap/ReSpec.js/documentation.html",
+
+ // if this is a LCWD, uncomment and set the end of its review period
+ // lcEnd: "2009-08-05",
+
+ // if you want to have extra CSS, append them to this list
+ // it is recommended that the respec.css stylesheet be kept
+ extraCSS: ["http://dev.w3.org/2009/dap/ReSpec.js/css/respec.css"],
+
+ // editors, add as many as you like
+ // only "name" is required
+ editors: [
+ { name: "Clarke Stevens", url: "http://example.org/",
+ company: "CableLabs", companyURL: "http://www.cablelabs.com" },
+ ],
+
+ // authors, add as many as you like.
+ // This is optional, uncomment if you have authors as well as editors.
+ // only "name" is required. Same format as editors.
+
+ //authors: [
+ // { name: "Your Name", url: "http://example.org/",
+ // company: "Your Company", companyURL: "http://example.com/" },
+ //],
+
+ // name of the WG
+ wg: "Media Pipeline Task Force of the Web & TV IG",
+
+ // URI of the public WG page
+ wgURI: "http://www.w3.org/2011/webtv/wiki/MPTF",
+
+ // name (without the @w3c.org) of the public mailing to which comments are due
+ wgPublicList: "spec-writers-anonymous",
+
+ // URI of the patent status for this WG, for Rec-track documents
+ // !!!! IMPORTANT !!!!
+ // This is important for Rec-track documents, do not copy a patent URI from a random
+ // document unless you know what you're doing. If in doubt ask your friendly neighbourhood
+ // Team Contact.
+ wgPatentURI: "",
+ };
+ </script>
+ </head>
+ <body>
+ <section id='abstract'>
+ The MPTF is a subset of the Web and TV Interest Group. The goal of MPTF is to discuss requirements placed on the HTML5 video, audio and media interfaces by media formats that used for Web and TV applications. The MPTF also proposes APIs that meet these requirements.
+ </section>
+
+ <section id="sotd">
+ Recommendations in this document...
+ </section>
+
+ <section>
+ <h2>Introduction</h2>
+ <p>A majority of Internet traffic is now streaming video.</p>
+
+ <p>However, there are currently no standards or common conventions in HTML to provide the level of content protection required by some content owners. As a result, content owners must support multiple, non-interoperable private content protection solutions.</p>
+ </section>
+
+ <section>
+ <h2>Conformance</h2>
+
+ <p>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.</p>
+
+ <p>The key words MUST, MUST NOT, SHALL, SHOULD and SHOULD NOT in this specification are to be interpreted as described in RFC 2119 [[RFC2119]].</p>
+
+ <p>This specification only applies to one class of product: <dfn>W3C Technical Reports</dfn>. 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 <dfn>conforming specifications</dfn>.</p>
+
+ <p>Conforming specifications are ones that address one or more requirements listed in this document. Conforming specifications should attempt to address SHOULD level requirements requirements unless there is a technically valid reason not to do so.</p>
+ </section>
+
+ <section>
+ <h2>Terminology</h2>
+
+ <dl>
+ <dt><dfn>programme</dfn> (program)</dt>
+ <dd>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.</dd>
+ </dl>
+ </section>
+
+ <section>
+ <h2>MPTF Requirements for Adaptive Bit Rate Streaming</h2>
+
+ <p>This section list the requirements that conforming specification(s) would need to adopt in order to ensure a common interface and interpretation for the playback and control of adaptive bit rate media. These requirements are the result of an interactive process of feedback and discussion within the Media Pipeline Task Force of the Web and TV Interest Group</p>
+
+ <section>
<h3>General</h3>
- <section>
- <h4>User Rights</h4>
- <p>Content protection methods must enable the rights of the user as specified in the agreement (See item 1 in Backgroud section above).</p>
- </section>
-
- <section>
- <h4>Owner Rights</h4>
- <p>Content protection methods must protect the rights of the content owners as specified in the agreement.</p>
- </section>
-
- <section>
- <h4>Distributor Rights</h4>
- <p>Content protection methods must protect the rights of the distribution service provider as specified in the agreement.</p>
- </section>
-
- <section>
- <h4>Container Format</h4>
- <p>The content protection system must not advantage one specific container format over another.</p>
- </section>
-
- <section>
- <h4>Mandatory Baseline</h4>
- <p>The content protection solution must support at least one mandatory method that can be used to enable interoperability between different systems.</p>
- <h5>This method should be unencumbered with IPR</h5>
- </section>
-
- <section>
- <h4>Browser Independence</h4>
- <p>Content protection methods must work with "open source" browsers. Specifically, the interface defined by the proposed solution should be implementable in any browser without requiring any privileged information. This scope of this requirement is limited to the interface defined in the proposed solution.</p>
- </section>
-
- <section>
- <h4>HTML5 Compatibility</h4>
- <p>Content protection must be useable in HTML5</p>
- </section>
-
- <section>
- <h4>Media Elements</h4>
- <p>(consensus not yet reached) Content protection must be useable with specific HTML5 features such as media elements (and features (such as timed tracks) within these elements).</p>
- </section>
-
- <section>
- <h4>Encrypted Content</h4>
- <p>(consensus not yet reached) Media element features that are available in an implementation must be available for encrypted content as well as unencrypted content.</p>
- </section>
-
- <section>
- <h4>Identifiable Content Protection Method</h4>
- <p>The particular content protection method required to use the content must be identifiable.</p>
- </section>
-
- <section>
- <h4>Common Parameters</h4>
- <p>Any parameters required for use of the content protection method must be identified and specifiable.</p>
- </section>
-
- <section>
- <h4>Common Errors</h4>
- <p>Specific errors relevant to content protections must be identified and reportable.</p>
- </section>
-
- <section>
- <h4>Adaptive Bit Rate Media</h4>
- <p>The content protection method must be compatible with the (new) media source element as described in the adaptive bit rate proposal.</p>
- </section>
-
- <section>
- <h4>Others...</h4>
- <p>Description...</p>
- </section>
-
- </section>
-
- </section>
-
- <section>
- <h2>Use Cases</h2>
-
-
- <p>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:</p>
-
- <dl>
+ <section>
+ <h4>User Rights</h4>
+ <p>Content protection methods must enable the rights of the user as specified in the agreement (See item 1 in Backgroud section above).</p>
+ </section>
+
+ <section>
+ <h4>Owner Rights</h4>
+ <p>Content protection methods must protect the rights of the content owners as specified in the agreement.</p>
+ </section>
+
+ <section>
+ <h4>Distributor Rights</h4>
+ <p>Content protection methods must protect the rights of the distribution service provider as specified in the agreement.</p>
+ </section>
+
+ <section>
+ <h4>Container Format</h4>
+ <p>The content protection system must not advantage one specific container format over another.</p>
+ </section>
+
+ <section>
+ <h4>Mandatory Baseline</h4>
+ <p>The content protection solution must support at least one mandatory method that can be used to enable interoperability between different systems.</p>
+ <h5>This method should be unencumbered with IPR</h5>
+ </section>
+
+ <section>
+ <h4>Browser Independence</h4>
+ <p>Content protection methods must work with "open source" browsers. Specifically, the interface defined by the proposed solution should be implementable in any browser without requiring any privileged information. This scope of this requirement is limited to the interface defined in the proposed solution.</p>
+ </section>
+
+ <section>
+ <h4>HTML5 Compatibility</h4>
+ <p>Content protection must be useable in HTML5</p>
+ </section>
+
+ <section>
+ <h4>Media Elements</h4>
+ <p>(consensus not yet reached) Content protection must be useable with specific HTML5 features such as media elements (and features (such as timed tracks) within these elements).</p>
+ </section>
+
+ <section>
+ <h4>Encrypted Content</h4>
+ <p>(consensus not yet reached) Media element features that are available in an implementation must be available for encrypted content as well as unencrypted content.</p>
+ </section>
+
+ <section>
+ <h4>Identifiable Content Protection Method</h4>
+ <p>The particular content protection method required to use the content must be identifiable.</p>
+ </section>
+
+ <section>
+ <h4>Common Parameters</h4>
+ <p>Any parameters required for use of the content protection method must be identified and specifiable.</p>
+ </section>
+
+ <section>
+ <h4>Common Errors</h4>
+ <p>Specific errors relevant to content protections must be identified and reportable.</p>
+ </section>
+
+ <section>
+ <h4>Adaptive Bit Rate Media</h4>
+ <p>The content protection method must be compatible with the (new) media source element as described in the adaptive bit rate proposal.</p>
+ </section>
+
+ <section>
+ <h4>Others...</h4>
+ <p>Description...</p>
+ </section>
+
+ </section>
+
+ </section>
+
+ <section>
+ <h2>Use Cases</h2>
+
+
+ <p>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:</p>
+
+ <dl>
<dt>Ux. <TITLE></dt>
<dd>Use case title</dd>
-
+
<dt>Description</dt>
<dd><ul>
- <li>High level description/overview of the goals of the use case</li>
- <li>Schematic illustration (devices involved, work flows, etc.) (Optional)</li>
+ <li>High level description/overview of the goals of the use case</li>
+ <li>Schematic illustration (devices involved, work flows, etc.) (Optional)</li>
</ul></dd>
-
+
<dt>Motivation</dt>
- <dd><ul>
- <li>Explanation of the benefit to the ecosystem</li>
- <li>Why existing standards cannot be used to accomplish this use case</li>
- </ul></dd>
-
+ <dd><ul>
+ <li>Explanation of the benefit to the ecosystem</li>
+ <li>Why existing standards cannot be used to accomplish this use case</li>
+ </ul></dd>
+
<dt>Dependencies</dt>
<dd>Other use cases, proposals or other ongoing standardization activities which this use case is dependent on or related to.</dd>
-
+
<dt>Requirements</dt>
<dd>List of requirements implied by this Use Case.</dd>
- </dl>
-
- <section>
- <h3>U1. Support Authorized User Access to Content</h3>
-
+ </dl>
+
+ <section>
+ <h3>U1. Support Authorized Access to Content</h3>
+
<dl>
<dt>Description</dt>
<dd>
- <p>A user who has legitimate rights to content can access the content according to the terms of the agreements with the content owner and distribution partner.</p>
-
+ <p>This use case is intended to illustrate the protection of the rights of users, owners and distributors of digital media according to a mutually supported contract. The use case does not stipulate the terms of any contract, it just requires the provision of tools that enable the terms of an anticipated contract. For users, this means provision of tools that can accurately determine a user's rights and tools allow or deny user access to content based on those rights.</p>
+ <p>For a content owner, this use case requires the provision of tools that allow the owner to ensure compensation for the use of content owned by the owner according to the contract between the owner, distributors and users. For the distributor, this use case requires the provision of tools that enable the secure distribution of content between owners and users such that the contract between owners and users can be accurately executed and vioation of that contract can be prefented.</p>
+ <p>Since all systems for providing the protection described above are vulnerable and violation of the protections is potentially lucrative, the system must be flexible enough to evolve to meet changing threats.</p>
+
<p>Possible implementation:</p>
<ul>
- <li>The user selects a content item for playback.</li>
- <li>The user's rights to play the content are automatically verified.</li>
- <li>The content plays.</li>
+ <li>The user selects a content item for playback.</li>
+ <li>The user's rights to play the content are automatically verified.</li>
+ <li>Assuming the rights are verified, the content plays. Otherwise, the content is prevented from playing.</li>
</ul>
</dd>
-
+
<dt>Motivation</dt>
<dd>
<p>There is no standard interface to verify a user's right to access premium content. This leads to the implementation of multiple incompatible rights authorization systems and interfaces. What should be standardized is:</p>
<ul>
- <li>an interface to specify the content protection system;</li>
- <li>an interface to allow any content protection system to be used to protect content;</li>
- <li>an interface to allow a user to gain legitimate access to content;</li>
+ <li>an interface to specify the content protection system;</li>
+ <li>an interface to allow any content protection system to be used to protect content;</li>
+ <li>an interface to allow a user to gain legitimate access and prevent illegitimate access to content;</li>
+ <li>an interface that allows the content protection provider to change the system over time to meet evolving threats without requiring changes to the interface</li>
</ul>
</dd>
-
+
<dt>Dependencies</dt>
<dd>
<p>In order to obtain access to protected content, the content protection system must be identified and proper credentials need to be provided.</p>
</dd>
-
+
<dt>Requirements</dt>
<dd><table>
<tr>
@@ -267,58 +270,246 @@
<td><a href="#user-rights" class="sectionRef"></a></td>
</tr>
<tr>
- <td>Identify the content protection method</td>
- <td><a href="#identifiable-content-protection-method" class="sectionRef"></a></td>
+ <td>Enable the rights of the content owner</td>
+ <td><a href="#owner-rights" class="sectionRef"></a></td>
</tr>
<tr>
- <td>Specify the content protection parameters</td>
- <td><a href="#common-parameters" class="sectionRef"></a></td>
+ <td>Enable the rights of the content distributor</td>
+ <td><a href="#distributor-rights" class="sectionRef"></a></td>
</tr>
</table></dd>
</dl>
- </section>
-
- </section>
-
- <section>
- <h2>Security</h2>
-
- <p>Paragraph...</p>
- </section>
-
- <section>
- <h2>Next Steps</h2>
-
- <p>Paragraph...</p>
- </section>
-
- <section>
- <h2>Proposals</h2>
-
- <section>
- <h3><a href=http://www.w3.org/2011/webtv/wiki/MPTF/HTML_adaptive_calls>Adaptive Bitrate calls for HTML5 <video> tag (WIP) (Duncan Rowden)</a></h3>
-
- <p>Description...</p>
- </section>
-
- <section>
- <h3><a href=http://html5-mediasource-api.googlecode.com/svn/trunk/draft-spec/mediasource-draft-spec.html>Mediasource specification (WIP) (Aaron Colwell, Adrian Bateman, Mark Watson)</a></h3>
-
- <p>Description...</p>
- </section>
- </section>
-
- <section>
- <h2>Related Works</h2>
-
- <p>Paragraph...</p>
- </section>
-
- <section class='appendix'>
- <h2>Acknowledgements</h2>
- <p>
- Many thanks to ...
- </p>
- </section>
- </body>
-</html>
+ </section>
+
+ <section>
+ <h3>U2. Support for Commonly-used Container Formats</h3>
+
+ <dl>
+ <dt>Description</dt>
+ <dd>
+ <p>This use case describes the need for a system that is flexible enough to support different implementations of content protection. Specifically, it must not unreasonably limit the container format to a design that excludes implementations.</p>
+
+ <p>Possible implementation:</p>
+ <ul>
+ <li>The user ...</li>
+ </ul>
+ </dd>
+
+ <dt>Motivation</dt>
+ <dd>
+ <p>T.... What should be standardized is:</p>
+ <ul>
+ <li>an interface ...</li>
+ </ul>
+ </dd>
+
+ <dt>Dependencies</dt>
+ <dd>
+ <p>In order ...</p>
+ </dd>
+
+ <dt>Requirements</dt>
+ <dd><table>
+ <tr>
+ <th>Low Level</th>
+ <th>High Level</th>
+ </tr>
+ <tr>
+ <td>Specify the container format</td>
+ <td><a href="#container-format" class="sectionRef"></a></td>
+ </tr>
+ </table></dd>
+ </dl>
+ </section>
+
+ <section>
+ <h3>U3. Support for a Baseline CDM</h3>
+
+ <dl>
+ <dt>Description</dt>
+ <dd>
+ <p>A ...</p>
+
+ <p>Possible implementation:</p>
+ <ul>
+ <li>The user ...</li>
+ </ul>
+ </dd>
+
+ <dt>Motivation</dt>
+ <dd>
+ <p>T.... What should be standardized is:</p>
+ <ul>
+ <li>an interface ...</li>
+ </ul>
+ </dd>
+
+ <dt>Dependencies</dt>
+ <dd>
+ <p>In order ...</p>
+ </dd>
+
+ <dt>Requirements</dt>
+ <dd><table>
+ <tr>
+ <th>Low Level</th>
+ <th>High Level</th>
+ </tr>
+ <tr>
+ <td>Define a mandatory basline content protection method</td>
+ <td><a href="#mandatory-baseline" class="sectionRef"></a></td>
+ </tr>
+ </table></dd>
+ </dl>
+ </section>
+
+ <section>
+ <h3>U4. Support for Browser-independent Implementation</h3>
+
+ <dl>
+ <dt>Description</dt>
+ <dd>
+ <p>A ...</p>
+
+ <p>Possible implementation:</p>
+ <ul>
+ <li>The user ...</li>
+ </ul>
+ </dd>
+
+ <dt>Motivation</dt>
+ <dd>
+ <p>T.... What should be standardized is:</p>
+ <ul>
+ <li>an interface ...</li>
+ </ul>
+ </dd>
+
+ <dt>Dependencies</dt>
+ <dd>
+ <p>In order ...</p>
+ </dd>
+
+ <dt>Requirements</dt>
+ <dd><table>
+ <tr>
+ <th>Low Level</th>
+ <th>High Level</th>
+ </tr>
+ <tr>
+ <td>Require implementation to be browser-independent</td>
+ <td><a href="#browser-independence" class="sectionRef"></a></td>
+ </tr>
+ <tr>
+ <td>Require compatibility with HTML5</td>
+ <td><a href="#html5-compatibility" class="sectionRef"></a></td>
+ </tr>
+ <tr>
+ <td>Require compatiblity with HTML5 media elements</td>
+ <td><a href="#media-elements" class="sectionRef"></a></td>
+ </tr>
+ </table></dd>
+ </dl>
+ </section>
+
+ <section>
+ <h3>U5. Support for Playback of Encrypted Content</h3>
+
+ <dl>
+ <dt>Description</dt>
+ <dd>
+ <p>A ...</p>
+
+ <p>Possible implementation:</p>
+ <ul>
+ <li>The user ...</li>
+ </ul>
+ </dd>
+
+ <dt>Motivation</dt>
+ <dd>
+ <p>T.... What should be standardized is:</p>
+ <ul>
+ <li>an interface ...</li>
+ </ul>
+ </dd>
+
+ <dt>Dependencies</dt>
+ <dd>
+ <p>In order ...</p>
+ </dd>
+
+ <dt>Requirements</dt>
+ <dd><table>
+ <tr>
+ <th>Low Level</th>
+ <th>High Level</th>
+ </tr>
+ <tr>
+ <td>Playback of encrypted content</td>
+ <td><a href="#encrypted-content" class="sectionRef"></a></td>
+ </tr>
+ <tr>
+ <td>Identification of the content-protection method used</td>
+ <td><a href="#identifiable-content-protection-method" class="sectionRef"></a></td>
+ </tr>
+ <tr>
+ <td>Common parameters used to control content-protection method</td>
+ <td><a href="#common-parameters" class="sectionRef"></a></td>
+ </tr>
+ <tr>
+ <td>Common errors reported for different content-protection methods</td>
+ <td><a href="#common-errors" class="sectionRef"></a></td>
+ </tr>
+ <tr>
+ <td>Support for playback of content-protected adaptive bit-rate media</td>
+ <td><a href="#adaptive-bit-rate-media" class="sectionRef"></a></td>
+ </tr>
+ </table></dd>
+ </dl>
+ </section>
+
+ </section>
+
+ <section>
+ <h2>Security</h2>
+
+ <p>Paragraph...</p>
+ </section>
+
+ <section>
+ <h2>Next Steps</h2>
+
+ <p>Paragraph...</p>
+ </section>
+
+ <section>
+ <h2>Proposals</h2>
+
+ <section>
+ <h3><a href=http://www.w3.org/2011/webtv/wiki/MPTF/HTML_adaptive_calls>Adaptive Bitrate calls for HTML5 <video> tag (WIP) (Duncan Rowden)</a></h3>
+
+ <p>Description...</p>
+ </section>
+
+ <section>
+ <h3><a href=http://html5-mediasource-api.googlecode.com/svn/trunk/draft-spec/mediasource-draft-spec.html>Mediasource specification (WIP) (Aaron Colwell, Adrian Bateman, Mark Watson)</a></h3>
+
+ <p>Description...</p>
+ </section>
+ </section>
+
+ <section>
+ <h2>Related Works</h2>
+
+ <p>Paragraph...</p>
+ </section>
+
+ <section class='appendix'>
+ <h2>Acknowledgements</h2>
+ <p>
+ Many thanks to ...
+ </p>
+ </section>
+ </body>
+ </html>