W3C home > Mailing lists > Public > public-html-media@w3.org > October 2012

[Bug 17660] Alternate mechanism -- (was Re: Request to add parameters to createSession)

From: Joe Steele <steele@adobe.com>
Date: Tue, 30 Oct 2012 13:15:59 -0700
To: Mark Watson <watsonm@netflix.com>, Martin Soukup <martin.soukup@irdeto.com>, Steven Robertson <strobe@google.com>
CC: "<public-html-media@w3.org>" <public-html-media@w3.org>
Message-ID: <0651A77B-4343-42E1-9FEE-BC53B120D2AA@adobe.com>
Let me start a side thread on this with an alternate proposal.

What if instead of adding a new parameter to createSession to allow for application data to be passed to the CDM, we explicitly allow for the CDM to request data directly from the application via an established URI scheme?

Take this example:
A media source is loaded and the media stack decides it needs a key. The application decides that it wants to use the "com.foo.keysystem" keysystem. It calls createSession, passing the initData from the media stack. The CDM then examines the initData and determines that an in-band authentication needs to occur. The CDM then fires a needkey event setting the destinationURI to be something like "app://com.foo.keysystem?username&password". The app is watching for destinationURIs beginning with "app://" which it then handles directly rather than resulting in an network request. The app parses the URI into the keysystem and the request portions. The app then decides how it wants to respond to the key request and returns the information requested via the addKey method.

This would put some of the burden back on the app developers, in terms of possibly needing to encode multiple pieces of information into the single key parameter. However it would be better than my current proposal in the sense that the app needs to have less information when createSession is called. And I think it would satisfy the concerns about fragmentation since only the CDMs that want this behavior would generate key requests like this. I would prefer codifying the scheme that will trigger app handling of the URI (e.g. "app://" followed by the keysystem) to enforce some level of uniformity and allow for app developers to display reasonable error messages should the CDM do something they are not expecting.

This would address the issue I am concerned about. Would this be an acceptable alternative?

Assuming this is acceptable -- how can we reflect this in the spec?

Joe Steele
Received on Tuesday, 30 October 2012 20:16:37 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:32:57 UTC