- From: Joe Steele <steele@adobe.com>
- Date: Tue, 18 Aug 2015 17:10:13 +0000
- To: "public-html-media@w3.org" <public-html-media@w3.org>
- Message-ID: <34AA7B7E-47BB-4769-BF46-51B4970385BA@adobe.com>
http://www.w3.org/2015/08/18-html-media-minutes.html <http://www.w3.org/2015/08/18-html-media-minutes.html> Joe Steele <http://www.w3.org/> HTML Media Task Force Teleconference 18 Aug 2015 Agenda <https://lists.w3.org/Archives/Public/public-html-media/2015Aug/0021.html> See also: IRC log <http://www.w3.org/2015/08/18-html-media-irc> Attendees <> Present paulc, markw, davide, steele, joesteele, ddorwin, jdsmith Regrets Chair paulc Scribe joesteele_ Contents Topics <http://www.w3.org/2015/08/18-html-media-minutes.html#agenda> Issue 45, pull request 54 <http://www.w3.org/2015/08/18-html-media-minutes.html#item01> Issue 41, 52, 53 cluster <http://www.w3.org/2015/08/18-html-media-minutes.html#item03> ISSUE-63 and Pull Request-66 <http://www.w3.org/2015/08/18-html-media-minutes.html#item04> ISSUE-77 - Correct object name at the beginning of section 6.3 MediaKeyStatusMap <http://www.w3.org/2015/08/18-html-media-minutes.html#item05> ISSUE-17 - Replace "fire a simple event" with "fire an event" for non-simple Events <http://www.w3.org/2015/08/18-html-media-minutes.html#item06> Next meeting <http://www.w3.org/2015/08/18-html-media-minutes.html#item07> Summary of Action Items <http://www.w3.org/2015/08/18-html-media-minutes.html#ActionSummary> <trackbot> Date: 18 August 2015 <paulc> Agenda: https://lists.w3.org/Archives/Public/public-html-media/2015Aug/0021.html <https://lists.w3.org/Archives/Public/public-html-media/2015Aug/0021.html> <jdsmith> jdsmith +present <paulc> help present <joesteele> scribe: joesteele_ <paulc> Agenda: https://lists.w3.org/Archives/Public/public-html-media/2015Aug/0021.html <https://lists.w3.org/Archives/Public/public-html-media/2015Aug/0021.html> Issue 45, pull request 54 paulc: Google presented a technical position paper <joesteele> … multiple calls for secure release to be put back in the spec <joesteele> … late emails still addressing this <joesteele> … let’s go around and discuss what should happen <joesteele> … and find out how much concensus we have <joesteele> … unless folks have questions, we probably don’t need to dig much more on this <joesteele> markw: David raised some interesting points but don’t think it fully replaces the secure release outlined <joesteele> … David has pointed out some client spec issues, but don’t believe they cannot be addressed by all browsers <markw> I don't think the client issues raised are "web architecture: issues suitable for the TAG <joesteele> jdsmith: I did not respond in a technical manner to the license renewal post, but we have some concerns about scalability <joesteele> … but we do have partners asking for this, industry demand <joesteele> … we think it should be in the spec to be interoperable and not too difficult to address <joesteele> … agree that this should be addressed in the task force <paulc> Is BobLund on the phone? <joesteele> joesteele: we agree that the license renewal is interesting but do not feel it 100% replaces the secure release as we have implemented <joesteele> BobLund: I can comment in a minute — hold on <joesteele> q: <joesteele> paulc: David do you want to speak? <joesteele> BobLund: I want to re-iterate our support for seure release — we have service provides who want to use it <ddorwin> Can people hear me (before Bob started talking)? <joesteele> … we are seeing multiple browsers, and multiple service providers implementing this <paulc> No we could not hear you. Sorry. <jdsmith> To ddorwin: I didn't hear you speak... <joesteele> paulc: do you have a position on license renewal? <joesteele> BobLund: License renewal is also used in some cases, but at least one of our members sees a need for both <joesteele> … dont think one is a replacement for the other <joesteele> paulc: David we could not hear you before — try again please <ddorwin> sorry. i'll try calling again <joesteele> ddorwin: <no audio> <ddorwin> our position is in the email I sent last night. I'll follow up on Mark's reply. <BobLund> dial in /irc <paulc> Is Davide on the phone call? <davide> i am using webex voip <joesteele> ddorwin: I responded in the email thread last night <davide> but i have nothing to say on this matter :) <joesteele> … if folks are sure this is not a web architecture issue we can move one <joesteele> jdsmith: can you summarize your concenrs about lifetime of objects? <paulc> See https://lists.w3.org/Archives/Public/public-html-media/2015Aug/0025.html <https://lists.w3.org/Archives/Public/public-html-media/2015Aug/0025.html> for David's position on web architecture issue <joesteele> ddorwin: unless you have persistent storage, when you close the application you can’t specifiy anything afterwards. there is no way of specifying something to happen after the apps is closed. <joesteele> … there is no other feature that has this <joesteele> markw: if you define what happens at close to not include this then it will not happen <joesteele> … I understand the req to not allow the web app to control how long it takes, but the browser could actually make this happen <joesteele> ddorwin: 2 of the browsers uses OS based systems that are very different <joesteele> … the question is not whether it can be done but whether it should be done <joesteele> … by definition the feature requires that after the apps is closed something ahppens <joesteele> markw: this is an implementation detail, not a web architecture issue <joesteele> ddorwin: I am suggesting we get input because neither of us are epxerts here <joesteele> BobLund: as far as I know there are no specs in W3C for user agent behavior other than algorithem behaviors for an API <joesteele> … this seems like an implementation detail <joesteele> ddorwin: this feature can only be implemented with this behavior <joesteele> … the implication is that the browser has to do this <joesteele> markw: there are things in the web platform that happen when the app is closed, ie. the onClose event <joesteele> … this does not seem out of sync with those, no lack of precedence here <joesteele> ddorwin: TAG has proposed some things as anti-features and they are being phased out <joesteele> paulc: we have two questions <joesteele> … 1) should we accept pull request 54 — seems to be substantial support <joesteele> … 2) even if we accept the request, should we get addiitonal feedback from TAG <joesteele> … seeems to me that the task force should decide here <joesteele> … is there anyone that cannot live with accepting this? <joesteele> ddorwin: until I answer the architectural question, <joesteele> paulc: these are things we can do after the pull request <joesteele> … so you are saying you object to the pull request? <joesteele> ddorwin: yes we have been working 4-5 months and are still working <joesteele> paulc: we have substantial support for accepting this <joesteele> … we don’t want to wait on getting the TAGs opinion <joesteele> … I propose we accept the pull request <joesteele> … and keep the other discussion orthogonal <joesteele> … there are avenues for you to object if you feel it necessary <joesteele> … would Mark or Jerry implement the pull request? <joesteele> jdsmith: I will handle the request since Mark offered <joesteele> ddorwin: I am already having discussions with the TAG so I can handle the other discussion <joesteele> paulc: let’s make that discussion transparent <joesteele> ddorwin: yes. I was just confirming this was an appropriate TAG discussion <ddorwin> For the record, I object to inclusion before resolving the architectural issues. <joesteele> paulc: if you have other questions on this, please open new issues Issue 41, 52, 53 cluster <joesteele> paulc: we can try to get the positions out before we have to leave <markw> \me oh, I guess I meant I would still be on the phone <paulc> ISSUE-41 Update algorithms to reflect keys being provided in the Initialization Data https://github.com/w3c/encrypted-media/issues/41 <https://github.com/w3c/encrypted-media/issues/41> <joesteele> ddorwin: Joe and Mark countered with examples of where issue 52 is blocked and non supported by the algoithsm <joesteele> paulc: do we have enough to resolve issue 41? <joesteele> ddorwin: made a proposal but not enough feedback yet <ddorwin> The proposal for resolving issue 52, is at the end of https://lists.w3.org/Archives/Public/public-html-media/2015Aug/0023.html <https://lists.w3.org/Archives/Public/public-html-media/2015Aug/0023.html> <joesteele> joesteele: I have not had a chance to review <joesteele> … and won’t have time on this call <joesteele> joesteele: 52 blocks 41 and 41 blocks 53 <joesteele> paulc: so David your proposal is how to handle issue 52? <paulc> ISSUE-52 Remove reference to keys in Initialization Data definition https://github.com/w3c/encrypted-media/issues/52 <https://github.com/w3c/encrypted-media/issues/52> <joesteele> ddorwin: yes <ddorwin> Issue 52 is basically independent and relates to a bug in the existing text. The other Issues are new features. <joesteele> paulc: any other comments on Davids proposal <joesteele> … Joe we need you to respond on this item <joesteele> ddorwin: 41 would need algorithm design if we resolve 52 <joesteele> joesteele: agreed <paulc> Issue-41 and ISSUE-53 need further elaboration after we resolved ISSUE-52 <paulc> Most of what is needed is there for ISSUE-41 but ISSUE-53 certainly needs more description if we decide to do that feature. <joesteele> joesteele: I believe I have provided much of the detail for 41, but needs more work. <joesteele> paulc: if you and David can get concensus on 52, would be good to specify how 41 should move forward <joesteele> joesteele: makes sense <joesteele> paulc: 53 will remain on hold then until the others are done ISSUE-63 and Pull Request-66 <joesteele> paulc: action on David <joesteele> ddorwin: have not had a chance to finish this - try to do in the next two weeks <paulc> https://github.com/w3c/encrypted-media/pull/66 <https://github.com/w3c/encrypted-media/pull/66> will be reviewed by David ISSUE-77 - Correct object name at the beginning of section 6.3 MediaKeyStatusMap <joesteele> paulc: no comments on this yet <joesteele> jdsmith: just a typo I think <paulc> https://github.com/w3c/encrypted-media/issues/77 <https://github.com/w3c/encrypted-media/issues/77> <joesteele> paulc: if you are confident it is editorial, please assign to yourself and make the change ISSUE-17 - Replace "fire a simple event" with "fire an event" for non-simple Events <paulc> https://github.com/w3c/encrypted-media/issues/71 <https://github.com/w3c/encrypted-media/issues/71> <joesteele> paulc: Jerry this was where you went to the WG to get advice <joesteele> … and you now have a proposal in hand? <joesteele> jdsmith: I got some additional advice after I made the proposal <joesteele> … David is right, these are not simple events <joesteele> … we have a named event, the change I made was to fire the named event <joesteele> … but I have an additional comment i need to digest <paulc> https://github.com/w3c/encrypted-media/issues/17 <https://github.com/w3c/encrypted-media/issues/17> <joesteele> … my proposal was essentialy David’s proposed language but with the named event from our spec. <joesteele> paulc: is the feedback in the response? <paulc> Proposal in https://github.com/w3c/encrypted-media/issues/17#issuecomment-128855753 <https://github.com/w3c/encrypted-media/issues/17#issuecomment-128855753> and feedback in https://github.com/w3c/encrypted-media/issues/17#issuecomment-129374107 <https://github.com/w3c/encrypted-media/issues/17#issuecomment-129374107> <joesteele> paulc: joe please look at issue 71 <joesteele> … folks review the rest of the agenda Next meeting <paulc> We will try for an EME meeting on Tue Sep 1. <joesteele> : rrsagent, generate minutes Summary of Action Items <>[End of minutes] Minutes formatted by David Booth's scribe.perl <http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm> version 1.140 (CVS log <http://dev.w3.org/cvsweb/2002/scribe/>) $Date: 2015/08/18 17:07:49 $
Received on Tuesday, 18 August 2015 17:10:45 UTC