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

[EME] Heartbeat support

From: David Dorwin <ddorwin@google.com>
Date: Mon, 11 Jun 2012 23:12:06 -0700
Message-ID: <CAHD2rsgoys474Qo0V6PiJ992HPbNPqkqsf56QHUJsNoQ3djUcw@mail.gmail.com>
To: public-html-media@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=16738

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 06:13:48 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:32:55 UTC