This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 25267 - Remove ability for in-memory sessions to be re-used
Summary: Remove ability for in-memory sessions to be re-used
Status: RESOLVED FIXED
Alias: None
Product: HTML WG
Classification: Unclassified
Component: Encrypted Media Extensions (show other bugs)
Version: unspecified
Hardware: All All
: P3 normal
Target Milestone: ---
Assignee: Adrian Bateman [MSFT]
QA Contact: HTML WG Bugzilla archive list
URL:
Whiteboard:
Keywords:
Depends on: 25268
Blocks:
  Show dependency treegraph
 
Reported: 2014-04-04 21:39 UTC by David Dorwin
Modified: 2014-04-21 23:11 UTC (History)
4 users (show)

See Also:


Attachments

Description David Dorwin 2014-04-04 21:39:21 UTC
The outcome of bug 21855 was to allow implementations to avoid firing a message event if there is already an in-memory session, possibly already containing a license, for the provided initData.

This was actually implemented as part of the state machine [1], and a clarification was later added to indicate that the sessions must still appear distinct [2].

I think such behavior causes inconsistent and unexpected behavior for applications. I think EME should not allow such *optional* in-memory sharing. Instead, we should try to really solve the underlying problem (redundant needkey events) and/or make the behavior explicit (i.e. adding another value to bug 25200).

The changes to the spec would be:
 A. Remove the note added in [2].
 B. Require a message event when creating a session unless otherwise specified.

There might be use cases for not firing a message when creating a session, but I don't think they are currently explicitly supported. We can re-evaluate the related algorithms when enabling such use cases.

[1] https://dvcs.w3.org/hg/html-media/rev/83629aec22e1
[2] https://dvcs.w3.org/hg/html-media/rev/cba144274140
Comment 1 David Dorwin 2014-04-04 21:46:32 UTC
The underlying problem is tracked as bug 25268.
Comment 2 David Dorwin 2014-04-04 22:08:08 UTC
Also, as discussed at the time, it seems difficult to define or implement this behavior in a way that still allows the "MediaKeySession instances [to] appear distinct" as is stated in [2].
Comment 3 Joe Steele 2014-04-07 16:32:26 UTC
(In reply to David Dorwin from comment #2)
> Also, as discussed at the time, it seems difficult to define or implement
> this behavior in a way that still allows the "MediaKeySession instances [to]
> appear distinct" as is stated in [2].

If your proposal for bug 25199 is accepted, it looks like this problem will go away.
Comment 4 David Dorwin 2014-04-07 17:25:54 UTC
(In reply to Joe Steele from comment #3)
> (In reply to David Dorwin from comment #2)
> > Also, as discussed at the time, it seems difficult to define or implement
> > this behavior in a way that still allows the "MediaKeySession instances [to]
> > appear distinct" as is stated in [2].
> 
> If your proposal for bug 25199 is accepted, it looks like this problem will
> go away.

Not necessarily. I was referring to the underlying state, not just the reporting of results. For example, if one session is release()'d, how does that affect the other session in a way that makes sense while still allowing the sessions to "appear distinct"?
Comment 5 David Dorwin 2014-04-21 23:11:17 UTC
The resolution of bug 25268 (all implementations check for existing sessions) addresses the original use case and makes the associated text obsolete.

The text is removed in https://dvcs.w3.org/hg/html-media/rev/a91faf82b9b5