15:00:14 RRSAgent has joined #html-media
15:00:14 logging to http://www.w3.org/2013/06/18-html-media-irc
15:00:16 RRSAgent, make logs public
15:00:16 Zakim has joined #html-media
15:00:18 Zakim, this will be 63342
15:00:18 ok, trackbot; I see HTML_WG()11:00AM scheduled to start now
15:00:19 Meeting: HTML Media Task Force Teleconference
15:00:20 Date: 18 June 2013
15:01:05 HTML_WG()11:00AM has now started
15:01:13 + +44.303.040.aaaa
15:01:13 +[Adobe]
15:01:21 Zakim, aaaa is me
15:01:21 +joesteele; got it
15:02:18 ddorwin has joined #html-media
15:03:53 + +1.425.202.aabb
15:04:09 +Mark_Watson
15:04:16 zakim, aabb is me
15:04:16 +ddorwin; got it
15:04:21 Zakim, Mark_Watson is markw
15:04:22 +markw; got it
15:04:43 BobLund has joined #html-media
15:05:48 +[Microsoft]
15:05:52 zakim, [Microsoft] is me
15:05:52 +adrianba; got it
15:06:26 Agenda: http://lists.w3.org/Archives/Public/public-html-media/2013Jun/0015.html
15:06:55 scribe: joesteele
15:07:08 Chair: Adrian Bateman
15:07:53 Topic: Previous Minutes
15:07:56 http://www.w3.org/2013/06/04-html-media-minutes.html
15:08:01 zakim, who is on the phone?
15:08:01 On the phone I see joesteele, [Adobe], ddorwin, markw, adrianba
15:08:26 + +1.303.661.aacc
15:08:39 zakim, aacc is me
15:08:41 +BobLund; got it
15:09:05 Topic: Review ACTION items
15:09:21 adrian: skip issue 1
15:09:43 ... dive into aciton 19
15:09:48 ACTION-19?
15:09:48 ACTION-19 -- John Simmons to will work with adrianba and jdsmith to make a proposal for bug 21854 -- due 2013-06-04 -- PENDINGREVIEW
15:09:48 http://www.w3.org/html/wg/media/track/actions/19
15:10:06 https://www.w3.org/Bugs/Public/show_bug.cgi?id=21854
15:10:10 adrian: this is about bug#21854
15:10:23 https://www.w3.org/Bugs/Public/attachment.cgi?id=1374
15:10:32 ... this morning copied in the proposal -- can describe
15:10:50 ... 2nd link is a link to an attachment with the state transition diagram
15:10:55 ... for this proposal
15:11:13 adrianba: this bug is about the lifetime of the session
15:11:28 ... we propose that there will be a state attribute associated with the session
15:11:39 ... when session is first created starts in the "created" state
15:11:47 ... can move into the "error" state
15:11:59 ... example is CDM initialization
15:12:11 ... or could move directly into the "ready" state
15:12:31 ... goal is to indicate that should an encrypted block be encountered
15:12:42 ... the CDM does not expect to wait for more key information
15:13:04 ... typical pattern is that from "created" you get a key msg to move into "pending" state
15:13:21 ... get a key msg event - then transition to the "ready" state
15:13:35 ... possible to move from "ready" to "pending" by firing a key msg
15:13:56 ... some implementations may want to fire additional key msgs later (e.g. key rotation)
15:14:09 ... to continue the conversation
15:14:11 q+
15:14:12 johnsim has joined #html-media
15:14:15 q+
15:14:31 markw: looks good -- same as F2F discussion
15:14:44 ddorwin1 has joined #html-media
15:14:47 ... like to see a "closed" state
15:15:01 adrianba: is there a separate bug on "closed"?
15:15:13 markw: bug for additional material on key release
15:15:24 ddorwin: think I own that
15:15:42 close bug: https://www.w3.org/Bugs/Public/show_bug.cgi?id=17750
15:15:48 markw: does this address what caused the key to be destroyed?
15:16:10 +[Microsoft]
15:16:34 adrianba: wanted to ask for feedback on this bug - does it really address the lifetime issue?
15:16:39 zakim, [microsoft] is me
15:16:39 +johnsim; got it
15:16:45 ... not sure what the behavior for "closed" should be
15:16:54 ... key release scenario is a slightly different flow
15:17:07 ... still need to do communication to the license server
15:17:44 ... but even in the absence of key release information were not quite sure how to manage close
15:18:16 ... calling close on a session, finding the keys to map to that session, but may have been provided by a paralell session
15:18:21 ... were not sure how to deal with this
15:18:31 q?
15:18:35 ack mark
15:18:37 ack markw
15:18:39 q-
15:18:41 ack joe
15:19:08 joesteele: how is this exposed to the app and what actions might an app take to seeing a step
15:19:26 adrianba: exposed in two ways
15:19:40 ... attribute on the session -- like an enum of states
15:19:55 ... two additions this proposal makes:
15:20:18 ... adding the ready state - distinct between acquiring keys and not acquiring keys
15:20:45 ... possible for apps to show a message to the user while acquiring keys
15:21:19 joesteele: if i'm in pending, is there a way for the app to say i'm never going to respond
15:21:35 ... i think we said before the only way for the app to not respond is to close the session
15:22:17 q+
15:22:18 adrianba: the signal state that you are in implies that "unless you respond you may not be able to continue playback"
15:22:18 q+
15:22:32 ack ddorwin
15:22:33 ... till we figure out what close means hard to be sure what the cost is
15:22:59 ddorwin: you mentioned key ready event, when heartbeat is being used key ready will be fired frequently
15:23:05 ... is that ok?
15:23:16 ... are there other interesting use cases for the key ready event?
15:23:34 adrianba: think is is the case that you would be moving back and forth between pending and ready
15:23:52 ... you should expect playback to stall if no response
15:24:05 ... likely that the app will show a msg but not required
15:24:18 ... should know whether license service is dealing with heartbeat
15:24:33 ... could use that information to determine that pending heartbeat made playback stop
15:24:50 ... might not want to show a msg every time, but if taking a long time might be approproate to show
15:25:09 ddorwin: if different DRMs use heartbeat, app might have to behave differently
15:25:18 .. was not the case before
15:25:22 q?
15:25:27 ack mark
15:25:27 adrianba: potentially
15:25:50 markw: re: close thing -- seems clear there will be keys that are not removed when the session is closed
15:26:02 ... isn't it up to the CDM when the session is closed?
15:26:17 ... might not be removed if in use by another session or the system
15:26:26 adrianba: that might be sufficient
15:26:37 ... will anyone take action on close?
15:26:51 ... might be better not to add close
15:27:16 markw: might make sense to have keys removed that are not in use by any sessions
15:27:17 q+
15:27:27 ack joe
15:27:33 ... secure proof of key release might require this
15:27:55 joesteele: i'm concerned - i would not want a situation where anyone but the CDM is in control of releasing the CDMs keys
15:28:01 ... that could mess up our system
15:28:27 ... i thought i heard an implication that the browser or app could release keys
15:28:29 q+
15:28:38 ack adr
15:28:46 markw: that is what I said
15:28:58 adrianba: I heard that close would not require that but might allow it
15:29:25 ... is there a CDM or CDM scenario where the app might have more knowledge than the CDM whether a key would be used again?
15:29:41 ... so app could signal to the CDM that those keys could be released
15:29:44 q+
15:29:49 q+ to ask about multiple sessions
15:29:49 q+
15:29:52 ... does that or something like that ever happen?
15:30:11 ... might want close in that case for the future
15:30:13 ack john
15:30:41 johnsimm: agree with joe that the CDMs should be in control, central to how the key systems are designed
15:30:58 ... rules about when the presentation ends that determine when kesy can be released
15:31:13 ... sounds like the behavior should be not key system specific
15:31:30 i think the CDM _is_ in control - the question is whether the app might have knowledge to add information to help the CDM decide?
15:31:35 ... simplest way to accomplish that is to allow the CDM to be in control according to its rules for key management
15:31:46 ... apps can rely on that taking places under the hood
15:32:01 ... concerned about apps doing anything other than "this session has eneded"
15:32:07 s/eneded/ended/
15:32:29 ... this is a "presentation stop" event -- though that is what close should accomplish
15:32:36 ack ddor
15:32:36 ddorwin, you wanted to ask about multiple sessions
15:32:41 ... what happens should be CDM specific
15:32:50 ddorwin: off-topic but related
15:33:06 ... does anyone have concrete use cases for multiple sessions?
15:33:51 adrianba: yes -- the use case we have is multiple tracks being fed in with MSE into same media source
15:33:57 ... each has init data which fired
15:34:14 ... might have a different key for each tracks (one from many audio tracks)
15:34:22 ... might get a needkey fired from each track
15:34:27 q+
15:34:48 ... storing those separately so might play in different combinations
15:34:51 q+
15:35:19 ack joe
15:35:32 joesteele: multiple streams in the same browser window
15:35:56 ... have a family of channels - not playing yet but queueing up ready for switching to that channel
15:36:08 ... another is the different videos in the same window
15:36:23 ... for example ad coming from different system alongside rather than embedded
15:36:45 different media elements in both those cases
15:37:13 ddorwin: the question was about supporting multiple sessions with the same decoder
15:37:32 ... we allow that currently, but we may be allowing more than one it needed
15:37:36 q?
15:37:39 s/it needed/is needed/
15:37:42 ack mark
15:38:05 markw: we have a use case where the user knows the content has finished playing and keys are destroyed
15:38:16 ... also need to be told when that time is (app)
15:38:32 ... so that keys are released when they are supposed to be at the end of the session
15:38:35 ack john
15:38:47 rrsagent, generate minutes
15:38:47 I have made the request to generate http://www.w3.org/2013/06/18-html-media-minutes.html joesteele
15:39:08 johnsimm: once you acknowledge multiple sessions per CDM has use
15:39:29 ... there are situations where an init data is acquired in one session to acquire a key from another session
15:39:52 ... have discussed where you have a key ready need because you don't need a key msg in this case
15:40:26 ... would be useful to discuss the additional scenarios between sessions for key release and make sure they are supported by the spec
15:40:33 ACTION-10?
15:40:33 ACTION-10 -- Adrian Bateman to discuss bug 21855 with johnsim -- due 2013-06-11 -- PENDINGREVIEW
15:40:33 http://www.w3.org/html/wg/media/track/actions/10
15:40:34 ACTION-10?
15:40:34 ACTION-10 -- Adrian Bateman to discuss bug 21855 with johnsim -- due 2013-06-11 -- PENDINGREVIEW
15:40:34 http://www.w3.org/html/wg/media/track/actions/10
15:40:45 https://www.w3.org/Bugs/Public/show_bug.cgi?id=21855
15:40:47 bug#21855
15:41:08 adrianba: this bug is about avoiding network traffic and duplicate sessions for the same key
15:41:30 ... as part of the state transition proposal we are saying it is allowable for there to be duplicate sessions
15:41:56 ... and allowable for CDMs to detect that there are other sessions and CDM can choose to keep that session in the created state
15:42:08 ... and fire the corresponding events in the second session
15:42:23 ... this is why we allow going directly from created to ready state
15:42:37 ... example of audio and video tracks which share the same key
15:43:00 ... create session for each key, CDM has decide to wait for first session before moving to the 2nd session
15:43:08 s/has decide/can decide/
15:43:14 Looks good to me
15:43:19 that works for me
15:43:29 q?
15:43:37 ACTION-12?
15:43:37 ACTION-12 -- Mark Watson to add text to Editor's Draft for bug 21155 -- due 2013-05-28 -- OPEN
15:43:37 http://www.w3.org/html/wg/media/track/actions/12
15:44:07 https://www.w3.org/Bugs/Public/show_bug.cgi?id=21155
15:44:08 adrianba: bug#21155
15:44:13 markw: this is finished
15:44:19 close action-12
15:44:19 Closed ACTION-12 Add text to Editor's Draft for bug 21155.
15:44:39 ACTION-13?
15:44:39 ACTION-13 -- Adrian Bateman to review comments and add text to editor's draft for bug 19009 -- due 2013-06-11 -- OPEN
15:44:39 http://www.w3.org/html/wg/media/track/actions/13
15:44:56 https://www.w3.org/Bugs/Public/show_bug.cgi?id=19009
15:45:00 adrianba: this is on me bug#19009
15:45:10 ... have not done this one yet -- need one more week
15:45:16 action-13 due in 1 week
15:45:16 Set ACTION-13 Review comments and add text to editor's draft for bug 19009 due date to 1 week.
15:45:38 ACTION-17?
15:45:38 ACTION-17 -- Adrian Bateman to provide feedback on keySystem string bugs 16540 and 20798 -- due 2013-05-28 -- PENDINGREVIEW
15:45:38 http://www.w3.org/html/wg/media/track/actions/17
15:46:01 https://www.w3.org/Bugs/Public/show_bug.cgi?id=16540
15:46:09 adrianba: bug#16540 and 20798
15:46:13 https://www.w3.org/Bugs/Public/show_bug.cgi?id=20798
15:46:30 ... about the keySystem string
15:46:44 ... added a comment to the action agreeing with the most recent comments
15:47:15 ... suggestion is that we remove the part of the spec that suggest prefix-matching of the keySystem string for versioning
15:47:31 ... add a non-normative note about CDMs choosing a structure for their string
15:47:56 ... second bug is about string-matching -- should be case-sensitive
15:48:13 ... add a non-normative note saying lower case because we can always add later
15:48:25 ... happy to close this now if no objections
15:48:26 +1
15:48:29 +1
15:48:37 close ACTION-17
15:48:37 Closed ACTION-17 Provide feedback on keySystem string bugs 16540 and 20798.
15:48:58 ACTION: adrianba to implement bugs 16540 and 20798 per the suggestion in ACTION-17
15:48:58 Created ACTION-20 - Implement bugs 16540 and 20798 per the suggestion in ACTION-17 [on Adrian Bateman - due 2013-06-25].
15:49:57 adrianba: that was all the outstanding actions -- any suggestions for bugs to discuss?
15:50:28 TOPIC: CDM storage question
15:50:41 joesteele: wanted to sound people out on whether CDMs should be allowed to store data
15:50:53 q+
15:50:56 q+
15:51:00 ack dd
15:51:17 q+
15:51:25 ack mark
15:51:26 ddorwin: probably can't prevent it, but difficult to implement in some cases
15:51:30 q+
15:51:49 markw: in practice CDMs do require it, open question as to whether browsers can provide this
15:52:08 ... as far as understood not a requirement for arbitrary storage
15:52:29 ... should be secure storage (anti-rollback, etc.)
15:52:44 ... might not be sufficient to have just file system access
15:52:58 ... but only a small amount of secure storage would be needed
15:53:05 ack john
15:53:19 johnsimm: 2 things to consider here
15:53:35 ... large world of DRM system being used for media consumption
15:53:56 ... one of our goals was to see that modest effrot could migrate existing solutions to this specification
15:54:15 ... if this would prevent it or make it difficult, we would do a disservice
15:54:29