Re: {minutes} HTML WG media telecon 2015-01-13 - EME status and bugs

http://www.w3.org/2015/01/13-html-media-minutes.html <http://www.w3.org/2015/01/13-html-media-minutes.html>

Joe Steele

 <http://www.w3.org/>
HTML Media Task Force Teleconference

13 Jan 2015

Agenda <http://lists.w3.org/Archives/Public/public-html-media/2015Jan/0012.html>
See also: IRC log <http://www.w3.org/2015/01/13-html-media-irc>
Attendees <>
Present
ddorwin, jdsmith, joesteele, markw, davide, BobLund
Regrets
Chair
ddorwin
Scribe
joesteele, joesteele_
Contents

Topics <http://www.w3.org/2015/01/13-html-media-minutes.html#agenda>
Role Call <http://www.w3.org/2015/01/13-html-media-minutes.html#item01>
Bugs awaiting input <http://www.w3.org/2015/01/13-html-media-minutes.html#item02>
Bug 27268 - Add a definition of a distinctive identifier <http://www.w3.org/2015/01/13-html-media-minutes.html#item03>
Bug 27093 - Support for proprietary/system-specific formats in initData should be discouraged/deprecated <http://www.w3.org/2015/01/13-html-media-minutes.html#item04>
other bugs <http://www.w3.org/2015/01/13-html-media-minutes.html#item05>
Bug 27738 - Need to change name of 'message' event to avoid confusion <http://www.w3.org/2015/01/13-html-media-minutes.html#item06>
Bug 27739 - Change event name 'keyschange' to 'keychange' <http://www.w3.org/2015/01/13-html-media-minutes.html#item07>
Bug 27740 - Suggest changing interface name 'MediaKeyStatuses' to 'MediaKeyStatusMap' <http://www.w3.org/2015/01/13-html-media-minutes.html#item08>
Issue #3 - Add "internal-error" to MediaKeyStatus enum <http://www.w3.org/2015/01/13-html-media-minutes.html#item09>
Issue #1 - requestMediaKeySystemAccess()'s supportedConfigurations parameter should not be optional <http://www.w3.org/2015/01/13-html-media-minutes.html#item10>
Issue #7 - EME should not fire waiting or canplay events - use a separate mechanism <http://www.w3.org/2015/01/13-html-media-minutes.html#item11>
Issue #8 - Define behavior for implementations that delay playback until setMediaKeys() is called <http://www.w3.org/2015/01/13-html-media-minutes.html#item12>
Issue 9 - Remove note that MediaKeySession events may not be fired until the MediaKeys object is associated with a media element <http://www.w3.org/2015/01/13-html-media-minutes.html#item13>
Bug 27138 - Consider changing how the MediaKeySession method algorithms run other algorithms to more accurately reflect implementations <http://www.w3.org/2015/01/13-html-media-minutes.html#item15>
other business <http://www.w3.org/2015/01/13-html-media-minutes.html#item16>
Issue tracking <http://www.w3.org/2015/01/13-html-media-minutes.html#item17>
Summary of Action Items <http://www.w3.org/2015/01/13-html-media-minutes.html#ActionSummary>
<ddorwin> this is html-media
<joesteele> trackbot, start meeting
<trackbot> Date: 13 January 2015
<joesteele> scribe: joesteele
trackbot, start meeting
<trackbot> Meeting: HTML Media Task Force Teleconference
<trackbot> Date: 13 January 2015
Role Call

Bugs awaiting input

Bug 27268 - Add a definition of a distinctive identifier

https://www.w3.org/Bugs/Public/show_bug.cgi?id=27268 <https://www.w3.org/Bugs/Public/show_bug.cgi?id=27268>
ddorwin: no replies from henri
... implemented but no replies from henri since december
Bug 27093 - Support for proprietary/system-specific formats in initData should be discouraged/deprecated

https://www.w3.org/Bugs/Public/show_bug.cgi?id=27093 <https://www.w3.org/Bugs/Public/show_bug.cgi?id=27093>
ddorwin: saw that joe replied yesterday -- no chance to reply as yet
... any other comments?
joesteele: think I covered most of the three we discussed
... might have missed one
ddorwin: might be good to discuss next week
other bugs

