14:58:32 <RRSAgent> RRSAgent has joined #html-media
14:58:32 <RRSAgent> logging to http://www.w3.org/2014/09/23-html-media-irc
14:58:34 <trackbot> RRSAgent, make logs public
14:58:34 <Zakim> Zakim has joined #html-media
14:58:36 <trackbot> Zakim, this will be 63342
14:58:36 <Zakim> ok, trackbot; I see HTML_WG()11:00AM scheduled to start in 2 minutes
14:58:37 <trackbot> Meeting: HTML Media Task Force Teleconference
14:58:37 <trackbot> Date: 23 September 2014
14:58:47 <paulc> zakim, this is HTML_WG
14:58:47 <Zakim> ok, paulc; that matches HTML_WG()11:00AM
14:59:21 <paulc> Agenda: http://lists.w3.org/Archives/Public/public-html-media/2014Sep/0017.html
14:59:27 <paulc> zakim, what is the code?
14:59:27 <Zakim> the conference code is 63342 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), paulc
14:59:29 <Zakim> + +1.215.286.aaaa
14:59:55 <joesteele> joesteele has joined #html-media
15:00:02 <Zakim> +[Microsoft]
15:00:08 <paulc> zakim, [Microsoft] is me
15:00:08 <Zakim> +paulc; got it
15:00:16 <paulc> zakim, who is on the phone?
15:00:16 <Zakim> On the phone I see jdsmith, +1.215.286.aaaa, paulc
15:00:27 <joesteele> Zakim, aaaa is me
15:00:27 <Zakim> +joesteele; got it
15:00:43 <paulc> Agenda: http://lists.w3.org/Archives/Public/public-html-media/2014Sep/0017.html
15:00:44 <joesteele> scribe: joesteele
15:00:51 <joesteele> chair: paulc
15:01:30 <davide> davide has joined #html-media
15:01:58 <ddorwin> ddorwin has joined #html-media
15:02:02 <markw> markw has joined #html-media
15:02:40 <Zakim> +davide
15:03:02 <Zakim> +markw
15:03:14 <Zakim> +ddorwin
15:03:52 <paulc> zakim, who is on the phone?
15:03:52 <Zakim> On the phone I see jdsmith, joesteele, paulc, davide, markw, ddorwin
15:04:02 <joesteele> Topic: role call
15:04:10 <joesteele> Topic: agenda
15:04:16 <paulc> rrsagent, generate the minutes
15:04:16 <RRSAgent> I have made the request to generate http://www.w3.org/2014/09/23-html-media-minutes.html paulc
15:04:49 <paulc> Agenda: http://lists.w3.org/Archives/Public/public-html-media/2014Sep/0017.html
15:04:53 <joesteele> topic: Eme status and bugs
15:05:52 <paulc>  Bugs: http://tinyurl.com/7tfambo
15:06:00 <joesteele> paulc: looks like 18-19 bugs
15:06:13 <joesteele> ... any recent changes from the editors?
15:06:32 <paulc> Current editor's draft: https://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html
15:06:38 <joesteele> ddorwin: recent edit was just a fix for the events that were not split up
15:07:04 <joesteele> topic: Bug 26776 - Diagnosing and resolving CDM errors needs a numeric systemCode (deleted with MediaKeyError)
15:07:29 <paulc> Bug 26776 - Diagnosing and resolving CDM errors needs a numeric systemCode (deleted with MediaKeyError)
15:07:51 <joesteele> paulc: Mark asked some questions in comment 5 -- thnk they were answered in comment 6
15:07:57 <joesteele> s/thnk/think/
15:08:09 <joesteele> paulc: Mark did you get what you needed?
15:08:36 <joesteele> markw: think so, i f I understand what they are saying
15:08:45 <paulc> latest question is in: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26776#c7
15:08:47 <joesteele> ... implies that anything like DOMEception might not be a good match though
15:09:08 <joesteele> paulc: any other opinions on this? here or in the bug would work
15:09:37 <joesteele> jdsmith: I have been meaning to make a proposal, will try to summarize with a proposal going forward
15:09:50 <joesteele> topic: Bug 26811 - Separate definitions of Initialization Data Types from Stream Format parsing
15:10:06 <joesteele> paulc: spun off from 26738
15:10:08 <paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=26811
15:10:54 <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.
15:10:59 <joesteele> ddorwin: this is just a separation of the registry, on the back burner now as it does not affect the main spec
15:11:16 <joesteele> paulc: so this is lower priority
15:11:36 <joesteele> topic: Bug 26887 (new from Jerry)
15:11:43 <paulc> http://lists.w3.org/Archives/Public/public-html-media/2014Sep/0019.html
15:12:29 <paulc> Very recent response from Mark: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26887#c1
15:12:30 <joesteele> 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
15:13:00 <joesteele> ... 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
15:13:04 <ddorwin> q+ to clarify whether this bug is specifically about Netflix' secure proof of key release or (also) something else (i.e. offline in general)?
15:13:13 <joesteele> ... session type for us does not make sense, reloading does not make sense
15:13:35 <joesteele> ... temporary licenses would still be compatible with secure release, does not fit the model today
15:14:07 <joesteele> ... we have been working on a proposal for the app to query that data about secure release information not yet complete
15:14:32 <joesteele> ... problem it raises is that between that model and the app-centric model have not come up with a common abstraction yet
15:14:46 <joesteele> ... have a draft proposal that discusses enumerating but have not posted yet
15:15:02 <joesteele> paulc: I put a link to marks coments
15:15:04 <paulc> ack dd
15:15:04 <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)?
15:15:05 <markw> q+
15:15:10 <joesteele> ddorwin: my comments are also in the queue
15:15:35 <joesteele> ... is this specifically about the Netflix secure proof of key release case? or something else?
15:15:54 <joesteele> jdsmith: there are similar issues with offline playback, but tried to focus on the secure key release
15:16:14 <joesteele> ... we would prefer the keys to just be re-used automatically
15:16:32 <joesteele> ddorwin: have discussed many times on many threads but have not come up with a better proposal
15:16:56 <joesteele> ... persistent sessions are not the same as persistent licenses -- Mark has cleaned up that text
15:17:08 <joesteele> ... some ambiguity maybe still needs to be addressed
15:17:09 <paulc> ack markw
15:17:12 <joesteele> q+
15:17:28 <joesteele> Markw: don't see a problem with a superset of the two models
15:17:46 <joesteele> ... clear that license server gets to approve any persistence, also approves any expected key release
15:17:59 <joesteele> ...question is how much can the application exercise control
15:18:08 <joesteele> s/...question/... question/
15:18:23 <joesteele> markw: we also need some concept of the group of keys that have been installed
15:18:41 <joesteele> ... need to be able to associate the original session with the group of keys
15:19:23 <joesteele> ... can't be entirely be opaque -- the application needs to know that this is a key release related to that earlier session
15:19:27 <ddorwin> q+ 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). Basically, what Mark said I believe.
15:19:47 <paulc> ack joe
15:20:13 <markw> s/associate the original session with the group of keys/associate the original session with the key release messages/
15:20:15 <paulc> Joe: I agree with Jerry's bug that we have had problems with loading persistent keys
15:20:29 <paulc> ... it is possible to do but ungaimly
15:21:00 <paulc> ... We expect that keys will be discovered automatically and don't expect the app to know what keys need for a particular content
15:21:10 <joesteele> s/ungaimly/ungainly/
15:21:24 <paulc> ... the current model seems to imply the app needs this information BUT it is does not say it explicitly
15:21:51 <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.
15:21:55 <paulc> ack dd
15:21:55 <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).
15:21:59 <Zakim> ... Basically, what Mark said I believe.
15:21:59 <joesteele> ddorwin: pasting my comments ...
15:22:03 <ddorwin> As with all other web APIs, the application must be in control. What Joe said is by design.
15:22:19 <ddorwin> The current text is designed to provide the app control while allowing the license to specify the exact details (for robustness reasons).
15:22:44 <ddorwin> I think htis is what Mark described.
15:22:45 <ddorwin> The important thing is that the application knows what will happen and the behavior is consistent across implementations.
15:22:48 <joesteele> ddorwin: what Mark described is in the spec
15:23:24 <joesteele> ... it is intentional that the license cannot tell you to store things when you did not request a persistent license
15:23:33 <joesteele> ... the important thing is that the application is in control
15:23:41 <markw> q+
15:23:44 <joesteele> ... consistent with other web APIs
15:23:44 <ddorwin> s/htis/this/
15:23:47 <jdsmith> q+
15:24:04 <joesteele> ... don't think some things should just be loaded
15:24:05 <paulc> ack markw
15:24:17 <joesteele> markw: if we did remove loadSession --
15:24:48 <joesteele> ... if it was made clear that reloading was happening when createSession reloaded a perisstent license, would that meet your need for application control?
15:24:51 <joesteele> ... if not why?
15:25:50 <joesteele> 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
15:26:05 <joesteele> markw: is that ambiuguity ok from the point of loading?
15:26:23 <joesteele> ... maybe still have something explicitly for key release
15:26:33 <joesteele> ddorwin: would need to store the iniData in your app for key release?
15:26:34 <joesteele> q+
15:26:54 <joesteele> ddorwin: offline pinning case would be similar  -- you would have two models
15:27:15 <joesteele> ... would like to hear from Joe and Jerry what specific use cases we would want to use initData in
15:27:59 <joesteele> jdsmith: I focused the bug on the secure release, but the offline playback case -- a transaction happens
15:28:27 <joesteele> ... where a persistent license is issued, we would recognize that it is persistent whether or not the app recognized it
15:28:42 <joesteele> ...  the server would drive the storage
15:28:54 <joesteele> ... they were issued and the service directed the client to store them
15:29:20 <joesteele> ... they should be reusable in the easiest manner possible, would be positive that in session startup they are discovered and reused
15:29:43 <joesteele> ... don't understand marks comment about the key release obligation
15:30:53 <ddorwin> How does the application manage the license? For example, to unpin?
15:30:53 <joesteele> ddorwin: my understanding is that in jerrys model the licenses are persisted and used, but how does the application manage the license?
15:31:35 <joesteele> jdsmith: that is part of the CDM awareness of the persistent licenses stored - would like to see a specific API for enumerating and removing
15:31:40 <markw> q+
15:31:50 <paulc> ack jd
15:31:50 <joesteele> ddorwin: I would be interested in seeing that
15:32:33 <paulc> Joe: From the use cases perspective, I would like to see the InitData retained in two cases:
15:32:59 <paulc> a) if the app wants to release keys it would be useful for the apps to have the InitData
15:33:44 <paulc> b) in line with what Jerry said, when you acquire keys then you would provide the InitData
15:33:46 <Zakim> -ddorwin
15:34:15 <paulc> ... The CDN should be able to find the keys from the supplied InitData
15:34:31 <Zakim> +ddorwin
15:34:44 <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)
15:35:03 <Zakim> -ddorwin
15:35:18 <paulc> ... The app may not want to cache a persistent key so the CDN should not always assume this is being done
15:35:28 <Zakim> + +1.425.605.aabb
15:35:36 <ddorwin> zakim, aabb is me
15:35:36 <Zakim> +ddorwin; got it
15:35:52 <paulc> ack mark
15:36:05 <joesteele> markw: re: Jerrys question about associated information with the keys
15:36:35 <joesteele> ... we associated some information with the session the keys were originally requested in -- we need to maintain that association when the keys are released
15:37:00 <joesteele> ... needs to be some notion of a group of keys which needs to be associated with that original session data
15:37:02 <jdsmith> q+
15:37:11 <joesteele> ack joesteele
15:37:11 <paulc> ack joe
15:37:31 <paulc> ack jd
15:37:46 <joesteele> jdsmith: re: Joe's comment about app having control
15:38:09 <joesteele> ... in our view the app participates in determining what type of license gets issued, but not necessarily getting stored
15:38:31 <joesteele> ... something like a buy/purchase that aligns the license type with the session type
15:38:58 <joesteele> ... 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
15:39:32 <joesteele> ... re: marks comment -- we have retained the idea that the app would retain the information that the information that the license were removed using
15:39:51 <ddorwin> q+
15:39:58 <paulc> ack dd
15:40:04 <joesteele> markw: that would work
15:40:09 <joesteele> ddorwin: pasting --
15:40:14 <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.
15:40:29 <joesteele> ... this is an example of the app not needing to be in control or not needing to be persistent
15:40:38 <joesteele> ... unexpected licenses on the client is a real concern
15:40:50 <markw> markw has joined #html-media
15:40:56 <joesteele> ... especially when app and server teams are different
15:41:11 <joesteele> paulc: spent 30min on this -- should we continue or move on?
15:41:32 <joesteele> ... any recommendations on which item we could go to next?
15:41:49 <joesteele> ... security bugs or new bug from David?
15:42:11 <ddorwin> I will send emails on bug 25923 and bug 26372 this week. Please provide feedback and suggestions
15:42:16 <joesteele> topic: Bug 26838
15:42:38 <joesteele> jdsmith: on last bug -- referred to a proposal we are drafting -- will post it
15:42:43 <paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=26838#c2
15:43:11 <joesteele> paulc: comment 2 had some pointers to changes made
15:43:28 <joesteele> ... Joe responded with questions this morning
15:43:34 <paulc> Joe's questions in https://www.w3.org/Bugs/Public/show_bug.cgi?id=26838#c3
15:43:54 <joesteele> ddorwin: I was aware of the things you mentioned -- Joe's format cannot be validated or pre-parsed
15:44:04 <joesteele> ... that is why there are SHOULDs in that text
15:44:18 <joesteele> ... can he tell us why it is encrypted?
15:44:46 <paulc> Joe: In our case the only thing that is encrypted is the keys
15:44:58 <paulc> ... The context is that metadata can be delivered separate
15:45:18 <paulc> ... The metadata can be provided in a manifest separately
15:45:43 <paulc> ... The policies in the metadata may be confidential and therefore some customers want it encrypted
15:45:58 <paulc> ... David:  Why shouldn't the customer see the policy?
15:46:16 <paulc> ... No it is hide the metadata in transit.
15:46:34 <paulc> David: Maybe HTTPS would be a better solution for transfering the manifest
15:46:46 <paulc> Joe: My concern is more about the signature
15:46:56 <paulc> David: That is why there is an AND/OR in the text.
15:47:42 <paulc> Joe: My first concern about the proprietary nature of the PSSH - you may need need an NDA to get the format
15:48:11 <paulc> ... it might be hard to implement in an OSS browser if the code exposes the proprietary format of the PSSH
15:48:22 <paulc> Joe: The Initidata can be under NDA as well
15:48:54 <paulc> ... it is relatively recent (4-5 years) that solutions to private InitData are provided
15:49:05 <paulc> ... older CDN's likely have these private formats
15:49:26 <ddorwin> s/CDN's/CDMs/
15:50:20 <paulc> Joe; i will go back and review it with this input
15:50:55 <paulc> ... My concern is that making it a SHOULD may make it not applicable to Adobe and MSFT - not sure about Google
15:51:11 <paulc> David: These could be useful hints to the implementer
15:51:36 <paulc> Joe: Having a hint to an implementer is okay
15:51:50 <paulc> ... I will add my concern but I am not blocking the solution moving forward
15:52:04 <joesteele> paulc: going back to the agenda
15:52:26 <joesteele> ... Joe appealed for more discussion on the HTTPS issue -- more came in
15:52:32 <joesteele> ... be aware of the TAG comments
15:52:57 <joesteele> Topic: Bug 26738
15:53:00 <paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=26738
15:53:13 <paulc> Paul: I think we have dealt with the Patent Policy question and can now return to the original technical request.
15:53:57 <joesteele> ... extending it to covers MPEG2 Commoon encryption is ok as long as that does not imply it is mandatory
15:54:11 <joesteele> ... should restate any objections so that folks who care can provide feedback
15:54:30 <joesteele> ddorwin: someone needs to writeup how this information is extracted
15:54:49 <joesteele> paulc: ask the TF for that -- maybe Bob will respond as he has been active
15:55:33 <joesteele> paulc: any particular bugs we should move on?
15:55:47 <joesteele> ddorwin: title of A has changed to reflct what we have been talking about
15:55:48 <ddorwin> I will send emails on bug 25923 and bug 26372 this week. Please provide feedback and suggestions
15:55:59 <paulc> Title of 26738 is now Add entry for MPEG-2 TS CENC to the Stream Format Registry
15:56:05 <joesteele> ...  trying to get clarification on Object.observe
15:56:25 <joesteele> ... there is agreement we want to address just trying to figure out how
15:56:39 <joesteele> ... please comment on those bugs
15:57:07 <joesteele> paulc: 24771 is an old bug -- you said you will make the change after the re-org -- is this in your pending queue?
15:57:19 <joesteele> ddorwin: yes, trying to get the design issues out of the way first
15:57:20 <paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=24771#c5 is behind other large design issues.
15:57:28 <joesteele> paulc: one last item
15:57:40 <joesteele> topic: HTML F2F meeting October 30-31
15:57:53 <joesteele> paulc: Think Media TF will meet during TPAC week
15:58:15 <joesteele> ... don't expect confirmation now -- will start a thread to collect opinions and for how long
15:58:48 <joesteele> ... if you are planning to stay at the conference hotel, block booking is released on Oct 3rd
15:58:55 <joesteele> ... any comments?
15:59:22 <joesteele> paulc: I will start a thread to discus next week
15:59:26 <joesteele> I would attend
15:59:36 <paulc> rrsagent, generate the minutes
15:59:36 <RRSAgent> I have made the request to generate http://www.w3.org/2014/09/23-html-media-minutes.html paulc
15:59:56 <Zakim> -davide
15:59:57 <Zakim> -joesteele
15:59:58 <Zakim> -ddorwin
16:00:00 <Zakim> -jdsmith
16:00:11 <Zakim> -markw
16:00:39 <joesteele> s/i f I /if i /
16:00:48 <joesteele> rrsagent: generate minutes
16:00:48 <RRSAgent> I have made the request to generate http://www.w3.org/2014/09/23-html-media-minutes.html joesteele
16:01:38 <davide> davide has left #html-media
16:01:51 <joesteele> Zakim, bye
16:01:51 <Zakim> leaving.  As of this point the attendees were jdsmith, +1.215.286.aaaa, paulc, joesteele, davide, markw, ddorwin, +1.425.605.aabb
16:01:51 <Zakim> Zakim has left #html-media
16:02:01 <joesteele> rrsagent: generate minutes
16:02:01 <RRSAgent> I have made the request to generate http://www.w3.org/2014/09/23-html-media-minutes.html joesteele
16:02:07 <joesteele> rrsagent: bye
16:02:07 <RRSAgent> I see no action items