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

Re: [EME] Requiring generateKeyRequest() in all cases for all key systems

From: David Dorwin <ddorwin@google.com>
Date: Tue, 19 Jun 2012 12:08:34 -0700
Message-ID: <CAHD2rsiNcQuW=b2K7+2jeReQhxok+iqjTHsOoyaMPNKvnEbkEw@mail.gmail.com>
To: Mark Watson <watsonm@netflix.com>
Cc: "<public-html-media@w3.org>" <public-html-media@w3.org>
This change doesn't seem to be controversial, but we'll need to figure out
how to implement the check. I added the following comment to the bug:

One option is that the user agent should fire an INVALID_STATE_ERR if addKey()
or cancelKeyRequest() are called before an appropriate (i.e. same keySystem)
successful call to generateKeyRequest().

However, should we also require a valid session ID (bug 17203
<https://www.w3.org/Bugs/Public/show_bug.cgi?id=17203>), which would
also require that generateKeyRequest() had been called? Note that the current
draft says to throw an INVALID_ACCESS_ERR if sessionId is unrecognized.
However, that assumes the session ID check is synchronous, which may not make
sense (bug 16550 <https://www.w3.org/Bugs/Public/show_bug.cgi?id=16550>).

This discussion may be moot depending on the specific solution to bug
16613 <https://www.w3.org/Bugs/Public/show_bug.cgi?id=16613>. [1]

[1] See also the discussion at

On Tue, Jun 19, 2012 at 8:33 AM, Mark Watson <watsonm@netflix.com> wrote:

>  On Jun 11, 2012, at 10:49 PM, David Dorwin wrote:
>  https://www.w3.org/Bugs/Public/show_bug.cgi?id=16548
>  The proposal currently allows addKey() to be called without
> calling generateKeyRequest(). This allows a very simple application as
> shown in the example in section 7.1. However, such applications are
> unlikely and supporting this adds complexity to implementations. Therefore,
> I would like to always require generateKeyRequest(). Does anyone object?
>  The impact on the example in section 7.1 is shown in
> http://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html#issue-disallow-addkey-only-example
> .
>  Benefits include:
>  * Simplifies user agent implementation - there is one API where a CDM can
> be instantiated.
>  * We can eliminate the keySystem parameter from addKey() and
> clearKeyRequest()
>  * Less confusion in the application and user agent related to the
> potential for the keySystem value to change, such as in addKey() and
> clearKeyRequest() calls.
>  * It fits nicely with an object-oriented design, such as the one proposed
> in bug 16613.
>  I agree.
>  ůMark
Received on Tuesday, 19 June 2012 19:09:23 UTC

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