HTML Media Task Force Teleconference -- 23 Sep 2014

<trackbot> Date: 23 September 2014

<paulc> Agenda: http://lists.w3.org/Archives/Public/public-html-media/2014Sep/0017.html

<scribe> scribe: joesteele

role call

agenda

<paulc> Agenda: http://lists.w3.org/Archives/Public/public-html-media/2014Sep/0017.html

Eme status and bugs

<paulc> Bugs: http://tinyurl.com/7tfambo

paulc: looks like 18-19 bugs
... any recent changes from the editors?

<paulc> Current editor's draft: https://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html

ddorwin: recent edit was just a fix for the events that were not split up

Bug 26776 - Diagnosing and resolving CDM errors needs a numeric systemCode (deleted with MediaKeyError)

<paulc> Bug 26776 - Diagnosing and resolving CDM errors needs a numeric systemCode (deleted with MediaKeyError)

paulc: Mark asked some questions in comment 5 -- think they were answered in comment 6
... Mark did you get what you needed?

markw: think so, if i understand what they are saying

<paulc> latest question is in: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26776#c7

markw: implies that anything like DOMEception might not be a good match though

paulc: any other opinions on this? here or in the bug would work

jdsmith: I have been meaning to make a proposal, will try to summarize with a proposal going forward

Bug 26811 - Separate definitions of Initialization Data Types from Stream Format parsing

paulc: spun off from 26738

<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=26811

<paulc> Backburner proposal: We should have a table and page for Initialization Data Types and separate pages for stream/container parsing information. Maybe we can use the MIME type as the index for a table pointing to the latter pages.

ddorwin: this is just a separation of the registry, on the back burner now as it does not affect the main spec

paulc: so this is lower priority

Bug 26887 (new from Jerry)

<paulc> http://lists.w3.org/Archives/Public/public-html-media/2014Sep/0019.html

<paulc> Very recent response from Mark: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26887#c1

jdsmith: I want repeat whats in the bug - issue I raised is that we have been trying to make the session load model work for our implementation and it does not work
... our model the license server controls things like this, for secure release we have a condition in the license itself that controls the secure release
... session type for us does not make sense, reloading does not make sense
... temporary licenses would still be compatible with secure release, does not fit the model today
... we have been working on a proposal for the app to query that data about secure release information not yet complete
... problem it raises is that between that model and the app-centric model have not come up with a common abstraction yet
... have a draft proposal that discusses enumerating but have not posted yet

paulc: I put a link to marks coments

<Zakim> ddorwin, you wanted to clarify whether this bug is specifically about Netflix' secure proof of key release or (also) something else (i.e. offline in general)?

ddorwin: my comments are also in the queue
... is this specifically about the Netflix secure proof of key release case? or something else?

jdsmith: there are similar issues with offline playback, but tried to focus on the secure key release
... we would prefer the keys to just be re-used automatically

ddorwin: have discussed many times on many threads but have not come up with a better proposal
... persistent sessions are not the same as persistent licenses -- Mark has cleaned up that text
... some ambiguity maybe still needs to be addressed

Markw: don't see a problem with a superset of the two models
... clear that license server gets to approve any persistence, also approves any expected key release
... question is how much can the application exercise control
... we also need some concept of the group of keys that have been installed
... need to be able to associate the original session with the key release messages
... can't be entirely be opaque -- the application needs to know that this is a key release related to that earlier session

<paulc> Joe: I agree with Jerry's bug that we have had problems with loading persistent keys

<paulc> ... it is possible to do but ungainly

<paulc> ... We expect that keys will be discovered automatically and don't expect the app to know what keys need for a particular content

<paulc> ... the current model seems to imply the app needs this information BUT it is does not say it explicitly

<ddorwin> The current text is designed to provide the app control while allowing the license to specify the exact details (for robustness reasons). Basically, what Mark said I believe.

<Zakim> ddorwin, you wanted to note that the current text is designed to provide the app control while allowing the license to specify the exact details (for robustness reasons).

ddorwin: pasting my comments ...

<ddorwin> As with all other web APIs, the application must be in control. What Joe said is by design.

<ddorwin> The current text is designed to provide the app control while allowing the license to specify the exact details (for robustness reasons).

<ddorwin> I think this is what Mark described.

<ddorwin> The important thing is that the application knows what will happen and the behavior is consistent across implementations.

ddorwin: what Mark described is in the spec
... it is intentional that the license cannot tell you to store things when you did not request a persistent license
... the important thing is that the application is in control
... consistent with other web APIs
... don't think some things should just be loaded

markw: if we did remove loadSession --
... if it was made clear that reloading was happening when createSession reloaded a perisstent license, would that meet your need for application control?
... if not why?

ddorwin: I think generateRequest() would take initiData and then say we loaded it, might be ok from a web api model, but then we have some ambiguity

markw: is that ambiuguity ok from the point of loading?
... maybe still have something explicitly for key release

ddorwin: would need to store the iniData in your app for key release?
... offline pinning case would be similar -- you would have two models
... would like to hear from Joe and Jerry what specific use cases we would want to use initData in

jdsmith: I focused the bug on the secure release, but the offline playback case -- a transaction happens
... where a persistent license is issued, we would recognize that it is persistent whether or not the app recognized it
... the server would drive the storage
... they were issued and the service directed the client to store them
... they should be reusable in the easiest manner possible, would be positive that in session startup they are discovered and reused
... don't understand marks comment about the key release obligation

