This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
From v0.1: Should this be handled {in the synchronous portion of the addKey() algorithm} or in the task scheduled in the next step. The advantage of handling it here is that what is likely a programming error is immediately and simply reported via an exception. The disadvantage is that the user agent must store session IDs (and track when they are released) for each Key System rather than letting the CDM manage them. This is inconsistent with the goal that the user agent should just pass information. This same issue also applies to cancelKeyRequest().
The related text in the cancelKeyRequest() algorithm from v0.1 is: Can this step^ be done synchronously or should a task be queued to do it in the background and a needkey event fired when done? ^ The step is: Clear any internal state associated with the sessionId (or if this is null with the keySystem for this media element). This sessionId will now be unrecognized.
I think this issue could be obsoleted if we removed sessionId parameters by encapsulating the session in an object as proposed in bug 16613.
Addressed by the object-oriented API (bug 16613). addKey() and close() no longer have sessionId parameters to check.