This is related to Bug 20944 (EME should do more to encourage/ensure CDM-level interop) which proposes a central registry.  A central registry does not appear to solve the matter, it just passes the buck - there is not path proposes for this central registry to progress through the W3C standardization process and if the CDMs in the registry were to be defined then they could equally be included in the standard.

This is related to Bug 20960 (EME is not limited to video) which is a result of the undefined CDM.

This might be related to Bug 20961 (EME depends on privileged access to the users computer which is not technically available), as there is no infrastructure defined to allow a user to forfeit control of their computer.

If the spec is technically incomplete, please propose spec text that completes it. It would be helpful to divide this into individual bugs addressing each missing feature. The spec isn't finished yet so being incomplete is expected.

The onus in on the proponents to supply a path to a complete specification.  Please leave this bug open until the specification is complete and can be reviewed, in particular the CDM is not specified

(In reply to comment #3)
> The onus in on the proponents to supply a path to a complete specification. 
> Please leave this bug open until the specification is complete and can be
> reviewed, in particular the CDM is not specified

As the bug reporter, the onus is on you to describe what is incomplete. You can't just say "it's incomplete" without describing specifics of how it is incomplete.

Please read the comment "in particular the CDM is not specified".

(In reply to comment #5)
> Please read the comment "in particular the CDM is not specified".

A CDM is specified. The fact that not all CDMs are specified does not make it technically incomplete any more than not specifying the image formats in HTML5 makes <img> technically incomplete.

There is something in software known as an abstraction barrier. Its purpose is to provide a well defined interface that abstracts some functionality from its implementation. It is sometimes known as a black box.  The fact that the design of EME permits use of one or more black box implementations of the CDM abstraction does not make it technically incomplete any more than an operating system API abstracts the implementation of some functionality.

If you can actually point out how something will technically fail to work in EME based on its defined API, then it is reasonable to keep this bug open. However, absent that, this bug should remain in the NEEDSINFO state. If you don't have that info, then it should be resolved as INVALID.

The scope of an image format can be well defined, the decoder can run in a sandbox controlled by the user.  The CDM requires unspecified, secure, and privileged access to the users computer - please supply the technical details.

The CDM proposed does not meet the requirements that content authors have articulated for usable DRM and thus does not even qualify as a valid example.  Please supply an example CDM that implements all of the DRM features required by content authors so it can be reviewed.

It could be made more technically complete as follows:
- Introduce a requirement that CDMs be downloadable and executable in a sandbox
-- Possible sandboxes might be JVM, .Net, NaCl, etc. Rather than require one 
   particular sandbox, implement a registry of sandbox IDs, and some way to
   request a particular version of that sandbox (e.g. Java version >= 7)
-- Have an XML manifest for the CDM that declares:
---- CDM identity and revision number
---- what sandbox it uses and what revision
---- URL from which it can be downloaded
---- list of native OS services it requires, if any
------ this list may be platform-specific, e.g. Windows API X from Y.dll
       Linux function X from Y.so. Define a naming scheme that works for
       common platforms, e.g. win32:dllname:exportname, linux:dllname:exportname
       make it extensible to support further platforms
------ a sandbox specific API to invoke those native services. This could be
       e.g. P/Invoke under .NET, JNA under Java, etc.
---- UA or sandbox must verify the CDM, either before executing it or while 
     executing it, to ensure it only uses the declared native services. How the
     UA or sandbox should do so would be sandbox-specific.

With this design, it should be possible for a CDM to work with multiple UAs or
even multiple platforms. Of course, there are no guarantees - the CDM could
always detect the UA or platform and refuse to run - but it means that building
a UA or platform restricted CDM becomes more of a conscious decision and less of
an accident.

(In reply to comment #8)
> It could be made more technically complete as follows:
> - Introduce a requirement that CDMs be downloadable and executable in a
> sandbox
> -- Possible sandboxes might be JVM, .Net, NaCl, etc. Rather than require one 
>    particular sandbox, implement a registry of sandbox IDs, and some way to
>    request a particular version of that sandbox (e.g. Java version >= 7)
> -- Have an XML manifest for the CDM that declares:
> ---- CDM identity and revision number
> ---- what sandbox it uses and what revision
> ---- URL from which it can be downloaded
> ---- list of native OS services it requires, if any
> ------ this list may be platform-specific, e.g. Windows API X from Y.dll
>        Linux function X from Y.so. Define a naming scheme that works for
>        common platforms, e.g. win32:dllname:exportname,
> linux:dllname:exportname
>        make it extensible to support further platforms
> ------ a sandbox specific API to invoke those native services. This could be
>        e.g. P/Invoke under .NET, JNA under Java, etc.
> ---- UA or sandbox must verify the CDM, either before executing it or while 
>      executing it, to ensure it only uses the declared native services. How
> the
>      UA or sandbox should do so would be sandbox-specific.
> 
> With this design, it should be possible for a CDM to work with multiple UAs
> or
> even multiple platforms. Of course, there are no guarantees - the CDM could
> always detect the UA or platform and refuse to run - but it means that
> building
> a UA or platform restricted CDM becomes more of a conscious decision and
> less of
> an accident.

All this is possible, and could certainly be accomplished in another specification (whether created by the W3C or not), but nothing in EME technically requires or depends on the existence of such a specification. In fact, it can be argued that the creation of such a CDM API and architecture is highly dependent on specific UA implementations, and possibly on OS specific ports of such implementations, and, as such, should be specified by individual UA vendors.

Given the desire for modularity, layering, and abstraction, EME should not be clouded by unrelated implementation details. As such, the CDM mechanism in EME is nothing more than a didactic device to aid in the explanation of EME processing semantics.

(In reply to comment #9)
> All this is possible, and could certainly be accomplished in another
> specification (whether created by the W3C or not), but nothing in EME
> technically requires or depends on the existence of such a specification.
Without specifying at this level of detail, the standard contains a massive 
black box, where true interoperability of independently developed 
implementations may well be impossible.

> In fact, it can be argued that the creation of such a CDM API and
> architecture is highly dependent on specific UA implementations, and
> possibly on OS specific ports of such implementations, and, as such,
> should be specified by individual UA vendors.
Need that be the case? One could define a platform-independent virtual
machine  under which CDMs would operate - and there is no reason why such a
VM could not be implemented by any UA on any OS - either one could leverage
an existing such VM (e.g. Java or .NET), or define a new one from scratch 
(which arguably could be simpler than Java or .NET are). With such a VM 
defined, there is no reason why multiple UAs on multiple OSs or hardware 
platforms could not implement it.

Inevitably, any CDM in such a VM may need access to the underlying OS, which
may prevent CDMs from being truly platform-independent. However, there are a
few ways in which platform-dependence can be limited:

1) A single CDM can contain code to integrate with multiple platform's native
services, and dynamically determine which services to use at runtime - thus
the same CDM might operate on iOS, Android, Windows, MacOS X, Linux, etc.

2) Native access to most platforms can be modelled as calls to named
functions (procedural style), or as method invocations on interfaces
(object-oriented style); and there is a common set of data types which will 
address the needs of most platforms (i.e. those provided by C). Such a
strategy might not work for every platform under the sun, but one could
design a native services standard whose basic functions would be equally 
implemented on multiple major OSes, and you could standardise extensions to 
deal with the peculiarities of common platforms (like Windows, Linux, Un*x, 
iOS, etc.)

How the VM code is executed - whether by interpretation, by AOT or JIT
compilation to native machine code, or translation to bytecode of another
VM - these are all implementation details which a standard need not specify. 
But it should define a VM (or VMs) for execution of CDMs.

The existing solutions in this area - both Flash and Silverlight - provide a
a platform independent VM at their core. If EME is to replace this use of
Flash/Silverlight, but does not provide such a VM, it is effectively a step
backwards.

> Given the desire for modularity, layering, and abstraction, EME should not
> be clouded by unrelated implementation details. As such, the CDM mechanism
> in EME is nothing more than a didactic device to aid in the explanation of
> EME processing semantics.
A standard containing a massive black box whose behaviour and interfaces are
insufficiently defined for interoperable implementations to be independently
developed has a major lack.

I don't object in principle to implementing support for DRM. However, if a new 
standard for DRM is going to be proposed in the HTML context, then it should
be superior to the existing Flash/Silverlight solutions, and I believe EME
as currently defined is inferior to them.

> The existing solutions in this area - both Flash and Silverlight - provide a
> a platform independent VM at their core. If EME is to replace this use of
> Flash/Silverlight, but does not provide such a VM, it is effectively a step
> backwards.

I believe I responded to this elsewhere, but I will repeat it here for the sake of clarity. I cannot speak for Silverlight, but the DRM component of Flash is not dependent on a VM for anything but the exposure of its APIs to applications running inside the VM. The core functionality is implemented entirely in native code and is largely independent of Flash itself. Assuming that we were to implement a CDM for this, it would expose its functionality to Javascript applications via the EME API hooks. 

> I don't object in principle to implementing support for DRM. However, if a
> new 
> standard for DRM is going to be proposed in the HTML context, then it should
> be superior to the existing Flash/Silverlight solutions, and I believe EME
> as currently defined is inferior to them.

One obvious advantage that EME offers is the ability to write high-value video player applications in HTML/CSS/JS rather than in Flash or Silverlight or native code. This is a win, even if there were no other interoperability. And the intent is that those applications can work across multiple platforms, assuming a compatible CDM is present.

(In reply to comment #8)
> It could be made more technically complete as follows:
> - Introduce a requirement that CDMs be downloadable and executable in a
> sandbox
> -- Possible sandboxes might be JVM, .Net, NaCl, etc. Rather than require one 
>    particular sandbox, implement a registry of sandbox IDs, and some way to
>    request a particular version of that sandbox (e.g. Java version >= 7)
> -- Have an XML manifest for the CDM that declares:
> ---- CDM identity and revision number
> ---- what sandbox it uses and what revision
> ---- URL from which it can be downloaded
> ---- list of native OS services it requires, if any
> ------ this list may be platform-specific, e.g. Windows API X from Y.dll
>        Linux function X from Y.so. Define a naming scheme that works for
>        common platforms, e.g. win32:dllname:exportname,
> linux:dllname:exportname
>        make it extensible to support further platforms
> ------ a sandbox specific API to invoke those native services. This could be
>        e.g. P/Invoke under .NET, JNA under Java, etc.
> ---- UA or sandbox must verify the CDM, either before executing it or while 
>      executing it, to ensure it only uses the declared native services. How
> the
>      UA or sandbox should do so would be sandbox-specific.
> 
> With this design, it should be possible for a CDM to work with multiple UAs
> or
> even multiple platforms. Of course, there are no guarantees - the CDM could
> always detect the UA or platform and refuse to run - but it means that
> building
> a UA or platform restricted CDM becomes more of a conscious decision and
> less of
> an accident.


This looks like a start to the CDM API that Robert O'Callahan is referring to in http://lists.w3.org/Archives/Public/public-html-admin/2013Feb/0194.html and that seems to be able to take EME on a path that makes it acceptable to all browsers. I would not dismiss this suggestion out of hand but use it for motivation to discuss such an API in the Media Subgroup.

(In reply to comment #8)
> -- Possible sandboxes might be JVM, .Net, NaCl, etc.

See bug 20992 comment 2.

Making dependent on bug 20944, bug 20960, bug 20961 as agreed in the telcon. A bug that says a spec is "technically incomplete" is the wrong level of granularity to report issues.
http://www.w3.org/2013/02/19-html-media-minutes.html

I am marking this bug a RESOLVED NEEDSINFO again.  

The EME Editors and Media TF have indicated several times that they cannot act on this bug without detailed technical recommendations being made.

The Media TF discussed this bug again today and I agreed to mark this bug as NEEDSINFO.
http://www.w3.org/2013/04/30-html-media-minutes.html

Please do not re-open this bug again without providing a detailed description of what is incomplete and at least some sort of suggestion on how this can be dealt with.

/paulc
HTML WG co-chair