W3C

- DRAFT -

HTML-WG EME

17 Feb 2015

See also: IRC log

Attendees

Present
jdsmith, ddorwin, markw, joesteele, BobLund
Regrets
Chair
ddorwin
Scribe
joesteele, ddorwin

Contents


<joesteele> scribe: joesteele

Agenda

<ddorwin> 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

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

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

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

Issue 29 - Allow applications to detect media key session type

<ddorwin> https://github.com/w3c/encrypted-media/issues/29

s/Allow applications/Issue 29 - Allow applications/

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

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

<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

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

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

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

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)

s/prefer first two/prefer one of first two/

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.140 (CVS log)
$Date: 2015-02-17 17:03:55 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
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/emtpy/empty/
FAILED: s/Allow applications/Issue 29 - Allow applications/
Succeeded: s/primpting/prompting/
Succeeded: s/repevent/prevent/
Succeeded: s/Problem about/Issue 25 - Problem about/
Succeeded: s/Allow applicatiosn/Issue 29 - Allow applications/
Succeeded: s/retreviging/retrieving/
Succeeded: s/primitve/primitive/
FAILED: s/prefer first two/prefer one of first two/
Succeeded: s/prefer the first two/prefer one of the first two/
Succeeded: s/make sense/makes sense/
Succeeded: s/figire/figure/
Succeeded: s/not me either/I am not either/
Found Scribe: joesteele
Inferring ScribeNick: joesteele
Found Scribe: ddorwin
Inferring ScribeNick: ddorwin
Found ScribeNick: ddorwin
Found ScribeNick: joesteele
Scribes: joesteele, ddorwin
ScribeNicks: joesteele, ddorwin
Default Present: jdsmith, ddorwin, markw, joesteele, BobLund
Present: jdsmith ddorwin markw joesteele BobLund
Got date from IRC log name: 17 Feb 2015
Guessing minutes URL: http://www.w3.org/2015/02/17-html-media-minutes.html
People with action items: 

[End of scribe.perl diagnostic output]