{minutes} HTML WG media telecon 2015-02-17 - EME status and bugs

http://www.w3.org/2015/02/17-html-media-minutes.html <http://www.w3.org/2015/02/17-html-media-minutes.html>

Joe Steele


 <http://www.w3.org/>
HTML-WG EME

17 Feb 2015

See also: IRC log <http://www.w3.org/2015/02/17-html-media-irc>
Attendees <>
Present
jdsmith, ddorwin, markw, joesteele, BobLund
Regrets
Chair
ddorwin
Scribe
joesteele, ddorwin
Contents

Topics <http://www.w3.org/2015/02/17-html-media-minutes.html#agenda>
Agenda <http://www.w3.org/2015/02/17-html-media-minutes.html#item01>
New Issues <http://www.w3.org/2015/02/17-html-media-minutes.html#item02>
Issue #30 – Switch terminology from "asynchronously" to "in parallel" <http://www.w3.org/2015/02/17-html-media-minutes.html#item03>
Issue #31 - generateRequest() should allow the first message to not be a license request based on initData <http://www.w3.org/2015/02/17-html-media-minutes.html#item04>
Issue #32 - Consider providing guidance for implementations on platforms that do not expose key IDs <http://www.w3.org/2015/02/17-html-media-minutes.html#item05>
https://github.com/w3c/encrypted-media/issues/29 <http://www.w3.org/2015/02/17-html-media-minutes.html#item06>
Issue 29 - Allow applications to detect media key session type <http://www.w3.org/2015/02/17-html-media-minutes.html#item07>
Bug 26776 - Diagnosing and resolving CDM errors needs a numeric systemCode (deleted with MediaKeyError) <http://www.w3.org/2015/02/17-html-media-minutes.html#item08>
Issue 25 - Problem about MediaKeySession.keyStatuses get/has methods <http://www.w3.org/2015/02/17-html-media-minutes.html#item09>
Issue #22- Provide more guidance on the behavior of the keyStatuses attribute <http://www.w3.org/2015/02/17-html-media-minutes.html#item10>
Issue #16 - Review close() and remove() logic and behavior for persistent-* sessions <http://www.w3.org/2015/02/17-html-media-minutes.html#item11>
EME/MSE heartbeat publication <http://www.w3.org/2015/02/17-html-media-minutes.html#item12>
Next meeting <http://www.w3.org/2015/02/17-html-media-minutes.html#item13>
Summary of Action Items <http://www.w3.org/2015/02/17-html-media-minutes.html#ActionSummary>
<joesteele> scribe: joesteele
Agenda

<ddorwin> http://lists.w3.org/Archives/Public/public-html-media/2015Feb/0030.html <http://lists.w3.org/Archives/Public/public-html-media/2015Feb/0030.html>
<davide> HTML_WG?
<ddorwin> scribe: ddorwin
<scribe> scribenick: ddorwin
New Issues

Issue #30 – Switch terminology from "asynchronously" to "in parallel"

https://github.com/w3c/encrypted-media/issues/30 <https://github.com/w3c/encrypted-media/issues/30>
Just a terminology change
Issue #31 - generateRequest() should allow the first message to not be a license request based on initData

https://github.com/w3c/encrypted-media/issues/31 <https://github.com/w3c/encrypted-media/issues/31>
Tracks restoring the intended behavior.
<scribe> scribenick:joesteele
after reviewing this internally -- Adobe has no problem with what is described in ussue #19. Will need to review #31 still
I will ask Chris Pearce to confirm he is ok with issue #19
Issue #32 - Consider providing guidance for implementations on platforms that do not expose key IDs

https://github.com/w3c/encrypted-media/issues/32 <https://github.com/w3c/encrypted-media/issues/32>
joesteele: needs to comments on issues #19 directly still -- TBD
ddorwin: some devices cannot expose key id statuses
... need to describe how those implementations behave
... either empty map or key id 0 with status for entire session
... Android devices, possibly others
https://github.com/w3c/encrypted-media/issues/29 <https://github.com/w3c/encrypted-media/issues/29>
Issue 29 - Allow applications to detect media key session type

<ddorwin> https://github.com/w3c/encrypted-media/issues/29 <https://github.com/w3c/encrypted-media/issues/29>
ddorwin: we have two persistent session types now, but now way to tell between them
... might be important for some use cases, e.g. pinning content offline
... this is proposal to add new sequence of strings that describe this
... could use to prevent prompting for things you can't do
joesteele: won't the app know the type of session?
ddorwin: this is before the session --
... you will know but not early enough
... this would let the app make better decisions
joesteele: I will have to review I think
Bug 26776 - Diagnosing and resolving CDM errors needs a numeric systemCode (deleted with MediaKeyError)

