{minutes} HTML WG media telecon 2013-09-10 - EME status and bug discussion

http://www.w3.org/2013/09/10-html-media-minutes.html

Joe Steele
steele@adobe.com




HTML Media Task Force Teleconference

10 Sep 2013

Agenda

See also: IRC log

Attendees

Present
+1.425.269.aaaa, Mark_Watson, +1.858.342.aabb, davide, ddorwin, pal, [Adobe], [Microsoft], BobLund, +1.425.269.aacc
Regrets
Paul Cotton
Chair
joesteele
Scribe
joesteele
Contents

Topics
Agenda
F2F coming up
Previous Minutes
Review of Action items and issues
Moving ClearKey into separate spec
EME heartbeat
EME status and bugs
Revisit Key Error codes
Define initialization data for ISO-BMFF
Need non-normative security considerations sections
Support for different CDM communication models
Summary of Action Items
<trackbot> Date: 10 September 2013
<scribe> Scribe: joesteele
Agenda

F2F coming up

<markw> Yes, I'm going
is anyone going to the F2F
johnsim: not sure whether Adrian is going -- think he is
jerry: believe he is attending
do we have a timeslot scheduled?
jdsmith: believe we have something scheduled for Thursday
... should figure out what we want to accomplish
... should take advantage of being together
johnsim: some topics are hard to do over the phone
... should come up with a list
Previous Minutes

http://www.w3.org/2013/09/03-html-media-minutes.html
any objections?
scribe: any corrections?
... mark as approved
Review of Action items and issues

https://www.w3.org/html/wg/media/track/
any information on Adrian's actions?
Adrian is not here
jdsmith: have not heard much -- he has been out for family reasons
johnsim: working on it with David
ddorwin: this is the ISOBMFF data format issue
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
... suggested at the last TPAC
<markw> +1
johnsim: my proposal would be to return to the old CENC definition
... in the section where we talk about formats
... we could make that normative sections be specific to CENC
joesteele: we are ok with that position
johnsim: does that resolve my action?
ddorwin: there were some other issues with the text I identified
... you proposed some revised text, that cleaned up some things but raised other issues
... we need to decide how/whether other key systems are supported
johnsim: in other words what the initData would be for ClearKey
ddorwin: this was one of the issues
... could just define a generic one and ClearKey would happen to use that as well
johnsim: a generic PSSH would have a format would be defined in the spec for ClearKey?
ddorwin: that is one issue, there is a list in the bug
johnsim: so the action is to go through the bug issues and highlight the ones that go away with CENC
... and propose solutions to the remainders
<ddorwin> ^ correct
Moving ClearKey into separate spec

