- From: Vickers, Mark <Mark_Vickers@cable.comcast.com>
- Date: Sat, 21 Apr 2012 16:43:14 +0000
- To: Mark Watson <watsonm@netflix.com>
- Cc: "robert@ocallahan.org" <robert@ocallahan.org>, Paul Cotton <paul.cotton@microsoft.com>, "<public-html@w3.org> (public-html@w3.org)" <public-html@w3.org>
On Apr 20, 2012, at 4:42 PM, Mark Watson wrote: > One approach would be to encourage the DRM vendors to publish their existing APIs. Another would be to work together on a common API which is sufficient to hook up a DRM component to the proposed HTML5 extensions and get multiple DRM vendors to expose that API. This second API would likely be simpler than the existing vendor-specific APIs. And it would be simpler to see how to connect it to the HTML5 extensions. At Netflix we have such an API which we use for integration with a wide variety of systems. I will see if we can publish that. Just for clarification, I've been assuming that a CDM external to a browser could not only be a DRM, but could also be an interface to embedded security, in which case this would be more of an OS API than an add-on software API. Is that the authors' intent? A benefit of embedded systems is that they can be equally available to any web browser on that OS, with no third-party software coordination. It does mean that an external CDM abstraction API would need to account for more than DRMs. > The only thing I am unsure about is how much of the above could/should be done in a W3C context and how much is about companies working together outside W3C ? Agree this is unclear, particularly if this gets into the OS API domain. Thanks, mav
Received on Saturday, 21 April 2012 16:43:50 UTC