- From: David Dorwin <ddorwin@google.com>
- Date: Mon, 11 Jun 2012 23:12:06 -0700
- To: public-html-media@w3.org
- Message-ID: <CAHD2rsgoys474Qo0V6PiJ992HPbNPqkqsf56QHUJsNoQ3djUcw@mail.gmail.com>
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