00:04:49 RRSAgent has joined #html-media
00:04:49 logging to http://www.w3.org/2015/10/30-html-media-irc
00:05:49 paulc: the agenda is now on the EME section. David believes the issues in item #2 he has commented on all of them and we can discuss as a group and put feedback before David comes online at 10:30am our time. Some folks may have already responded. The work assignment until then is to review these issues. Take 5-10 minutes to go over them. We will start at 9:15 or so
00:05:55 rrsagent, draft minutes
00:05:55 I have made the request to generate http://www.w3.org/2015/10/30-html-media-minutes.html joesteele
00:09:21 chair: paulc
00:09:40 meeting: HTML Media F2F
00:09:48 paulc has joined #html-media
00:09:49 toddg has joined #html-media
00:09:51 Agenda: https://www.w3.org/wiki/HTML/wg/2015-10-Agenda#EME
00:10:12 rrsagent, generate the minutes
00:10:12 I have made the request to generate http://www.w3.org/2015/10/30-html-media-minutes.html paulc
00:11:05 Chair: paulc
00:11:30 Topic: ISSUE-68
00:11:32 https://github.com/w3c/encrypted-media/issues/68
00:11:54 igarashi_ has joined #html-media
00:12:05 topci: ISSUE-68
00:12:20 topic: ISSUE-68 Define key ID representation (byte order)
00:12:25 https://github.com/w3c/encrypted-media/issues/68
00:12:36 present+ Tatsuya_Igarashi
00:12:37 paulc: Mark you responded 3 days ago
00:12:43 present+ paulc
00:12:50 present+ markw
00:13:04 markw: there are many issues about key ids but this is standalone
00:13:13 … if folks agree we can note it and move on
00:13:29 kokabe has joined #html-media
00:13:29 jdsmith: do we want feedback now?
00:13:39 paulc: I can poll the room
00:13:40 markw has joined #html-media
00:13:49 present+ markw
00:13:53 … we can walk through again once David is online
00:14:05 present+ rus
00:14:10 MarkVickers has joined #html-media
00:14:15 rrsagent, draft minutes
00:14:15 I have made the request to generate http://www.w3.org/2015/10/30-html-media-minutes.html joesteele
00:14:27 paulc: we just want to close on these as much as possible before David gets here
00:14:34 … Mark has a suggestion in this issue
00:14:59 markw: I responded that the key id is a sequence of octets — that should be uncontroversial
00:15:11 … that has an order — it is a propertty of that thing
00:15:27 … you have to be careful about how you represent the order
00:15:48 … if you represent as a GUID there are multiple ways of doing it
00:15:58 … but as a BufferSource there is no ambiguity
00:16:05 rus: treat as bytes then?
00:16:25 markw: yes — if someone wants to represent as a GUID that is their repsonbitilty to reolve then
00:16:52 paulc: so concensus seems to be that we could just add that it is a sequence of octets
00:17:03 robink has joined #html-media
00:17:12 markw: if clarifying that is useful , is that sufficient to address David concern?
00:17:58 … do people agree with me?
00:18:25 joesteele: I agree
00:18:56 rrsagent, draft minutes
00:18:56 I have made the request to generate http://www.w3.org/2015/10/30-html-media-minutes.html joesteele
00:19:21 paulc: so when we have concensus I will mark on my list to come back to
00:19:36 topic: ISSUE-85 "tracked" sessions: architectural concerns pending resolution with TAG
00:19:40 https://github.com/w3c/encrypted-media/issues/85
00:19:59 paulc: this is the TAG issue that we will skip for now
00:20:18 jdsmith: are we going to get an update from Travis on this?
00:20:20 paulc: no
00:21:19 rrsagent, draft minutes
00:21:19 I have made the request to generate http://www.w3.org/2015/10/30-html-media-minutes.html joesteele
00:21:41 rrsagent, make logs public
00:21:48 RRSAgent, draft minutes
00:21:48 I have made the request to generate http://www.w3.org/2015/10/30-html-media-minutes.html timeless
00:22:42 s|topci: ISSUE-68||
00:23:23 s/concensus/consensus/
00:24:31 masato has joined #html-media
00:25:39 present+
00:25:40 present+ Josh_Soref
00:25:40 present+ joesteele
00:25:50 present+ MarkVickers
00:25:55 present+ rus
00:26:19 present+ toddg
00:26:22 paulc_ has joined #html-media
00:26:28 RRSAgent, draft minutes
00:26:28 I have made the request to generate http://www.w3.org/2015/10/30-html-media-minutes.html timeless
00:26:30 present+ paulc
00:26:35 Yves has joined #html-media
00:26:41 s/… /... /G
00:26:46 present +Yves
00:26:52 s/present +/present+ /
00:26:57 topic: ISSUE-98 Decide on ideal "waitingforkey" event behavior when update() doesn't resume playback
00:27:01 https://github.com/w3c/encrypted-media/issues/98
00:27:27 yosuke has joined #html-media
00:27:31 paulc: David had a proposal here to always fire the event and ensure consistency
00:27:43 rrsagent, draft minutes
00:27:43 I have made the request to generate http://www.w3.org/2015/10/30-html-media-minutes.html yosuke
00:28:08 present+ Yosuke
00:28:19 s/Topic: ISSUE-68//
00:28:38 s|https://github.com/w3c/encrypted-media/issues/68|http://github.com/w3c/encrypted-media/issues/68
00:28:46 s|https://github.com/w3c/encrypted-media/issues/68|
00:28:52 s|http://github.com/w3c/encrypted-media/issues/68|https://github.com/w3c/encrypted-media/issues/68|
00:28:55 RRSAgent, draft minutes
00:28:55 I have made the request to generate http://www.w3.org/2015/10/30-html-media-minutes.html timeless
00:29:38 scribe: timeless
00:30:17 joesteele: not an implementer, don't know what the impact of this would be
00:30:28 ... seems like it'd be something that would vary between CDMs
00:31:03 paulc_: he has explicit questions here, and then a proposal
00:31:11 jdsmith: he has two proposals
00:31:21 ... one is waiting for key-event multiple times
00:31:25 ... i'm not sure about
00:31:33 ... attempting to do playback multiple times
00:31:48 ... if it fails, UA can try again
00:31:50 ... he's proposing to remove it
00:32:00 paulc_: he's referring to ISSUE-83
00:32:13 joesteele: if the CDM is downloadable, I don't know if the UA would know that resuming would fail
00:32:48 ... I agree w/ jdsmith, I don't see a reason not to allow it to fire multiple times
00:32:54 ... leave it alone, no incompatibility
00:33:04 jdsmith: i'm having trouble w/ a reason to keep the other language
00:33:11 ... "where the UA has knowledge that resuming will fail"
00:33:20 ... I doubt that's practical, unless an implementer is here
00:33:25 joesteele: ISSUE-83 on a Track
00:33:42 ... MarkVickers does a key record need to be updated ...
00:33:52 joesteele: it's unrelated, but he's pointing to it
00:33:59 markw: he's pointing to it,
00:34:13 ... there's a potential for an update to happen w/o keys delivered
00:34:17 s/MarkVickers/markw
00:34:23 ... an update could come, and not provide keys
00:34:29 ... the app should watch status event to see what happens
00:34:36 ... not sure we need the subsequent waiting-for-key-events
00:34:46 ... but it's a continuing state, you're waiting until you see it
00:34:52 rus: I agree w/ markw
00:34:58 ... app shouldn't assume something it doesn't know about
00:35:09 ... get specific events + notifications, should be zero assumptions from app
00:35:14 paulc_: ok to fire more than once?
00:35:28 markw: only file when you transition from waiting-for-key to not-waiting-for-key
00:35:39 paulc_: jdsmith, seems contrary to what you said originally?
00:35:52 jdsmith: i guess you could argue it's a spurious event, not very useful, doesn't tell you anything
00:36:07 ... waiting-for-key-fires, key arrives, you try to resume playback, i think that's the desired flow
00:36:20 ... on allowing the events, i don't know there's a strong negative if you trigger waiting-for-key-event
00:36:29 markw: only fire event when state changes
00:36:39 ... i agree w/ ddorwin's suggestion that it should at least be consistent
00:36:48 ... either we should only send event when state changes
00:36:57 ... or we fire after every update that doesn't deliver the correct key
00:37:02 ... question from author's PoV
00:37:17 ... if you fire event after every event, you know there's an event waiting-for-key or key-status-change
00:37:20 ... that might be useful
00:37:23 ... otherwise, what happens
00:37:25 wdh__ has joined #html-media
00:37:27 ... you still know you'll get something
00:37:33 ... either media-key-status-change, or another-message
00:37:38 joesteele: that's the issue
00:37:48 ... you've put an update, you should get something indicating processing-is-done
00:37:56 ... got-a-key, waiting-for-key, error
00:38:03 markw: if you're waiting for a key, you get a message
00:38:07 jdsmith: you're agreeing
00:38:10 joesteele: we're agreeing
00:38:24 markw: you will get a message if you're waiting
00:38:37 joesteele: you're waiting for a key, you'll get a message indicating what to do to go forward
00:38:51 [ paulc_ reads proposed comment for issue from github comment box ]
00:38:58 s/paulc_/paulc/G
00:39:03 RRSAgent, draft minutes
00:39:03 I have made the request to generate http://www.w3.org/2015/10/30-html-media-minutes.html timeless
00:39:17 joesteele: which is the least amount of work?
00:39:25 paulc_: this issue is marked for AUTHOR input
00:39:35 ... ddorwin's suggestion is we need input from people writing authors
00:39:41 ... we can suppose we're authors
00:39:44 jdsmith: but we aren't
00:39:52 markw: i can ask our implementers
00:40:24 paulc_: that's a possible answer to the first question
00:40:33 action for markw to ask his developers about issue-98
00:40:33 Error finding 'for'. You can review and register nicknames at .
00:40:36 ... there's a second question, do we have a position on removing this text?
00:40:46 s/action for markw to ask his developers about issue-98//
00:40:48 action markw to ask his developers about issue-98
00:40:49 Created ACTION-103 - Ask his developers about issue-98 [on Mark Watson - due 2015-11-06].
00:41:01 markw: i agree w/ the suggestion to make it consistent, we can work it out
00:41:11 paulc_: not confident that's the right solution, but you agree in general?
00:41:32 jdsmith: implication is, you're waiting for a key, you receive one, you're supposed to attempt to resume playback
00:41:38 ... but UA knows in advance it won't work
00:41:48 rus: app should attempt and worst case it gets a failure
00:41:52 jdsmith: that's what i'd assume
00:42:17 paulc_: so i hear a preference for removing the (short circuit) text?
00:42:23 jdsmith: +1
00:42:24 joesteele: +1
00:42:26 rus: +1
00:42:59 paulc_: markw, you said you'd get that feedback?
00:43:02 markw: yep
00:43:33 [ paulc_ reads the proposed text again ]
00:43:42 s/text/pending comment/
00:44:38 rrsagent, draft minutes
00:44:38 I have made the request to generate http://www.w3.org/2015/10/30-html-media-minutes.html joesteele
00:44:48 jdsmith: we're trying to button up the spec
00:44:55 ... worried we're twiddling knobs
00:45:04 ... value consistency over tweaking too much
00:45:09 ... i think it's consistent to fire the event
00:45:24 markw: right now, as spec is written, they can't rely on the event
00:45:32 ... so right now they don't rely on this event
00:45:45 ... if you make it happen always, then it might encourage people to rely on it
00:46:01 jdsmith: instinct is that i doubt anyone is exercising the right to suppress now
00:46:07 q+
00:46:12 ... but that the option is in there for reasons no one remembers
00:46:21 markw: your way is editorially simpler
00:46:25 Zakim has joined #html-media
00:46:35 q+ joesteele
00:46:40 ack joesteele
00:46:44 joesteele: Joe Steele, Adobe
00:46:53 ... if we handle the second part of this, and remove that text
00:47:00 ... would it then make more of a difference?
00:47:07 ... would firing the event be more relevant to authors?
00:47:21 ... it would be redundant, you'll get a message in every case where you're still waiting for a key, presumably
00:47:35 markw: if you have this separate event
00:47:46 ... it's clearer, "waiting-for-key" if you're still waiting for key
00:47:58 ... attaching semantics "can't-start-playback" would be wrong
00:48:20 joesteele: we have consensus: always send message
00:48:27 jdsmith: which is what ddorwin proposed
00:49:08 [ paulc_ reads the github proposed comment ]
00:49:25 markw: if we can resume playback, is there some other message that fires?
00:49:33 ... you might be getting a different key than the one you need
00:49:37 paulc_: is this orthogonal
00:49:42 s/l/l?
00:49:47 markw: related
00:50:10 joesteele: i think you're saying "not receiving waiting-for-key doesn't mean you have a key?"
00:50:27 markw: you always receive waiting-for-key if you're waiting for a key
00:50:35 ... but do you get something explicit saying that playback will go?
00:50:49 joesteele: you'll get a key-status-change saying that something might happen
00:51:02 markw: when playback-resumes does an event fire?
00:51:07 Josh_Soref: i'm sure there is
00:51:32 Josh_Soref has joined #html-media
00:51:52 paulc_: ok, so we're done w/ that one
00:52:25 topic: ISSUE-100 Is "running the Encrypted Block Encountered algorithm" the correct way to Attempt to Resume Playback If Necessary?
00:52:28 https://github.com/w3c/encrypted-media/issues/100
00:52:39 paulc_: markw you responded w/in 2/3 days
00:52:49 ... ddorwin said this was related to ISSUE-98
00:52:55 ... (a) + (b)
00:53:19 ... others should look at markw's response
00:53:46 markw: resource-fetch in html-media is hard to hook into
00:53:52 ... it doesn't have extension points
00:54:01 kinjim has joined #html-media
00:54:02 ... one thing i was surprised by, when looking at the text we have
00:54:16 ... if you run into an encrypted block and we don't have the key, you're supposed to block downloading media data
00:54:19 ... until you get the key
00:54:26 ... i doubt that implementations would do that
00:54:38 paulc_: they'll buffer and attempt to resolve key problem in parallel
00:54:49 markw: you don't need to decrypt to resolve time points
00:54:57 ... encryption isn't a big problem
00:55:05 ... this isn't how our spec describes things
00:55:16 ... but that's a separate issue
00:55:26 ... we're monkey-patching
00:55:52 ... "writing requirements that get inserted into another specification"
00:56:07 ... recommended good design pattern is to provide extension points
00:56:25 ... those hooks warn people that "dragons might happen here"
00:56:42 paulc_: anyone disagree w/ markw's proposal?
00:56:50 [ Silence ]
00:57:05 markw: the italicized text is from the resource-fetch algorithm
00:57:45 ... we'd suppress the state changes listed here in our suspended state
00:58:18 ... in an ideal world we'd have someone working on adding those extension points
00:58:46 paulc: there was a pointer to a bug in the whatwg spec to supply functionality in preload yesterday
00:59:00 ... not 100% useful since our normative reference is to w3c's version
00:59:33 jdsmith: no one here disagrees that this is a problem
00:59:37 ... some change is necessary
00:59:39 action joesteele to ask Adobe developers about issue-98
00:59:39 Created ACTION-104 - Ask adobe developers about issue-98 [on Joe Steele - due 2015-11-06].
00:59:44 ... weird to stop in the middle of an algorithm
00:59:53 paulc has joined #html-media
01:00:46