W3C home > Mailing lists > Public > public-html-admin@w3.org > February 2013

Re: On the Encrypted Media Extensions (EME) document

From: Henri Sivonen <hsivonen@iki.fi>
Date: Mon, 11 Feb 2013 13:30:52 +0200
Message-ID: <CAJQvAuf4vdB=S0LextrU-8am0dTqa6sPPbM0fstvNp2awFEB1A@mail.gmail.com>
To: Glenn Adams <glenn@skynav.com>
Cc: Philippe Le Hegaret <plh@w3.org>, public-html-admin@w3.org, Paul Cotton <Paul.Cotton@microsoft.com>, Maciej Stachowiak <mjs@apple.com>, Sam Ruby <rubys@us.ibm.com>
On Mon, Feb 11, 2013 at 11:44 AM, Glenn Adams <glenn@skynav.com> wrote:
> On Mon, Feb 11, 2013 at 12:41 AM, Henri Sivonen <hsivonen@iki.fi> wrote:
>> On Fri, Feb 8, 2013 at 6:10 PM, Philippe Le Hegaret <plh@w3.org> wrote:
>> > This clarification is not a statement of support towards the technical
>> > approach taken in the EME specification or the CfC itself.
>> Is the Team taking a position on whether it's appropriate for a W3C
>> specification to rely exclusively on components that cannot be
>> independently interoperably implemented when the specification is used
>> for its intended purpose? (Clear Key does not count, because none of
>> the proponents of EME intend to use Clear Key in production.)
> Please demonstrate how the EME "cannot be independently interoperably
> implemented when the specification is used for its intended purpose".

The whole point of a Hollywood-strength CDM is that it's designed not
to be independently replicable. In other words, to pitch a CDM to
Hollywood, you'd try to convince them that it doesn't have the
characteristics that fully W3C-specified tech has.

Anyway, under the Process, the burden of proof is to show
interoperability. It's not that one has to prove the impossibility of
interoperability. Moreover, I was not talking about EME itself but
about other components without which EME doesn't serve its intended

> Clearly you do not, nor does anyone else participating in this thread have
> such knowledge.

It's pretty clear that EME is motivated by the desire to have
something that Hollywood would deem acceptable for streaming their
movies (and possibly come up with something that pleases video
producers with lesser requirements as a side effect).

It's completely unproductive to try to cast doubts upon the motivation
and suggest it's about something else.

>> Is the Team taking a position on whether it's appropriate for a W3C
>> specification to include mandatory parts whose sole purpose is
>> debugging or satisfying the form of the W3C Process?
> From the team response, I don't see any position articulated regarding
> appropriateness or inappropriateness of any technical aspect of the EME
> draft.

That's why I asked if the Team is taking positions on the questions I stated.

> Surely you aren't you suggesting you have complete knowledge of the (present
> and future) intentions of potential users of EME?

I'm suggesting that in the WG threads about EME, I have not seen any
participant say that they have content that they won't (or aren't
allowed to) serve using non-EME facilities (in the clear or using
JS-based decryption) but would serve using Clear Key if it was
available. I think it's counterproductive to keep implying that such
an entity might exist somewhere and that the potential existence of
such entities is somehow lessens concerns raised about non-Clear Key
Key Systems.

> What is the bearing on
> possible uses of ClearKey and its inclusion in the EME draft?

We shouldn't complicate the platform with features that lack use cases.

> There is nothing stopping you or another party from specifying an additional
> CDM that employs [http+aes].

Having both Clear Key and http+aes would make the Web Platform more
complex than having just either one. "No one is stopping you from
doing [some different thing]" is a really poor argument for making
something part of the Web Platform.

> Are you suggesting it should be done in the EME
> draft itself?


> Are you suggesting a choice needs to be made between
> specifying ClearKey and [http+aes]?

I am suggesting that non-debugging, non-Process use cases for Clear
Key are a red herring. If there were parties genuinely interested in
the supposed use cases, they could speak for themselves and browsers
could address the use cases more appropriately with a design like

Henri Sivonen
Received on Monday, 11 February 2013 11:31:22 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:37:33 UTC