RE: CfC: Create Media Task Force

On Tuesday, April 3, 2012 11:58 AM, Paul Cotton wrote:
> ** RESOLUTION: The HTML Working Group shall create a Media Task Force to
> advise on HTML media-related features. **
> 
> If we create this Task Force, any HTML WG member will be free to participate.
> Any interested members of the Web and TV IG must join the HTML WG first
> before being permitted to join this TF.  The Chairs of the HTML WG will
> appoint facilitators. The Task  Force will operate according to the
> principles laid out below:
> 
> HTML WG Media Task Force:
>  1. Any HTML WG member can join the Media Task Force (opt in model).
>  2. Any Web and TV IG [1] member that wants to join the Media TF should first
> join the HTML WG (see item 1).
>  3. Any member of the Media TF MUST be a member of the HTML WG.
>  4. The Media TF will use a separate email list for TF discussions (ie
> public-html-media@w3.org).
>  5. The Media TF may have a separate weekly meeting slot (day and time TBD).
>  6. The Media TF will not make final decisions about its scope, work plan or
> work products. These decisions will be made by HTML WG.
>       Note: The HTML WG might decide at some future point in time to delegate
> more responsibility to the Media TF.
>  7. Facilitator(s) of the Media TF will be selected by the HTML WG chairs.
>  8. The Media TF facilitator(s) will report back to the HTML WG on the work
> of the TF on a regular basis.
>  9. The first task of the Media TF will be to draft its scope and initial
> work plan.  This scope will include work on the Encrypted Media proposal [2]
> in order produce a candidate first public Working Draft.
> 
> If you object to this resolution, please indicate your objection by Tuesday
> April 10 2012. If you object, please give a reason.  If there are no
> objections by the stated date, this resolution will become a Working Group
> Decision by unanimous consent.

Having requested the task force, Microsoft obviously supports its creation. We believe
there are important media features that need to be discussed and developed for enhancing
HTML5 and the Encrypted Media proposal is one of them.

One might compare the Encrypted Media situation to the codec discussions for the media
elements. If we take the approach of not proceeding to develop the Encrypted Media
proposal because we don't know the status of future CDMs then, to me, that's a bit like
saying that we shouldn't have proceeded with specifying the <video> element because
someone might use an encumbered codec. In this case, though, we even have an instance
of a CDM specified with the Clear Key proposal and so we can test the API without
having the situation we have with the media elements today of relying on a number of
formats for tests.

It makes sense for this work to be done in the working group that defines the HTML5
media elements both to ensure alignment between proposals solving different problems.
Following the pattern that started with Accessibility discussions and Testing
discussions, I think creating a task force provides a way for those specifically
interested in these topics to participate in developing solutions without the whole
group having to filter the mail. Since the Task Force would be part of the working
group, eventual decisions about those solutions will be taken as a group.

As far as the Encrypted Media proposal itself, there appears to be substantial
interest from members of the working group in pursuing this topic [1]. Today, this
kind of capability is masked behind the <object> element alongside complete media
stacks. Our goal in making this proposal, working alongside Google and Netflix, was
to provide a common programming model for interacting with Content Decryption Modules
(CDMs) allowing the rest of the HTML5 media stack to be used as it is today. The
proposal includes the Clear Key encryption module but allows further modules to be
added using the same programming model.

There have been questions asked about exactly how those other CDMs will work.
I don't think we know that yet. This is an extension point that will allow
experimentation and innovation. It's a bit like asking how the Canvas getContext()
method will be used. What if people build proprietary context APIs tied to a
particular platform? What if they use license encumbered technology? Well, we'll
consider them when we see the details but at the same time allowing other context
standards to be developed has been useful.

It has been suggested that the W3C should not endorse the Encrypted Media spec
unless there "details of the CDMs that will be used and how any UA can access them."
I can't predict the future and what people might build so I think it is impossible
to satisfy this request. The same goes for other extension points where we can't
predict their use.

Is it possible that further CDMs will be developed that can be standardised in
the W3C or other forums? I think there is that possibility. Might there be a
common binary API that allows different user agents to share CDMs? That's also
possible.

In summary, my view is that the Encrypted Media proposal provides an extensible
model for delivering protected content. Its advantage is that web developers can
use a common programming model for different protections schemes including the
Clear Key approach.


[1] Examples from public-html:
http://lists.w3.org/Archives/Public/public-html/2012Feb/0314.html
http://lists.w3.org/Archives/Public/public-html/2012Feb/0341.html
http://lists.w3.org/Archives/Public/public-html/2012Feb/0369.html
http://lists.w3.org/Archives/Public/public-html/2012Feb/0347.html
http://lists.w3.org/Archives/Public/public-html/2012Feb/0391.html
http://lists.w3.org/Archives/Public/public-html/2012Mar/0181.html

Received on Friday, 13 April 2012 16:01:50 UTC