RE: CfC: to publish two revised heartbeat Working Drafts

Paul Cotton wrote:
>
> This is a Call for Consensus (CfC) to the Media Task Force to publish as a
> heartbeat Working Draft the following “Encrypted Media Extensions”
> specification:
>
>       https://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/
> encrypted-media-wd.html
>
> Silence will be taken to mean there is no objection, but positive
responses
> are encouraged.

I support the publication of this heartbeat Working Draft.



*************
Meanwhile,

Fred Andrews wrote:
>
> The director of the W3C has still not responded to the objections raised
> to the EME and thus I believe it is completely inappropriate to be
publicly
> advancing this version of the EME specification.

I believe you need to do some fact-checking. 

In February 2013, Philippe Le Hegaret wrote:

"...the HTML Chairs asked the W3C Team to provide clarifications, which I
provide below. - The HTML Working Group is chartered to provide "APIs for
the
manipulation of linked media" [2]. As such, API extensions to the
HTMLMediaElement interface are in scope for the HTML Working
Group. This includes work items like the Media Source Extensions,
already published as a First Public Working Group, or the Encrypted
Media Extensions."

That note was signed
Philippe,
for the W3C Team
(which includes the Director, Tim Berners-Lee)
http://lists.w3.org/Archives/Public/public-html-admin/2013Feb/0122.html 

Thus the Director did in fact rule work on EME in-scope for this working
group, and any Formal Objection lodged against any Recommendation work at
the W3C is and will be addressed by the Director later in the approval
timeline (per W3C Process -
http://www.w3.org/2005/10/Process-20051014/policies#WGArchiveMinorityViews).
Since this is a call for a heartbeat publication, now is not that time. 

>
> It is certainly not the wishes of the vast majority of the open web
> community,

According to whom? While it is clear that some vocal members of the Open
Software community have objections, it is less clear whether their
objections are "the majority" or rather the very loud protestations by a
small but vocal minority. I certainly welcome proof of your assertion
however: data, numbers, how those numbers were compiled, etc. It is easy to
wave your hand and say "the vast majority" - I say prove it.


> nor the work of the open web community, and attempting
> to pass it off as such will cause signification damage.

To whom? And can you please provide a detailed explanation as to what kind
of damage you are concerned about? "Bad things" is hardly a technical
description that can be addressed in a technical specification.

>From my perspective, all of the work around EME has been open, public and
transparent, even if at its core it involves, as part of its deliverable, a
potential (non-mandatory) closed security box.  However, the EME API is and
remains an open piece of the larger web platform. It is also worth repeating
(again!) that this proposed non-proprietary API would work equally well with
proprietary CDMs as with non-proprietary content protection schemes that
could be implemented in and by open source software.
 

>
> Please withdraw the publication of the specification immediately to
> avoid causing irreparable damage to the open web community.

What damage is being caused? It strikes me that the only real potential
damage being caused is by a small and vocal group of critics who refuse to
accept the business requirements that EME is seeking to address. In their
zealous attempts to enforce *their* limited vision of how the web should be,
they are, by their very actions, attempting to further fracture the web
ecosystem by driving away legitimate business participants, forcing them to
create, (what?) a forked version of HTML? The "Open Web Zealots" version and
the "Real World" version? It is as much you and yours sir that is causing
damage, by seeking to  refuse to allow legitimate participants to also be
part of the web, simply because they do not share the same business model as
you. 


>
> This select and narrow group is welcome to do as it wish in the back
> rooms, but this work should not be surfacing here.

Why yes, back-room forking of the web is so much preferable than having an
open, common (if imperfect) version of the web! How silly of us all. Bring
on the Warner-Web, and the SonyPictures-Web, and the Microsoft-Web, and the
Adobe-Web, and the EFF-Web, and the Netflix-Web, and the Google-Web, and the
BBC-Web, and the TurnerBroadcasting-Web - that will be so much more "open"
and useful won't it?


>
> Paul, a Chair of the HTML grouping group should know better.  You do
> not have the confidence of the open web community.  Could you please
> resign and move on.

I'm not sure how one qualifies to a member of "the open web community", but
as a member of the free web community I personally have a lot of confidence
in the W3C, and specifically in Mr. Cotton, who has proven to me numerous
times his steady hand, fair and balanced approach, and flawless diplomatic
handling of personal attacks against himself and other members of the HTML
WG Chairs.  Perhaps it is you Mr. Andrews who should move along, as you are
not providing any technical feedback here, but instead nothing but personal
opinion and stale hyperbole that has been well tread in the past.

>
> cheers,
> Fred

Nothing cheery about your attack Fred. Your (and others') constant repeating
of your concerns is doing nothing to advance the work of the W3C. The W3C
has repeatedly asked for alternatives to the current API work that would
address both your concerns and the business requirements of those behind the
EME work. We've heard plenty of moaning and complaining, but little in the
way of real alternative proposals.  Jamming the W3C mailing lists with
emails ripe with indignation, decrying the evils of Content Protection and
the "harm" to the open web is not engineering, it is sloganeering and has no
place here.

JF

Received on Wednesday, 25 September 2013 00:33:27 UTC