19810 2012-11-01 00:43:33 +0000 Should key IDs be required in content and addKey()'s parameter? 2013-04-30 01:53:31 +0000 1 1 1 Unclassified HTML WG Encrypted Media Extensions unspecified All All RESOLVED FIXED P2 normal --- 1 ddorwin ddorwin mike public-html-media public-html-bugzilla oldest_to_newest 77629 0 ddorwin 2012-11-01 00:43:33 +0000 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 86616 1 ddorwin 2013-04-23 20:32:35 +0000 As agreed in the the February 5th telecon, we will eliminate the text that supports media data and update() calls without key IDs. 86982 2 ddorwin 2013-04-30 01:53:31 +0000 Removed support for content and |key| values (licenses) without key IDs in https://dvcs.w3.org/hg/html-media/rev/dbfb9104f0ee