26313 2014-07-11 21:41:32 +0000 Steps for createSession should define what happens if the sessionType is not supported 2014-07-25 22:54:32 +0000 1 1 1 Unclassified HTML WG Encrypted Media Extensions unspecified PC Windows NT RESOLVED FIXED P2 normal --- 1 jdsmith jdsmith ddorwin mike public-html-media public-html-bugzilla oldest_to_newest 108872 0 jdsmith 2014-07-11 21:41:32 +0000 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". 108873 1 ddorwin 2014-07-11 21:50:51 +0000 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.) 109303 2 jdsmith 2014-07-25 22:54:32 +0000 I agree this text is sufficient. Thanks.