- From: Henri Sivonen <hsivonen@iki.fi>
- Date: Mon, 11 Feb 2013 13:30:52 +0200
- 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 purpose. > 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? No. > 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 http+aes. -- Henri Sivonen hsivonen@iki.fi http://hsivonen.iki.fi/
Received on Monday, 11 February 2013 11:31:22 UTC