Re: [EME] Heartbeat support

Thanks for the comments. See inline.

On Tue, Jun 12, 2012 at 9:03 AM, Martin Soukup <martin.soukup@irdeto.com>wrote:

> 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.
>
Can you clarify your comment about key rotation? Are you saying that if a
new key is a new session that heartbeat should also be a new session? In
other words, your preference changes if this is the case?

Key rotation could be handled in multiple ways, but I don't think a
keymessage is one of them. The application will not receive a keymessage
that indicates it should rotate keys. The keymessage should generally be
passed to the server and the reply provided to the UA via addKey().

> ****
>
> ** **
>
> Similar to the question that came up on the call, how does the keymessage
> identify the media element?
>
In the current draft, all events are fired at the media element. Thus, the
element is identified by event.target. If we move toward an object-oriented
design and fire events at the new object, we'd need to specify a way to
identify the associated media element.

> ****
>
> ** **
>
> Martin****
>
> ** **
>
> *From:* David Dorwin [mailto:ddorwin@google.com]
> *Sent:* June-12-12 2:12 AM
> *To:* public-html-media@w3.org
> *Subject:* [EME] Heartbeat support****
>
> ** **
>
> 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?
> ****
>