Re: CfC: to publish Encrypted Media Extensions specification as a First Public Working Draft (FPWD)

On Sat, Feb 9, 2013 at 5:27 AM, Mark Watson <watsonm@netflix.com> wrote:
> We must see what we can do to relax these requirements, but I would not
> accept that the test should be that specification must fully define a DRM
> system, as you suggest. We do not do this for other HTML specifications: The
> video element does not define a codec, the geo-location API does not define
> a method of determining geographic location, WebGL can't be implemented
> (performantly) without hardware which is in practice proprietary (i.e.
> graphics cards).

There are different kinds of proprietary. When the codecs of the video
element were left open ended in the spec, it was indeed expected that
proprietary codecs would be plugged into that extension point.
However, when that extension point was made, it was expected that the
proprietary codecs would be proprietary in the sense that there'd be
someone out there seeking patent licensing fees. It was not expected
that codecs that couldn't be implemented without access to secret
knowledge would be plugged into the extension point. I.e. proprietary
in the sense of essential secrets was not expected.

Video, geolocation and WebGL can all be independently interoperably
implemented without access to secrets.

The same is not true for EME with the kind of CDMs that actually
matter. It appears that the proponents of EME intend to target content
to CDMs that will not be independently interoperably implementable
without access to secrets.

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/

Received on Monday, 11 February 2013 07:10:31 UTC