[Bug 21854] Define MediaKeySession life cycle states and/or events

https://www.w3.org/Bugs/Public/show_bug.cgi?id=21854

--- Comment #25 from David Dorwin <ddorwin@google.com> ---
(In reply to Adrian Bateman [MSFT] from comment #24)
> (In reply to David Dorwin from comment #23)
> > This change added the following text to the update() algorithm:
> > > If the session is not in the PENDING state, throw an INVALID_STATE_ERR.
> > 
> > I don't think this should be the case. There are probably legitimate reasons
> > for the application to provide a new message without the session requesting
> > it (and thus being in the PENDING state) - in other words, in the READY
> > state.
> > 
> > There may even be use cases for calling update() in the CREATED, ERROR, or
> > CLOSED states.
> 
> update() is intended to provide a message in response to the keymessage
> payload.
That's the basic model, but I never assumed it was the only model.

> I'm not sure we should change the spec unless we know of specific
> use cases where we don't want to limit it to this. We could wait to see if
> implementation experience suggests this is actually needed? I think we need
> to specify what to do if you call update() and it is not expected. Should it
> be silently ignored or should you get a state error.

Why do UAs/CDMs need to be "expecting" an update() call? I assumed they would
just always process the input and decide what to do?

As for use cases, an app could proactively provide a renewal message, a new
key, etc. I imagine there might be some more complex uses cases where
operations need to be performed on the session as well.

> > This change also included the following text describing the new keyready
> > event:
> > > The media element should not be blocked if encrypted data is encountered associated with the initData used to create the session.
> > 
> > I don’t think we can say this. Output protection or other issues could cause
> > the key(s) in the session to be unusable and thus for the media element to
> > be blocked.
> 
> This is a should rather than a must. The intent is that you move to READY
> when you don't expect to be blocked waiting for key material. Are you
> proposing to remove or revise this text? Perhaps we can change it into
> informative text?

I agree that this is the expected behavior in the happy case and it may be
useful in understanding the general flow. The problem I see is that the text
implies that playback will not be blocked, but there are expected scenarios
when the key/license will be unusable when such media data is encountered
(output protection, expired license, etc.)

I think we can probably reword the text to provide the helpful information
without implying the media element can't be blocked. Maybe we should just say
the license/key is ready for use. "Use" may include checking validity.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Tuesday, 12 November 2013 03:58:57 UTC