W3C home > Mailing lists > Public > public-html-media@w3.org > June 2012

RE: [EME] Heartbeat support

From: Martin Soukup <martin.soukup@irdeto.com>
Date: Tue, 12 Jun 2012 12:03:24 -0400
To: David Dorwin <ddorwin@google.com>, "public-html-media@w3.org" <public-html-media@w3.org>
Message-ID: <333F1B211D1F71488F6C74D6757F2A1002E6A2CA3B@CAOTT-MSG001.domain1.intra>
I think Option 1 is simpler for the application developer and is consistent with the idea that a single key has a single session. If the rotation of keys will generate new sessions, however, I believe that the heartbeat mechanism should be consistent and be treated as a new key request since as an application developer I shouldn't need to differentiate between what kind of requests are being made.

Similar to the question that came up on the call, how does the keymessage identify the media element?


From: David Dorwin [mailto:ddorwin@google.com]
Sent: June-12-12 2:12 AM
To: public-html-media@w3.org
Subject: [EME] Heartbeat support


Some content providers require a heartbeat from the client device. Implementations often involve a message being generated by the decryption module and being ACK'd by the server. The APIs in the proposal were designed to allow such additional features without requiring API changes. However, there are multiple ways heartbeat might be implemented, and it probably makes sense to provide guidance to avoid fragmentation.

The current draft mentions two potential implementations at http://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html#faq-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.

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(). Assuming we make the change in https://www.w3.org/Bugs/Public/show_bug.cgi?id=16548,  addKey() is always a response to a keymessage event, so that is somewhat consistent with existing use cases.

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

If we feel heartbeat is common enough, another option would be to add explicit support for heartbeat, as is the case for key release. However, unlike key release, heartbeat can be handled within the existing APIs, and we want to avoid adding specific features to the API as much as possible.

Mark has provided his input in the bug. Does anyone else have a preference?
Received on Tuesday, 12 June 2012 16:04:13 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 15:48:22 UTC