This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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). [1] http://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html#dom-addkey [2] http://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html#algorithms-enrypted-block [3] http://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html#algorithms-encrypted-stream
As agreed in the the February 5th telecon, we will eliminate the text that supports media data and update() calls without key IDs.
Removed support for content and |key| values (licenses) without key IDs in https://dvcs.w3.org/hg/html-media/rev/dbfb9104f0ee