Bug 27738 - Need to change name of 'message' event to avoid confusion

https://www.w3.org/Bugs/Public/show_bug.cgi?id=27738 <https://www.w3.org/Bugs/Public/show_bug.cgi?id=27738>
ddorwin: filed by Glenn last week with some others
... posted some updates about names -- is this really a problem?
does someone have comments on this one?
scribe: messages are used for APIs and they are all used for simple events, we are using for custom events
... should not do that
jdsmith: is this a big change? could accomodate
ddorwin: it is misleading as it is unlikely to relate to a key
... it just about finding another name
markw: I don't think keymessage is that bad
jdsmith: I agree - does not seem like a bad name
ddorwin: I will do some more reseach and then make the change depending on the research
+1
Bug 27739 - Change event name 'keyschange' to 'keychange'

https://www.w3.org/Bugs/Public/show_bug.cgi?id=27739 <https://www.w3.org/Bugs/Public/show_bug.cgi?id=27739>
ddorwin: I added some comments about this could imply key rotation, again a simple change, but needs feedback
... also mentioned this depends on the next bug
<crickets/>
scribe: any basic comments?
... any comments on what the name should be
Bug 27740 - Suggest changing interface name 'MediaKeyStatuses' to 'MediaKeyStatusMap'

https://www.w3.org/Bugs/Public/show_bug.cgi?id=27740 <https://www.w3.org/Bugs/Public/show_bug.cgi?id=27740>
ddorwin: type so does not impact compatibility
... noted that the attribute that uses this type is KeyStatuses -- do we want to change that? if so to what?
<markw> MediaKeyStatusMap and keystatuschange seems good to me
+1
ddorwin: I guess the attribute could be keyStatusMap?
jdsmith: Glenn is objecting to the plural I think
ddorwin: my point is that is used in the attribute as well
... ok we will make changes on those two as well
... will take a shot at that
Issue #3 - Add "internal-error" to MediaKeyStatus enum

https://github.com/w3c/encrypted-media/issues/3 <https://github.com/w3c/encrypted-media/issues/3>
ddorwin: could be other reasons that the key is not usable -- rather than force implementation to pick other reasons
... many statuses existed before
... will file a bug on one today
... InternalError seems like a good name
jdsmith: like that also
+1
<markw> +1
jdsmith: intent is that an error that cannot be typed as one of the normal statuses
ddorwin: that makes senses
Issue #1 - requestMediaKeySystemAccess()'s supportedConfigurations parameter should not be optional

https://github.com/w3c/encrypted-media/issues/1 <https://github.com/w3c/encrypted-media/issues/1>
ddorinw: currently can pass a keySystem without any config
... causes additional spec logic and complexity for implementations
... getConfiguration() can also return null
... proposal is to remove optional
... discussion of "can you pass an empty config"?
joesteele: think I agree that it should be required
ddorwin: couple votes for that now
... should we have any constraints on what the config can be?
<ddorwin> Should "[ { } ]" be a valid second parameter?
ddorwin: probably easiest to leave this, to avoid the extra logic in the spec
... need to make sure the main algorithm supports that
joesteele: were you thinking about security?
ddorwin: no this was just to avoid the complexity of the logic, but this forces the developer to think about it
Issue #7 - EME should not fire waiting or canplay events - use a separate mechanism

