On Tue, Apr 16, 2013 at 5:40 PM, Mark Watson <watsonm@netflix.com> wrote:
> The server side yes, but the server side is not the subject of this
> specification. It's necessary to implement a Silverlight compiler to
> deliver content to Silverlight, or an H.264 encoded to deliver content to a
> device that only supports H.264, but these things do not mean that <object>
> or <video> are not in scope of the HTML charter.
>
The non standardization of video/audio codecs has historically been
contested leading to today where no single codec can be used across
implementations. The <object> specification is content agnostic and does
not concern itself with specifica of the implementations of either
silverlight or flash, while the HTML-DRM specification does. Regardless a
retirement of the <object> in favor of standardized approaches is lauded
from all sides, even from the providers of such content.
Websockets, HTTP, TLS etc. are specified by the IETF, is it in the charter
of the IETF to specify the HTML-DRM protocol?
> How is the current capabilities of a single device relevant to the status
> of the specification ?
>
Because it is the first use-case, and hurdle, to overcome to measure the
success of the specification. A success criteria which I consider failed
thus far.
> You are more than welcome to propose a DRM solution that is available
> Royalty-Free. Indeed, such a thing would be very welcome. I don't know of
> one. If I did I would certainly propose it.
>
> You can certainly implement EME in a fully RF Open Source way - it just
> might not meet the requirements of all content providers. Similarly, you
> can implement WebGL fully in software, but it won't meet the requirements
> of all content - for that you need proprietary hardware (for performance).
>
So you agree that HTML-DRM is not implementable in a fashion compatible
with the HTML-WG charter, while retaining its usefulness to the usecase it
should satisfy.