W3C home > Mailing lists > Public > public-html-media@w3.org > March 2013

RE: {agenda} HTML WG media telecon 2013-03-26 - EME bugs discussion

From: Fred Andrews <fredandw@live.com>
Date: Wed, 27 Mar 2013 00:43:13 +0000
Message-ID: <BLU156-W37AF13AD4408080B1C1809AAD10@phx.gbl>
To: Philippe Le Hegaret <plh@w3.org>
CC: "public-html-media@w3.org" <public-html-media@w3.org>, "public-restrictedmedia@w3.org" <public-restrictedmedia@w3.org>
> [[
> [...]
> We invite those who are interested in the technical discussions about
> Encrypted Media Extensions to monitor or participate in the HTML Working
> Group, which is open to all.
> [...]
> ]]

I dispute that these discussions are technical in nature and thus
dispute that they were/are appropriate for this forum.

Technical matters would be expected to be resolved on objective
terms, yet the EME specification defines no use cases or
requirements usable as a basis for such objective technical
discussion.   The working group has been very explicit in ruling
the CDM out of scope for technical discussion and has
refused to address a range of issues on this basis.

Let's consider some of the proceedings of this meeting:

"Mark: we already have a mention that the sessionID
may be assigned by the CDM"

If the CDM is out of scope and there are no requirements
based on the operation of the CDM so this discussion
has no objective technical basis here.  It may well have a
technical basis w.r.t the proponents hidden agenda, but
this is not a matter they have chosen to specify here.

"Joe: agreed. I propose that we never pass back the data to the JS layer"

Communication takes two sides, and although the API is one
side the other is the CDM or platform which has no technical
requirements and has been declared out of scope.  Thus
this is not an objective technical discussion here.

I could go on.

Using tactics that falsely attempt to classify the proponents
discussions as sound technical matters and appropriate for
this forum and to have a sound basis for deciding on the
advancement of the specification, and the oppositions
discussions as non-technical matters to be taken elsewhere
and to have no basis for deciding on the advancement of
the specification may not be defensible or constructive.

> The W3C never directed the discussion of EME to the Restricted Media
> Community Group. Again, quoting from the blog:
> [[
> To help crystallize the technical discussions around Encrypted Media and
> DRM, we're opening a new Restricted Media Community Group specifically
> to consider the paired challenges of openness and access-restriction.
> [...] The CG does not intend to develop specifications, although it
> might approach requirements documents from a user perspective.
> ]]

Thank you for the clarification.  Could you please make sure the
the Chairs of the HTML WG understand this point and do not
use their authority to continue to misdirect discussions about
the EME specification to the Restricted Media Community Group.

> The Community Group is intended to have higher level discussion. Those
> discussion could feed back into the HTML Working Group later, ideally
> before EME reaches W3C Recommendation. That doesn't mean the HTML
> Working Group has to stop its work in the meantime however.
> See also
> http://lists.w3.org/Archives/Public/public-html-admin/2013Feb/0122.html

Suggesting that the EME specification be advanced irrespective
of ongoing discussions as to its compatibility with the open
web standard process and other higher level issues would appear
to conflict with the requirement for, or claim of, consensus in
the process.  Further, directing important input elsewhere
and declaring that it 'could feed back into the HTML Working
Group later' would appear to be a failure of process.  Further,
objections raises later in the advancement process carry less
weight so attempting to defer objections would be an attempt
to lessen their weight and a good reasons that this should
not be acceptable conduct.

In summary, if the game is not played fairly and with integrity
then the process failures may well be reason to object to the
advancement of the EME specification.


Received on Wednesday, 27 March 2013 00:43:42 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:32:58 UTC