This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 19810 - Should key IDs be required in content and addKey()'s parameter?
Summary: Should key IDs be required in content and addKey()'s parameter?
Alias: None
Product: HTML WG
Classification: Unclassified
Component: Encrypted Media Extensions (show other bugs)
Version: unspecified
Hardware: All All
: P2 normal
Target Milestone: ---
Assignee: David Dorwin
QA Contact: HTML WG Bugzilla archive list
Depends on:
Reported: 2012-11-01 00:43 UTC by David Dorwin
Modified: 2013-04-30 01:53 UTC (History)
2 users (show)

See Also:


Description David Dorwin 2012-11-01 00:43:33 UTC
The draft currently supports content and |key| values (licenses) that do not use a key ID.

This adds complexity to the addKey() [1] and Encrypted Block Encountered [2] algorithma. If there are no use cases for this, we should eliminate this support and simplify the algorithms. The no key behavior is a little confusing anyway.

Note that the Potentially Encrypted Stream Encountered [3] algorithm would still need to deal with key IDs, assuming we want to avoid sending an event when we already know the key (issue 16553).

Comment 1 David Dorwin 2013-04-23 20:32:35 UTC
As agreed in the the February 5th telecon, we will eliminate the text that supports media data and update() calls without key IDs.
Comment 2 David Dorwin 2013-04-30 01:53:31 UTC
Removed support for content and |key| values (licenses) without key IDs in