<ddorwin> How does the application manage the license? For example, to unpin?

ddorwin: my understanding is that in jerrys model the licenses are persisted and used, but how does the application manage the license?

jdsmith: that is part of the CDM awareness of the persistent licenses stored - would like to see a specific API for enumerating and removing

ddorwin: I would be interested in seeing that

<paulc> Joe: From the use cases perspective, I would like to see the InitData retained in two cases:

<paulc> a) if the app wants to release keys it would be useful for the apps to have the InitData

<paulc> b) in line with what Jerry said, when you acquire keys then you would provide the InitData

<paulc> ... The CDN should be able to find the keys from the supplied InitData

<paulc> ... I want the app to be able to say explicitly say if the keys should be persisted (since the user may be on a public computer and the CDN does not know this)

<paulc> ... The app may not want to cache a persistent key so the CDN should not always assume this is being done

markw: re: Jerrys question about associated information with the keys
... we associated some information with the session the keys were originally requested in -- we need to maintain that association when the keys are released
... needs to be some notion of a group of keys which needs to be associated with that original session data

jdsmith: re: Joe's comment about app having control
... in our view the app participates in determining what type of license gets issued, but not necessarily getting stored
... something like a buy/purchase that aligns the license type with the session type
... want to avoid having the app create a session where storage is authorized but the app is not allowed to request that type of license
... re: marks comment -- we have retained the idea that the app would retain the information that the information that the license were removed using

markw: that would work

ddorwin: pasting --

<ddorwin> Counterexample to not needing app control: There have been real problems with PlayReady servers being configured to send persistent licenses (possibly to get some related behavior) and unexpectedly leaving licenses on the client causing problems.

ddorwin: this is an example of the app not needing to be in control or not needing to be persistent
... unexpected licenses on the client is a real concern
... especially when app and server teams are different

paulc: spent 30min on this -- should we continue or move on?
... any recommendations on which item we could go to next?
... security bugs or new bug from David?

<ddorwin> I will send emails on bug 25923 and bug 26372 this week. Please provide feedback and suggestions

Bug 26838

jdsmith: on last bug -- referred to a proposal we are drafting -- will post it

<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=26838#c2

paulc: comment 2 had some pointers to changes made
... Joe responded with questions this morning

<paulc> Joe's questions in https://www.w3.org/Bugs/Public/show_bug.cgi?id=26838#c3

ddorwin: I was aware of the things you mentioned -- Joe's format cannot be validated or pre-parsed
... that is why there are SHOULDs in that text
... can he tell us why it is encrypted?

<paulc> Joe: In our case the only thing that is encrypted is the keys

<paulc> ... The context is that metadata can be delivered separate

<paulc> ... The metadata can be provided in a manifest separately

<paulc> ... The policies in the metadata may be confidential and therefore some customers want it encrypted

<paulc> ... David: Why shouldn't the customer see the policy?

<paulc> ... No it is hide the metadata in transit.

<paulc> David: Maybe HTTPS would be a better solution for transfering the manifest

<paulc> Joe: My concern is more about the signature

<paulc> David: That is why there is an AND/OR in the text.

<paulc> Joe: My first concern about the proprietary nature of the PSSH - you may need need an NDA to get the format

<paulc> ... it might be hard to implement in an OSS browser if the code exposes the proprietary format of the PSSH

<paulc> Joe: The Initidata can be under NDA as well

<paulc> ... it is relatively recent (4-5 years) that solutions to private InitData are provided

<paulc> ... older CDMs likely have these private formats

<paulc> Joe; i will go back and review it with this input

<paulc> ... My concern is that making it a SHOULD may make it not applicable to Adobe and MSFT - not sure about Google

<paulc> David: These could be useful hints to the implementer

<paulc> Joe: Having a hint to an implementer is okay

<paulc> ... I will add my concern but I am not blocking the solution moving forward

paulc: going back to the agenda
... Joe appealed for more discussion on the HTTPS issue -- more came in
... be aware of the TAG comments

Bug 26738

<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=26738

<paulc> Paul: I think we have dealt with the Patent Policy question and can now return to the original technical request.

UNKNOWN_SPEAKER: extending it to covers MPEG2 Commoon encryption is ok as long as that does not imply it is mandatory
... should restate any objections so that folks who care can provide feedback

ddorwin: someone needs to writeup how this information is extracted

paulc: ask the TF for that -- maybe Bob will respond as he has been active
... any particular bugs we should move on?

ddorwin: title of A has changed to reflct what we have been talking about

<ddorwin> I will send emails on bug 25923 and bug 26372 this week. Please provide feedback and suggestions

<paulc> Title of 26738 is now Add entry for MPEG-2 TS CENC to the Stream Format Registry

ddorwin: trying to get clarification on Object.observe
... there is agreement we want to address just trying to figure out how
... please comment on those bugs

paulc: 24771 is an old bug -- you said you will make the change after the re-org -- is this in your pending queue?

ddorwin: yes, trying to get the design issues out of the way first

<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=24771#c5 is behind other large design issues.

paulc: one last item

HTML F2F meeting October 30-31

paulc: Think Media TF will meet during TPAC week
... don't expect confirmation now -- will start a thread to collect opinions and for how long
... if you are planning to stay at the conference hotel, block booking is released on Oct 3rd
... any comments?
... I will start a thread to discus next week

I would attend

rrsagent: generate minutes

- DRAFT -

HTML Media Task Force Teleconference

23 Sep 2014

Attendees

Contents