This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
In the January 14, 2013 version of the spec, createSession()'s |type| parameter is optional, meaning it may be null. The question is whether this makes sense. |type|'s primary purpose is as a media/MIME type to tell the CDM how to interpret the |initData|, which is container-specific. |type| was left optional in case key systems wanted to create sessions not for a specific key, or something like that. With no real world use case for this, maybe we should make it required. This also avoid null being used for some key system-specific purpose, which could lead to fragmentation. If a generally useful use case emerges, we can always make it optional in the future without breaking existing apps.
Requiring the type parameter would simplify things a bit. Since the purpose of |type| was to specify how to interpret |initData| and we don't yet have a use case for it being optional
, we should make it required. Key systems could define a string for their "default" use case and we could always change this in the future. This was agreed on in the February 5th telecon.
Agreed - the format of initdata is likely to always be determined by type.
Similarly, should |initData| be required as well? It could be an empty array I suppose, but not allowing null would simplify code and remove the only remaining optional parameter in EME. The use case I imagine someone might want is to create a generic session for some purpose. In that case, |type| doesn't make much sense, but we've required it so why not require |initData|? It seems we should either allow both to be null (already decided not to allow |type|) or not allow either to be null. Thoughts?
One use case I brought up previously for allowing initData to be null was to allow a CDM which requires activation independent of content to start that process before the user has selected any content. This could be signaled by an empty initData just as easily though, if that makes the implementation easier on the UA side.
Both parameters are now required as discussed in the May 21st telecon: https://dvcs.w3.org/hg/html-media/rev/4a8be9f80c1a