15:07:38 RRSAgent has joined #html-media
15:07:38 logging to http://www.w3.org/2013/09/10-html-media-irc
15:07:40 RRSAgent, make logs public
15:07:41 Zakim has joined #html-media
15:07:42 Zakim, this will be 63342
15:07:42 ok, trackbot; I see HTML_WG()11:00AM scheduled to start 7 minutes ago
15:07:43 Meeting: HTML Media Task Force Teleconference
15:07:43 Date: 10 September 2013
15:08:10 Zakim, who is on the phone ?
15:08:10 HTML_WG()11:00AM has not yet started, markw
15:08:12 On IRC I see RRSAgent, joesteele, pal, BobLund, ddorwin, davide, markw, PetrPeterka, wseltzer, trackbot
15:09:05 Scribe: joesteele
15:09:25 Agenda: http://lists.w3.org/Archives/Public/public-html-media/2013Sep/0014.html
15:09:30 jdsmith has joined #html-media
15:09:32 Topic: Agenda
15:09:43 Topic: F2F coming up
15:10:06 Yes, I'm going
15:10:08 is anyone going to the F2F
15:10:32 johnsim: not sure whether Adrian is going -- think he is
15:10:46 jerry: believe he is attending
15:11:10 do we have a timeslot scheduled?
15:11:25 jdsmith: believe we have something scheduled for Thursday
15:11:32 ... should figure out what we want to accomplish
15:11:46 ... should take advantage of being together
15:11:55 johnsim: some topics are hard to do over the phone
15:12:01 ... should come up with a list
15:12:19 Zakim,
15:12:19 I don't understand '', joesteele
15:12:27 Zakim, who is call?
15:12:27 I don't understand your question, joesteele.
15:12:33 Zakim, who is on the call?
15:12:33 HTML_WG()11:00AM has not yet started, joesteele
15:12:34 On IRC I see jdsmith, Zakim, RRSAgent, joesteele, pal, BobLund, ddorwin, davide, markw, PetrPeterka, wseltzer, trackbot
15:12:44 zakim, start meeting
15:12:45 I don't understand 'start meeting', joesteele
15:12:59 Zakim, this is html-media
15:12:59 sorry, joesteele, I do not see a conference named 'html-media' in progress or scheduled at this time
15:13:10 zakim, this is media
15:13:10 ok, ddorwin; that matches HTML_WG()11:00AM
15:13:25 Topic: Previous Minutes
15:13:26 http://www.w3.org/2013/09/03-html-media-minutes.html
15:13:42 any objections?
15:13:47 ... any corrections?
15:13:54 ... mark as approved
15:14:16 Topic: Review of Action items and issues
15:14:17 https://www.w3.org/html/wg/media/track/
15:15:10 any information on Adrian's actions?
15:15:19 Adrian is not here
15:15:40 jdsmith: have not heard much -- he has been out for family reasons
15:16:17 johnsim: working on it with David
15:16:32 ddorwin: this is the ISOBMFF data format issue
15:17:08 johnsim: growing consensus that is we are talking about CENC we should just have the concatenated PSSH boxes rather than the generic approach of the entire SINF
15:17:16 ... suggested at the last TPAC
15:17:21 +1
15:17:44 johnsim: my proposal would be to return to the old CENC definition
15:17:53 ... in the section where we talk about formats
15:18:29 ... we could make that normative sections be specific to CENC
15:18:40 we (Adobe) are ok with that position
15:18:59 johnsim: does that resolve my action?
15:19:16 ddorwin: there were some other issues with the text I identified
15:19:35 ... you proposed some revised text, that cleaned up some things but raised other issues
15:19:52 ... we need to decide how/whether other key systems are supported
15:20:08 johnsim: in other words what the initData would be for ClearKey
15:20:17 ddorwin: this was one of the issues
15:20:37 ... could just define a generic one and ClearKey would happen to use that as well
15:20:59 johnsim: a generic PSSH would have a format would be defined in the spec for ClearKey?
15:21:11 ddorwin: that is one issue, there is a list in the bug
15:21:42 johnsim: so the action is to go through the bug issues and highlight the ones that go aways with CENC
15:21:53 ... and propose solutions to the remainders
15:22:15 s/go aways/go away/
15:22:15 ^ correct
15:22:56 Topic: Moving ClearKey into separate spec
15:23:21 ddorwin: is is an issue but has been punting forward -- need impl feedback
15:23:28 ... in every agenda
15:23:37 joesteele: no resolution ye
15:23:46 s/ye /yet/
15:24:07 johnsim: what led us to suggest this?
15:24:17 ddorwin: discussion about a year ago
15:24:29 ... might add extra work, might not be possible
15:24:45 ... my opinion is that we should keep it in
15:25:45 ... links is in the issue (e.g. https://www.w3.org/Bugs/Public/show_bug.cgi?id=21016)
15:25:57 here is the link to the issue -- https://www.w3.org/html/wg/media/track/issues/1
15:26:16 Topic: EME heartbeat
15:26:22 any progress?
15:26:32 I was wrong - 7 months ago.
15:26:44 ... this would be Adrian so no progress
15:27:14 johnsim: no one on the call to address this I think -- need someone saavy in W3C arcana
15:27:34 ddorwin: obligation to update the spec, but not sure what the downside is
15:28:15 johnsim: so what do we need to do to publish the heartbeat?
15:28:56 joesteele: don't believe any specific bugs needed to be in the hearbeat, no specific changes needed, ...
15:29:32 Topic: EME status abd bugs
15:29:46 does anyone have any specific bugs they want o go over?
15:30:17 ddorwin: Adrian had the same-origin bug which I reviewed
15:30:44 ... also opened the ClearKey bug about the key format
15:30:53 Clear Key format bug: https://www.w3.org/bugzilla_public/show_bug.cgi?id=17682
15:30:53 joesteele: why the change here?
15:31:26 ddorwin: some ambiguity about key id, wanted to specify things more
15:31:38 ... will make implementations easier and interoperable
15:32:23 Topic: Revisit Key Error codes
15:32:24 https://www.w3.org/Bugs/Public/show_bug.cgi?id=21798
15:33:22 ddorwin: on me to document - people can continue the discussion in the bug
15:33:48 ... this will spark more discussion
15:34:12 Topic: Define initialization data for ISO-BMFF
15:34:25 https://www.w3.org/Bugs/Public/show_bug.cgi?id=17673
15:34:40 joesteele: john will do more investigation before we close this out
15:34:59 ddorwin: john do you want a new date?
15:36:06 ddorwin: I will change the date to two weeks hence
15:36:56 Topic: Need non-normative security condierations sections
15:36:57 https://www.w3.org/Bugs/Public/show_bug.cgi?id=22909
15:36:58 - +1.425.269.aaaa
15:37:23 ddorwin: Adrian closed the privacy bug
15:37:28 ... 229010
15:37:38 s/229010/22910/
15:37:46 s/two weeks hence/next week/
15:38:25 ddorwin: there is a discrepancy with 20965 the master bug, we should either close 909 or close 910
15:38:41 ... either this was an oversight or there was proposed text for one and not the other
15:38:53 joesteele: should get Adrians feedback on that
15:38:59 markw has joined #html-media
15:39:04 ddorwin: I will update the bug
15:39:35 pal: can we talk about 17615
15:39:39 Topic: Support for different CDM communication models
15:39:47 https://www.w3.org/Bugs/Public/show_bug.cgi?id=17615
15:40:08 + +1.425.269.aacc
15:40:24 PetrPeterka: one model is that DRM as explicit out of band channel, other model is that all comms go through the browser
15:40:26 q+
15:40:37 ... some changes came later to exclude the out-of-band model
15:40:58 ... text in the abstract that explcitly prevents this
15:41:11 s/explcitly/explicitly/
15:41:20 q+
15:41:27 ... supporting both models should not require architectural changes
15:41:41 ... just need to return the right status
15:41:54 ack ddorwin
15:41:59 The original discussion was that the out-of-band mode was *already* supported by HTML5 media elements
15:42:21 s/pal:/PetrPeterka:/
15:42:22 q-
15:42:36 david is saying just what I was going to say
15:42:57 ddorwin: what is the new information that you think changes this?
15:43:10 ... taking out needKey and other makes this not EME anymore
15:43:27 PetrPeterka: goal is to make this interoperable and remove app-specific knowledge
15:43:52 ... eg. MPEG-DASH with CENC could just provide the strea to the DRM and say "handle this - I don't know much"
15:44:14 Interoperable is the key - the two modes are not interoperable. Applications written for one would not be interoperable with the other.
15:44:15 ... application designer has to treat either model in the same way without pushing too much information into the app
15:44:29 s/strea to/stream to/
15:44:41 ddorwin: that is the issue -- application does have to know
15:44:59 PetrPeterka: application could say "take care of the keys" and not have to deal with it
15:45:05 q+
15:45:18 ... in some cases the app would have to be involved, in others the DRM could just handle it
15:45:25 ack mark
15:45:47 markw: is that a realistic scenario? that would imply the app provider has both ends of the system
15:46:07 ... they also have a front-end server which talks to the back end-server ocrreclty
15:46:33 ... distinguishing between front-end DRM server and back-end DRM server
15:46:44 PetrPeterka: why does the application have to make that decision?
15:46:56 s/ocrreclty/correctly/
15:47:44 ... today there are operators that are using multiple DRMs
15:47:54 ... so they would have multiple license servers
15:48:19 markw: the point of EME was to make it simpler for application providers to support multiple DRMs
15:48:41 PetrPeterka: think we have the same goal, that app should not be aware of those differences
15:48:45 q+
15:49:09 ... service providers want to choose which DRMs they support
15:49:11 q+
15:49:30 ... and invoke te matching services based on their needs
15:50:26 q+
15:50:32 q+
15:51:10 johnsim has joined #html-media
15:51:16 ack joesteele
15:51:42 markw: intention was to make it easier for apps to support multiple DRMs -- that was the idea behind the model
15:52:03 ... providers are restricted to the models they support
15:52:18 ... if you add additional models it makes it more complicated
15:52:53 PetrPeterka: this is what I am missing -- from my point of view the application generates the message and either the CDM handles it or it does not.
15:53:04 markw: I am including the server side when I say application
15:53:07 ack markw
15:53:37 BobLund: want to comment on whether service proivders want to choose the DRMs they use
15:53:53 ... our members want and need to support the clients they provide service to
15:54:11 ... this means they have to support a set of DRMs and want to support a common set of functionality
15:54:19 ... EME as defined does a good job of that
15:54:58 PetrPeterka: at the recent CableLabs conference I heard opposite to this, that MSOs want to choose the DRMs and that browsers have already made they choices and will want to stick with them
15:55:27 BobLund: have to distinguish between the goals with the leased equipments and retail euqipment
15:55:45 ... in the legacy environment they have already started to deliver DRM
15:55:57 ... this will be the same set as the retail devices
15:56:16 ... IP delivery is all about delivering to the non-legacy devices
15:56:31 PetrPeterka: I am not talking about the legacy devices, I am talking about the IP devices today
15:56:40 ... those devices have built-in DRM of their choise
15:56:42 q+
15:56:47 BobLund: I would not agree
15:56:55 ack BobLund
15:57:16 pal: reading the bug -- what are the proposed changes?
15:57:20 q+
15:57:28 ... is it just to remove the informative statement in the introduction?
15:57:33 ack pal
15:57:40 PetrPeterka: that was the main request I believe
15:58:04 ... there was also the issue of informing the browser that the key has been acquired
15:58:17 pal: difference between normative and informative changes to the spec
15:58:25 PetrPeterka: first is an informative change
15:58:51 ... not familiar with the details of the key request today to tell the browser that the key has been requested
15:59:05 pal: would be good to know the full consequences of these changes
15:59:33 ... please provide more details
16:00:03 markw: briefly - a service provider who thinkg they can convince every provider to support their DRM is out of luck
16:00:10 -BobLund
16:00:26 ... in the model we have, their is an ability to message the browser that no more key request is needed
16:00:32 ack markw
16:00:54 ... we should get the sevice providers to support this model
16:01:10 PetrPeterka: model today allows for this existing key model right?
16:01:21 ... then the end result to the API is the same?
16:01:38 markw: the spirit of the spec disagrees, but the letter allows it
16:01:47 ... browser providers might not agree with this
16:02:17 PetrPeterka: one provider on the call who wants a different model -- why should we forbid?
16:02:27 ddorwin: should we call that EME compatible?
16:02:46 PetrPeterka: but it meets the same normative requirements? why would it not be compatible?
16:03:14 ddorwin: what would be the point of that level of interop if it is not really interoperabl?
16:04:06 @pal The document describes the architecture as well as the API
16:04:13 From the abstract: "License/key exchange is controlled by the application…" This was also an important design requirement. This is not the case with the second model.
16:04:13
16:04:13 Applications should be able to expect consistent behavior, such as (as mentioned earlier) being able to proxy the license requests through its front end server.
16:04:13
16:04:13 Reiterating what was just said: Regardless of what the spec says, key systems using the other model are unlikely to be supported by applications written for the application-driven EME.
16:04:13
16:04:13 As discussed in the email thread, there are concerns related to origin, etc. with out-of-band license exchanges.
16:04:38 +1 to what david said
16:04:43 - +1.425.269.aacc
16:04:44 -pal
16:04:44 -davide
16:04:46 -[Adobe]
16:04:46 - +1.858.342.aabb
16:04:58 -[Microsoft]
16:05:02 cutting off conversation -- please continue via email or at next weeks meeting!
16:05:06 thanks all!
16:05:09 -Mark_Watson
16:05:12 rrsagent, generate minutes
16:05:12 I have made the request to generate http://www.w3.org/2013/09/10-html-media-minutes.html joesteele
16:05:16 s/application-driven EME/application-driven EME model/
16:05:25 rrsagent, generate minutes
16:05:25 I have made the request to generate http://www.w3.org/2013/09/10-html-media-minutes.html ddorwin
16:05:27 "Reiterating what was just said: Regardless of what the spec says, key systems using the other model are unlikely to be supported by applications written for the application-driven EME."
16:05:33 -ddorwin
16:05:34 HTML_WG()11:00AM has ended
16:05:34 Attendees were +1.425.269.aaaa, Mark_Watson, +1.858.342.aabb, davide, ddorwin, pal, [Adobe], [Microsoft], BobLund, +1.425.269.aacc
16:05:47 rrsagent, generate minutes
16:05:47 I have made the request to generate http://www.w3.org/2013/09/10-html-media-minutes.html joesteele
16:06:01 chair: joesteele
16:06:03 rrsagent, generate minutes
16:06:03 I have made the request to generate http://www.w3.org/2013/09/10-html-media-minutes.html joesteele
16:06:28 Zakim, Adobe is joesteele
16:06:28 sorry, joesteele, I do not recognize a party named 'Adobe'
16:06:35 Zakim, [Adobe] is joesteele
16:06:35 sorry, joesteele, I do not recognize a party named '[Adobe]'
16:07:16 s/we (Adobe)/joesteele: we
16:07:18 s/we (Adobe)/joesteele: we/
16:07:22 rrsagent, generate minutes
16:07:22 I have made the request to generate http://www.w3.org/2013/09/10-html-media-minutes.html joesteele
16:07:22 pal has joined #html-media
16:07:52 s/resolution ye/resolution yet/
16:08:12 s/here is/joesteele: here is/
16:08:15 rrsagent, generate minutes
16:08:15