[Bug 20944] EME should do more to encourage/ensure CDM-level interop

https://www.w3.org/Bugs/Public/show_bug.cgi?id=20944

--- Comment #27 from Glenn Adams <glenn@skynav.com> ---
(In reply to comment #26)
> (In reply to comment #22)
> > > I will draft a proposed registry along the lines I propose. If you feel the
> > > urge and think you can gain sufficient support for your proposal, then you
> > > are free to draft an alternative form.
> > 
> > http://www.w3.org/html/wg/wiki/KeySystemRegistry
> 
> The phrase "a public available specification (PAS) which the registrant
> believes satisfies some standard of openness" pretty obviously places no
> real requirement on registrants at all. And "Each entry listed as a Non-Open
> Key System is encouraged to include a link that references some form of
> publicly available information about the Key System" does even less.
>  
> (In reply to comment #23)
> > I was hoping we would be able to do a little more here, especially for the
> > case of DRMs supported by the operating system.
> > 
> > Specifically, if a DRM is included in the OS, can be accessed through public
> > APIs and can be used to implement EME in a browser then the specification of
> > how to do this should be public. The registry should encourage or require
> > this.
> 
> I agree that the registry could and should require that any DRM system
> listed in the registry must make available a clear specification about how
> it can be used to implement EME in a browser. Otherwise, there's really no
> point in having a registry at all.

Registration in this registry is strictly voluntary. The real registry is the
DNS, since nothing prevents a User Agent from supporting an arbitrary Key
system based on their own DNS entries.

Thus, the purpose of this registry is to permit Key system implementers to
declare some level of openness (or not) and to disclose specifications or
documentation. That's it, but that's more than nothing.

Finally, you say "implement EME in a browser", but I think you mean Key System,
since EME can be implemented by anyone without implementing any Key System
except clear key (though such an implementation won't be very useful).

The fact of the matter is that there are a number of Key Systems in use today
with protected content that require an NDA to access their specifications.
These will not be openly specified any time soon, so any UA vendor will need to
work directly with those vendors to determine how to implement support for
those Key Systems.

What you propose, of mandating a required open specification, will ensure those
systems are not registered, though they will be likely implemented in any case
(at least in some UAs) and used by service providers.

If a non-open registry is available for these systems, then it will at least
expose their use, which is a small, but non-zero increase in transparency, and
will provide an opportunity for those registration entries to disclose some
information, even if not sufficient for an open implementation.

Again, this provides a positive benefit, greater than the "there's really no
point" you suggest.

> 
> > Otherwise we have an obvious interoperability problem where multiple
> > browsers use public OS APIs to implement a CDM, but they do so in different,
> > incompatible, ways.
> > 
> > Potentially, we could go further and say that when a CDM is built using
> > platform APIs then it should be a condition of registration that these APIs
> > are public, rather than secret APIs only available to a single browser.
> 
> I agree it should be a requirement of registration that the APIs are public
> and not only available to a single browser. Because there would otherwise
> really no point in registering them at all.

I don't agree with this either, since it doesn't interoperability with the
status quo. I agree we should encourage use of open APIs if available and used
on some platform, and we could add this to the requirements for a registration
in the Open Key System registry, but I don't agree that this should be applied
to the Non-Open registry.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Friday, 16 August 2013 17:13:10 UTC