[EME] Moved Key Release section after the Algorithms section.
authorDavid Dorwin <ddorwin@google.com>
Mon, 06 May 2013 17:04:40 -0700
changeset 116 41f749af979d
parent 115 d23844083fd0
child 117 60cca843f269
[EME] Moved Key Release section after the Algorithms section.
encrypted-media/encrypted-media.html
encrypted-media/encrypted-media.xml
--- a/encrypted-media/encrypted-media.html	Mon May 06 16:54:20 2013 -0700
+++ b/encrypted-media/encrypted-media.html	Mon May 06 17:04:40 2013 -0700
@@ -144,13 +144,13 @@
           <li><a href="#event-definitions">3.1 Event Definitions</a></li>
           <li><a href="#event-summary">3.2 Event Summary</a></li>
         </ul></li>
-      <li><a href="#key-release">4. Key Release</a></li>
-      <li><a href="#algorithms">5. Algorithms</a></li>
+      <li><a href="#algorithms">4. Algorithms</a></li>
         <li><ul style="list-style-type:none">
-          <li><a href="#algorithms-encrypted-stream">5.1. First Time a Key Reference is Encountered</a></li>
-          <li><a href="#algorithms-enrypted-block">5.2. Encrypted Block Encountered</a></li>
-          <li><a href="#algorithms-load">5.3. Addition to Media Element Load Algorithm</a></li>
+          <li><a href="#algorithms-encrypted-stream">4.1. First Time a Key Reference is Encountered</a></li>
+          <li><a href="#algorithms-enrypted-block">4.2. Encrypted Block Encountered</a></li>
+          <li><a href="#algorithms-load">4.3. Addition to Media Element Load Algorithm</a></li>
         </ul></li>
+      <li><a href="#key-release">5. Key Release</a></li>
       <li><a href="#simple-decryption">6. Simple Decryption</a></li>
         <li><ul style="list-style-type:none">
           <li><a href="#simple-decryption-clear-key">6.1. Clear Key</a></li>
@@ -751,30 +751,10 @@
       </tbody>
     </table>
 
-    <h2 id="key-release">4. Key Release</h2>
-    <p class="non-normative">Note: it is an open issue whether further normative specification of this feature is required. See <a href="https://www.w3.org/Bugs/Public/show_bug.cgi?id=17199">Bug 17199</a>.</p>
-    <h3 id="key-release-intro">4.1. Introduction</h3>
-    <p><i>This section is non-normative.</i></p>
-    <p>The above sections provide for delivery of key/license information to a <a href="#cdm">Content Decryption Module</a>.
-    This section provides for management of the entire key/license lifecycle, that is, secure proof of key release.
-    Use cases for such proof include any service where is it necessary for the service to know, reliably, which granted keys/licences are still available for use by the user and which have been deleted.
-    Examples include a service with restrictions on the number of concurrent streams available to a user or a service where content is available on a rental basis, for use offline.
-    </p>
-    
-    <p>Secure proof of key release must necessarily involve the CDM due to the relative ease with which scripts may be modified.
-    The CDM must provide a message asserting, in a CDM-specific form, that a specific key or license has been destroyed.
-    Such messages must be cached in the CDM until acknowledgement of their delivery to the service has been received.
-    This acknowledgement must also be in the form of a CDM-specific message.
-    </p>
-    
-    <p>The mechanism for secure proof of key release operates outside the scope of any <a href="#media-element">media element</a>.
-    This is because proof-of-release messages may be cached in CDMs after the associated media elements have been destroyed.
-    Proof-of-key-release messages are subject to the same origin policy: they shall only be delivered to scripts with the same origin as the script which created the media element that provided the key/license.
-    </p>
 
-    <h2 id="algorithms">5. Algorithms</h2>
+    <h2 id="algorithms">4. Algorithms</h2>
 
-    <h3 id="algorithms-encrypted-stream">5.1. First Time a Key Reference is Encountered</h3>
+    <h3 id="algorithms-encrypted-stream">4.1. First Time a Key Reference is Encountered</h3>
     <p>The following steps are run when the <a href="#media-element">media element</a> encounters a source that may contain encrypted blocks or streams during the <a href="http://www.w3.org/TR/html5/embedded-content-0.html#concept-media-load-resource">resource fetch algorithm</a>:</p>
 
     <ol>
@@ -837,7 +817,7 @@
       <li><p><i>Continue Normal Flow</i>: Continue with the existing media element's <a href="http://www.w3.org/TR/html5/embedded-content-0.html#concept-media-load-resource">resource fetch algorithm</a>.</p></li>
     </ol>
 
-    <h3 id="algorithms-enrypted-block">5.2. Encrypted Block Encountered</h3>
+    <h3 id="algorithms-enrypted-block">4.2. Encrypted Block Encountered</h3>
     <p>The following steps are run when the <a href="#media-element">media element</a> encounters a block <span class="non-normative">(i.e. frame)</span> of encrypted <a href="http://www.w3.org/TR/html5/embedded-content-0.html#media-data">media data</a> during the <a href="http://www.w3.org/TR/html5/embedded-content-0.html#concept-media-load-resource">resource fetch algorithm</a>:</p>
 
     <ol>
