IRC log of html-media on 2014-09-23

Timestamps are in UTC.

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