Re: Proposal to Advance EME to Proposed Recommendation

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.
>
>
>