Bug 16738 - Provide more guidance on heartbeat implementation
Provide more guidance on heartbeat implementation
Status: RESOLVED WONTFIX
Product: HTML WG
Classification: Unclassified
Component: Encrypted Media Extensions
unspecified
All All
: P4 normal
: ---
Assigned To: David Dorwin
HTML WG Bugzilla archive list
:
Depends on:
Blocks: 16616
  Show dependency treegraph
 
Reported: 2012-04-13 22:12 UTC by David Dorwin
Modified: 2013-05-07 00:30 UTC (History)
6 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description David Dorwin 2012-04-13 22:12:43 UTC
v0.1 mentions two methods of implementing a heartbeat:
 1) Use keymessage to continue the current session
 2) Start a new message exchange procedes in exactly the same way as the initial message exchange, with the exception that the Key System and Session ID are known when the needkey event is sent.

The second option may impact the MediaKeyNeededEvent definition (see issue 16616).
Comment 1 David Dorwin 2012-05-25 22:52:35 UTC
In option 1, keymessage would be used to provide the heartbeat, which must be ACK'd by the server. The thought is that this ACK would be provided via addKey().

While this option seems more sensible for the server and CDM, it is not consistent with normal uses of addKey() (and the pairing with generateKeyRequest()). Is there a better name for addKey() that addresses both use cases? (Assuming we make the change in bug 16548) addKey() is always a response to a keymessage event, though one could imagine multiple addKey() calls for a given message.)


Option 2 is very consistent with the initial key request, but seems overly complex for a periodic heartbeat related to the same license.


The current text says an "an expiration time or valid duration" should be provided in the license. This language seems specific to option 2 and should be changed if we choose option 1.
Comment 2 Mark Watson 2012-05-30 22:17:43 UTC
(In reply to comment #1)
> In option 1, keymessage would be used to provide the heartbeat, which must be
> ACK'd by the server. The thought is that this ACK would be provided via
> addKey().
> 
> While this option seems more sensible for the server and CDM, it is not
> consistent with normal uses of addKey() (and the pairing with
> generateKeyRequest()). Is there a better name for addKey() that addresses both
> use cases? (Assuming we make the change in bug 16548) addKey() is always a
> response to a keymessage event, though one could imagine multiple addKey()
> calls for a given message.)
> 
> 
> Option 2 is very consistent with the initial key request, but seems overly
> complex for a periodic heartbeat related to the same license.
> 
> 
> The current text says an "an expiration time or valid duration" should be
> provided in the license. This language seems specific to option 2 and should be
> changed if we choose option 1.

I prefer Option 1 as it does not require much special knowledge in the script about heartbeat. When it gets a keymessage from the CDM the script just does what it usually does (send that to the server, get the response and give the response to the CDM with addKey).

addKey is not such a bad name: heartbeat can just be thought of as a sequence of expiring keys.

A more generic name would be ok, but making it as generic as "provideMessage" would be too much - we should retain the semantics that what this method does is provide data that is needed to (continue) decrypting the content.
Comment 3 Yang Sun 2012-06-12 14:07:55 UTC
I prefer Option1,since it is a light-weight keep-alive mechanism.
And the generateKeyRequest is used when load the page, but when keep-alive happens, it does not need reload the page, so we can still use addKey() for keep-alive.

My question is:

CDM->UA---(keymessage)------>Server
CDM->UA,--ACK----------------Server

In your second comment, it is said that 
ACK would be provided via addKey.
What does this mean? ACK from server is provided by addKey() API of UA?
I am a little confused.


(In reply to comment #1)
> In option 1, keymessage would be used to provide the heartbeat, which must be
> ACK'd by the server. The thought is that this ACK would be provided via
> addKey().
> 
> While this option seems more sensible for the server and CDM, it is not
> consistent with normal uses of addKey() (and the pairing with
> generateKeyRequest()). Is there a better name for addKey() that addresses both
> use cases? (Assuming we make the change in bug 16548) addKey() is always a
> response to a keymessage event, though one could imagine multiple addKey()
> calls for a given message.)
> 
> 
> Option 2 is very consistent with the initial key request, but seems overly
> complex for a periodic heartbeat related to the same license.
> 
> 
> The current text says an "an expiration time or valid duration" should be
> provided in the license. This language seems specific to option 2 and should be
> changed if we choose option 1.
Comment 4 David Dorwin 2012-06-22 23:20:20 UTC
(In reply to comment #3)
> I prefer Option1,since it is a light-weight keep-alive mechanism.
> And the generateKeyRequest is used when load the page, but when keep-alive
> happens, it does not need reload the page, so we can still use addKey() for
> keep-alive.
Neither option requires reloading the page.

> My question is:
> 
> CDM->UA---(keymessage)------>Server
> CDM->UA,--ACK----------------Server
> 
> In your second comment, it is said that 
> ACK would be provided via addKey.
> What does this mean? ACK from server is provided by addKey() API of UA?
> I am a little confused.
The ACKs the message and provides an ACK message back to the application, which then provides it to the UA/CDM using addKey().

Note also that the application should appear to the left of "Server" in both flows above.
Comment 5 David Dorwin 2012-08-17 06:30:38 UTC
I'll add my proposal (http://lists.w3.org/Archives/Public/public-html-media/2012Jun/0121.html) to the spec.
Comment 6 David Dorwin 2013-05-07 00:30:01 UTC
The heartbeat text was in the FAQ, which has been removed.