Proposal to Advance EME to Proposed Recommendation

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.