See also: IRC log
<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
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27268
ddorwin: no replies from
henri
... implemented but no replies from henri since december
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
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
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
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
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
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
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
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
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
<ddorwin> 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. 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. 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?
<ddorwin> 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
s/https:\/\/www.w3.org/Bugs/Public/show_bug.cgi?id=//
s/topic\: http.*$//
s/of can you/of whether you can/
This is scribe.perl Revision: 1.140 of Date: 2014-11-06 18:16:30 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/kekystatuschange/keystatuschange/ Succeeded: s/config can also be null/getConfiguration() can also return null/ Succeeded: s/spc/spec/ Succeeded: s/Bug 27138/Bug 27138 - Consider changing how the MediaKeySession method algorithms run other algorithms to more accurately reflect implementations/ WARNING: Bad s/// command: s/In the November 11th telecon, 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./ Succeeded: s/beasically/basically/ Succeeded: s/buginizer/bugzilla/ WARNING: Bad s/// command: s/https:\/\/www.w3.org/Bugs/Public/show_bug.cgi?id=27138 - Consider changing how the MediaKeySession method algorithms run other algorithms to more accurately reflect implementations// Succeeded: s/27138 - Consider changing how the MediaKeySession method algorithms run other algorithms to more accurately reflect implementations// FAILED: s/topic\: http.*$// Succeeded: s/Consider changing how the MediaKeySession method algorithms run other algorithms to more accurately reflect implementations//g Succeeded: s/researfch/research/ Succeeded: s/can you pass an empty config/"can you pass an empty config"/ FAILED: s/of can you/of whether you can/ Succeeded: s/Bug 27138 - /Bug 27138 - Consider changing how the MediaKeySession method algorithms run other algorithms to more accurately reflect implementations/ Found Scribe: joesteele Inferring ScribeNick: joesteele Found Scribe: joesteele_ Inferring ScribeNick: joesteele_ Scribes: joesteele, joesteele_ ScribeNicks: joesteele, joesteele_ Default Present: ddorwin, jdsmith, joesteele, markw, davide, BobLund Present: ddorwin jdsmith joesteele markw davide BobLund Agenda: http://lists.w3.org/Archives/Public/public-html-media/2015Jan/0012.html Found Date: 13 Jan 2015 Guessing minutes URL: http://www.w3.org/2015/01/13-html-media-minutes.html People with action items:[End of scribe.perl diagnostic output]