@@ -913,7 +893,7 @@
     <li class="non-normative">The media element leaves this state when seeking but could re-enter it if the same conditions exist.</li>
     </ul>
 
-    <h3 id="algorithms-load">5.3. Addition to Media Element Load Algorithm</h3>
+    <h3 id="algorithms-load">4.3. Addition to Media Element Load Algorithm</h3>
     <p>The following step is added to the existing <a href="http://www.w3.org/TR/html5/embedded-content-0.html#media-element-load-algorithm">media element load algorithm</a>:</p>
     <ul>
       <li>
@@ -923,6 +903,28 @@
     </ul>
 
 
+    <h2 id="key-release">5. Key Release</h2>
+    <p class="non-normative">Note: it is an open issue whether further normative specification of this feature is required. See <a href="https://www.w3.org/Bugs/Public/show_bug.cgi?id=17199">Bug 17199</a>.</p>
+    <h3 id="key-release-intro">5.1. Introduction</h3>
+    <p><i>This section is non-normative.</i></p>
+    <p>The above sections provide for delivery of key/license information to a <a href="#cdm">Content Decryption Module</a>.
+    This section provides for management of the entire key/license lifecycle, that is, secure proof of key release.
+    Use cases for such proof include any service where is it necessary for the service to know, reliably, which granted keys/licences are still available for use by the user and which have been deleted.
+    Examples include a service with restrictions on the number of concurrent streams available to a user or a service where content is available on a rental basis, for use offline.
+    </p>
+    
+    <p>Secure proof of key release must necessarily involve the CDM due to the relative ease with which scripts may be modified.
+    The CDM must provide a message asserting, in a CDM-specific form, that a specific key or license has been destroyed.
+    Such messages must be cached in the CDM until acknowledgement of their delivery to the service has been received.
+    This acknowledgement must also be in the form of a CDM-specific message.
+    </p>
+    
+    <p>The mechanism for secure proof of key release operates outside the scope of any <a href="#media-element">media element</a>.
+    This is because proof-of-release messages may be cached in CDMs after the associated media elements have been destroyed.
+    Proof-of-key-release messages are subject to the same origin policy: they shall only be delivered to scripts with the same origin as the script which created the media element that provided the key/license.
+    </p>
+
+
     <h2 id="simple-decryption">6. Simple Decryption</h2>
     <p>All user agents must support the simple decryption capabilities described in this section regardless of whether they support a more advanced <a href="#cdm">CDM</a>.
     <span class="non-normative">This ensures that there is a common baseline level of protection that is guaranteed to be supported in all user agents, including those that are entirely open source.
--- a/encrypted-media/encrypted-media.xml	Mon May 06 16:54:20 2013 -0700
+++ b/encrypted-media/encrypted-media.xml	Mon May 06 17:04:40 2013 -0700
@@ -141,13 +141,13 @@
           <li><a href="#event-definitions">3.1 Event Definitions</a></li>
           <li><a href="#event-summary">3.2 Event Summary</a></li>
         </ul></li>
-      <li><a href="#key-release">4. Key Release</a></li>
-      <li><a href="#algorithms">5. Algorithms</a></li>
+      <li><a href="#algorithms">4. Algorithms</a></li>
         <li><ul style="list-style-type:none">
-          <li><a href="#algorithms-encrypted-stream">5.1. First Time a Key Reference is Encountered</a></li>
-          <li><a href="#algorithms-enrypted-block">5.2. Encrypted Block Encountered</a></li>
-          <li><a href="#algorithms-load">5.3. Addition to Media Element Load Algorithm</a></li>
+          <li><a href="#algorithms-encrypted-stream">4.1. First Time a Key Reference is Encountered</a></li>
+          <li><a href="#algorithms-enrypted-block">4.2. Encrypted Block Encountered</a></li>
+          <li><a href="#algorithms-load">4.3. Addition to Media Element Load Algorithm</a></li>
         </ul></li>
+      <li><a href="#key-release">5. Key Release</a></li>
       <li><a href="#simple-decryption">6. Simple Decryption</a></li>
         <li><ul style="list-style-type:none">
           <li><a href="#simple-decryption-clear-key">6.1. Clear Key</a></li>
@@ -706,30 +706,10 @@
       </tbody>
     </table>
 
