Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add ISO Common Encryption 'cbcs' Protection Scheme. Fixes #391. #392

Merged
merged 1 commit into from
Nov 13, 2019
Merged

Add ISO Common Encryption 'cbcs' Protection Scheme. Fixes #391. #392

merged 1 commit into from
Nov 13, 2019

Conversation

hober
Copy link
Member

@hober hober commented May 2, 2017

No description provided.

@hober
Copy link
Member Author

hober commented May 2, 2017

I don't know why the IPR check failed. I am in the HME WG.

@paulbrucecotton
Copy link

The HME WG's charter expired on Apr 30 so until the charter is extended no one is actually a member of the HME WG. ;<)

@plehegar needs to fix this.

/paulc

@plehegar
Copy link
Member

Adding a protection scheme would probably impact the tests, right? If yes, then this seems a late request imho.

@hober
Copy link
Member Author

hober commented May 10, 2017

This change brings the spec more into alignment with shipping implementations. For instance, Safari has supported cbcs since it first shipped EME. The spec should reflect reality here.

@mwatson2
Copy link
Contributor

@hober We weren't able to run the test suite with Safari back last year. Have things changed and Safari is now spec-compliant ?

@jernoble
Copy link

@mwatson2 WebKit is working on improving our compatibility with the test suite. But apart from bringing our DOM APIs up to spec, we have the additional limitation on macOS that our platform only supports the 'cbcs' scheme. Hence our desire to document Safari's shipping behavior.

@plehegar plehegar added this to the VNext milestone Jun 6, 2017
@hober
Copy link
Member Author

hober commented Aug 11, 2017

What's the rationale for deferring this to v.next?

@paulbrucecotton
Copy link

What's the rationale for deferring this to v.next?

EME V1 is done and the Proposed Recommendation is being dealt with by the Director and Advisory Committee. IFF EME becomes a Recommendation the current HME WG charter would only permit us to work on non-breaking changes errata.

/paulc
HME WG Chair

@hober
Copy link
Member Author

hober commented Aug 17, 2017

Fair enough. Any reason to not spin up an Editor's Draft of small changes like this one, so that we can hit the ground running when the way forward is clearer?

@paulbrucecotton
Copy link

Note that this pull request actually proposes changes to the non-normative Encrypted Media Extensions Stream Format Registry which was last published as a WG Note in Sep 2016. I believe this kind of change can be made at any time IFF we can get consensus on the change.

/paulc
HME WG Chair

@joeyparrish
Copy link
Member

Any objections to merging this now? I'll be sending a PR soon for an API change to query encryption scheme support, including 'cbcs', and this seems like a needed compliment to that.

@hober
Copy link
Member Author

hober commented Nov 13, 2019

@joeyparrish I'm all for it.

@joeyparrish
Copy link
Member

I'll go ahead and merge it, then. I may make a few edits on top of that as I work to complete PR #457.

@joeyparrish joeyparrish merged commit 067bf88 into w3c:master Nov 13, 2019
@hober
Copy link
Member Author

hober commented Nov 14, 2019

I'll go ahead and merge it, then.

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants