Re: Encrypted Media proposal: Summary of the discussion so far

On Mar 13, 2012, at 2:35 PM, Tab Atkins Jr. wrote:

> On Tue, Mar 13, 2012 at 2:25 PM, Glenn Adams <glenn@skynav.com> wrote:
>> On Tue, Mar 13, 2012 at 3:00 PM, Tab Atkins Jr. <jackalmage@gmail.com>
>> wrote:
>>> On Mon, Mar 12, 2012 at 1:51 PM, Glenn Adams <glenn@skynav.com> wrote:
>>>> On Mon, Mar 12, 2012 at 1:24 PM, Charles Pritchard <chuck@jumis.com>
>>>> wrote:
>>>>> Confirmation that the development of CDM "key systems" is covered by
>>>>> the
>>>>> W3C Patent Policy: should a company decide that they want to create
>>>>> their
>>>>> own CDM, and they do so, they should not face face IP litigation from
>>>>> W3C
>>>>> members. Each existing CDM vendor, who is also a w3c member, would
>>>>> check
>>>>> their patent holdings for relevant IP. A fictional example would be
>>>>> "Encryption of a network video stream and management of a collection of
>>>>> keys
>>>>> for decoding of the data".
>>>> 
>>>> nothing in the proposal requires a specific CDM to be covered by W3C PP;
>>>> nor
>>>> does the W3C PP or PD require this; so you are asking for something that
>>>> is
>>>> out of scope; this is no different from someone defining a canvas
>>>> context
>>>> that is IPR encumbered and publishing its availability via
>>>> canvas.getConext("anEncumberedCanvasContext");
>>> 
>>> Once again, *please* stop attempting to derail conversations about the
>>> badness of CDMs by falsely claiming they are "out of scope".
>> 
>> 
>> We disagree.
>> 
>>> 
>>> CDMs are novel, essential pieces of technology for the API.  There is
>>> *no reasonable argument* for calling them "out of scope".
>> 
>> 
>> Wrong. Other than Clearkey, individual CDMs are not part of what is
>> specified in the proposal.
> 
> And, *once again*, the fact that the CDMs that will *actually be used*
> aren't specified in the spec means the spec is incomplete.  If this
> spec moves forward, I will formally object to this lack as well,
> because it is not possible to implement the spec in practice without
> the CDMs that will actually be used.

You both may be getting confused between 'out of scope of the specification' (and so of the Patent Policy) and 'out of scope of this discussion'.

CDMs, except clearkey, are clearly out of scope of the specification *as currently proposed*, but clearly not out of scope of this discussion.

Understandably, people would like to know more about what CDMs will be available under what terms. I hope that landscape will become clearer as we progress the proposal (it's unrealistic to expect that a priori). Implementation experience is one of the requirements for progress in W3C recommendations, so we can be sure we will know much more about this before we cross those specification process milestones.

Approved W3C specifications exist which describe how to access certain functions but which do not specify an implementation of those functions (the video element being a good example). Tab: you may consider that "incomplete" as well, but others consider it useful to have a common API to functions that will be widely available, even if we're not able to agree on a single RF implementation.

Equally, if your definition of "implement the spec in practice" is "implement enough that the video element can be used by Netflix" - which it seems to be by some of your comments - then all of your arguments apply to the existing HTML5 specification, since at Netflix we use H.264.

Again, we should not be aiming to restrict the web to only those applications based on a purely FOSS stack. The W3C is not in any position to achieve that anyway. Our aim should be to expand the scope of W3C RF specifications to encompass as much of the web as possible.

…Mark
…Mark

> 
> ~TJ
> 
>

Received on Tuesday, 13 March 2012 22:25:47 UTC