W3C home > Mailing lists > Public > public-html-media@w3.org > October 2016

Re: Proposal to Advance EME to Proposed Recommendation

From: Mark Watson <watsonm@netflix.com>
Date: Fri, 21 Oct 2016 19:15:36 -0700
Message-ID: <CAEnTvdCSV7K5iENeU2i+Wfy-4OAkbc5Un7zeG2o9-R=BHhF7vw@mail.gmail.com>
To: David Dorwin <ddorwin@google.com>
Cc: "Jerry Smith (WPT)" <jdsmith@microsoft.com>, Paul Cotton <Paul.Cotton@microsoft.com>, Matt Wolenetz <wolenetz@google.com>, Jatinder Mann <jmann@microsoft.com>, Adrian Bateman <adrianba@microsoft.com>, "public-html-media@w3.org" <public-html-media@w3.org>

The proposed implementation experience criteria below do not lead to the
conclusion that has been proposed.

If this is the path the group would like to take, I propose we do so based
on implementation experience criteria that includes *at least one compliant
implementation of each feature*, in addition to the criteria proposed by
Microsoft. This would be a lesser relaxation of the standard criteria than
proposed by Microsoft.

Specifically, I do not see how *persistent-license* passes the proposed
criteria but *persistent-usage-record* does not: there is at least equal
implementation and deployment experience in browsers with
*persistent-usage-record* functionality - based on pre-standard APIs - to
*persistent-license*. If we are to include such pre-standard implementation
and deployment experience in our evaluation, as is proposed for
*persistent-license*, we should also do so for *persistent-usage-record*.
Just as '“*Persistent-license”* sessions add requirements for saving,
re-using and destroying licenses', *persistent-usage-record* sessions add
requirements for saving, retrieving and destroying usage information; with
the same APIs and flows.

Point 2 below states "“*Temporary”* sessions are the primary EME session
type that has been broadly tested commercially via user agents and
commercial site implementations." But as the largest user of EME, a large
fraction of our sessions are *persistent-usage-record* ones (again, based
on pre-standard APIs) across three browsers (and at one point four and with
one more in test). The underlying functionality is supported by at least
three different DRMs.

I certainly agree that this kind of experience - with the same
functionality and earlier-specification-version APIs - is relevant to the
questions of implementability and market demand. But it does not - in the
case of either persistent session type - prove out the exact API design we
have now: you need a real implementation for that.

Where we are lacking with *persistent-usage-record* is only in that fully
compliant implementation, now. Since the API for the two persistent
sessions is so similar, it's hard to see a difference on any criteria, but
at least actual compliant implementations is the traditional W3C criteria
and the situation there is clear.


On Fri, Oct 21, 2016 at 4:21 PM, David Dorwin <ddorwin@google.com> wrote:

