15:01:09 RRSAgent has joined #html-media
15:01:09 logging to http://www.w3.org/2013/04/02-html-media-irc
15:01:11 RRSAgent, make logs public
15:01:11 Zakim has joined #html-media
15:01:13 Zakim, this will be 63342
15:01:13 ok, trackbot; I see HTML_WG()11:00AM scheduled to start now
15:01:14 Meeting: HTML Media Task Force Teleconference
15:01:14 Date: 02 April 2013
15:01:21 zakim, who's on the call?
15:01:21 HTML_WG()11:00AM has not yet started, glenn
15:01:23 On IRC I see RRSAgent, glenn, joesteele, johnsim, hsivonen, wseltzer, trackbot
15:01:37 paulc has joined #html-media
15:02:00 MartinSoukup has joined #html-media
15:02:03 ddorwin has joined #html-media
15:02:25 pal has joined #html-media
15:02:47 Good morning
15:02:48 markw has joined #html-media
15:03:01 zakim, what is the code?
15:03:01 the conference code is 63342 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), paulc
15:03:05 Zakim, who is on the phone ?
15:03:05 HTML_WG()11:00AM has not yet started, markw
15:03:05 On IRC I see markw, pal, ddorwin, MartinSoukup, paulc, Zakim, RRSAgent, glenn, joesteele, johnsim, hsivonen, wseltzer, trackbot
15:03:32 zakim, this will be html_wg
15:03:32 ok, glenn, I see HTML_WG()11:00AM already started
15:03:39 Agenda: http://lists.w3.org/Archives/Public/public-html-media/2013Apr/0000.html
15:03:41 zakim, who's on the phone?
15:03:41 On the phone I see glenn, joesteele, pal, markw, Bin, [Microsoft], +1.613.287.aaaa, [Microsoft.a], [Microsoft.aa], ddorwin
15:03:53 zakim, aaaa is me
15:03:53 +MartinSoukup; got it
15:04:10 zakim, [Microsoft] has paulc
15:04:10 +paulc; got it
15:04:20 Bin has joined #html-media
15:04:24 zakim, aa is me
15:04:24 sorry, johnsim, I do not recognize a party named 'aa'
15:04:38 zakim, microsoft.aa is me
15:04:38 +johnsim; got it
15:05:33 +??P27
15:06:04 scribe: joesteele
15:06:13 jernoble has joined #html-media
15:06:29 Zakim, who is here?
15:06:29 On the phone I see glenn, joesteele, pal, markw, Bin, [Microsoft], MartinSoukup, [Microsoft.a], johnsim, ddorwin, ??P27
15:06:32 [Microsoft] has paulc
15:06:32 On IRC I see jernoble, Bin, markw, pal, ddorwin, MartinSoukup, paulc, Zakim, RRSAgent, glenn, joesteele, johnsim, hsivonen, wseltzer, trackbot
15:06:40 zakim, ??P27 is me
15:06:41 +jernoble; got it
15:06:44 chair: paulc
15:06:46 Agenda: http://lists.w3.org/Archives/Public/public-html-media/2013Apr/0000.html
15:06:53 Topic: Bug19009
15:07:13 https://www.w3.org/Bugs/Public/show_bug.cgi?id=19009
15:07:50 zakim, [Microsoft.a] is jdsmith
15:07:50 +jdsmith; got it
15:07:58 adrianba has joined #html-media
15:08:39 +[Microsoft.a]
15:08:51 zakim, [Microsoft.a] is me
15:08:51 +adrianba; got it
15:09:03 Web interface: http://irc.w3.org/
15:09:54 Bug 19009: Bug 19009: A MediaKeys should belong to a single HTMLMediaElement
15:10:00 paulc: talking about bug 19009
15:10:39 jernobie: this bug resulted from a discussion with our JavaScript manager
15:10:56 ... he wa sincredualuous that a single DOM object could belong to multiple DOM objects
15:11:13 ... would change it to a diamond instead of a tree
15:11:29 ... the CDM implementation will have to live in the media object itself in our implementation
15:11:52 ... but when single media keys object can belong to multiple media objects this will be hairy
15:12:03 ... that is the basic problem
15:12:25 s/wa sincredualuous/was incredulous/
15:12:35 paulc: do you want to respond David?
15:13:05 adrianba: my comments are in the bug, don't see this as an ownership question
15:13:15 ... don't have strong feelings about this bug
15:13:52 ... can see where this would be useful - if you wanted a presentation where you see a screen and a presenter and use the same keys for protection
15:14:14 ... or a sign language interpretation of the presentation
15:14:18 ... using the same keys
15:14:19 BobLund has joined #html-media
15:14:37 ... we did not have a problem with allowing sharing, but we did not necessarily suppor tit
15:14:58 q+
15:15:00 q+
15:15:06 ... noticed that Jer talked about Media Controller solution we could talk about that
15:15:11 +BobLund
15:15:34 jernobie: probably not exactly what people are going to want to use this for, any other way to implement this?
15:15:52 q+
15:15:55 ... can you just add the keys to both media elements so they are there when queried?
15:16:08 ack mark
15:16:44 markw: don't think we can just add the keys as you get different challenges and need different responses
15:16:48 q-
15:17:21 q+ to talk about standalone MediaKeys
15:17:24 ... question I had was - media keys can have a seperate existence from medial elements as they can get message prior to media element existing
15:17:31 q+
15:17:31 s/medial/media/
15:17:33 ack glenn
15:17:59 glenn: my question was - is it just seperating the underlying state from the DOM instance?
15:18:07 ack adrian
15:18:07 adrianba, you wanted to talk about standalone MediaKeys
15:18:55 adrianba: comment on point about standalone media keys objects - possible for media keys to be standalone, but probably that some implementations will need the media engine to tie back to it
15:19:22 ... don't think that we need to change the API surface, but key acquisition messages might not fire until when you tie the media keys to a media element
15:19:45 ... one question might be -- is there a use case for the standalone media keys? may be some related to secure key release
15:19:54 ... have not investigated this much yet
15:20:24 markw: if that is the case, we should be clear about that in the spec (tying together)
15:20:37 ... otherwise folks will not support it
15:20:40 ack jer
15:21:13 jernobie: saying the same thing as adrian - current way that we approach this won't fire the messages until the media keys are added to the media element
15:21:26 ... don't have access to the internal bits of the CDM
15:21:44 ... if we want to make this explicit in the spec I am ok with that
15:21:54 paulc: David, do you have enough information?
15:22:20 ddorwin: sounds like people want to add to the spec that media keys must be added to the element before message are fired.
15:22:31 ... mot sure whether they can then be connected to multiple media elements
15:22:48 q+
15:22:50 ... little concerned that apps would try to share media keys when the implementations may not support it
15:22:55 ack jer
15:23:00 markw has joined #html-media
15:23:29 jernobie: suggest that if this is a use case (sharing) making an explicit API that can be queried would be preferable as opposed to it being a side effect
15:23:37 paulc: then app would know it is supported?
15:23:42 jernobie: exactly
15:23:55 you might not know until you try
15:23:59 paulc: plausible design? any comment or objections?
15:24:11 q+
15:24:18 ddorwin: exceptions is generally the feature detection capability
15:24:24 ack mark
15:24:32 markw: do we have this as a requirement?
15:24:41 ... we could just allow it
15:25:00 paulc: Adrian mentioned some use cases that might require it
15:25:02 s/just allow/just not allow/
15:25:04 +q
15:25:25 adrianba: I described a couple of use cases, trying to avoid this being hard in the future
15:25:37 q+
15:25:38 paulc: forbidding it and then allowing it later is possible
15:25:57 adrianba: that might be fine as long as we don't modify the API to make it harder later
15:26:14 ... especially since we still have open issue of using existing keys
15:26:19 ... somewhat related
15:26:35 ack joe
15:27:33 ack ddorwin
15:27:34 If we define an exception for setKeys() now, we can allow UAs to not throw it later. Also, we could note in the exception text that it is likely that UAs will not support this and will throw the exception.
15:28:14 I am echoing Adrians comments. I think the issue of existing keys is similar and would like to avoid the overhead of requesting the same key multiple times
15:28:56 Bug 21203: EME leaks information cross-origin https://www.w3.org/Bugs/Public/show_bug.cgi?id=21203
15:28:57 paulc: moving on to next bug
15:29:03 Topic: Bug 21203
15:29:18 q+
15:29:32 ack adrian
15:30:11 adrianba: general principle that web platform should not be able to read information from a different origin within firm indication that that origin is sharing the content
15:30:32 ... example of image sharing image data from another page
15:30:42 ... script cannot access without additional permissions
15:30:59 -jernoble
15:31:16 ... prevents situations where page can embed resource from your social network and get access using your logged in context
15:31:22 ... e.g. stealing an image
15:31:42 ... when we provide init data from the media file might be from a different origin
15:32:02 ... bug asked that we explicitly document what information is shared across origins
15:32:15 ... call out if a problem
15:32:35 ... needkey could provide something the app wouldn't normally have access to
15:32:43 q+
15:32:44 paulc: looking for explicit ask for text in this bug
15:33:03 ddorwin: original report has suggestions
15:33:16 See comment 6: https://www.w3.org/Bugs/Public/show_bug.cgi?id=21203#c6
15:33:21 adrianba__ has joined #html-media
15:33:33 paulc: any objections to these proposed changes?
15:34:13 adrianba: do we believe that exposing init data cross origin is a problem?
15:34:30 ... if so - then something like Henris proposal is a good solution
15:34:36 ack mark
15:34:48 markw: point I made in the bug is that this is analogous to text track cues
15:34:59 ... could contain arbitrary information
15:35:12 ... similar problem
15:35:31 ... Henri point out text tracks must adhere to CORS
15:35:36 ... don't have a problem with that
15:35:47 paulc: any other commnets?
15:35:47 q+
15:35:54 ack adrian
15:35:54 s/commnets/comments/
15:36:20 adrianba: if we do add something like this, must scope to where the media element is doing the network request
15:36:25 q+
15:36:30 ... so if using MSE that is out of scope
15:36:39 ... already need to do CORS
15:36:57 ... once data is available to app is should already be considered same origin
15:37:08 paulc; is this different to what Henri proposed?
15:37:23 markw: don't think so for EME, raises questions for MSE
15:37:38 s/paulc;/paulc:/
15:37:51 markw: I will open that bug
15:38:03 paulc: moving on?
15:38:23 Topic: Bug 20991
15:38:25 https://www.w3.org/Bugs/Public/show_bug.cgi?id=20991
15:38:48 ddorwin: started as reference to something that doesn't exist in algorithm
15:38:59 .. now how do we report errors during loading of the CDM
15:39:19 ... synchronous or asynchronous behaviors
15:39:24 q+
15:39:33 ack mark
15:39:34 q-
15:39:36 ack adrian
15:39:37 ... what do we want to say about a partially initialized media keys
15:40:09 adrianba: interesting timing, we were about to file the same bug last week after thinking about this.
15:40:23 ... mark outlined this in his comments for the bug
15:40:47 ... when you create an instance of the media keys you can start asynchronously initializing
15:41:06 ... not until you need to fire a needkeys that the presence or absence matters to the app
15:41:29 ... could change the API to allow for a pending state on the media keys objects, or an error saying "could not initialize"
15:41:40 ... in the end probably not that much different to the app
15:41:48 ... chose not to raise as a bug
15:42:12 MSE bug mentioned above: https://www.w3.org/Bugs/Public/show_bug.cgi?id=21536
15:42:18 ... considered the privacy issue raised in the intro - related to comments Henri made
15:43:00 adrianba: CDM will do some kind of initialization, at what point could the UA prompt the user to accept the initialization? does the API support a way to do this without blocking the UI?
15:43:12 ... need to provide a way to initialize asynchronously
15:43:14 q+
15:43:26 paulc: are you suggesting this is not actually a problem since you did not file?
15:43:33 ack dd
15:43:33 adrianba: yes
15:43:51 ddorwin: original bug still exists in the spec -- text is incorrect
15:44:01 ... error reporting text should be change to something else
15:44:14 +1 to the change to tidy up the language is needed anyway
15:44:18 ... this is a downside of Adrians proposal, hard to word this text
15:44:30 ddorwin: other than that I am fine
15:44:48 paulc: any other comments?
15:45:27 Topic: Introducing remaining bugs
15:45:29 Bug 16617: Consider more granular error reporting https://www.w3.org/Bugs/Public/show_bug.cgi?id=16617
15:45:36 Just to confirm (21536), we will tidy up the text, but there will be no new MediaKeys state - errors are reported asynchronously on the MediaKeySession
15:45:46 q+
15:45:47 ddorwin: all related to error reporting
15:45:54 Bug 16737: Should MEDIA_KEYERR_CLIENT be two separate errors? https://www.w3.org/Bugs/Public/show_bug.cgi?id=16737
15:46:14 ddorwin: talking about the client err and what that means
15:46:18 Bug 16857: MEDIA_ERR_ENCRYPTED should exclude decrypt failure https://www.w3.org/Bugs/Public/show_bug.cgi?id=16857
15:46:28 ... then detection of decrypt errors
15:46:54 ... please take a look before next time especially MEDIA_KEYERR_CLIENT
15:47:04 ack adrian
15:47:05 ... like to discuss how detailed we want to get
15:47:39 adrianba: this group is assigned to me for a long time, as we have been experimenting, thoughs about error reporting continue to change
15:47:45 ... don't have a complete proposal yet
15:47:52 ... but will throw this out --
15:48:14 ... we think folks will want to try to avoid an error situation preventing playback
15:48:46 ... may be that instead of firing a fatal error, will tell app that it can't guarantee protection and allow fallback to lower quality media
15:49:13 ... second issue is that in PlayReady implementation lots of ways things can generate errors
15:49:33 ... we have been wrestling with how granular errors in the spec should be or rely on system specific errors
15:49:59 q+
15:50:05 ... when people try to debug, more specific is helpful, but might not be able to describe all the errors in an implementation independent way
15:50:16 ... might not be useful for interop
15:50:18 -MartinSoukup
15:50:33 ... could add more errors and not get any closer
15:50:35 ack dd
15:50:44 We should define error codes that the production application should handle.
15:51:02 q+
15:51:20 ddorwin: want detailed errors for debugging, e.g. configuration errors
15:51:37 q+
15:51:40 ... general issue with no feature detection, how does application provide that
15:51:52 ... still going to be some interruption if fallback is required
15:52:00 ack adrian
15:52:24 adrianba: emphasize we want detailed error codes even in production apps, common to want diagnostic codes on the server
15:52:42 ... allow finding common issues and errors, should show up in the API somewhere
15:52:45 ack mark
15:52:49 markw: agreed with that
15:53:13 ... often the license to the CDM will include the policy/rules about when media can be played, e.g. output protection
15:53:47 ... if app cannot there are various callbacks. Need to distinguish between this case (which is normal) and things whic are actually problems (bad key, bad file)
15:53:53 s/whic /which /
15:54:24 paulc: these are all assigned to you Adrian and you are continuing to work on them, any ETA?
15:54:39 adrianba: if folks have specific proposals that would be welcome
15:54:41 F2F meeting agenda wiki location: http://www.w3.org/wiki/HTML/wg/2013-04-Agenda#Potential_Topics
15:54:44 Topic: F2F
15:55:03 paulc: sent email about whether we should have time on the agenda
15:55:21 ... need to have critical mass
15:55:46 ... do we want to request an agenda slot? some people have indicated they would like to attend any sessions like this
15:56:04 ... TPAC sessions seemed to push us along quite a bit
15:56:05 q+
15:56:12