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

On Mon, Mar 5, 2012 at 11:16 AM, Mark Watson <watsonm@netflix.com> wrote:
> On Mar 5, 2012, at 10:27 AM, Tab Atkins Jr. wrote:
>> On Mon, Mar 5, 2012 at 9:42 AM, Glenn Adams <glenn@skynav.com> wrote:
>>> On Mon, Mar 5, 2012 at 9:56 AM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>>>> As argued multiple times, it would be a disservice to the web platform
>>>> as a whole to bake closed-source royalty-encumbered technology into
>>>> HTML.
>>>
>>> And who is proposing doing this? Nobody. Nobody is proposing requiring a
>>> specific encumbered CDM just as nobody is proposing a specific encumbered
>>> A/V codec. Please stop making claims that are patently untrue.
>>
>> Sigh.  It's not untrue.  As Mark Watson has admitted, the CDMs that
>> Netflix *actually expects to be able to use* are closed-source and/or
>> royalty-encumbered.  I expect other video distributors to be similar.
>
> There is a difference between a market requirement and a specification requirement. Not least that market requirements can change rather more quickly.
>
> W3C RF rules apply to the specification requirements. We are not proposing to change those rules.
>
> There is very little we can do in W3C that will influence market requirements. There may be much we can do outside W3C, if we work together, to push both market requirements and available technologies towards a happier intersection.

As stated by Henri Sivonen and others before, de facto requirements,
even "temporary" ones, are just as important when evaluating a
proposal as de jure ones.  A spec that does not acknowledge the de
facto requirements it's dealing with is an incomplete spec.

There is currently a de facto requirement that CDMs be closed-source
and/or royalty-encumbered.


>> Unless you have evidence that a sufficiently large marketshare of
>> video distributors are actually planning to use an open-source
>> royalty-free CDM like ClearKey, we must treat the CDM section of the
>> spec as being poisonous.
>
> There is a chicken and egg effect here. If there is no progress on standardization then I don't expect there will be much interest from the content protection vendors in offering a solution.

We don't need the content-protection vendors to offer a solution.  We
need the video distributors to agree that ClearKey or something
similar is sufficient for them to be happy delivering video over
<video>, or even better, to agree that no special mechanism is
required.

(Adding speedbumps like in-the-clear encryption is *acceptable*, but
regretable.  WOFF is an example of this kind of thing.  The WOFF spec,
though, also offered additional benefits alongside its speedbump (in
fact, the speedbump is basically a side-effect of the benefits), and
there's a clear direction for *greater* benefits in the future without
increasing the downsides.)

~TJ

Received on Monday, 5 March 2012 20:01:57 UTC