This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
loadSession is optional now, which means that session storage is as well. Current createSession steps don't state what to do if sessionType is not supported. Proposed add to under step 7.4.2 for createSession: 3.If the sessionType is not supported by the cdm, reject promise with a new DOMException whose name is "NotSupportedError".
Step 4 currently says: If sessionType is not supported by the content decryption module corresponding to the keySystem, return a promise rejected with a new DOMException whose name is "NotSupportedError". I think that addresses this request. The only difference is that this happens synchronously vs. asynchronously as would be the case in 7.4.x. I think this is fine and consistent with other knowledge the UA must have about the CDM (initDataType support, etc.). I suppose there might be scenarios where support cannot be known a priori. A CDM could always then report "NotSupportedError" in 7.7 in this scenario. I think it's nice to do parameter verification together in the synchronous steps, and this provides a quick and early escape for implementations that know they do not support a specific session type. (I can see this being even more useful if other session types are added.)
I agree this text is sufficient. Thanks.