https://github.com/w3c/encrypted-media/issues/7 <https://github.com/w3c/encrypted-media/issues/7>
ddorwin: we added waitingFor and fired the waiting event, firing canPlay etc
... got feedback that this was not good, fired on transitions in the state machine which we agreed not to do
... also changing the value of an attribute means a possible race condition
... proposal is to simplify and revert the use of waitingFor and canPlay
... just queue a simple waitingForKey event
... simpler for implementations and applications
... not indication of resuming playback, but you should not be relying on this for your playback
... in the beginning you are already working on providing a key so it is not a problem
... proposal is to remove that logic
joesteele: will have to think about that one more
ddorwin: thought this one would have the most discussion, would like to resolve relatively soon
... would like to get feedback this week
jdsmith: have you looked through the resume logic and rationalized what will happen when we are not waitingForKeys, presumably you would get an event like that still
ddorwin: have not gone through the algorithm yet, if there is a thought that that is how this would go I can
... you would want to internally track that it is in that state, we probably already have something like that internally
... it is the public state that is spec'd and possibly wrong and hard to get right
... not the end of the world to fire twice, but possibly bad if in the wrong state
jdsmith: if we can get by with a simple evenet, would be cleaner and preferable
... have not had time to go through the spec and think about this
... I think I made some of these changes. Not opposed to simplifying if we can.
... Just need to confirm no downsides to stripping out the waitingFor information
ddorwin: so you will take a look at the bug and comment?
jdsmith: yes -- have to bail now
Issue #8 - Define behavior for implementations that delay playback until setMediaKeys() is called

https://github.com/w3c/encrypted-media/issues/8 <https://github.com/w3c/encrypted-media/issues/8>
ddorwin: Jerry might care about this one as well
... non-normative note that apps should call setMediaKeys before providing media data
<joesteele_> scribe: joesteele_
ddorwin: waiting on Issue #7 to resolve this one
Issue 9 - Remove note that MediaKeySession events may not be fired until the MediaKeys object is associated with a media element

https://github.com/w3c/encrypted-media/issues/9 <https://github.com/w3c/encrypted-media/issues/9>
ddorwin: need Jerrys input on this -- please review
... currently text that in some implementations mediakey implementations will not fire events
... breaks some use case
... probably should remove this note and discourage those implementations
... believe this came from Microsoft so need Jerrys input
Bug 27138 - Consider changing how the MediaKeySession method algorithms run other algorithms to more accurately reflect implementations

<ddorwin> https://www.w3.org/Bugs/Public/show_bug.cgi?id=27138 <https://www.w3.org/Bugs/Public/show_bug.cgi?id=27138>
<ddorwin> In the November 11th telecon, http://www.w3.org/2014/11/11-html-media-minutes.html#item10. <http://www.w3.org/2014/11/11-html-media-minutes.html#item10.> Feedback from others is also welcome
ddorwin: this is related to the algorithms, no one has commented, Jerry would review
<ddorwin> s/In the November 11th telecon, http://www.w3.org/2014/11/11-html-media-minutes.html#item10. <http://www.w3.org/2014/11/11-html-media-minutes.html#item10.> Feedback from others is also welcome/In the November 11th telecon, Jerry said he would review it./
ddorwin: comments are welcome
... this affects basically every algorithm
... that is all the bugs
... any other bug comments?
other business

Issue tracking

<ddorwin> http://lists.w3.org/Archives/Public/public-html-media/2015Jan/0009.html <http://lists.w3.org/Archives/Public/public-html-media/2015Jan/0009.html>
ddorwin: sent out the email about using github
<markw> +1 for switching to GitHub
ddorwin: we have a mix now -- would like to drive the bugzilla to zero and continue to file bugs in github
... seems to work well now
joesteele: so we will continue to resolve existing bugs in bugzilla, new bugs will go to github
<markw> when we have only a few left in bugzilla we might want to move those to GitHib
ddorwin: yes. some of the new bugs are just tracking stuff I need to do
... don't appear to be many that we need to move
... except maybe that last one
... we will still receive emails from the old Bugzilla and can ask folks to move them to github
... someone would have to find the component eventually
... and then update the status of the document that has new bugs in github
... thanks everyone! that's all for now
joesteele: MSE next week?
ddorwin: probably should email thread on that
joesteele: I will go ahead and send that out
ddorwin: need folks to respond, but can probably skip EME meeting next week
Summary of Action Items <>[End of minutes]
Minutes formatted by David Booth's scribe.perl <http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm> version 1.140 (CVS log <http://dev.w3.org/cvsweb/2002/scribe/>)
$Date: 2015-01-13 16:54:12 $