Internet Encrypted Media Extensions - Revision history

Fredandw: /* Requirements */

2014-01-27T05:15:18Z

Requirements

← Older revision		Revision as of 05:15, 27 January 2014
Line 39:		Line 39:
	* A user agent should be able to differentiate IEME media content from non-protected content early enough that it can redirect the playing of protected content to an alternative device or application as seamlessly as possible. This might be implemented by a distinct URL extension or mime type.		* A user agent should be able to differentiate IEME media content from non-protected content early enough that it can redirect the playing of protected content to an alternative device or application as seamlessly as possible. This might be implemented by a distinct URL extension or mime type.

	* The web browser support, for redirecting content, must clearly not be part of a DRM system. If it needs to be tagged ~~of distinctly identified~~ then it should not be tagged as protected content but rather as redirected content. It is only expected that general mechanisms for redirecting content will need to be implemented in the browser, and that the media player can stand alone and accept a URL.		* The web browser support, for redirecting content, must clearly not be part of a DRM system. If the link needs to be tagged then it should not be tagged as protected content but rather as redirected content. It is only expected that general mechanisms for redirecting content will need to be implemented in the browser, and that the media player can stand alone and accept a URL, and that no modification of the redirecting web browser could compromise the content protection scheme.

Fredandw: /* Requirements */

2014-01-27T05:11:56Z

Requirements

← Older revision		Revision as of 05:11, 27 January 2014
Line 31:		Line 31:
	* It must be possible to implement a media player conforming to this standard as a non-web applications that does not implement Javascript, DOM APIs, or the EME API.		* It must be possible to implement a media player conforming to this standard as a non-web applications that does not implement Javascript, DOM APIs, or the EME API.

	* The ~~proposal will define the http~~ protocol between the client media player and the server~~, and thus~~ be ~~linked by~~ a ~~http~~ URL.		* The protocol between the client media player and the server must be well defined.

			* Content published conforming to this standard should be playable in a reference player application.

			* The protected content must be linkable via a URL that can be forwarded to the media player.

	* A user agent should be able to differentiate IEME media content from non-protected content early enough that it can redirect the playing of protected content to an alternative device or application as seamlessly as possible. This might be implemented by a distinct URL extension or mime type.		* A user agent should be able to differentiate IEME media content from non-protected content early enough that it can redirect the playing of protected content to an alternative device or application as seamlessly as possible. This might be implemented by a distinct URL extension or mime type.

	* Content published conforming to this standard should be playable in a reference player application.

	* The web browser support, for redirecting content, must clearly not be part of a DRM system. If it needs to be tagged of distinctly identified then it should not be tagged as protected content but rather as redirected content. It is only expected that general mechanisms for redirecting content will need to be implemented in the browser, and that the media player can stand alone and accept a URL.		* The web browser support, for redirecting content, must clearly not be part of a DRM system. If it needs to be tagged of distinctly identified then it should not be tagged as protected content but rather as redirected content. It is only expected that general mechanisms for redirecting content will need to be implemented in the browser, and that the media player can stand alone and accept a URL.

Fredandw: /* Requirements */

2014-01-27T04:59:28Z

Requirements

← Older revision		Revision as of 04:59, 27 January 2014
Line 27:		Line 27:
	== Requirements ==		== Requirements ==

	* It must be possible to implement a media player conforming to this standard using the W3C EME API on a proprietary web browser. A		* It must be possible to implement a media player conforming to this standard using the W3C EME API on a proprietary web browser. A reference player application is expected to be written.
	reference player application is expected to be written.

	* It must be possible to implement a media player conforming to this standard as a non-web applications that does not implement Javascript, DOM APIs, or the EME API.		* It must be possible to implement a media player conforming to this standard as a non-web applications that does not implement Javascript, DOM APIs, or the EME API.

Fredandw: /* Requirements */

2014-01-27T04:58:57Z

Requirements

