V1: Remove the at-risk persistent-usage-record feature and the related MediaKeySession destroyed algorithm, and remove the at risk notation for setting the media element readyState based on key availabity in two algorithms #353
Comments
|
The recommendation to remove the persistent-usage-record feature from EME V1 was discussed at the HME WG meeting on Oct 25. See meeting minutes. |
|
I've self-assigned this bug. My plan is to:
If other changes are needed, please add to this bug with details. I intend to start on a PR for this soon. |
|
I believe the conclusion of the discussion with plh was that we should create the Proposed Recommendation version without this feature, meaning that the ED becomes the ED for a future version. Is that your plan ? |
|
There are also references to record of key usage, the session object's record of key usage, first decryption time, and latest decryption time as well as some specific text and an example in the Clear Key sections. Some instances may not be obvious when implementing in the above plan. |
|
I noted most of these, but do see some record of key usage references that aren't directly associated with a persistent-usage-record instance. I can make sure to remove those as well. @plehegar: Please advise on whether we want to leave this content in the working EME document, and do the at-risk changes in a PR specific copy. |
|
On Tue, Nov 1, 2016 at 4:17 PM, jdsmith3000 [email protected]
|
As Chair, I am okay with that plan as I indicated in my Editors email. But my absolute min-bar is that I need a draft Proposed Recommendation for EME with this feature. |
|
I'm not sure making an "ED for a future version" makes sense before we've figured out the process for such a version. I think the simplest and safest thing to do is to make this change in mainline then revert the To make such a revert as easy as possible, I suggest a two commit approach:
That will allow (1) to be reverted cleanly without adding the at-risk section, especially the part about |
|
So, then, I think we do disagree about the process. The reason we are removing So, since implementations are ongoing, we should not just discard the text. That's why I believe we should create a new branch for the PR. We can also discuss where the work should continue and when we agree on that we can transfer the ED there. But for that we will need an ED to transfer. |
|
There is currently no process for maintaining this repository after the WG charter expires. The only changes we know we can make are those outlined in https://lists.w3.org/Archives/Public/public-hme-editors/2016Oct/0005.html. Thus, we shouldn’t leave the repository (and primary URL, https://w3c.github.io/encrypted-media/) in a state that is unclear. Furthermore, before repurposing the main repository from V1/REC-track, we’d have to decide how to identify it as distinct from V1/REC, and we haven't discussed, let alone reached consensus on (or a charter for), what that would be. With the WG charter coming to an end, we'd also need to update the SotD. The most appropriate and expeditious path is to keep the main repository as V1.
The removed text is not discarded. It is still in the Git history, and with the proposal above, there should be a single commit that can be reverted to restore the text.
I don’t see why we should diverge mainline now or why we need an ED now. As I said, we can always create an ED later from the Git history, and anyone can create a fork of the repository that includes the feature and any future changes. (This model also puts the responsibility for merging on the fork owner rather than requiring the editors and staff to merge every change for V1 between a branch and mainline.) |
I don't think this adequately represents the status of the work. Can you give me any example where a web API that is actively being implemented, with some implementations nearly complete and an earlier version already widely deployed, is only documented in GitHub history ? I'm open to other suggestions, but I think we do need a way to maintain a draft containing the
The GitHub repo does not cease to exist and our ability to make changes there is not revoked. The Charter constrains what we can do on the formal Recommendation track and of course we should not accept new material outside of either a WG Charter of CG Contribution License, but we can still maintain a draft in preparation for moving it to wherever we decide (probably WICG or WAVE CG). |
jdsmith3000
changed the title
|
From the email referenced by @paulbrucecotton, @plehegar recommends this approach:
@mwatson2 clarifies this by asking:
To which @plehegar responds,
@ddorwin: There seems little harm to this approach, and it is largely endorsed by the working group. I think we should accept it and move forward with the edits. |
|
The Working Group’s protocols for handling at-risk items and what the main repo should contain appears to have already been established with MSE. That precedence is that the MSE GitHub repo and https://w3c.github.io/media-source/ both reflect V1 and do not contain the at-risk features removed from V1. The commit messages even reference “revert[ing] it… if we wish to refine the spec and implementation in To avoid spending more cycles making a decision, EME should be consistent with this precedent. This path also ensures that we don’t further delay PR working on and debating new text, such as for the SotD. Meanwhile, there are a variety of options to maintain a version of the spec with the removed text. My recommendation is a fork, whether that be in a WICG repo or (short-term) someplace else. |
|
There are two very different reasons that a "feature-at-risk" might be removed at PR: a feature may turn out to have no implementation interest or it may have implementation interest but simply not have met the criteria for inclusion at the time of publication. In the former case, the material can simply be removed. In the latter case, the draft specification should be maintained for those implementors, somewhere. In the MSE case, the feature-at-risk in the second category had already been moved to WICG. So, EME is in a different situation from MSE. I don't think the "precedent" applies. Again, other suggestions are welcome, but treating |
|
I believe @ddorwin has proposed that we archive the copy of EME w/persistent-usage-record in a fork off of gh-pages, and that we continue to do our edits in gh-pages, like we've been doing. I think that can meet everyone's objectives. |
|
If we agree on this, I can start on a PR now while someone else prepares the fork. We just need to have the archive done before we merge the PR. |
|
Do you mean fork or branch ? If branch, I'd prefer that we keep at least the HTML gh-pages (with a different filename), so that it still has a github.io address. |
|
I meant a fork. A fork would have its own @jdsmith3000, SGTM. Note that we don't need to have the archive complete before the PR since the fork can reference any point in time and may want to include some of the changes as we prepare for PR. I don't expect it to be an issue, but there is no technical reason we'd need to delay the PR draft. |
|
Makes sense to me. Thanks. |
|
A fork is fine, yes. Where should it be ? |
|
@mwatson2, any GitHub account or organization can create a fork. I'm looking into this more and will report back. |
|
MediaKeySession Destroyed is called outside of persistent-usage-record in this text under MediaKeySession:
It's listed at-risk as associated with persistent-usage-record, but appears to be independent. I'm leaving it in for now. |
|
The only remaining potentially actionable step in the MediaKeySession Destroyed algorithm is 3.1:
I guess it doesn't hurt, but it's not that useful either. This is probably similar to step 5.2 in
Neither step normatively defines what "close the session" means, though the latter has a non-normative note. Completely separate from this issue, we might want to add an algorithm for closing the CDM session or copy the note to this algorithm. In this PR, we should collapse step 3 and its substep into the step from |
|
It sounds like I should remove MediaKeySession Destroyed completely and revise the paragraph that calls it now:
|
|
SGTM. There is no cdm variable at that point, so just use "CDM." |
|
Yes, I could ask that the same thing be done for MSE. I'm trying to understand the general approach for parallel incubations of the same spec, and this would apply to both EME and MSE. I think that probably means master tracks upstream, at least initially, and individual features are incubated in branches. (Note, branches can also reference other branches.) I believe the material could be accessed via |
|
Everything in WICG is incubation (by definition), so I see no reason why the master branch of the WICG repo wouldn't just contain the work-in-progress specification, like it does for all other WICG repos. |
|
An important part of incubation is exploring ideas in a lightweight way. Thus, we should enable them to occur independently and not assume they will all happen in master. An alternative mechanism would be to use independent forks, but GitHub doesn't appear to allow that. |
|
What do we do about all the VNEXT issues if we move the content of the spec to another location? |
|
@ddorwin Sure, and people can create branches for exploring new ideas. But our starting point for the master branch should (obviously, I think) be where we left off in this group, there being no indication of lack of developer interest in the |
|
@paulbrucecotton, that's something we should clarify with WICG. We can probably discuss most of them in place. For that are non-trivial feature requests, we actual development could then move to a WICG branch. |
|
So, are we agree we will create a fork wicg ( |
|
Is someone actively looking into this? From: mwatson2 [mailto:[email protected]] So, are we agree we will create a fork wicghttps://github.com/wicg/ (wicg/encrypted-media) ? Who is going to create it and when ? — |
|
I believe we have to request a repository from the WICG chairs. I think we should request EME and MSE at the same time. My WICG contact is busy through next week, but I can work with him on this the following week. I believe we should address #355 before we create that fork anyway. |
|
Still need to remove the list of at-risk features in the SOTD. |
|
This language in the SOTD also seems like it should be removed. When should that happen?
|
|
I assume @plehegar will take care of that as he prepares the spec for PR. |
|
@plehegar, @wolenetz, @ddorwin, @mwatson2, @jdsmith3000: Before forking the MSE and EME repositories the Team and Editors should consider if the MSE V2 and EME V2 specifications should be incubated in the new W3C Media API CG. The CTA GIVE project submitted MSE V2 and EME V2 requirements and some of these were discussed at the TPAC meeting in Sept. I believe the many of the CTA GIVE project members are now joining the W3C Media API CG (which was created after TPAC) and that is where they would like to incubate new features for MSE and EME. Therefore I suggest the Team and Editors should consult with the community before deciding where to fork the MSE and EME repositories. /paulc |
|
I recommend we use WICG for both MSE and EME incubation, and create the spec forks in it. The W3C Media API CG, as I understand it, is being created to provide informative guidance to future W3C media spec efforts. I know incubation in it has been suggested, but see value in maintaining a clear separation between CGs that develop guidelines and the incubation process that inherently leads to at least preliminary normative spec development. The WICG was specifically created to serve that role, and I don’t see a reason it shouldn’t continue to be used for that by us. Jerry From: Paul Cotton [mailto:[email protected]] @plehegarhttps://github.com/plehegar, @wolenetzhttps://github.com/wolenetz, @ddorwinhttps://github.com/ddorwin, @mwatson2https://github.com/mwatson2, @jdsmith3000https://github.com/jdsmith3000: Before forking the MSE and EME repositories the Team and Editors should consider if the MSE V2 and EME V2 specifications should be incubated in the new W3C Media API CGhttps://www.w3.org/community/webmediaapi/. The CTA GIVE project submitted MSE V2 and EME V2 requirements https://www.w3.org/wiki/File:Mse-eme-v2-use-cases-reqs-wave.pdf and some of these were discussed at the TPAC meeting in Sept. I believe the many of the CTA GIVE project members are now joining the W3C Media API CG (which was created after TPAC) and that is where they would like to incubate new features for MSE and EME. Therefore I suggest the Team and Editors should consult with the community before deciding where to fork the MSE and EME repositories. /paulc — |
|
@jdsmith3000's recommendation is fine for me. |
|
Paul, I strongly agree with Jerry that the next versions of EME and MSE should be incubated in the WICG, for three reasons:
Note that this is my opinion and not necessarily the opinion of the Web Media API CG (cc’d) nor CTA WAVE (formerly GIVE). I encourage other WMA CG members to speak for themselves. Thanks, |
|
My only reservation with only doing the next version of MSE and EME in WICG is that it's preventing us from making substantive changes to the v1 if we have the need to. ie, changes of type 3 in the W3C Process: |
|
Philippe, To be clear, my comment was only favoring WICG over WMACG as a CG location for EME & MSE. As far as a WG vs. WICG, I defer to whatever works best with the W3C process and for the browser vendors. Thanks, |
|
I've assumed we will keep the WG responsible for V1, including Type 1, 2 & 3 changes. Type 4 changes (new features) only would be considered VNext and handled in incubation, and I believe that should be done in WICG. @plehegar: How much spec activity do you expect on V1 going forward? |
|
I don't expect a lot of work on V1 going forward but if we do want to allow ourselves to make substantive fixes, we'll keep the wg around. |
https://bugs.webkit.org/show_bug.cgi?id=166012 Reviewed by Xabier Rodriguez-Calvar. Remove the "persistent-usage-record" value from the MediaKeySessionType. This was removed from the spec as an at-risk feature. w3c/encrypted-media#353 No non-imported tests need to be updated. This is still present in the tests imported from the W3C's web-platform-tests repository, but the tests haven't yet been updated upstream. * Modules/encryptedmedia/CDM.cpp: (WebCore::CDM::isPersistentType): * Modules/encryptedmedia/MediaKeySessionType.h: * Modules/encryptedmedia/MediaKeySessionType.idl: git-svn-id: http://svn.webkit.org/repository/webkit/trunk@209983 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=166012 Reviewed by Xabier Rodriguez-Calvar. Remove the "persistent-usage-record" value from the MediaKeySessionType. This was removed from the spec as an at-risk feature. w3c/encrypted-media#353 No non-imported tests need to be updated. This is still present in the tests imported from the W3C's web-platform-tests repository, but the tests haven't yet been updated upstream. * Modules/encryptedmedia/CDM.cpp: (WebCore::CDM::isPersistentType): * Modules/encryptedmedia/MediaKeySessionType.h: * Modules/encryptedmedia/MediaKeySessionType.idl: Canonical link: https://commits.webkit.org/183612@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@209983 268f45cc-cd09-0410-ab3c-d52691b4dbfc
These features are marked at-risk in the July 5, 2016 EME CR document. Based on the criteria applied by the working group for features to remain in the spec:
The text was updated successfully, but these errors were encountered: