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 paulc: who's creating the pull request? 01:00:55 markw: need to see if ddorwin agrees 01:01:06 ... ideally we'd change things more substantially 01:01:24 ... so encrypted block handling isn't in fetch, but somewhere further down the line 01:01:40 topic: ISSUE-102 Define what to do when CDM becomes unavailable 01:01:44 See also https://www.w3.org/Bugs/Public/show_bug.cgi?id=27067 01:02:19 paulc: there's a proposal 01:02:22 ... joesteele agrees 01:02:26 jdsmith: i agree as well 01:02:35 rus: proposal is by cpearce 01:03:04 [ paulc reads cpearce's proposal ] 01:03:26 jdsmith: ddorwin restated the changes in his subsequent post 01:03:32 ... more of a proposed implementation 01:04:26 rus: what i see that's missing from ddorwin's proposal 01:04:29 plh has joined #html-media 01:04:33 ... in FF they state they fire an error message at the end 01:04:38 ... i don't see that from ddorwin 's proposal 01:04:57 ... no very specific way of saying "there was an error", "how do you propagate the error?" 01:05:24 joesteele: i think there should be an error 01:05:42 ... oh, he says methods, not promises 01:05:44 ... good point 01:06:39 Josh_Soref: this is for debugability? 01:06:47 rus: debugability and also troubleshooting 01:07:52 I believe an example of the text ddorwin is referring to is https://w3c.github.io/encrypted-media/#createMediaKeys section 2.10 01:08:38 topic: ISSUE-112 Encrypted Block Encountered algorithm: Steps to abort playback are insufficient 01:08:55 joesteele: i think ddorwin misunderstood what i was saying 01:09:10 ... ddorwin says it's not generally possible to determine if you have the wrong key 01:09:15 ... not what i'm talking about 01:09:27 ... does it make sense, when we had decrypted some content, and now we're failing 01:09:36 ... that's different from never decrypted content, and we're failing 01:09:43 ... in my CDM those are two different error conditions 01:10:27 joesteele: my response to ddorwin 01:10:40 ... he seems to imply that have-nothing means that you have no data 01:10:44 ... you could have no encrypted data 01:10:56 ... he's mapping the unencrypted data algorithm down 01:11:19 i|generally|https://github.com/w3c/encrypted-media/issues/112 01:11:32 paulc: he's trying to refer to MSE's alg 01:11:38 joesteele: he's ... 01:11:48 ... i'm giving a reason for handling one of the cases extra specially 01:11:56 ... i agree w/ his point that we should handle one case 01:12:03 paulc: could we make it a separate issue? 01:12:09 joesteele: make it such that it won't be done 01:12:13 ... but i don't feel strongly on it 01:12:41 ... i think we could make the other thing a separate issue 01:12:48 ... "as an optimization, we can split this out" 01:13:06 s/optimization/enhancement 01:13:14 ... to improve debugging 01:13:35 s/this/this error case/ 01:14:27 topic: ISSUE-118 Can EME support link protection, such as DTCP-IP? 01:14:42 s/topic: ISSUE/topic: ISSUE/ 01:14:50 MarkVickers: i replied to this 01:15:01 i|rep|https://github.com/w3c/encrypted-media/issues/118 01:15:18 ... I agree w/ your comment about source, it's a detail of content protection DRM 01:15:28 ... but if you have a web browser on the other end, a TV receiving the content 01:15:35 ... and you have a app running there 01:15:48 ... need to do two things, (1) as EME do... 01:15:55 ... and (2) do you support media type and details 01:16:00 ... alternative is horrible 01:16:12 ... make up mime type and media type and other link content protection 01:16:19 ... DTCPIP+ etc. 01:16:30 ... although yes, a lot of machinery you're not using, passing keys, etc 01:16:41 ... the machinery you're using is the only way to do it, via EME 01:16:50 ... as a practical issue, one could say "that's a separate API" 01:17:05 ... but as a practical matter, there will be 0 or 1 content protection APIs 01:17:21 markw: how does a browser on the other end identify DTCPIP content? 01:17:29 ... file extension? what? 01:17:36 MarkVickers: i'd have to look 01:17:48 [ Break until 10:30 am ] 01:17:48 ddorwin1 has joined #html-media 01:26:47 gurupanguji has joined #html-media 01:27:08 nsakai_ has joined #html-media 01:28:06 ddorwin1 has joined #html-media 01:30:20 rus has joined #html-media 01:33:45 rus has joined #html-media 01:33:47 rrsagent, generate the minutes 01:33:47 I have made the request to generate http://www.w3.org/2015/10/30-html-media-minutes.html paulc 01:37:38 ddorwin: Are you joining the teleconference? 01:37:52 shoko has joined #html-media 01:38:40 topic: Outstanding action items 01:38:45 paulc: i'd like to move on 01:38:51 working on it 01:39:15 topic: ACTION-93: Get in touch with webappsec wg about the "privileged context" which is more generic than saying https, etc." 01:39:25 paulc: do we need to do more? 01:39:46 ... there was a sessions you, markw, ran on Wed? 01:40:02 ... slides? 01:40:14 markw: the slides will be public when i put them up 01:40:20 present+ ddorwin 01:40:26 MarkVickers: i sent boblund 01:40:32 ... a link 01:41:12 paulc: when we deprecated support of EME on insecure contexts 01:41:16 Mark will respond to https://lists.w3.org/Archives/Public/public-html-media/2015Oct/0070.html with results of the TP session https://www.w3.org/wiki/TPAC2015/SessionIdeas#Secure_communication_with_local_network_devices 01:41:33 ... there was no support for pages to connect to insecure devices 01:41:44 ... we discussed second screen UCs at a meeting 01:42:49 s/paulc/markw/ 01:43:00 toddg has joined #html-media 01:43:00 ... before we didn't know of a way for apps to do stuff w/o a fix 01:43:09 ... but since it was raised that there's a workaround 01:43:19 MarkVickers: and we've raised this to #webappsec (mkwst) 01:43:28 present+ ddorwin 01:43:35 ddorwin: i'm on irc, and catching up on notes in github 01:43:40 https://www.w3.org/wiki/HTML/wg/2015-10-Agenda#EME 01:44:07 i/www/Topic: Meeting Logistics 01:44:26 paulc: yesterday, Matt got the best results from being on mute when not speaking 01:44:33 s/that there's a workaround/that there's at least one option that could work today, we have something we can experiment with 01:44:42 ... we've disconnected the cisco system from the room bridge 01:44:50 ... Josh_Soref will be here until 11am (15mins) 01:45:01 ... i've asked plh to give us an update on Charter 01:45:08 ... before we turn into a pumpkin tomorrow 01:45:10 plh: on that, nothing 01:45:21 plh: update... 01:45:35 ... we could at least extend the HTML WG 01:45:42 ... but, we'd have an HTML WG that doesn't work on HTML 01:45:48 ... nice aspect is that you guys keep doing what you're doing 01:45:58 ... and no question about patent commitments, they carry over 01:46:01 rrsagent, drat minutes 01:46:01 I'm logging. I don't understand 'drat minutes', joesteele. Try /msg RRSAgent help 01:46:09 ... obviously i'd have to talk to Directors as well 01:46:09 rrsagent, draft minutes 01:46:09 I have made the request to generate http://www.w3.org/2015/10/30-html-media-minutes.html joesteele 01:46:16 ... maybe we can change the name of the group w/o a full AC Review 01:46:21 s|rrsagent, drat minutes|| 01:46:32 ... one proposal, strongest so far, is to extend HTMLWG for the purpose of the Media TF until June 30 01:46:37 ... I think that's the bottom line proposal 01:47:31 paulc: ddorwin, if you look at the agenda, we spent the first 90 mins on topic 1 01:47:35 ... let's do topic 3 01:47:45 ... we have one formal objection against EME 01:47:54 topic: Formal Objections 01:48:07 paulc: we don't have to do anything about EME-1 yet 01:48:11 ... we have to do it before LC-CR 01:48:15 ... under Process 2014 01:48:36 ... "This formal objection will be handled no later than when EME progresses to LC/CR." 01:48:43 ... ddorwin, don't bother moving it to github 01:48:59 i|formal|-> http://dev.w3.org/html5/status/formal-objection-status.html#EME-1 EME-1 01:49:07 ddorwin: +1 01:49:41 s/on Wed/yesterday 01:49:54 topic: "Secure release" discussion with TAG 01:50:01 paulc: our issue-85 / tag issue-73 01:50:15 topic: ISSUE-85 "tracked" sessions: architectural concerns pending resolution with TAG 01:50:26 paulc: i don't think there are any updates, and i've been pushing Travis regularly 01:50:35 ... I don't think anything else until TAG does something 01:50:45 topic: Email items that might be issues 01:50:49 paulc: I think jdsmith said he'd look 01:51:04 topic: EME Initialization Data Correlation 01:51:18 paulc: I remembered the discussion 01:51:20 https://lists.w3.org/Archives/Public/public-html-media/2015Oct/0020.html 01:51:28 ... jdsmith you asked during the meeting whether the second message 01:51:30 Yves has left #html-media 01:51:40 ... in the last agenda, and i said, "well yeah", "it's a direct reply" 01:52:04 jdsmith: it's in my todo queue 01:52:27 action jdsmith to process the EME initData correlation issue 01:52:27 Created ACTION-105 - Process the eme initdata correlation issue [on Jerry Smith - due 2015-11-06]. 01:53:00 topic: Items David would like feedback on 01:53:08 paulc: i characterized this 01:53:23 ... a set of issues, you sent me a private email saying it'd be good to have feedback on a query 01:53:35 ... i took out the issues 80..84 as you suggested 01:53:39 ... our results are in github and irc 01:53:45 ... how would you like to process these? 01:53:57 ... i think i met your request to get F2F processing 01:54:07 ddorwin: those were the ones w/o clear direction 01:54:14 ... you've got feedback 01:54:21 .. i've marked some as needs-implementation 01:54:26 s/../... 01:54:29 ... that's good 01:54:46 paulc: thanks ddorwin on the background work, and coaching me on maximum to declare victory and progress 01:55:00 ... markw and MarkVickers, on ISSUE-118, is the ball in your court, MarkVickers ? 01:55:03 MarkVickers: yes 01:55:20 ddorwin: on ISSUE-118 01:55:31 markw: i'll send you the spec 01:55:40 http://www.dtcp.com/specifications.aspx 01:55:49 ddorwin: is it link-layer, or does communication come through the app? 01:55:52 MarkVickers: it's link-layer 01:56:03 ... the notion is, could this link-layer be supported w/o change 01:56:19 ... by only using EME that identifies part that determine encryption-layer, and media-support 01:56:35 ... w/o this, you have to use some combination of link-protection scheme + media type format 01:56:40 Previous discussions on OOB: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25434 and https://www.w3.org/Bugs/Public/show_bug.cgi?id=17615 01:56:42 ... and come up w/ some mime type that supports both 01:56:48 ... that's the only part of EME that would be used 01:57:00 ... there's never a Key, since it's link protection between two endpoints 01:57:14 s/-layer/-system/ 01:57:14 What was described is *not* EME. That's no more EME than HTML-CE is HTML. 01:57:31 ddorwin: not really EME 01:57:36 ... there's no interop story 01:57:48 ... i brought up a link to previous discussions 01:57:49 billf has joined #html-media 01:57:53 ... i don't think it makes sense to fork EME 01:58:02 ... maybe it's a use of requestMediaKeySystemAccess 01:58:08 scribe: joesteele 01:58:16 paulc: where is the information? 01:58:22 MarkVickers: its in IRC 01:58:30 rrsagent, draft minutes 01:58:30 I have made the request to generate http://www.w3.org/2015/10/30-html-media-minutes.html joesteele 01:59:04 MarkVickers: I am not interested in forking EME, but I think we can agree that when we get done with the process we will either have 0 or 1 Content Protection APIs in W3C. 01:59:21 … its a question of using the identification system in EME — don’t think this is cinompatible 01:59:36 markw: this depends how you identify the DTCP-IP content 01:59:58 … the only reaone you would need this is that the ability of the devic eto protect content will vayr based on whether it can handle this type 02:00:09 … seems to me it would be an entirely different typ of content 02:00:27 … I maight be wrong though — need to know more about how it fits into the stack 02:01:08 MarkVickers: to flesh out a bit more — an operator proivdes two options for getting content — from the locao device using DTCP-IP, the other is from the cloud using DRM protection s we have discussed 02:01:32 … the application is also written by the service provider, so they know what options they have, but they don’t know what the device looks like 02:01:47 … e.g. can this device support DTCP-IP? and can it decode this format? 02:01:59 … in which case it would come from the cloud 02:02:29 markw: the right way to do that might be to have a mime-type — there is no unprotedcted DTCP-IP content 02:02:55 MarkVickers: binding to a mime-type means that there are multiple variants on multiples axis which grows quickly 02:03:05 … we have 2 APIs that give a clean answer today 02:03:21 pangu has joined #html-media 02:03:32 markw: there arent 2 sep questions for DTCP-IP — it is a problem with the canPlayType API — you have to call it multiple times 02:03:44 … requestMediaKeySystem is much better in that respect 02:03:48 rrsagent, draft minutes 02:03:48 I have made the request to generate http://www.w3.org/2015/10/30-html-media-minutes.html joesteele 02:03:59 paulc: we know what next steps are — 02:04:05 MarkVickers: I took an action 02:04:24 jdsmith: I would like a very specific answer here eventually 02:04:32 topic: New issues since last meeting 02:04:32 s/requestMediaKeySystem is much better in that respect/requestMediaKeySystem is much better in that respect but if that is the only aspect of it that you want it's not clear it's appropriate/ 02:05:08 paulc: 3 of these issues have had progress since last meeting, excepting 112 02:05:18 … lets look at that and try to get an answer there 02:05:34 ddorwin: I already changed that to “needs implementation” 02:05:44 … so all are in the same state now 02:06:23 topic: Recent EME issues with outstanding pull requests 02:06:37 paulc: Mark and I discussed this morning — pull requests for 80-84 02:07:08 … we probably need more discussion on 87 to get traction on the others (minus 84 which is orthogonal) 02:07:19 … let discuss issue 80 and its pull request 02:07:28 topic: ISSUE-80 - "tracked" sessions: record of usage should track session usage, not individual key usage 02:07:51 ddorwin: I answrred Marks questions — plan to handle the rest tomorrow — nothing really pending there now. 02:08:24 paulc: so Mark and David will close on pull request 87 and once that is done Mark Watson can make the cascading changes required out of that 02:08:40 … markw it would help if you sent a summary email once you are done with step #1 02:08:54 markw: needs a rebae now and then will be easier to see 02:08:57 pangu_ has joined #html-media 02:09:03 topic: ISSUE-84 - "tracked" sessions: document usage for limiting concurrent streams 02:09:10 https://github.com/w3c/encrypted-media/issues/84 02:09:30 paulc: does not have a pull request — still waiting for feedback from people — might be able to just resolve this issue 02:09:36 rrsagent, draft minutes 02:09:36 I have made the request to generate http://www.w3.org/2015/10/30-html-media-minutes.html joesteele 02:09:54 paulc: I think if no complaints before next week we may just close this issue 02:10:17 jdsmith: I was thinking we should be more proactive — we can always re-open 02:10:29 paulc: any objection to closing now? 02:10:46 ddorwin: had some discussion today and thinkg that is more relevant — we can close it for now though 02:10:53 s/thinkg/thinking/ 02:11:21 topic: ISSUE-41 https://github.com/w3c/encrypted-media/issues/41 02:11:42 paulc: no convinced this we have concensus that this is a feature request 02:11:53 s/no convinced/not convinced/ 02:12:01 paulc: we have been going around on this awhile 02:12:09 … should Joe talk about this? 02:13:17 joesteele: I will pass the mike to Mark on this first 02:14:21 https://github.com/w3c/encrypted-media/issues/41#issuecomment-152360391 02:15:04 rus has joined #html-media 02:15:10 markw: we have this idea at the beginning that CDMs control the timing of messages. When this message requirement of one was introduced not sure anyone noticed. 02:15:21 … thinkg we all agree that we must have interoperability, 02:15:35 There was no introduction of requiring a message. It has been there since the very first version! 02:15:43 … we are really talking here about optimizations to cut down on the message exchanges — optiomizations that are already deployed 02:16:22 … the way CDMs determine what mesages to send have not been gone over in detail in this group 02:16:32 … that is one interpretation of the TAG review 02:16:50 … we can talk about whether that is a good thing — not sure that is a good thing to discuss yet 02:17:15 … there are many things that a CDM could do — but we are not yet at the place where we need to document this 02:18:21 joesteele: Look at v0.1b 02:20:52 kokabe has joined #html-media 02:21:16 markw: for me it is not important when it changes - it is the higher level principle that CDM control the messages they sent 02:21:41 … maybe it did not occur to us at the beginning — but it was not an agreed principle that there must be a message exhange 02:21:53 https://rawgit.com/w3c/encrypted-media/8f06759/encrypted-media.html#dom-generatekeyrequest 02:22:11 ddorwin: the claim that this was not in the spec is not true — this was in the first version 02:22:14 ^ Very first version of the spec 02:23:43 ddorwin: this opens up things we need to consider, maybe there are specific use cases we can talk about 02:23:46 Travis_ has joined #html-media 02:23:57 … figuring this out is going to take time 02:24:06 … and staying within the TAG requirements 02:24:20 … think we need to focus on all the other issues we should focus on for v1 02:25:13 markw: its about the level of scrutiny being applied here, always saying we need interoperability, this feels like it is getting a higher level of scrutiny 02:25:33 … I would be fine applying this level of scrutiny in v2 - when it is not for others 02:25:51 paulc: and those other features alo impact key flow 02:26:20 ddorwin: we would have to consider the impact because this impacts video format 02:26:39 … just because it is common encryption does not mean that it is interoperable 02:26:55 … the content encryption being different would cause a problem for other systems 02:27:10 … how you do renewal does not necessairly impact this 02:27:25 … it just happens that renewal is already within the spec 02:27:43 … applying more scrutiny is fine — and might be the fastest way to resolve htis 02:29:14 joesteele: the content encryption is exactly the same 02:29:57 ddorwin: we are not sure what you are doing here, would like to here more 02:30:07 … especailly with regards to the key chaining 02:30:15 … don’t want to cause us problems now 02:30:35 … you can hide things but that is not necesarily good 02:30:56 markw: David you are saying you want to have interoperability, Joe is saying this content would be interoperable 02:31:09 … if we can produce text that crequires this — could we move forward? 02:31:41 paulc: is ths issue that the text says a single message is mandatory? 02:31:45 joesteele: yes 02:31:55 ddorwin: but that does not let you actually use the keys provided 02:32:20 … to Marks question yes — but think this changes core assumptions and would be far reaching 02:32:30 … just like with secure release this would take a long time 02:32:53 … would be fine to do this if we can guarantee interoperability — but will delay a lot 02:33:13 markw: dont think this has to delay us a lot — because I dont think we need the level of detail you are implying 02:33:23 … you are making assumptions we do not know what they are 02:33:56 … if the CDM wants to do lots of key related operations as long as the app behavior is clear and according to the spec, should be fine and does not change things significantly 02:34:10 … would be tractable to come up with something that requires interop 02:34:57 ddorwin: the spec is very clear on what the CDM can do with the initData — we would run afoul of the TAG discussion otherwise 02:35:18 paulc: we have an active thread — lots of discussion going on 02:35:48 … as the chair I may have to ask who believes that the initial messgae is mandatory, but who can live with the spec like that 02:35:53 kinjim has joined #html-media 02:35:57 … we disagree on how long it will take to change 02:36:17 … we will have to trade-off getting features in and finish v1 02:37:17 markw: I want to clarify one point of difference — you can implement the CDM to do anythngin it wants with the initData as long as it conforms to the specification 02:37:31 paulc: that is pretty standard spec behavior 02:37:49 — as long as you are not breaking the spec conformance 02:38:14 paulc: how many of these optimizations impact the visible perfomance? 02:38:31 ddorwin: think this break interoperability — citing HTML example 02:38:49 paulc: disgree with this — look at the conformance clause there. 02:38:59 makrw: think we are in agreement on interoperability 02:39:11 s/makrw/markw/ 02:39:34 … any CDM should be able to process any compliant media — that does not breka interoperability 02:39:38 q+ 02:39:57 ack joe 02:41:25 joesteele: I believe that nothing in my proposal implies that the content would be non-interoperable and the process I mentioned for determining when a key is available is actually more interoperable across browsers than waiting for a message 02:41:49 topic: ISSUE-19 (Jerry) Ensure promises returned by methods are fulfilled before event handlers are executed 02:41:53 https://github.com/w3c/encrypted-media/issues/19 02:42:24 jdsmith: I am not assigned to this, but I have an action to comment 02:42:36 … about sequencing of events and promise resolutions 02:42:49 … I am concerned that simply delaying events is not good API design 02:43:06 … comment from Joey 02:43:15 https://github.com/w3c/encrypted-media/issues/19#issuecomment-126759849 02:44:00 jdsmith: I was suggesting we consider reviewing — he is stating renewal message are sent by events — I added a comment that speciyfing events are not fired until promises are resolved is good 02:44:13 … thi gives clarity — want event to return only after the promise is resolved 02:44:18 https://github.com/w3c/encrypted-media/issues/19#issue-54946877 02:44:21 s/thi gives/this gives/ 02:44:44 ddorwin: guaranteeing the order is quite complex … need to parse my notes on this 02:44:53 … need to spend time on this 02:45:30 action ddorwin to propose soluiton for issue-19 02:45:30 Created ACTION-106 - Propose soluiton for issue-19 [on David Dorwin - due 2015-11-06]. 02:48:04 paulc: David will get to issue-19 as soon as he can 02:48:13 … he believes this fix is mandatory for v1 02:48:44 rus: one thing we can do in bubbling up the errors is having systemCodes — so we know what is really going on 02:48:57 paulc: we had that 19 blocks 14 and 31 02:49:05 ddorwin: still believe that is true 02:49:12 … believe this will change the algorithms 02:49:25 … don’t want both changes to happen at the same time 02:49:32 https://github.com/w3c/encrypted-media/issues/31#issuecomment-152273712 02:50:07 topic: ISSUE-59 (David} 02:50:08 https://github.com/w3c/encrypted-media/issues/59 02:50:37 ddorwin: was assigned to me and progress has been made on the HTML spec which will let me make progress on this. New WebIDL spec will define time 02:50:53 … the primary Web IDL spec will remove data 02:51:00 s/remove data/remove date/ 02:51:27 ddorwin: I expect there to be progress there and I will ping it — this is blocked on Web IDL — we know what the intended behavior 02:51:32 … just monitoring 02:51:59 paulc: isn’t this a breaking interop problem? 02:52:32 ddorwin: we removed the use of Date but they had not removed Date. Boris said — yes we are really removing Date. He was supposed to send a patch. 02:52:47 … I will definie a new bug that says you should define Time as a concept 02:52:57 https://github.com/w3c/encrypted-media/issues/59#issuecomment-151220498 02:53:21 paulc: in this comment, you point to a hash IDL Date in another github — that is the current one? 02:53:37 ddorwin: it is in both version and the TR — might get removed from the TR dont know 02:53:43 Note that DOM's Event interface defines its timestamp as: https://heycam.github.io/webidl/#common-domtimestamp 02:53:47 paulc: so you know what needs to happen here 02:53:49 ddorwin: yes 02:53:52 q+ 02:54:03 Yet, that domtimestamp is not actually defined :-( 02:54:08 ack plh 02:54:34 plh: the are you aware of the hires stamp? 02:54:44 s/the are/are/ 02:54:53 http://w3c.github.io/hr-time/ 02:55:18 travis_: this sounded familiar — went to the DOM spec and the type for the timestamp links to Web IDL and there is no definition in Web IDL 02:55:27 … you would probably be safe using that same link 02:55:57 … to answer PLH comment about highres timestamp — think they may need something different here. that would not be comparable 02:56:21 ddorwin: would be great if Travis could update issue-19 with what he said 02:56:39 s/update issue-19/update issue-59/ 02:56:40 https://github.com/w3c/encrypted-media/issues/59 02:56:53 s/comparable/comparable because you need to compare the times and the hr-time time origin wouldn't work/ 02:57:16 topic: ISSUE-75 MediaKeyStatusMap: iterable declaration has unexpected behavior; ForEachCallback definition is incorrect 02:57:19 https://github.com/w3c/encrypted-media/issues/75 02:57:24 paulc: where are we on this? 02:57:45 ddorwin: this is another dependency on Web IDL 02:58:10 … there is an outstanding thread on script-coord — we need them to figure out how iterable works. As defined it is buggy and not useful 02:58:30 ^… in certain uses 02:58:44 Travis_: looks like this issue is being actively discussed and some movement on the Web IDL github issue 02:59:00 … sounds like the behavior will match the Array ForEeach syntax — if folks cares 02:59:09 s/folks cares/folks care/ 02:59:24 ddorwin: Cameron rpelied this morning but have not read yet 02:59:34 s/rpelied/replied/ 02:59:39 rrsagent, draft minutes 02:59:39 I have made the request to generate http://www.w3.org/2015/10/30-html-media-minutes.html joesteele 02:59:47 see https://lists.w3.org/Archives/Public/public-script-coord/2015OctDec/0039.html 02:59:57 paulc: in active motion so lets go on 03:00:13 topic: ISSUE-101 Normatively require distinctive identifiers to be different by top-level and EME-using origin 03:00:17 https://github.com/w3c/encrypted-media/issues/101 03:00:29 ddorwin: think this needs author input and followup a bit 03:00:43 see also https://www.w3.org/Bugs/Public/show_bug.cgi?id=27269 03:00:55 … there are two of these bugs now — some ambiguity now 03:01:10 … trying to figure out how to scribe the issues with Distinctive Identifier — coming soon 03:01:28 … this will be in issue 117 — should be up next week 03:01:44 paulc: this is one that is currently “needs implementation”? 03:01:51 ddorwin: it needs followup 03:02:26 … its assigned to me — I need to fill in the description 03:02:38 https://github.com/w3c/encrypted-media/issues/117 should be updated with better desc 03:02:58 topic: ISSUE-105 EME registry: Separate definitions of Initialization Data Types from Stream Format parsing 03:03:02 https://github.com/w3c/encrypted-media/issues/105 03:03:13 paulc: this blocks 104 and 106 03:03:26 ddorwin: also a Buggzilla bug — has been low priority 03:03:48 … it is now blcoking the MPEG-2 stuff as well as the registry — need to take some time to restructure 03:04:00 … proposed structure is there — needs feedback from the group 03:04:26 paulc: who will sign up to provide feedback? 03:04:46 paulc: plh can you express an opinion? 03:04:52 plh: I will provide personal comments on this 03:05:13 topic: ISSUES 107 and 108 03:05:29 paulc: PLH resolved these this week and they need implementation now 03:05:49 plh: I did an analysis of the references in the spec and opened another bug 03:05:56 https://github.com/w3c/encrypted-media/issues/107, https://github.com/w3c/encrypted-media/issues/108 03:06:16 topic: Needs author input bugs 03:06:22 paulc: believe we have covered this 03:06:26 https://github.com/w3c/encrypted-media/issues/68 03:06:29 https://github.com/w3c/encrypted-media/issues/98 03:06:33 https://github.com/w3c/encrypted-media/issues/101 03:06:36 https://github.com/w3c/encrypted-media/issues/102 03:06:56 s/: https://github.com/w3c/encrypted-media/issues/101/: https://github.com/w3c/encrypted-media/issues/100/ 03:07:11 paulc: these were processed earlier 03:07:23 topic: ISSUE-99 Remove note recommending setMediaKeys() be called before providing media data 03:07:26 https://github.com/w3c/encrypted-media/issues/99 03:07:34 paulc: marked as needs implementation now 03:07:41 jdsmith: the comment was the action 03:07:59 … I commented on whether it was acceptable 03:08:19 … ready for implementation 03:08:31 topic: ISSUE-110 Individualization text regarding device identifiers is overly broad and restrictive 03:08:35 https://github.com/w3c/encrypted-media/issues/110 03:08:45 paulc: David you pointed out this is related to 117 03:09:04 ddorwin: the description I am creating will point out why this is difficult 03:09:31 … changing the definition will change this — so this may not make sense in the end 03:09:41 paulc: so 110 is blocked by this work on 117 03:10:03 topic: Open Bugzilla bugs 03:10:05 https://www.w3.org/Bugs/Public/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&component=Encrypted%20Media%20Extensions&list_id=60418&product=HTML%20WG&query_format=advanced 03:10:26 paulc: David converted the bulkd of these to github issues 03:10:31 s/bulkd/bulk/ 03:10:48 paulc: recommended leaving the formal objection bug in Bugzilla for now 03:11:28 markw: I just moved the systemCode bug 03:11:46 paulc: some private discussion going on with Jerry to resolved before even moving right? 03:11:48 jdsmith: yes 03:12:03 paulc: would be useful to send a link to the group about the status 03:12:25 ddorwin: folks should be getting messages as these are moved — but not necessarily for each one 03:12:37 jdsmith: they should get a disposition message is they are closed 03:12:58 paulc: may end up with just one bug left in Bugzilla (to preserve the old links) 03:13:07 … suggest the editors continue as they have been doing 03:13:21 topic: EME issues "to be implemented" by Editors 03:13:27 https://github.com/w3c/encrypted-media/labels/needs%20implementation 03:13:34 paulc: 24 ready to be implemented 03:14:45 topic: TAG question 03:15:00 joesteele: if we do something that TAG did not approve of — what is the impact? 03:15:19 pangu has joined #html-media 03:15:29 paulc: would suggest we go back to the TAG and discuss anything that we consider “not appropriate” for EME. 03:15:36 topic: Next Meeting 03:15:47 paulc: would it be useful to get back together on Nov 17th? 03:16:24 ddorwin: I think github has worked really well — if we have stuff we need to discuss we can, but bring up things there. 03:16:55 paulc: I will try to craft an agenda even earlier than normal 03:17:22 … would like to point out the huge amount of work David has done in getting things done and providing suggestions on how to handle things 03:17:39 ddorwin: I will be out of time on the 17th 03:17:59 paulc: next week is 24th and Thankgiving in the US — don’t want to skip a whole month 03:18:19 … would be useful if maybe we can work something out 03:18:43 ddorwin: yes Matt and I are both going to the same thing — we will try to do as much as possible offline 03:18:48 paulc: any other business? 03:19:00 rrsagent, draft minutes 03:19:00 I have made the request to generate http://www.w3.org/2015/10/30-html-media-minutes.html joesteele 03:19:52 present+ plh 03:20:00 rrsagent, draft minutes 03:20:00 I have made the request to generate http://www.w3.org/2015/10/30-html-media-minutes.html joesteele 03:21:05 s/ISSUE-59 (David}/ISSUE-59 |expiration| should be Unix time like Date()/ 03:21:13 rrsagent, draft minutes 03:21:13 I have made the request to generate http://www.w3.org/2015/10/30-html-media-minutes.html joesteele 03:48:54 rus has joined #html-media 04:35:12 giuseppe has joined #html-media 04:36:34 RRSAgent, draf minutes 04:36:34 I'm logging. I don't understand 'draf minutes', giuseppe. Try /msg RRSAgent help 04:37:31 draft minutes 04:37:35 rrsagent, draft minutes 04:37:35 I have made the request to generate http://www.w3.org/2015/10/30-html-media-minutes.html giuseppe 04:53:52 kinjim has joined #html-media 04:54:02 rus has joined #html-media 04:56:48 rus_ has joined #html-media 04:59:09 rus_ has joined #html-media 05:29:33 kinjim has joined #html-media 05:34:19 ddorwin has joined #html-media 05:45:06 Zakim has left #html-media 05:51:24 rus has joined #html-media 06:01:01 kinjim has left #html-media 07:30:33 giuseppe has left #html-media 07:45:12 rus has joined #html-media 08:53:06 rus has joined #html-media 09:39:57 rus has joined #html-media 10:09:10 rus has joined #html-media 10:48:00 rus has joined #html-media 11:18:45 rus has joined #html-media