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

I told Glenn I'd follow up his comment
https://www.w3.org/Bugs/Public/show_bug.cgi?id=20944#c2 on this list.

Glenn Adams wrote:

> (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.
>

"Interop" is short for "interoperabilty" and the Wikipedia definition is
pretty good.

By "interop at the CDM level" I mean the degree to which CDM support is
uniform across user-agents, by which I mean both that each CDM should be
supported in as many user-agents as possible, and each CDM should work in
exactly the same way across user-agents. (There is probably also something
to say about the content production side, but I know less about that.)

> 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.
>

You have made a straw-man argument. The EME draft is neutral on the issue
of CDM interop, and that is the problem.

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.
>

We discussed these cases on the list. You've ignored that discussion and
just repeated your claims here.

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.
>

You seem to be objecting to the idea that a specification with extension
points can require those extensions to be subject to some form of
standardization. In previous email I provided evidence that this is common
practice.

I agree that W3C specs usually haven't been explicit about it, but I think
we as a community have assumed extensions that aren't standardized are a
problem.

Going to back to your list, at the risk of repeating earlier discussion:
-- geo-location devices and IMEs are irrelevant to interop because they
don't affect what "goes over the wire". It simply doesn't matter to any
party but the user-agent how a particular input string or geo-location was
determined.
-- if a UA vendor supports a media format, font format or canvas context
that is not standardized and not on any path to standardization, then we
have a problem. The size of the problem depends on how aggressively the
vendor is promoting that feature and how much adoption it has received (or
will receive).

> 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.


How about this one?
http://www.w3.org/Consortium/mission.html
"Web For All: The social value of the Web is that it enables human
communication, commerce, and opportunities to share knowledge. One of W3C's
primary goals is to make these benefits available to all people, whatever
their hardware, software, ..."
"Web on Everything: The number of different kinds of devices that can
access the Web has grown immensely. Mobile phones, smart phones, personal
digital assistants, interactive television systems, voice response systems,
kiosks and even certain domestic appliances can all access the Web."

Restricting content to a particular UA runs counter to those goals.

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).
>

Following the W3C Process is not enough to ensure that the W3C's goals are
met. Creative decision-making will always be required.

> 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).


That is not the goal of this registry. I agree that the goal of avoiding ID
conflict doesn't justify a registry.

I described some interoperability benefits of part 1 here:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=20944#c4
I thought the benefit for part 2 was pretty clear from the parenthetical
remark: part 2 ensures that if a CDM is implemented on top of a DRM
platform, then any UA with an interface to that platform is able to
implement the CDM.

Rob
-- 
Wrfhf pnyyrq gurz gbtrgure naq fnvq, “Lbh xabj gung gur ehyref bs gur
Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl
bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat
lbh zhfg or lbhe freinag, naq jubrire jnagf gb or svefg zhfg or lbhe fynir
— whfg nf gur Fba bs Zna qvq abg pbzr gb or freirq, ohg gb freir, naq gb
tvir uvf yvsr nf n enafbz sbe znal.” [Znggurj 20:25-28]