https://www.w3.org/Bugs/Public/show_bug.cgi?id=26776 <https://www.w3.org/Bugs/Public/show_bug.cgi?id=26776>
jdsmith: added a comment about retrieving an event -- a DOMString
... thought Dominics comments about subclassing ECMAScript Errors there, but not sure how to handle
... event is a more normal feature for us to implement in our spec
... but David expressed a concern about this approach
ddorwin: reading now
... this provides human-readable events for things outside the specification
... goes back to earlier discussion -- what events are we targeting?
... promises failing, decode errors, key status changes
jdsmith: I think this would be more asynchronous in the algorithms we are providing
... this could provide more diagnostic information
ddorwin: what object is this fired at?
jdsmith: MediaKeySession
ddorwin: I was thinking this would be disconnected, or is that just a side effect
... so you would fire this and the key statuses at the same time
... should this be more closely attached to that?
jdsmith: all the normal key status responses are directly related to keys
... are you thinking something more generic could be attached?
ddorwin: you are talking about "something else" can you give an example?
... can you give an example?
jdsmith: yes
... should we treat the option of subclassing Errors as viable? Dominic indicated this
ddorwin: don't think we want to get into our own ECMAScript bindings .. don't know if this would solve Marks original issue
<markw> I think this would work for me
joesteele: the example I can give is when the DRM sub-system actually fails, at the communication level.
... this would be async
jdsmith: would prefer a numeric value here, but a string can work
<ddorwin> Related bug to Joe's comments: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27067 <https://www.w3.org/Bugs/Public/show_bug.cgi?id=27067>
<markw> \me back in 2 mins
ddorwin: this also proposes an event -- might be moving towards a solution
... app might not record this behavior and you are doing something wrong anyway
... a system code might be OK there
joesteele: what are the next steps?
ddorwin: Jerry will add comments and examples
jdsmith: and discuss whether should be fired against MediaKeySession
Issue 25 - Problem about MediaKeySession.keyStatuses get/has methods

<ddorwin> AKA, keyStatuses cannot be maplike
<ddorwin> https://github.com/w3c/encrypted-media/issues/25 <https://github.com/w3c/encrypted-media/issues/25>
ddorwin: jwwang reported a problem with comparing the reference and not the values for the map-like object here
... this means apps could not actually get the real data for a key id
... could just check the value instead, but that is not how ECMAScript works
... last comment was to check with public-scriptcoord
... few options:
... define our own map interface
... use a primitive type for the string
... use a sequence instead
... probably have to take one of these options
... prefer one of the first two
... think this is easier for developers, annoying to iterate over the sequence
<ddorwin> Options: https://github.com/w3c/encrypted-media/issues/25#issuecomment-73821831 <https://github.com/w3c/encrypted-media/issues/25#issuecomment-73821831>
markw: from the script authors point of view the ability to look up using the key id is the most obvious thing
... this is not uncommon with Web IDL but if we have to define our own map interface might be worth it
ddorwin: I will double-check with public-scriptcoord
markw: maybe we can give the WebIDL team this feedback, seems like obvious things are hard to do
ddorwin: I will reply and CC the editors, others can follow along
jdsmith: the WebMIDI examples is this the input/output interfaces?
ddorwin: yes
... editors said they would move to this when available
Issue #22- Provide more guidance on the behavior of the keyStatuses attribute

https://github.com/w3c/encrypted-media/issues/22 <https://github.com/w3c/encrypted-media/issues/22>
joesteele: I will reply to this -- and double-check the last minutes
Issue #16 - Review close() and remove() logic and behavior for persistent-* sessions

https://github.com/w3c/encrypted-media/issues/16 <https://github.com/w3c/encrypted-media/issues/16>
ddorwin: close and remove logic, another bug (issue 18) as well, we agreed to review
... assuming we will have to sit down and think this through
... some description in the wiki
... probably also needs review
... would like the two perisistent session work similarly and be well-defined
markw: agree with those goals, would like to say that in some places for the persistent key release case it mentions that it will send messages and in other cases it does not.
... would like to at least try in all cases.
... might not work in all implementations
ddorwin: probably just need to think through all the use cases and put those in the algorithms
... take a fresh look
markw: makes sense
EME/MSE heartbeat publication

ddorwin: need to follow up on this thread
... I think the main spec will be a working draft and the others into a non-working draft
... publish in the same place for now, but need to figure out where to put them
... I will followup
joesteele: any help needed?
ddorwin: no unless folks disagree
... just replacing the existing working files
Next meeting

ddorwin: do we want to meet next week?
joesteele: I will not be available next week
markw: I am not either
ddorwin: Ok we will meet March 3rd unless something comes up with MSE
<ddorwin> Next meeting: March 3rd - EME (unless we have anything for MSE)
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-02-17 17:03:55 $