See also: IRC log
<trackbot> Date: 07 May 2013
<glenn> scribenick: johnsim
TOPIC Roll call
<scribe> done
http://www.w3.org/2013/04/30-html-media-minutes.html
<glenn> Action-10?
<trackbot> ACTION-10 -- Adrian Bateman to discuss bug 19208 with johnsim -- due 2013-04-22 -- OPEN
<trackbot> http://www.w3.org/html/wg/media/track/actions/10
<ddorwin> Action 10 is related to "Keymessage event not needed when Key System already has Key"
<trackbot> Error finding '10'. You can review and register nicknames at <http://www.w3.org/html/wg/media/track/users>.
<ddorwin> Which has been replaced with bug 21855
<ddorwin> "Avoid network traffic and duplicate sessions for the same key(s)"
<ddorwin> Action-11?
<trackbot> ACTION-11 -- Mark Watson to write a proposal for the case where the data is not available to the JS -- due 2013-04-02 -- OPEN
<trackbot> http://www.w3.org/html/wg/media/track/actions/11
markw: new update for action 11 is in a week
<scribe> done
correction: http://tinyurl.com/7tfambo
Things done: Removed the second needkey event (19788). Require key IDs (19810) Updated examples to use asynchronous XHR and addEventListener (16541, 18928). Added Issue blocks for error codes and asynchronous loading of the CDM. Swapped 5.1 <-> 5.2 then 4 <-> 5. Removed the FAQ, which was superfluous and diverging from the main text.
joesteele: did removing FAQ clear bugs referring to the FAQ?
http://lists.w3.org/Archives/Public/public-html-media/2013May/0004.html
<ddorwin> https://www.w3.org/Bugs/Public/show_bug.cgi?id=21854
ddorwin: replaces a bunch of bugs - we have a lot of bugs about when to fire bugs, asynchronous events,
... lifecycle one, we need some proposed text. Adrian had a proposal. Lifecycle may lead to states or events. comments?
joesteele: a useful diagram - forget who put it together - lifecycle or states changing
<ddorwin> Diagram is in https://www.w3.org/Bugs/Public/show_bug.cgi?id=20688#c5
ddorwin: we need to discuss states
markw: aagree with joe's comment, key message and getting the message back state
<ddorwin> markw: The question is whether the application needs to know the state or can tell from the events
johnsim: provide a state diagram example
<ddorwin> Next bug: https://www.w3.org/Bugs/Public/show_bug.cgi?id=21855
<ddorwin> "Avoid network traffic and duplicate sessions for the same key(s)"
joesteele: i had one picky comment - avoiding network traffic - my concern is not the additional network traffic but impact on user
... no reason to make the user act when you already have the key
... if the application has decided that it does not want to forward the key request
... hashed something in some other way or user has said "no", you are kind of stuck
... may not be clear what the application should do in response to that
ddorwin: CDM - for first one - doesn't care if server or application - talking to the UA which is talking to the application - as long as it leads to some result
... second one, wouldn't you just call close?
joesteele: agree
ddorwin: next one is media key error codes, skip that one - research that i haven't pasted yet
<ddorwin> https://www.w3.org/Bugs/Public/show_bug.cgi?id=16857
ddorwin: group of 4-5 looking for feedback
... current discussion is whether we need this
any good reason for application to distinguish - three causes of this error
ddorwin: UA does not support decryption of this content. may not be possible to determine that, so not supported would be a better error
... UAs that don't support decryption, to determine it is encrypted, applications that don't have a needkey handler, maybe they just get a decode error or not supported
joesteele: if i am a developer writing an application and i don't know the content is encrypted, how would i know that i need to provide a needkey handler?
ddorwin: even if you have an event handler, hopefully an error handler, could be one you don't recognize
markw: summary is useful. what we do about the case where we provided key but it is the wrong one?
ddorwin: basically, fired needkey, but it is not what i need, so there is not anything we do in any of the algorithms for that, relates to lifecycle
... how do you indicate that the application things it is done
... and that would be a mediakey error and not a media error
<ddorwin> akc joe
ddorwin: error when App is not EME aware, and is that the right thing to do
joesteele: if you are not EME aware, encrypted content - maybe I need to do something more in app
ddorwin: when to distinguish EME aware and EME unaware app
... call createsession without getting the data from the needkey event - to avoid getting the key error you would have to register the needkey event
markw: knows that information out of band, not a big imposition to require registering needkey()
ddorwin: john and mark comment in the bug on what they just said
joesteele: one more question - isn't the case where you need to throw this error only going to happen when you don't already have the key you need?
ddorwin: depends on the second bug, always firing needkey event, tbd in the avoid network traffic
... i believe we will always fire the needkey event, have to load the CDM to do otherwise
johnsim: create mediakeys = EME aware?
ddorwin: it can be even more messy for timing, create media keys and assign element and then load the media, might be simpler to just load the handler
... there are those other bugs, down to 29, alot of them are looking for closure or comments, resolutions, please comments on the bugs, especially those in the minutes
joesteele: i can scribe for the next meeting
ddorwin: assume next meeting is EME. MSE went to pre-last call - should be driving towards zero
adjorned
<glenn> trackbot, end meeting