- From: <bugzilla@jessica.w3.org>
- Date: Wed, 30 Apr 2014 22:41:03 +0000
- To: public-html-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25218 --- Comment #21 from David Dorwin <ddorwin@google.com> --- (In reply to Joe Steele from comment #18) > (In reply to David Dorwin from comment #17) > > (In reply to Joe Steele from comment #16) > > > One of my concerns is that there seems to be some disagreement about what is > > > considered in the session. The spec > > > (https://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted- > > > media.html#dom-release) seems clear that the CDM has flexibility in deciding > > > what is considered part of the session and what is not. > > > > What specific text are you referring to? I don't read this algorithm that > > way. > > From algorithm step 1.2.1: > Note: the release() method is intended to act as a hint to the user agent > that the application believes the session is no longer needed. ** However, > the CDM determines whether resources can now be released. ** Oh, that simply means that release() is not close(). This idea of release() being a "hint" started in https://www.w3.org/Bugs/Public/show_bug.cgi?id=17750#c5, but I'm not sure of the use case. Maybe the point was that the CDM may need to send messages before closing. The release flow needs to be improved. I'll add this to the list. > A CDM would not load a session when provided a key ID. The CDM would load a > cached key based on the key ID into an empty session created by the > application. > I would not expect the CDM to load a "session" which could contain multiple > keys, but instead load a single key into an empty session. > I am not sure what this means. If you mean that a CDM may not support > splitting out keys into separately loadable chunks, that could be a problem. All of these statements seem to assume that CDMs support loading, managing, and destroying the individual keys within a license separately. It seems unlikely that such support is common. -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Wednesday, 30 April 2014 22:41:09 UTC