ddorwin: is is an issue but has been punting forward -- need impl feedback
... in every agenda
joesteele: no resolution yet
s/ye /yet/
johnsim: what led us to suggest this?
ddorwin: discussion about a year ago
... might add extra work, might not be possible
... my opinion is that we should keep it in
... links is in the issue (e.g. https://www.w3.org/Bugs/Public/show_bug.cgi?id=21016)
here is the link to the issue -- https://www.w3.org/html/wg/media/track/issues/1
EME heartbeat

any progress?
<ddorwin> I was wrong - 7 months ago.
scribe: this would be Adrian so no progress
johnsim: no one on the call to address this I think -- need someone saavy in W3C arcana
ddorwin: obligation to update the spec, but not sure what the downside is
johnsim: so what do we need to do to publish the heartbeat?
joesteele: don't believe any specific bugs needed to be in the hearbeat, no specific changes needed, ...
EME status and bugs

joesteele: does anyone have any specific bugs they want o go over?
ddorwin: Adrian had the same-origin bug which I reviewed
... also opened the ClearKey bug about the key format
<ddorwin> Clear Key format bug: https://www.w3.org/bugzilla_public/show_bug.cgi?id=17682
joesteele: why the change here?
ddorwin: some ambiguity about key id, wanted to specify things more
... will make implementations easier and interoperable
Revisit Key Error codes

https://www.w3.org/Bugs/Public/show_bug.cgi?id=21798
ddorwin: on me to document - people can continue the discussion in the bug
... this will spark more discussion
Define initialization data for ISO-BMFF

https://www.w3.org/Bugs/Public/show_bug.cgi?id=17673
joesteele: john will do more investigation before we close this out
ddorwin: john do you want a new date?
... I will change the date to next week
Need non-normative security considerations sections

https://www.w3.org/Bugs/Public/show_bug.cgi?id=22909
ddorwin: Adrian closed the privacy bug
... 22910
... there is a discrepancy with 20965 the master bug, we should either close 22909 or close 22910
... either this was an oversight or there was proposed text for one and not the other
joesteele: should get Adrians feedback on that
ddorwin: I will update the bug
PetrPeterka: can we talk about 17615
Support for different CDM communication models

https://www.w3.org/Bugs/Public/show_bug.cgi?id=17615
PetrPeterka: one model is that DRM as explicit out of band channel, other model is that all comms go through the browser
... some changes came later to exclude the out-of-band model
... text in the abstract that explicitly prevents this
... supporting both models should not require architectural changes
... just need to return the right status
<ddorwin> The original discussion was that the out-of-band mode was *already* supported by HTML5 media elements
<markw> david is saying just what I was going to say
ddorwin: what is the new information that you think changes this?
... taking out needKey and other messages makes this not EME anymore
PetrPeterka: goal is to make this interoperable and remove app-specific knowledge
... eg. MPEG-DASH with CENC could just provide the stream to the DRM and say "handle this - I don't know much"
<ddorwin> Interoperable is the key - the two modes are not interoperable. Applications written for one would not be interoperable with the other.
PetrPeterka: application designer has to treat either model in the same way without pushing too much information into the app
ddorwin: that is the issue -- application does have to know
PetrPeterka: application could say "take care of the keys" and not have to deal with it
... in some cases the app would have to be involved, in others the DRM could just handle it
markw: is that a realistic scenario? that would imply the app provider has both ends of the system
... they also have a front-end server which talks to the back end-server correctly
... distinguishing between front-end DRM server and back-end DRM server
PetrPeterka: why does the application have to make that decision?
... today there are operators that are using multiple DRMs
... so they would have multiple license servers
markw: the point of EME was to make it simpler for application providers to support multiple DRMs
PetrPeterka: think we have the same goal, that app should not be aware of those differences
... service providers want to choose which DRMs they support
... and invoke te matching services based on their needs
markw: intention was to make it easier for apps to support multiple DRMs -- that was the idea behind the model
... providers are restricted to the models they support
... if you add additional models it makes it more complicated
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.
markw: I am including the server side when I say application
BobLund: want to comment on whether service proivders want to choose the DRMs they use
... our members want and need to support the clients they provide service to
... this means they have to support a set of DRMs and want to support a common set of functionality
... EME as defined does a good job of that
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
BobLund: have to distinguish between the goals with the leased equipments and retail euqipment
... in the legacy environment they have already started to deliver DRM
... this will be the same set as the retail devices
... IP delivery is all about delivering to the non-legacy devices
PetrPeterka: I am not talking about the legacy devices, I am talking about the IP devices today
... those devices have built-in DRM of their choise
BobLund: I would not agree
pal: reading the bug -- what are the proposed changes?
... is it just to remove the informative statement in the introduction?
PetrPeterka: that was the main request I believe
... there was also the issue of informing the browser that the key has been acquired
pal: difference between normative and informative changes to the spec
PetrPeterka: first is an informative change
... not familiar with the details of the key request today to tell the browser that the key has been requested
pal: would be good to know the full consequences of these changes
... please provide more details
markw: briefly - a service provider who thinks they can convince every provider to support their DRM is out of luck
... in the model we have, there is an ability to message the browser that no more key request is needed
... we should get the sevice providers to support this model
PetrPeterka: model today allows for this existing key model right?
... then the end result to the API is the same?
markw: the spirit of the spec disagrees, but the letter allows it
... browser providers might not agree with this
PetrPeterka: one provider on the call who wants a different model -- why should we forbid?
ddorwin: should we call that EME compatible?
PetrPeterka: but it meets the same normative requirements? why would it not be compatible?
ddorwin: what would be the point of that level of interop if it is not really interoperabl?
<markw> @pal The document describes the architecture as well as the API
<ddorwin> 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.
<ddorwin> 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.
<ddorwin> 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 model.
<ddorwin> As discussed in the email thread, there are concerns related to origin, etc. with out-of-band license exchanges.
<markw> +1 to what david said
joesteele: cutting off conversation -- please continue via email or at next weeks meeting!
... thanks all!
<pal> "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."
Summary of Action Items

[End of minutes]
Minutes formatted by David Booth's scribe.perl version 1.138 (CVS log)
$Date: 2013-09-10 16:11:47 $