- From: Maruyama, Shinya <Shinya.Maruyama@jp.sony.com>
- Date: Tue, 11 Mar 2014 02:38:08 +0000
- To: "public-html-media@w3.org" <public-html-media@w3.org>
- Message-ID: <E7496ED336482E459A47A005EAE8161201BE69@JPYOKXMS121.jp.sony.com>
Hi all, I'm concerned about 'persistent' attribute usage mentioned in Bugzilla#24025. https://www.w3.org/Bugs/Public/show_bug.cgi?id=24025#c10 The attribute seems to be very useful to switch at runtime whether to store acquired license by createSession or load stored license by loadSession. I prefer this option rather than CDM deciding it implicitly as current methods assume. (There should be the case where application wants to avoid storing the license no matter whether the license/drm permits to store it. 'persistent' attribute seems to be reasonable to introduce for the reason). In addition to these usages, I wonder if we could use the attribute to determine whether to load stored license in createSession. That is, persistent=true enables createSession to behave like offline first as application cache. Meaning, createSession with persistent=true tries to use cached license first. If there is no available license then it tries to acquire the license from server. In the use-case of loading persistent license, I think the usage of createSession above is better than existing loadSession because of a interoperability problem for loadSession(sessionId). The rules of sessionId generation does not ensure that sessionId is unique across the browsing context. It may cause sessionId collision between current sessionId and a sessionId stored in CDM, which may result in unexpected overriding of sessionId or loading wrong license due to unexpected overriding etc. Unless EME clearly specifies that UA supporting loadSession must take care of such a collision, loadSession may behave in browser dependent way (The description in 1.1.4 "Note: Some use cases may require that Session IDs be unique within the origin over time, including across browsing sessions." may imply the rule but currently this is just a informative). Thanks, Shinya Maruyama
Received on Tuesday, 11 March 2014 15:35:41 UTC