Re: Encrypted Media proposal (was RE: ISSUE-179: av_param - Chairs Solicit Alternate Proposals or Counter-Proposals)

On Fri, Mar 2, 2012 at 11:12 AM, Glenn Adams <glenn@skynav.com> wrote:
> On Fri, Mar 2, 2012 at 11:59 AM, Tab Atkins Jr. <jackalmage@gmail.com>
> wrote:
>> No.  Again, a working CDM is *required* for this API to be of any use.
>>  If implementing a working CDM is troublesome or impossible for
>> various reasons, that makes the API itself useless.
>
> A no-op CDM is a working CDM. However, I agree that it is obviously the case
> that there is an expectation in producing this proposal that non no-op CDMs
> will be implemented and deployed. In that regard, I agree it is a fair
> question to query the proposers (and others) on whether they have intentions
> to build/deploy real world CDMs, and also that there is an expectation that
> (eventual) implementation reports will include information demonstrating
> that such real world CDMs have been tested. I presume there is such intent,
> but it doesn't hurt to ask. However, I would argue that it is not
> necessarily appropriate to ask (in this forum) for more details of specific
> CDM implementations, such as licensing terms, etc.

You're still wrong.  CDMs aren't floating in the ether to be used by
any who are interested.  If the CDMs that are expected to be used are
restricted in various ways, such as requiring licensing fees, being
closed-source so browsers can't fix security bugs in them, being
restricted to only certain OSes/platforms, etc., that's problematic.

If the CDMs that are expected to be used are unacceptable for the open
web, then the API whose sole purpose is to *communicate* with those
CDMs is useless.

Thus these details are entirely within the scope of this discussion.
Multiple implementors have expressed concern with these details, and
said that they require the details to even start to evaluate the
proposal.  Your attempts to push these details out of this
conversation will not be successful.

~TJ

Received on Friday, 2 March 2012 19:31:54 UTC