- From: Henri Sivonen <hsivonen@iki.fi>
- Date: Mon, 11 Feb 2013 09:41:31 +0200
- To: Philippe Le Hegaret <plh@w3.org>
- Cc: public-html-admin@w3.org, Paul Cotton <Paul.Cotton@microsoft.com>, Maciej Stachowiak <mjs@apple.com>, Sam Ruby <rubys@us.ibm.com>
On Fri, Feb 8, 2013 at 6:10 PM, Philippe Le Hegaret <plh@w3.org> wrote: > This clarification is not a statement of support towards the technical > approach taken in the EME specification or the CfC itself. It isn't quite clear how broad a statement that is. Is the Team taking a position on whether it's appropriate for a W3C specification to rely exclusively on components that cannot be independently interoperably implemented when the specification is used for its intended purpose? (Clear Key does not count, because none of the proponents of EME intend to use Clear Key in production.) It is worth noting that the pluggability of codecs does not set precedent for this question. At the time when the codecs were left pluggable, it was expected that codecs that would not be RF would be plugged into the extension point, but those codecs (H.264 and AAC specifically) were still expected to be independently interoperably implementable, since they were specified without secrets. Is the Team taking a position on whether it's appropriate for a W3C specification to include mandatory parts whose sole purpose is debugging or satisfying the form of the W3C Process? (Again, it appears that none of the proponents of EME intend to use Clear Key in production. No one has stepped up credibly arguing that they themselves would put Clear Key to substantial production use. All suggested production use scenarios for Clear Key have been contrived in the sense that they'd be better addressed by another solution that the proponents of EME we not interested in pursuing [http+aes].) -- Henri Sivonen hsivonen@iki.fi http://hsivonen.iki.fi/
Received on Monday, 11 February 2013 07:41:59 UTC