← Older revision		Revision as of 04:58, 27 January 2014
Line 30:		Line 30:
	reference player application is expected to be written.		reference player application is expected to be written.

	* A media player conforming to this standard ~~must be implementable by~~ non-web applications that do not implement Javascript ~~or the~~ DOM APIs or the EME API.		* It must be possible to implement a media player conforming to this standard as a non-web applications that does not implement Javascript, DOM APIs, or the EME API.

	* The proposal will define the http protocol between the client media player and the server, and thus ~~it might~~ be linked by a http URL.		* The proposal will define the http protocol between the client media player and the server, and thus be linked by a http URL.

	* A user agent should be able to differentiate IEME media content from non-protected content early enough that it can redirect the playing of protected content to an alternative device or application as seamlessly as possible. This might be implemented by a distinct URL extension or mime type.		* A user agent should be able to differentiate IEME media content from non-protected content early enough that it can redirect the playing of protected content to an alternative device or application as seamlessly as possible. This might be implemented by a distinct URL extension or mime type.
Line 38:		Line 38:
	* Content published conforming to this standard should be playable in a reference player application.		* Content published conforming to this standard should be playable in a reference player application.

	* The web browser support, for redirecting content, must clearly not be part of a DRM system. It is only expected that general mechanisms for redirecting content will need to be implemented in the browser, and that the media player can stand alone and accept a URL.		* The web browser support, for redirecting content, must clearly not be part of a DRM system. If it needs to be tagged of distinctly identified then it should not be tagged as protected content but rather as redirected content. It is only expected that general mechanisms for redirecting content will need to be implemented in the browser, and that the media player can stand alone and accept a URL.

Fredandw: Minor revision

2014-01-27T04:53:56Z

Minor revision

← Older revision		Revision as of 04:53, 27 January 2014
Line 7:		Line 7:
	The W3C EME defines a web API to control playback of protected content but leaves it to the web application to link this API to the server. This proposal defines a standard to fill this gap.		The W3C EME defines a web API to control playback of protected content but leaves it to the web application to link this API to the server. This proposal defines a standard to fill this gap.

	This proposal will support web developers publishing protected content without the need to distribute a web application media player. It might only be necessary to ~~publish~~ a ~~distinct~~ URL or mime type.		This proposal will support web developers publishing protected content without the need to distribute a web application media player. It might only be necessary to declare a source URL and a mime type or other attributes.

	It will make it possible to play the protected media content on a lighter weight native media player that does not implemented a general web client and without loss of features. Web developers would keep the web app in the web browser.		It will make it possible to play the protected media content on a lighter weight native media player that does not implemented a general web client and without loss of features. Web developers would keep the web app in the web browser.

	It will create a market for media players, allowing the user to choose a media player that suits their needs, and ~~that support a~~ market ~~for media player developers to meet their needs. This in turn will allow the market to~~ address the security and privacy needs of users.		It will create a market for media players orthogonal to the content owners and distributors, allowing the user to choose a media player that suits their needs, and this market can address some of the security and privacy needs of users.

	Some users need the convenience of viewing protected content on their general purpose computer and are not too concerned about the security and privacy implications of their computer being controlled by publishers. Some users need security and privacy so need to view protected content on separate sand-boxed devices.		Some users need the convenience of viewing protected content on their general purpose computer and are not too concerned about the security and privacy implications of their computer being controlled by publishers. Some users need security and privacy so need to view protected content on separate sand-boxed devices.

	This proposal will allow web browsers built on FOSS stacks, that do not support the playing of protected content, to redirect the playing of ~~such~~ content to alternative devices.		This proposal will allow web browsers built on FOSS stacks, that do not support the playing of protected content, to redirect the playing of protected content to alternative devices.

	~~This proposal~~ will also allow web browser vendors to avoid implementing the EME API while still supporting users needs to view protected content, by redirecting to a separate application~~. This~~ might be relatively seamless on a proprietary stack.		It will also allow web browser vendors to avoid implementing the EME API while still supporting users needs to view protected content, by redirecting to a separate application and this might be relatively seamless on a proprietary stack.

	This standard will be implementable in a proprietary EME capable web browser, but the web developer will not have access to a general web client which will mitigating the anti-competitive impact of having to redirect to a competing web browser. The ~~FOSS~~ browser vendor can distribute their own web player application that closes the competing browser when ~~finish~~ viewing the protected content.		This standard will be implementable in a proprietary EME capable web browser, but the web developer will not have access to a general web client which will mitigating the anti-competitive impact of having to redirect to a competing web browser. The browser vendor can distribute their own web player application that closes the competing browser when finished viewing the protected content.

	Given that this proposal will have wider reach than the EME API, it is expected that the EME API will be relegated to a proprietary standard and need not be part of the open web. The EME API can be deprecated in favor of separate media applications.		Given that this proposal will have wider reach than the EME API, it is expected that the EME API will be relegated to a proprietary standard and need not be part of the open web. The EME API can be deprecated in favor of separate media applications.

	While this proposal promotes the use of DRM content, it is far better for the user than the EME API which is underspecified allowing distributors to lock-in users to use only the distributors media player web application, and the EME API taints the open web with DRM components.		While this proposal promotes the use of DRM content, it is far better for the user than the EME API which is underspecified allowing distributors to lock-in users to use only the distributors media player web application, and the EME API taints the open web with DRM components.


	== Requirements ==		== Requirements ==