-    <h2 id="key-release">4. Key Release</h2>
-    <p class="non-normative">Note: it is an open issue whether further normative specification of this feature is required. See <a href="https://www.w3.org/Bugs/Public/show_bug.cgi?id=17199">Bug 17199</a>.</p>
-    <h3 id="key-release-intro">4.1. Introduction</h3>
-    <non-normative-section/>
-    <p>The above sections provide for delivery of key/license information to a <a href="#cdm">Content Decryption Module</a>.
-    This section provides for management of the entire key/license lifecycle, that is, secure proof of key release.
-    Use cases for such proof include any service where is it necessary for the service to know, reliably, which granted keys/licences are still available for use by the user and which have been deleted.
-    Examples include a service with restrictions on the number of concurrent streams available to a user or a service where content is available on a rental basis, for use offline.
-    </p>
-    
-    <p>Secure proof of key release must necessarily involve the CDM due to the relative ease with which scripts may be modified.
-    The CDM must provide a message asserting, in a CDM-specific form, that a specific key or license has been destroyed.
-    Such messages must be cached in the CDM until acknowledgement of their delivery to the service has been received.
-    This acknowledgement must also be in the form of a CDM-specific message.
-    </p>
-    
-    <p>The mechanism for secure proof of key release operates outside the scope of any <a href="#media-element">media element</a>.
-    This is because proof-of-release messages may be cached in CDMs after the associated media elements have been destroyed.
-    Proof-of-key-release messages are subject to the same origin policy: they shall only be delivered to scripts with the same origin as the script which created the media element that provided the key/license.
-    </p>
 
-    <h2 id="algorithms">5. Algorithms</h2>
+    <h2 id="algorithms">4. Algorithms</h2>
 
-    <h3 id="algorithms-encrypted-stream">5.1. First Time a Key Reference is Encountered</h3>
+    <h3 id="algorithms-encrypted-stream">4.1. First Time a Key Reference is Encountered</h3>
     <p>The following steps are run when the <a href="#media-element">media element</a> encounters a source that may contain encrypted blocks or streams during the <resource-fetch-algorithm/>:</p>
 
     <ol>
@@ -787,7 +767,7 @@
       <li><p><i>Continue Normal Flow</i>: Continue with the existing media element's <resource-fetch-algorithm/>.</p></li>
     </ol>
 
-    <h3 id="algorithms-enrypted-block">5.2. Encrypted Block Encountered</h3>
+    <h3 id="algorithms-enrypted-block">4.2. Encrypted Block Encountered</h3>
     <p>The following steps are run when the <a href="#media-element">media element</a> encounters a block <span class="non-normative">(i.e. frame)</span> of encrypted <videoanchor name="media-data">media data</videoanchor> during the <resource-fetch-algorithm/>:</p>
 
     <ol>
@@ -858,7 +838,7 @@
     <li class="non-normative">The media element leaves this state when seeking but could re-enter it if the same conditions exist.</li>
     </ul>
 
-    <h3 id="algorithms-load">5.3. Addition to Media Element Load Algorithm</h3>
+    <h3 id="algorithms-load">4.3. Addition to Media Element Load Algorithm</h3>
     <p>The following step is added to the existing <media-element-load-algorithm/>:</p>
     <ul>
       <li><p>Clear the <coderef>keys</coderef> attribute for this <a href="#media-element">media element</a>.</p>
@@ -867,6 +847,28 @@
     </ul>
 
 
+    <h2 id="key-release">5. Key Release</h2>
+    <p class="non-normative">Note: it is an open issue whether further normative specification of this feature is required. See <a href="https://www.w3.org/Bugs/Public/show_bug.cgi?id=17199">Bug 17199</a>.</p>
+    <h3 id="key-release-intro">5.1. Introduction</h3>
+    <non-normative-section/>
+    <p>The above sections provide for delivery of key/license information to a <a href="#cdm">Content Decryption Module</a>.
+    This section provides for management of the entire key/license lifecycle, that is, secure proof of key release.
+    Use cases for such proof include any service where is it necessary for the service to know, reliably, which granted keys/licences are still available for use by the user and which have been deleted.
+    Examples include a service with restrictions on the number of concurrent streams available to a user or a service where content is available on a rental basis, for use offline.
+    </p>
+    
+    <p>Secure proof of key release must necessarily involve the CDM due to the relative ease with which scripts may be modified.
+    The CDM must provide a message asserting, in a CDM-specific form, that a specific key or license has been destroyed.
+    Such messages must be cached in the CDM until acknowledgement of their delivery to the service has been received.
+    This acknowledgement must also be in the form of a CDM-specific message.
+    </p>
+    
+    <p>The mechanism for secure proof of key release operates outside the scope of any <a href="#media-element">media element</a>.
+    This is because proof-of-release messages may be cached in CDMs after the associated media elements have been destroyed.
+    Proof-of-key-release messages are subject to the same origin policy: they shall only be delivered to scripts with the same origin as the script which created the media element that provided the key/license.
+    </p>
+
+
     <h2 id="simple-decryption">6. Simple Decryption</h2>
     <p>All user agents must support the simple decryption capabilities described in this section regardless of whether they support a more advanced <a href="#cdm">CDM</a>.
     <span class="non-normative">This ensures that there is a common baseline level of protection that is guaranteed to be supported in all user agents, including those that are entirely open source.