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 "needkey" event was originally intended to indicate "this stream is (may be) encrypted" and provide some data about it. At one time, it was even possible to fire in response to not having the key for a block. Since then, the algorithm has changed, we've dropped MEDIA_ERR_ENCRYPTED, and put less focus on using this event to drive createSession() calls. The event that is fired Initialization Data Encountered [1] does not necessarily mean that a key is needed (only the CDM knows this and the CDM is not involved in firing this event). Therefore, I think we should rename it to avoid confusion. Since the event is fired at HTMLMediaElement, it should somehow indicate that it is related to EME/encrypted content. For example, "initdata" is too general and ambiguous. Possible options include "encrypted" and "encryptedinitdata". [1] https://dvcs.w3.org/hg/html-media/raw-file/default/encrypted-media/encrypted-media.html#algorithms-initdata-encountered
Perhaps "encryptedmedia", since it is indicating that the file triggers the "Encrypted Media Extensions". More specific than 'encrypted' and less obscure than encryptedinitdata (also, the initdata is not the thing that is (might be) encrypted.
"encrypted" would suffice I think. I think this is better than "encryptedmedia" as the "media" suffix is a bit superfluous, given that the event is targeted at the media element.
I prefer "encryptedmedia" for the same reason Mark lists below. It seems more complete and is clear. We also need to update the needkey event interface and dictionary: [Constructor(DOMString type, optional EncryptedMediaEventInit eventInitDict)] interface EncryptedMediaEvent : Event { readonly attribute DOMString initDataType; readonly attribute ArrayBuffer? initData; }; dictionary EncryptedMediaEventInit: EventInit { DOMString initDataType = ""; ArrayBuffer? initData = null; };
Summary: I'm leaning towards "encrypted" because anything longer is either inaccurate or too wordy. Background: * The event really means that the UA has encountered container data that indicates that media data blocks {are possibly | are potentially | may be} encrypted. The event type happens to provide that container data. * Looking at other APIs, most event names appear to be one of the following: - actions (in various tenses) - noun-then-verb "encryptedmedia" does not reflect the meaning or match the existing patterns. If anything, "mediaencrypted" would be more consistent, though this would imply that media was just encrypted. "encryptedmediaencountered" would be better, but implies the UA has actually encountered encrypted media, which is not necessarily true - the UA just encountered a header. The following are probably more accurate, though not very appealing: * potentiallyencryptedmedia[data][encountered] * encryptionheader[encountered] * encryptiondata[encountered] * initdataencountered Lacking a good accurate and consistent name, "encrypted" seems the least misleading.
Agreed on "encrypted" in the telecon today.
https://dvcs.w3.org/hg/html-media/rev/0e67f757aeb9 renames the "needkey" event to "encrypted" and updates related text. I changed the event type name to MediaEncryptedEvent "EncryptedEvent" is too generic for the global namespace, and the "Media" prefix is consistent with MediaKeyMessageEvent. We could use a name containing "InitData", but that seems less flexible if the "encrypted" event ever needs to be extended to contain other attributes.