See also: IRC log
<joesteele> scribe: joesteele
<ddorwin> http://lists.w3.org/Archives/Public/public-html-media/2015Feb/0030.html
<davide> HTML_WG?
<ddorwin> scribe: ddorwin
<scribe> scribenick: ddorwin
https://github.com/w3c/encrypted-media/issues/30
Just a terminology change
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
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
<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
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
<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
https://github.com/w3c/encrypted-media/issues/22
joesteele: I will reply to this -- and double-check the last minutes
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
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
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/
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]