--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/mpreq/adbreq.html Thu Aug 09 14:56:13 2012 -0600
@@ -0,0 +1,810 @@
+<!DOCTYPE html>
+<html>
+ <head>
+ <title>MPTF Requirements for Adaptive Bit Rate Streaming</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' type="text/javascript"></script>
+ <script class='remove' type="text/javascript">
+ var respecConfig = {
+ // specification status (e.g. WD, LCWD, NOTE, etc.). If in doubt use ED.
+ specStatus: "NOTE",
+
+ // the specification's short name, as in http://www.w3.org/TR/short-name/
+ shortName: "mptf-adb-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
+ to provide commercial quality IP streaming video across different
+ platforms and between unrelated companies.</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>Adaptive Bit Rate</dfn>
+ </dt>
+ <dd>Adaptive bit rate media is characterized by short
+ independent parallel media stream segments that can be individually
+ selected and rendered according to some selective criteria.
+ Typically, the parallel segments are differentiated by a feature
+ such as required bandwidth, image resolution, etc.</dd>
+
+ <dt>
+ <dfn>Common Time Base</dfn>
+ </dt>
+ <dd>A common time base is a time reference that can be
+ unambiguously interpreted for synchronization purposes.</dd>
+
+ <dt>
+ <dfn>Trick Play</dfn>
+ </dt>
+ <dd>Trick play refers to common media playback controls such as
+ play, stop, pause, rewind and fast forward.</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>Standards Compatibility</h4>
+ <h5>Compatibility with widely deployed standards</h5>
+ <p>One of the primary purposes for standardizing the way the
+ media elements use adaptive bitrate streaming is to enable
+ different existing and future adaptive bitrate streming methods to
+ work consistently with HTML5 media tags. Therefore, media tags must
+ work with the widely deployed adaptive bitrate methods that are
+ available now.</p>
+ </section>
+
+ <section>
+ <h4>Media Tags</h4>
+ <h5>The <video> and <audio> tags should be used to
+ specify video and audio in HTML.</h5>
+ <p>In the past, the <obj> tag has been used to add
+ non-standard functionality to HTML pages. In order to provide more
+ consistent functionality, the <video> and <audio>
+ elements were added to HTML. This allows for consistent handling of
+ streaming media between different browsers and encoded with
+ different codecs. In order to maintain this consistency, any ABR solution must define how the video and audio elements can be used for playback of adaptive delivery format media.</p>
+ </section>
+
+ <section>
+ <h4>Common Time Reference</h4>
+ <h5>A common time reference must be unambiguously defined for
+ combining tracks with different time references and for
+ "continuous" tracks. Overlapping track segments must also be
+ handled. (DASH may provide a reasonable model.)</h5>
+ <p>Frequently, it is necessary to synchronize serveral different
+ steaming content sources. For example, audio tracks must be
+ synchronized with streaming video or the experience of watching the
+ video becomes unpleasant. Synchronization is also important for
+ advertising, closed caption and other streaming media features.
+ Since different streaming media sources have different time
+ references, a strategy for synchronizing these different references
+ must be adopted.</p>
+ </section>
+
+ <section>
+ <h4>Splicing</h4>
+ <h5>It should be possible to seamlessly splice content with a
+ discontinuous timeline (such as advertising) into the presentation.</h5>
+ <p>In addition to a common time reference, mapping to that
+ common time reference must be seamless enough to enable continuous
+ playback from sources spliced relative to different time bases.</p>
+ </section>
+
+ <section>
+ <h4>Trick Play</h4>
+ <h5>Search and trick-play must be unambiguously defined in the
+ context of this common time reference (e.g. anchor point and
+ offset).</h5>
+ <p>A common time reference is also important in the context of
+ trick play. Pausing, advancing or rewinding media content must be
+ done accurately and within a common reference. This is necessary in
+ order to advance or rewind to exact locations or the adjust the
+ playback lockation by precise increments.</p>
+ </section>
+
+ <section>
+ <h4>Playability</h4>
+ <h5>The ability of the user agent to play a piece of content
+ must be determined quickly and with reasonable accuracy (e.g. using
+ CanPlayType(codec, level, profile) or other means)</h5>
+ <p>With media content available from sources around the world,
+ it is important to quickly determine whether various content
+ sources can be rendered. Therefore this determinitaion must be
+ madew with a minimum of overhead.</p>
+ </section>
+
+ <section>
+ <h4>No ABR Method Preference</h4>
+ <h5>The standard interface to support adaptive bit rate streaming must not advantage one specific ABR method
+ over another.</h5>
+ <p>HTML aspires to be a level playing field. This philosophy
+ enables innovation to flourish and allows superior solutions to
+ become quickly implemnted and adopted. ABR media systems are and
+ should continue to be innovative solutions within this spirit of
+ openness. Support for different ABR systems should not require any
+ proprietary modification of the user agent</p>
+ </section>
+
+ <section>
+ <h4>Open Source Browsers</h4>
+ <h5>The standard interface to support adaptive bit rate streaming must work with "open source" browsers.</h5>
+ <p>The ability for a browser vendor to implement playback of ABR
+ media in accordance with the requirements in this document must be
+ supported.</p>
+ </section>
+
+ <section>
+ <h4>Common Parameters</h4>
+ <h5>Any parameters required for use of the ABR system must be
+ identified and specifiable.</h5>
+ <p>While specific implementations may include vendor-specific
+ parameters for special features, the parameters required for basic
+ playback should be publicly specified.</p>
+ </section>
+
+ <section>
+ <h4>Common Errors</h4>
+ <h5>Specific errors relevant to ABR media must be identified
+ and reportable.</h5>
+ <p>While specific implementations may include vendor-specific
+ error codes, the error codes required for basic operation and
+ diagnosis should be publicly specified. However, the particular ABR
+ systems to be supported is an implementation decision.</p>
+ </section>
+
+ <section>
+ <h4>(Others)</h4>
+ </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>
+ </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>
+
+ <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. Play Adaptive Bit Rate Content</h3>
+
+ <dl>
+ <dt>Description</dt>
+ <dd>
+ <p>A user can play adaptive bit rate content identified in
+ media tags regardless of the particular adaptive bit rate method
+ used to format the content. Support for the playable content
+ formats must be provided by the browser or extensible features of
+ the browser.</p>
+
+ <p>Possible implementation:</p>
+ <ul>
+ <li>The user selects a content item for playback.</li>
+ <li>The content plays.</li>
+ </ul>
+ </dd>
+
+ <dt>Motivation</dt>
+ <dd>
+ <p>There is no standard interface for adaptive bit rate content
+ content. This leads to the implementation of multiple incompatible
+ playback systems and interfaces. What should be standardized is:</p>
+ <ul>
+ <li>an interface to specify the playback of adaptive bit rate
+ content.</li>
+ </ul>
+ </dd>
+
+ <dt>Dependencies</dt>
+ <dd>
+ <p>In order to play adaptive bit rate content, the application
+ interface must be provided.</p>
+ </dd>
+
+ <dt>Requirements</dt>
+ <dd>
+ <table>
+ <tr>
+ <th>Low Level</th>
+ <th>High Level</th>
+ </tr>
+ <tr>
+ <td>Compatibility with existing standards</td>
+ <td><a href="#standards-compatibility" class="sectionRef"></a></td>
+ </tr>
+ <tr>
+ <td>Support for media tags</td>
+ <td><a href="#media-tags" class="sectionRef"></a></td>
+ </tr>
+ <tr>
+ <td>Support for a common time reference</td>
+ <td><a href="#common-time-reference" class="sectionRef"></a></td>
+ </tr>
+ <tr>
+ <td>Support for particular ABR media type</td>
+ <td><a href="#playability" class="sectionRef"></a></td>
+ </tr>
+ <tr>
+ <td>Specify the ABR parameters</td>
+ <td><a href="#common-parameters" class="sectionRef"></a></td>
+ </tr>
+ </table>
+ </dd>
+ </dl>
+ </section>
+
+ <section>
+ <h3>U2. Trick Mode with Adaptive Bit Rate Content</h3>
+
+ <dl>
+ <dt>Description</dt>
+ <dd>
+ <p>A user can use trick-play modes (pause, rewind,
+ fast-forward) with adaptive bit rate content regardless of the
+ particular adaptive bit rate method used to format the content.</p>
+
+ <p>Possible implementation:</p>
+ <ul>
+ <li>The user selects a content item for playback.</li>
+ <li>The user clicks a trick-play button (pause, rewind,
+ fast-forward) in the user interface.</li>
+ <li>The playback of the content is changed according to the
+ trick-play feature selected.</li>
+ </ul>
+ </dd>
+
+ <dt>Motivation</dt>
+ <dd>
+ <p>Playback of media should be consistent regardless of the
+ particular format of the content. Trick-play modes available to
+ non-adaptive media formats should also be available to adaptive
+ bit rate media. What should be standardized is:</p>
+ <ul>
+ <li>trick-play modes should work consistently across all
+ streaming media formats.</li>
+ </ul>
+ </dd>
+
+ <dt>Dependencies</dt>
+ <dd>
+ <p>None.</p>
+ </dd>
+
+ <dt>Requirements</dt>
+ <dd>
+ <table>
+ <tr>
+ <th>Low Level</th>
+ <th>High Level</th>
+ </tr>
+ <tr>
+ <td>Compatibility with existing standards</td>
+ <td><a href="#standards-compatibility" class="sectionRef"></a></td>
+ </tr>
+ <tr>
+ <td>Support for media tags</td>
+ <td><a href="#media-tags" class="sectionRef"></a></td>
+ </tr>
+ <tr>
+ <td>Support for a common time reference</td>
+ <td><a href="#common-time-reference" class="sectionRef"></a></td>
+ </tr>
+ <tr>
+ <td>Support for trick-play modes</td>
+ <td><a href="#trick-play" class="sectionRef"></a></td>
+ </tr>
+ <tr>
+ <td>Specify the ABR parameters</td>
+ <td><a href="#common-parameters" class="sectionRef"></a></td>
+ </tr>
+ </table>
+ </dd>
+ </dl>
+ </section>
+
+ <section>
+ <h3>U3. Search Adaptive Bit Rate Content</h3>
+
+ <dl>
+ <dt>Description</dt>
+ <dd>
+ <p>A user can search adaptive bit rate content identified in
+ media tags to position playback at a specific point in time
+ regardless of the particular adaptive bit rate method used to
+ format the content.</p>
+
+ <p>Possible implementation:</p>
+ <ul>
+ <li>The user selects a content item for playback.</li>
+ <li>The user selects a particular point in time in the
+ playback of the video (e.g. 30 seconds ahead, 75% through the
+ video, etc.).</li>
+ <li>The playback pointer is positioned at the specified
+ location in time.</li>
+ <li>The content plays beginning at the new position.</li>
+ </ul>
+ </dd>
+
+ <dt>Motivation</dt>
+ <dd>
+ <p>Playback of media should be consistent regardless of the
+ particular format of the content. Search modes available to
+ non-adaptive media formats should also be available to adaptive
+ bit rate media. What should be standardized is:</p>
+ <ul>
+ <li>an interface to specify searching of adaptive bit rate
+ content.</li>
+ </ul>
+ </dd>
+
+ <dt>Dependencies</dt>
+ <dd>
+ <p>None.</p>
+ </dd>
+
+ <dt>Requirements</dt>
+ <dd>
+ <table>
+ <tr>
+ <th>Low Level</th>
+ <th>High Level</th>
+ </tr>
+ <tr>
+ <td>Compatibility with existing standards</td>
+ <td><a href="#standards-compatibility" class="sectionRef"></a></td>
+ </tr>
+ <tr>
+ <td>Support for media tags</td>
+ <td><a href="#media-tags" class="sectionRef"></a></td>
+ </tr>
+ <tr>
+ <td>Support for a common time reference</td>
+ <td><a href="#common-time-reference" class="sectionRef"></a></td>
+ </tr>
+ <tr>
+ <td>Support for particular ABR media type</td>
+ <td><a href="#playability" class="sectionRef"></a></td>
+ </tr>
+ <tr>
+ <td>Specify the ABR parameters</td>
+ <td><a href="#common-parameters" class="sectionRef"></a></td>
+ </tr>
+ </table>
+ </dd>
+ </dl>
+ </section>
+
+ <section>
+ <h3>U4. Merge, Splice and Append Adaptive Bit Rate Content</h3>
+
+ <dl>
+ <dt>Description</dt>
+ <dd>
+ <p>A user merge, splice and append adaptive bit rate content
+ identified in media tags regardless of the particular adaptive bit
+ rate method used to format the content.</p>
+
+ <p>Possible implementation:</p>
+ <ul>
+ <li>The user selects two content items and identifies a
+ location in time where they are to be merged (both items continue
+ playing at the merge point), spliced (one item stops playing and
+ the other item continues) or appended (one item plays to its end,
+ then the other item plays from its beginning).</li>
+ <li>The content plays as specified.</li>
+ </ul>
+ </dd>
+
+ <dt>Motivation</dt>
+ <dd>
+ <p>There is no standard interface for merging, splicing
+ content. Content can typically be appended by queueing up the next
+ segment, but there is no guarantee that the common time reference
+ will be preserved. What should be standardized is:</p>
+ <ul>
+ <li>an interface to specify the means to merge, splice and
+ append adaptive bit rate content;</li>
+ <li>a specification on how to preserve a common time base
+ when merging, splicing or appending adaptive bit rate content.</li>
+ </ul>
+ </dd>
+
+ <dt>Dependencies</dt>
+ <dd>
+ <p>None.</p>
+ </dd>
+
+ <dt>Requirements</dt>
+ <dd>
+ <table>
+ <tr>
+ <th>Low Level</th>
+ <th>High Level</th>
+ </tr>
+ <tr>
+ <td>Compatibility with existing standards</td>
+ <td><a href="#standards-compatibility" class="sectionRef"></a></td>
+ </tr>
+ <tr>
+ <td>Support for media tags</td>
+ <td><a href="#media-tags" class="sectionRef"></a></td>
+ </tr>
+ <tr>
+ <td>Support for a common time reference</td>
+ <td><a href="#common-time-reference" class="sectionRef"></a></td>
+ </tr>
+ <tr>
+ <td>Support for particular ABR media type</td>
+ <td><a href="#playability" class="sectionRef"></a></td>
+ </tr>
+ <tr>
+ <td>Specify the ABR parameters</td>
+ <td><a href="#common-parameters" class="sectionRef"></a></td>
+ </tr>
+ </table>
+ </dd>
+ </dl>
+ </section>
+
+ <section>
+ <h3>U5. Continuous Adaptive Bit Rate Content</h3>
+
+ <dl>
+ <dt>Description</dt>
+ <dd>
+ <p>A user can play a continuous stream of adaptive bit rate
+ content identified in media tags regardless of the particular
+ adaptive bit rate method used to format the content. Continuous
+ content could be a stream that is continuously encoded from a live
+ source (e.g. it has no specific finite length) or a play list that
+ is continually getting content appended and has a common time
+ base.</p>
+
+ <p>Possible implementation:</p>
+ <ul>
+ <li>The user selects a "channel" for playback.</li>
+ <li>The channel plays continuously until the user selects a
+ different source.</li>
+ </ul>
+ </dd>
+
+ <dt>Motivation</dt>
+ <dd>
+ <p>There is no standard interface for continuous playback
+ adaptive bit rate content. What should be standardized is:</p>
+ <ul>
+ <li>an interface to specify the playback of continuous
+ adaptive bit rate content;</li>
+ <li>a specification for maintaining a common time base for
+ continuous content.</li>
+ </ul>
+ </dd>
+
+ <dt>Dependencies</dt>
+ <dd>
+ <p>None.</p>
+ </dd>
+
+ <dt>Requirements</dt>
+ <dd>
+ <table>
+ <tr>
+ <th>Low Level</th>
+ <th>High Level</th>
+ </tr>
+ <tr>
+ <td>Compatibility with existing standards</td>
+ <td><a href="#standards-compatibility" class="sectionRef"></a></td>
+ </tr>
+ <tr>
+ <td>Support for media tags</td>
+ <td><a href="#media-tags" class="sectionRef"></a></td>
+ </tr>
+ <tr>
+ <td>Support for a common time reference</td>
+ <td><a href="#common-time-reference" class="sectionRef"></a></td>
+ </tr>
+ <tr>
+ <td>Support for particular ABR media type</td>
+ <td><a href="#playability" class="sectionRef"></a></td>
+ </tr>
+ <tr>
+ <td>Specify the ABR parameters</td>
+ <td><a href="#common-parameters" class="sectionRef"></a></td>
+ </tr>
+ </table>
+ </dd>
+ </dl>
+ </section>
+
+ <section>
+ <h3>U6. Timed Tracks and Adaptive Bit Rate Content</h3>
+
+ <dl>
+ <dt>Description</dt>
+ <dd>
+ <p>A user can add timed tracks adaptive bit rate content at
+ specific points in time regardless of the particular adaptive bit
+ rate method used to format the content.</p>
+
+ <p>Possible implementation:</p>
+ <ul>
+ <li>The user selects a content item, timed text track to be
+ merged and a specific location in time.</li>
+ <li>The content item and timed text track are merged as
+ specified.</li>
+ <li>The merged content plays.</li>
+ </ul>
+ </dd>
+
+ <dt>Motivation</dt>
+ <dd>
+ <p>There is no standard interface for merging timed text tracks
+ with adaptive bit rate content. What should be standardized is:</p>
+ <ul>
+ <li>an interface to specify the merging of timed text tracks
+ with adaptive bit rate content.</li>
+ </ul>
+ </dd>
+
+ <dt>Dependencies</dt>
+ <dd>
+ <p>None.</p>
+ </dd>
+
+ <dt>Requirements</dt>
+ <dd>
+ <table>
+ <tr>
+ <th>Low Level</th>
+ <th>High Level</th>
+ </tr>
+ <tr>
+ <td>Compatibility with existing standards</td>
+ <td><a href="#standards-compatibility" class="sectionRef"></a></td>
+ </tr>
+ <tr>
+ <td>Support for media tags</td>
+ <td><a href="#media-tags" class="sectionRef"></a></td>
+ </tr>
+ <tr>
+ <td>Support for a common time reference</td>
+ <td><a href="#common-time-reference" class="sectionRef"></a></td>
+ </tr>
+ <tr>
+ <td>Support for particular ABR media type</td>
+ <td><a href="#playability" class="sectionRef"></a></td>
+ </tr>
+ <tr>
+ <td>Specify the ABR parameters</td>
+ <td><a href="#common-parameters" class="sectionRef"></a></td>
+ </tr>
+ </table>
+ </dd>
+ </dl>
+ </section>
+
+ </section>
+ <h3>Other Issues or Use Cases</h3>
+ <h2>Byte Range, Events, Events at start of request</h2>
+ <h2>(Others?)</h2>
+ <section></section>
+
+
+ <section>
+ <h2>Security</h2>
+
+ <p>In the context of adaptive bit rate media, security is
+ primarily concerned with ensuring that authorized users are able to
+ play the media and unauthorized users are not. This may involve
+ verifying that the content has been legally obtained. It may also
+ mean that personally produced video is only viewable by friends and
+ family. If viewing is intended to be restricted, a content protection
+ system must be in place. Adaptive bit rate video should be treated
+ the same as any video element in this regard. A content protection
+ system for media elements has been proposed to the W3C HTML WG and is
+ being reviewed. (Put reference here)</p>
+ </section>
+
+ <section>
+ <h2>Next Steps</h2>
+
+ <ul>
+ <li>Make any necessary changes or refinements in this document</li>
+ <li>Submit this document to the appropriate W3C WC (likely HTML)
+ for development of specification.</li>
+ </ul>
+ </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>This proposal refers to work done in WHATWG regarding three
+ implementation methods and their associated APIs.</p>
+ </section>
+
+ <section>
+ <h3>
+ <a
+ href="http://dvcs.w3.org/hg/html-media/raw-file/tip/media-source/media-source.html">Mediasource
+ specification (Aaron Colwell, Kilroy Hughes, Mark Watson)</a>
+ </h3>
+
+ <p>This proposal was jointly developed by Microsoft, Google and
+ Netflix. It is comprehensive and is intended to meet the
+ requirements described in this document.</p>
+ </section>
+ </section>
+
+ <section class='appendix'>
+ <h2>Acknowledgements</h2>
+ <p>Many thanks to the members of the Media Pipeline Task Force of
+ the W3C Web & TV Interest Group who collaborated to create this
+ requirements document and reviewed the proposals to be submitted to
+ the HTML WG for inclusion in the HTML specification.</p>
+ </section>
+ </body>
+ </html>
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/mpreq/cpreq.html Thu Aug 09 14:56:13 2012 -0600
@@ -0,0 +1,689 @@
+<!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' type="text/javascript"></script>
+ <script class='remove' type="text/javascript">
+ var respecConfig = {
+ // specification status (e.g. WD, LCWD, NOTE, etc.). If in doubt use ED.
+ specStatus: "NOTE",
+
+ // 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>Adaptive Bit Rate</dfn>
+ </dt>
+ <dd>Adaptive bit rate media is characterized by short
+ independent parallel media stream segments that can be individually
+ selected and rendered according to some selective criteria.
+ Typically, the parallel segments are differentiated by a feature
+ such as required bandwidth, image resolution, etc.</dd>
+ <dt>
+ <dfn>Content Decryption Module (CDM)</dfn>
+ </dt>
+ <dd>The Content Decryption Module (CDM) is a generic term for a
+ part of or add-on to the user agent that provides functionality for
+ one or more Key Systems. Implementations may or may not separate the
+ implementations of CDMs and may or may not treat them as separate
+ from the user agent. This is transparent to the API and application.
+ A user agent may support one or more CDMs.</dd>
+ </dl>
+ </section>
+
+ <section>
+ <h2>MPTF Requirements for Content Protection</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
+ protected 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>Background</h3>
+ <ol>
+ <li>The Media Pipeline Task Force takes no position on the
+ specifics of the legal agreements (referred to hereinafter
+ collectively as "the agreement.") between users, content owners and
+ content distibution service providers. The objective of the MPTF
+ regarding content protection is to identify requirements for the
+ technical tools to enable the terms of those agreements.</li>
+ <li>The requirements below will not be perfect. There is no
+ system that can absolutely guarantee the intended behavior in all
+ cases. When perfection cannot be achieved, a reasonable solution
+ (as agreed upon by the MPTF) should be adopted.</li>
+ </ol>
+
+ <section>
+ <h3>General</h3>
+ <section>
+ <h4>User Rights</h4>
+ <h5>Content protection methods must enable the rights of the
+ user as specified in the agreement (See item 1 in Backgroud
+ section above).</h5>
+ <p>The user should not be restricted from accessing content for
+ which legal rights have been obtained.</p>
+ </section>
+
+ <section>
+ <h4>Owner Rights</h4>
+ <h5>Content protection methods must protect the rights of the
+ content owners as specified in the agreement.</h5>
+ <p>The content owners control the legal rights to the content.
+ If their rights are not protected, they are less likely to produce
+ the high-value content that drives the commercial video business.</p>
+ </section>
+
+ <section>
+ <h4>Distributor Rights</h4>
+ <h5>Content protection methods must protect the rights of the
+ distribution service provider as specified in the agreement.</h5>
+ <p>Content distributors also have certain rights and
+ obligations as specified in the agreement. Content must be
+ protected in transit so as not to be intercepted and used without
+ authorization.</p>
+ </section>
+
+ <section>
+ <h4>Container Format</h4>
+ <h5>The content protection solution (the standard interface to support content protection) must not advantage one
+ specific container format over another.</h5>
+ <p>Specifically, the choice of container format should not
+ prevent the content protection system from operating.</p>
+ </section>
+
+ <section>
+ <h4>Mandatory Baseline</h4>
+ <h5>The content protection solution (the standard interface to support content protection) must support at least one
+ mandatory method that can be used to enable interoperability
+ between different systems.</h5>
+ <p>Support for a baseline content protection solution allows at
+ least one method for protected content to be distributed and used.
+ This method should be unencumbered with IPR.</p>
+ </section>
+
+ <section>
+ <h4>Browser Independence</h4>
+ <h5>The content protection solution (the standard interface defined to support content protection) must work with "open source"
+ browsers</h5>
+ <p>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>
+ <h5>Content protection must be useable in HTML5</h5>
+ <p>The implementation of content protection must be capable of
+ running within an HTML5 environment. This means any browser
+ supportive of HTML5 will be able to specify the parameters and use
+ the appropriate tags to get the protected content to play back.</p>
+ </section>
+
+ <section>
+ <h4>Media Elements</h4>
+ <h5>(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).</h5>
+ <p>Timed text tracks and other features of HTML5 media tags
+ must work with protected media streams as described in this
+ requirements document. The use of any of these features must not
+ disable or prevent the use of a compliant implementation of
+ protected media.</p>
+ </section>
+
+ <section>
+ <h4>Encrypted Content</h4>
+ <h5>(consensus not yet reached) Media element features that
+ are available in an implementation must be available for encrypted
+ content as well as unencrypted content.</h5>
+ <p>This is the corrolary to the previous requirement. The use
+ of any compliant content protection system must not disable or
+ prevent the use of any particular media element features.</p>
+ </section>
+
+ <section>
+ <h4>Common Errors</h4>
+ <h5>Specific errors relevant to content protections must be
+ identified and reportable.</h5>
+ <p>The primary errors must be common across different
+ content protection systems so that the unique details of the
+ protection method are not required to be known in advance</p>
+ </section>
+
+ <section>
+ <h4>Adaptive Bit Rate Media</h4>
+ <h5>The content protection solution (the standard interface defined to support content protection) must be compatible with
+ adaptive bit rate media.</h5>
+ <p>The content protection solution must work with adaptive bit
+ rate streaming as well as traditional non-adaptive streaming
+ methods. This ensures that the content protection systems will
+ work with emerging streaming media types.</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>
+ </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>
+
+ <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 Access to Content</h3>
+
+ <dl>
+ <dt>Description</dt>
+ <dd>
+ <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
+ specification of features that enable the terms of an anticipated
+ contract. For users, this means specification of features that can
+ accurately determine a user's rights and the features to allow or deny user
+ access to content based on those rights.</p>
+ <p>For a content owner, this use case requires the specification
+ of features 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 specification of features 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 prevented.</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>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
+ 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>
+ <th>Low Level</th>
+ <th>High Level</th>
+ </tr>
+ <tr>
+ <td>Enable the rights of the user</td>
+ <td><a href="#user-rights" class="sectionRef"></a></td>
+ </tr>
+ <tr>
+ <td>Enable the rights of the content owner</td>
+ <td><a href="#owner-rights" class="sectionRef"></a></td>
+ </tr>
+ <tr>
+ <td>Enable the rights of the content distributor</td>
+ <td><a href="#distributor-rights" class="sectionRef"></a></td>
+ </tr>
+ </table>
+ </dd>
+ </dl>
+ </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 common
+ implementations. The system must be flexible enough to multiple
+ content protection systems simultaneously. For example, it must
+ be capble of playing back programming in one supported protection
+ system, then switching to another supported protection system on
+ a subsequent piece of programming.</p>
+
+ <p>Possible implementation:</p>
+ <ul>
+ <li>Content that is encrypted is specified for playback.</li>
+ <li>The content protection method is applied and the
+ decrypted content is played.</li>
+ <li>A new encrypted media segment using a different copy
+ protection system is selected for playback</li>
+ <li>The new content protection method is applied and the
+ decrypted content is played</li>
+ </ul>
+ </dd>
+
+ <dt>Motivation</dt>
+ <dd>
+ <p>What should be standardized is:</p>
+ <ul>
+ <li>A common interface for specifying the container format
+ and protection system</li>
+ </ul>
+ </dd>
+
+ <dt>Dependencies</dt>
+ <dd>
+ <p>The implementation is dependent upon the the commonality
+ between different container formats and a defining a common way
+ to specify them.</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>This use case describes a baseline CDM (e.g. ClearKey) that
+ can be implemented by a user agent in any browser. A baseline CDM
+ ensures that there is a way for content to be encoded that allows
+ for interoperability between implementations. If a content
+ provider encodes content compatible with the baseline CDM, it
+ should be playable on any client platform.</p>
+
+ <p>Possible implementation:</p>
+ <ul>
+ <li>A common CDM is defined that can be implemented in open
+ source code.</li>
+ <li>Content that is expected to run on all platforms must be
+ encoded using the common CDM.</li>
+ <li>When the content is selected for playback, the common
+ CDM is used to decrypt it prior to playback.</li>
+ </ul>
+ </dd>
+
+ <dt>Motivation</dt>
+ <dd>
+ <p>What should be standardized is:</p>
+ <ul>
+ <li>A common CDM that can be implemented in open source
+ code.</li>
+ </ul>
+ </dd>
+
+ <dt>Dependencies</dt>
+ <dd>
+ <p>The implementation of this use case is dependent upon the
+ premise of a system that is both secure and implementable with
+ open source code.</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>In this use case, the ability to get access to content is
+ dependent upon the use of compatible content formats and
+ legitimate credentials. These requirements must be
+ implementatable by any browser, including and open source
+ browser, and the implementation must report common errors.</p>
+
+ <p>Possible implementation:</p>
+ <ul>
+ <li>The user selects copy-protected content for playback.</li>
+ <li>The copy protection system requests credentials to
+ authorize the playback of the protected content.</li>
+ <li>The user provides credetials (or previously provided
+ credentials are retrieved) in a way that is common regardless of
+ the particular browser platform.</li>
+ <li>Once the credentials are verified, the copy protection
+ method is applied and the decrypted content is played back.</li>
+ </ul>
+ </dd>
+
+ <dt>Motivation</dt>
+ <dd>
+ <p>What should be standardized is:</p>
+ <ul>
+ <li>A common method for authorization assertion that is
+ independent of the particular browser.</li>
+ </ul>
+ </dd>
+
+ <dt>Dependencies</dt>
+ <dd>
+ <p>None.</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. The player must support playback of Encrypted Adaptive
+ Bit-rate Content</h3>
+
+ <dl>
+ <dt>Description</dt>
+ <dd>
+ <p>In this use case, a player renders encrypted adaptive
+ bit-rate content. The encryption method doesn't limit the ability
+ of the player to play the content. Specifically, the fragmented
+ nature of adaptive bit-rate content doesn't limit the use of the
+ encryption method.</p>
+
+ <p>Possible implementation:</p>
+ <ul>
+ <li>The user selects encrypted adaptive bit rate (ABR)
+ content for playback.</li>
+ <li>The content is decrypted and played back using the same
+ process as non-adaptive bit-rate content.</li>
+ </ul>
+ </dd>
+
+ <dt>Motivation</dt>
+ <dd>
+ <p>What should be standardized is:</p>
+ <ul>
+ <li>A content protection system that works for adaptive
+ bit-rate content as well as non-adaptive bit-rate content.</li>
+ </ul>
+ </dd>
+
+ <dt>Dependencies</dt>
+ <dd>
+ <p>None</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>
+ </table>
+ </dd>
+ </dl>
+ </section>
+
+ </section>
+
+ <section>
+ <h2>Next Steps</h2>
+
+ <ul>
+ <li>Make any necessary changes or refinements in this document</li>
+ <li>Submit this document to the appropriate W3C WC (likely
+ HTML) for development of specification.</li>
+ </ul>
+ </section>
+
+ <section>
+ <h2>Proposals</h2>
+
+ <section>
+ <h3>
+ <a
+ href="http://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html">Encrypted
+ Media Extensions(Draft Proposal) (David Dorwin, Adrian Bateman,
+ Mark Watson)</a>
+ </h3>
+
+ <p>This proposal was jointly developed by Microsoft, Google and
+ Netflix. It is comprehensive and is intended to meet the
+ requirements described in this document.</p>
+ </section>
+
+ <section class='appendix'>
+ <h2>Acknowledgements</h2>
+ <p>Many thanks to the members of the Media Pipeline Task Force
+ of the W3C Web & TV Interest Group who collaborated to create this
+ requirements document and reviewed the proposal to be submitted to
+ the HTML WG for inclusion in the HTML specification.</p>
+ </section>
+ </section>
+ </section>
+ </body>
+ </html>
--- a/mpreq/mpreq.xcodeproj/project.pbxproj Fri Jul 20 11:43:54 2012 -0600
+++ b/mpreq/mpreq.xcodeproj/project.pbxproj Thu Aug 09 14:56:13 2012 -0600
@@ -7,6 +7,8 @@
objects = {
/* Begin PBXFileReference section */
+ 840546B215D42777009FF288 /* adbreq.html */ = {isa = PBXFileReference; lastKnownFileType = text.html; path = adbreq.html; sourceTree = "<group>"; };
+ 840546B315D4278F009FF288 /* cpreq.html */ = {isa = PBXFileReference; lastKnownFileType = text.html; path = cpreq.html; sourceTree = "<group>"; };
843C45C615408B920060EAA9 /* intent.html */ = {isa = PBXFileReference; lastKnownFileType = text.html; path = intent.html; sourceTree = "<group>"; };
84B86CC1153F60DA001121D7 /* MPTF-ADB-Requirements.html */ = {isa = PBXFileReference; lastKnownFileType = text.html; path = "MPTF-ADB-Requirements.html"; sourceTree = "<group>"; };
84B86CC2153F60DA001121D7 /* MPTF-CP-Requirements.html */ = {isa = PBXFileReference; lastKnownFileType = text.html; path = "MPTF-CP-Requirements.html"; sourceTree = "<group>"; };
@@ -18,6 +20,8 @@
children = (
843C45C615408B920060EAA9 /* intent.html */,
84B86CC1153F60DA001121D7 /* MPTF-ADB-Requirements.html */,
+ 840546B215D42777009FF288 /* adbreq.html */,
+ 840546B315D4278F009FF288 /* cpreq.html */,
84B86CC2153F60DA001121D7 /* MPTF-CP-Requirements.html */,
);
sourceTree = "<group>";
Binary file mpreq/mpreq.xcodeproj/project.xcworkspace/xcuserdata/cstevens.xcuserdatad/UserInterfaceState.xcuserstate has changed