W3C home > Mailing lists > Public > public-html-media@w3.org > August 2015

{minutes} HTML WG media telecon 2015-08-18 - EME bug status

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

This archive was generated by hypermail 2.3.1 : Tuesday, 18 August 2015 17:10:46 UTC