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

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

--- Comment #24 from Adrian Bateman [MSFT] <adrianba@microsoft.com> ---
(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. 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.

> 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?

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

Received on Tuesday, 12 November 2013 02:09:29 UTC