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

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

Glenn Adams <glenn@skynav.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |glenn@skynav.com

--- Comment #2 from Glenn Adams <glenn@skynav.com> ---
(In reply to comment #0)
> The current EME draft makes no attempt to encourage interop at the CDM
> level.

This is not a well defined statement in the sense that neither "interop" nor
"at the CDM level" are defined concepts.

> For example, the current EME draft does not forbid or even discourage
> a UA vendor from promulgating a CDM that no other user-agent can support,
> and encouraging the creation of content for that CDM consumable only by that
> user-agent.

This statement suggests that the EME draft "encourag[es] the creation of
content ... consumable only by that user-agent". However, no reference is made
to language in the draft that makes such a suggestion.

Further, by analogy, the HTML5 draft "does not forbid or even discourage a UA
vendor from promulgating" a large number of possible UA dependent features,
such as UA specific video codecs, UA specific geo-location devices, UA specific
input method editors, UA specific fonts, UA specific canvas context
implementations, and so forth.

This "bug" report appears to assert that conceptual CDM architecture, which is
essentially a UA dependent implementation feature outside the scope of EME,
should be proscribed in terms of how a UA vendor chooses to support specific
CDM functionality and which functionality is to be supported by that vendor.

This form of mandate would represent an abrupt shift in the independence of UA
implementors in terms of which W3C specifications are implemented, as well as
how implementation specific decisions are made.

> Such an outcome would be antithetical to the mission of the W3C,
> and the W3C should not bless, appear to bless, or enable such scenarios.

The W3C mission is well defined by its published documents and particularly the
W3C Process Document. The development of the EME specification has occurred
within the charter of the HTML WG in accordance with the W3C Process (unless
the reporter is claiming otherwise).

If the reporter of this "bug" takes issue with that charter and/or process,
then the "bug" should be registered against those documents. As such, this
"bug" does not represent a technical issue, but is instead a philosophical or
business argument about how some UA vendors perceive their own mission and how
they pursue their own individual philosophical or business goals.

> I believe it is possible to fix this bug without making major changes to EME
> or CDM technology, without discarding existing EME/CDM requirements, and
> that it's worth making at least a good-faith effort to try. I believe this
> should be settled (at least to the point of committing to fix the bug)
> before EME progresses further, or any requirements we need to add to EME and
> CDMs are likely to be rejected as "too late".
> 
> My proposed fix is to have EME require CDMs to be registered in a central
> registry. To be registered, a CDM would have to meet the following
> conditions:
> 
> 1) Documentation must be published describing the complete operation of the
> CDM, in enough detail to enable independent implementation in user-agents
> and to enable content deployment by content providers, except for some set
> of secret keys whose values may be withheld. (Similar to but weaker than
> IANA's "specification required" registry policy.)
> 
> 2) If the CDM vendor offers functionality to third parties to decrypt
> content that can be decrypted by the CDM, then it must publish documentation
> describing how to implement the CDM using that functionality. (E.g. if a DRM
> platform vendor implements a CDM using that DRM platform, other consumers of
> that platform must also be able to implement the same CDM.)

The reporter does not cite any technical reason why interoperability would be
enhanced in the presence of such a registry or reduced in the absence of such a
registry. However, given other similar registries, such as the IETF MIME Type
registry, it may useful to consider this suggestion for the simple purpose of
reducing the likelihood of CDM identification conflict (though one might argue
that the current specified use of a reversed domain name already provides
adequate identification conflict). If such a registry is introduced, then it
should support both a public (standard) and private (pre-standard or
non-standard) category of registrations, such as is supported by RFC6838 [1]
(cf. Standards tree with Vendor, Personal, and Unregistered trees).

[1] http://www.rfc-editor.org/rfc/rfc6838.txt

If such a registry is created or promoted, then non-standard (vendor, personal,
unregistered) portions of the registry should not be subjected to any greater
documentation or interoperability requirements than hold for similar
registrations (of MIME types) in RFC6838.

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

Received on Monday, 11 February 2013 09:15:10 UTC