16738 2012-04-13 22:12:43 +0000 Provide more guidance on heartbeat implementation 2013-05-07 00:30:01 +0000 1 1 1 Unclassified HTML WG Encrypted Media Extensions unspecified All All RESOLVED WONTFIX P4 normal --- 16616 1 ddorwin ddorwin eric.sun mike philipj public-html-media public-html-wg-issue-tracking watsonm public-html-bugzilla oldest_to_newest 66714 0 ddorwin 2012-04-13 22:12:43 +0000 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). 68167 1 ddorwin 2012-05-25 22:52:35 +0000 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. 68326 2 watsonm 2012-05-30 22:17:43 +0000 (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. 68983 3 eric.sun 2012-06-12 14:07:55 +0000 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. 69352 4 ddorwin 2012-06-22 23:20:20 +0000 (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. 72339 5 ddorwin 2012-08-17 06:30:38 +0000 I'll add my proposal (http://lists.w3.org/Archives/Public/public-html-media/2012Jun/0121.html) to the spec. 87300 6 ddorwin 2013-05-07 00:30:01 +0000 The heartbeat text was in the FAQ, which has been removed.