Fredandw: A proposal to extend the EME to support operation over the Internet and to add browser support to redirect to IEME media players

2014-01-27T02:23:43Z

A proposal to extend the EME to support operation over the Internet and to add browser support to redirect to IEME media players

New page

Editor: Fred Andrews

== Abstract ==

This proposal extends the W3C Encrypted Media Extension (EME) to support the playing of protected content by Internet clients that are not required to implement a web client.

The W3C EME defines a web API to control playback of protected content but leaves it to the web application to link this API to the server. This proposal defines a standard to fill this gap.

This proposal will support web developers publishing protected content without the need to distribute a web application media player. It might only be necessary to publish a distinct URL or mime type.

It will make it possible to play the protected media content on a lighter weight native media player that does not implemented a general web client and without loss of features. Web developers would keep the web app in the web browser.

It will create a market for media players, allowing the user to choose a media player that suits their needs, and that support a market for media player developers to meet their needs. This in turn will allow the market to address the security and privacy needs of users.

Some users need the convenience of viewing protected content on their general purpose computer and are not too concerned about the security and privacy implications of their computer being controlled by publishers. Some users need security and privacy so need to view protected content on separate sand-boxed devices.

This proposal will allow web browsers built on FOSS stacks, that do not support the playing of protected content, to redirect the playing of such content to alternative devices.

This proposal will also allow web browser vendors to avoid implementing the EME API while still supporting users needs to view protected content, by redirecting to a separate application. This might be relatively seamless on a proprietary stack.

This standard will be implementable in a proprietary EME capable web browser, but the web developer will not have access to a general web client which will mitigating the anti-competitive impact of having to redirect to a competing web browser. The FOSS browser vendor can distribute their own web player application that closes the competing browser when finish viewing the protected content.

Given that this proposal will have wider reach than the EME API, it is expected that the EME API will be relegated to a proprietary standard and need not be part of the open web. The EME API can be deprecated in favor of separate media applications.

While this proposal promotes the use of DRM content, it is far better for the user than the EME API which is underspecified allowing distributors to lock-in users to use only the distributors media player web application, and the EME API taints the open web with DRM components.

== Requirements ==

* It must be possible to implement a media player conforming to this standard using the W3C EME API on a proprietary web browser. A
reference player application is expected to be written.

* A media player conforming to this standard must be implementable by non-web applications that do not implement Javascript or the DOM APIs or the EME API.

* The proposal will define the http protocol between the client media player and the server, and thus it might be linked by a http URL.

* A user agent should be able to differentiate IEME media content from non-protected content early enough that it can redirect the playing of protected content to an alternative device or application as seamlessly as possible. This might be implemented by a distinct URL extension or mime type.

* Content published conforming to this standard should be playable in a reference player application.

* The web browser support, for redirecting content, must clearly not be part of a DRM system. It is only expected that general mechanisms for redirecting content will need to be implemented in the browser, and that the media player can stand alone and accept a URL.