- From: Jeff Jaffe <jeff@w3.org>
- Date: Sun, 16 Jun 2013 16:34:11 -0400
- To: Henri Sivonen <hsivonen@hsivonen.fi>
- CC: public-restrictedmedia@w3.org, timbl@w3.org
On 6/16/2013 2:41 PM, Henri Sivonen wrote: > On Sun, Jun 16, 2013 at 5:30 AM, Jeff Jaffe <jeff@w3.org> wrote: >> To clarify, the HTML WG Draft Charter neither mentions DRM or EME. All that >> it states is that content protection is in scope for the HTML Working Group. > It's unclear to me what distinction the W3C intends to make between > the terms "content protection" and "DRM". To illustrate the > distinction, could you, please, give an example of something that > constitutes "content protection" for digital content but does not > constitute "DRM"? > I did not press the Director for a specific definition, but I will provide my best interpretation. The Web and TV Interest Group brought in a requirement for "content protection" - a level of protection for premium content that meets their needs. The Director, by declaring "content protection" to be "in scope" has declared that the HTML Working Group should find a solution that meets these requirements and are consistent with W3C policies and practices. I can imagine many potential solutions to content protection, but several of them might fail to either meet the requirements or be consistent with W3C policies. Here are some examples: 1. The Working Group could propose an entire closed DRM solution. Such a solution would be inconsistent with W3C policies. 2. The Working Group could propose a breakable open source DRM solution that relies on social norms and convenience to encourage people not to break the system. Such a solution might be consistent with W3C policies (although one would need to see if it could steer clear of patents), but might be deemed inadequate by the group with the requirement. 3. The Working Group could propose a password based access control system. Such a solution would almost certainly be consistent with W3C policies, but it is unlikely that it would be deemed adequate by the group with the requirement. 4. The Working Group could propose an open framework, including APIs, to have a common means to access non-standard CDMs. This approach (EME) at the moment is getting the most traction in the Working Group. The current draft still has issues raised against it, and has not yet been reviewed by the Director. I'm sure this is not exhaustive, but hopefully it illustrates that there is a non-trivial design space for the Working Group. Jeff
Received on Sunday, 16 June 2013 20:34:18 UTC