[Bug 17199] Provide examples for and get feedback on Key Release

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

--- Comment #7 from Mark Watson <watsonm@netflix.com> 2012-09-04 14:45:04 UTC ---
(In reply to comment #6)
> Comments on Comment 4:
>  * (i) and (ii): Do we need to define official states or are those
> non-normative?

The reason for mentioning states was just to make it clear that there is a
state where the system will keep trying to send the key release message for a
session, until it receives the key release acknowledgement. 

Since it's really up to the CDM how long it tries to do this (i.e. how long it
persists the key release state), we might not need to make it normative.

>  * (i) and (ii): I don't think the key release is "pending" or "complete" (it
> is the ack is pending or complete). Would "provided" and "ACKed" be better
> names?

Yes.

>  * (iii): I would prefer to avoid adding more methods, especially since not all
> implementations will support key release. I propose a solution below.
> 
> The active key session stuff in (i) and (ii) seems fine. For stored sessions, I
> propose reusing CreateKeySession() - To get stored key release proofs, pass
> "keyrelease" as the "type" parameter to createSession().^ The new session
> object is populated with the relevant information (keySystem, sessionId), and a
> keymessage with the key release proof is fired at it. The application could
> make the same call repeatedly until an exception occurs, which indicates that
> there are no such sessions.^^ A simple example to obtain a single proof is
> shown below.
>     var mediaKeys = new MediaKeys("com.example.somesystem");
>     try {
>       var releasedSession = mediaKeys.createSession("keyrelease");
>       releasedSession.onkeymessage="handleKeyRelease(event)";
>     }
> 
> It should probably be made clear that this is an optional recommendation for
> how to support key release use cases (similar to the recommendations for
> heartbeat). The details of proof storage, etc. are implementation-dependent,
> but stored sessions must only ever be provided to the same origin.

Sounds good to me.

> 
> 
> ^ This requires minor modification of step 1 of the current CreateKeySession()
> algorithm because the second parameter is not present.
> ^^ An alternative to this call-until-exception flow would be to expose a list
> of MediaKeySessions from MediaKeys (potentially useful for other scenarios?)
> then have createSession("keyreleases") populate that list. The application
> would need to immediately iterate through the list and add a handler to each
> object.

I'd like to understand this better.

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Tuesday, 4 September 2012 14:45:12 UTC