> We support the path proposed by Microsoft to move forward to Proposed
> Recommendation and remove currently at-risk features. We believe it
> provides a solid base that demonstrates extensibility, such as through
> session types, and unblocks incubation of additional functionality.
> On Fri, Oct 21, 2016 at 11:35 AM, Jerry Smith (WPT) <jdsmith@microsoft.com
> > wrote:
>> At Microsoft, we think the EME specification is ready to transition to
>> Proposed Recommendation status and do not believe reissuing an EME CR with
>> further features “at risk” is necessary. We think the work to develop the
>> EME test suite has been extremely valuable and we will continue to use
>> these tests when updating our Edge EME implementation. The test suite has
>> confirmed where we have features with two passing “independent”
>> “implementations” and also provides good evidence of implementation
>> experience across most of the EME specification. This leads us to believe
>> that we already have sufficient implementation experience
>> <http://www.w3.org/2015/Process-20150901/#implementation-experience> as
>> required by the W3C Process document.
>> Some brief points on our current testing status as of Monday, 10/17:
>> We’ve largely completed a test suite of 306 subtests and currently have 2
>> independent implementations passing all but 68 tests (78% pass rate).  42
>> of these 68 failures (14% of the full test suite) are related to
>> incorrect implementation error handling based on recent specification
>> changes that aligned EME with current error handling norms. These
>> failures really should be considered as implementation bugs and should not
>> block progress of the specification within W3C.  That leaves only 26
>> non-passing tests (a 91% pass rate) as of Monday, and test results will
>> improve with fixes being checked in this week.  In other words, our
>> current test suite results are actually quite good.
>> *Our Proposal:*
>> We would like to adopt a plan that does NOT republish an EME Candidate
>> Recommendation with additional “at risk” features.  To do that, we propose:
>> 1.       EME be considered substantially proven by broad implementation
>> experience in commercial use on sites like Netflix, YouTube and Amazon.
>> This is permitted via the “judgement level” of the “Model CR Exit Criteria
>> (Public Permissive version 3)” referenced in the EME Candidate
>> Recommendation.
>> 2.       The recent experience with the EME test suite supports that the
>> EME spec is implementable, most specifically on “*temporary”* sessions
>> that exercise most core features of the spec.  “*Temporary”* sessions
>> are the primary EME session type that has been broadly tested commercially
>> via user agents and commercial site implementations.
>> 3.       We believe that the “*persistent-license”* sessions feature
>> further builds on the base feature set already proven by experience for “
>> *temporary”* sessions.  “*Persistent-license”* sessions add requirements
>> for saving, re-using and destroying licenses persisted on a client device
>> so that they are available for offline playback (e.g. through web apps).
>> Although we don’t yet have *two* passing independent implementations,
>> the “*persistent-license”* sessions feature is an optional extension to
>> the core EME mechanisms and should be judged to be proven by implementation
>> experience to date including experience from* “temporary”* sessions.
>> 4.       This leaves the “at risk” features already identified in the
>> current EME Candidate Recommendation:  “*persistent-usage-record”*
>> (optional) and “*readyState”* changes when an EME implementation is
>> waiting for a key. We do not need to return to Candidate Recommendation to
>> remove either of these “at risk” features.
>> a.       *“Persistent-usage-record”* passed a lengthy W3C TAG review
>> process but we have substantially agreed as a group that this feature needs
>> additional implementation support to prove it out.  That proof is currently
>> lacking and does not appear likely to be available in the EME V1 timeframe
>> even if we published a new Candidate Recommendation.  If that is true then
>> we believe the “*persistent-usage-record”* feature should be moved out
>> of the EME V1 spec.  Depending on continued interest, it may move to a
>> separate spec for additional development and/or implementation support.
>> b.       The *“readyState”* feature is currently being discussed via
>> several recent Github issues.  It’s unclear currently whether it should be
>> included in EME V1 or not.  We do not believe we should republish a EME CR
>> with just this feature marked “at risk”.
>> A proposed implementation experience criteria consistent with the above
>> is:
>> 1.       Positive *interoperable* *implementation* experience with at
>> least two *independent* browser engines.
>> 2.       Support or commitment to support *compliant implementations* by
>> at least two *independent* browser vendors.
>> 3.       Positive, *but not necessarily fully passing*, results in our
>> test suite by at least one *implementation*.
>> *The Take Home Message:*
>> We want to propose that EME be published as a Proposed Recommendation
>> based on our current level of testing and implementation experience and
>> that we remove the “at risk” *persistent-usage-record* feature and
>> perhaps the *readyState* interaction portions (depending on disposition
>> of the related Github issues).  This would produce a highly interoperable
>> EME V1 Proposed Recommendation and the aspects moved out of it would not be
>> blocked from proceeding in an EME V2 or in a separate specification.
>> We’d like to gain agreement on this proposal within the HME Working Group
>> and then propose it to the W3C Director as an alternate plan for completing
>> the WG’s work on the EME specification.
Received on Saturday, 22 October 2016 02:16:06 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 15:49:17 UTC