This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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).
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.
(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.
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.
(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.
I'll add my proposal (http://lists.w3.org/Archives/Public/public-html-media/2012Jun/0121.html) to the spec.
The heartbeat text was in the FAQ, which has been removed.