- From: Joe Steele <steele@adobe.com>
- Date: Tue, 12 Aug 2014 16:14:40 +0000
- To: "<public-html-media@w3.org>" <public-html-media@w3.org>
- Message-ID: <71A1642C-E8C2-4CAA-9FB9-3D987A44DAF3@adobe.com>
http://www.w3.org/2014/08/12-html-media-minutes.html Joe Steele HTML Media Task Force Teleconference 12 Aug 2014 Agenda See also: IRC log Attendees Present jdsmith, markw, +1.714.928.aaaa, joesteele, davide, Niels_Thorwirth, glenn, +1.425.936.aabb, adrianba, paulc, ddorwin, [IPcaller], heff_ Regrets Chair paulc Scribe joesteele, joesteele_ Contents Topics traffic EME status and bugs EME bugs with proposal Bug 25866 - "needkey" event name is misleading Bug 18515 - Provide more details on behavior of the media element when the key for an encrypted block is not available Bug 20336 - Revert addition of keySystem attribute to HTMLSourceElement Bug 26372 EME bugs awaiting input from Task Force or actions Bug 25268 - Reduce the burden on applications to deduplicate initData from many needkey events [Bug 26332] Applications should only use EME APIs on secure origins (e.g. HTTPS) [Bug 26401] Key message destinationURL usage is not reflected in examples Bug 26207 - Provide a way to check system capabilities required for UHD playback Do we need LoadSession? EME Use cases wiki Timing, Scribe, Chair for next meeting Adjourn Summary of Action Items <trackbot> Date: 12 August 2014 <joesteele> Scribe: joesteele <scribe> Chair: markw <scribe> Chair: adrianba <paulc> trackbot, start meeting <trackbot> Meeting: HTML Media Task Force Teleconference <trackbot> Date: 12 August 2014 <scribe> Chair: paulc traffic paulc: bad today <paulc> Agenda: http://lists.w3.org/Archives/Public/public-html-media/2014Aug/0005.html EME status and bugs EME bugs with proposal Bug 25866 - "needkey" event name is misleading https://www.w3.org/Bugs/Public/show_bug.cgi?id=25866#c4 <heff_> hey, 714 is me. Steve from Brightcove/Video.js paulc: here is the proposal ddorwin: was talking to some team members to this -- anything really accurate is too long and wordy. This seems short and reasonable <adrianba> +1 joesteele: +1 paulc: any objections? ... make it so David ddorwin: ok Bug 18515 - Provide more details on behavior of the media element when the key for an encrypted block is not available <paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=18515 paulc: Jerry expressed some concern that the solution in the bug had not resovled some race conditions <paulc> Race conditions concerns: https://www.w3.org/Bugs/Public/show_bug.cgi?id=18515#c31 jdsmith: was not a concern -- just was raised paulc: are there outstanding issues to resolve? <paulc> Comments since last meeting: https://www.w3.org/Bugs/Public/show_bug.cgi?id=18515#c40 paulc: some comments since last mtg ddorwin: that is my comment to Jerry -- if he agrees lets move forward jdsmith: have not looked yet ... leave for editors and assume will be resolved Bug 20336 - Revert addition of keySystem attribute to HTMLSourceElement <joesteele_> https://www.w3.org/Bugs/Public/show_bug.cgi?id=20336#c8 <joesteele_> Scribe: joesteele_ paulc: any resolution needed by task force? <paulc> David's proposal: I plan to submit a changeset that removes HTMLSourceElement (rather than spending time converting it). paulc: proposing remove rather than convert correct? <adrianba> +1 <paulc> Related to https://www.w3.org/Bugs/Public/show_bug.cgi?id=23828#c4 ddorwin: Jerry and I discussed, p3828 if no objection will make removal permanent ... don't think can support with the way isTypeSupported is today jdsmith: I agree paulc: any objections? ... presume resolved Bug 26372 paulc: skipped last week because David was not here <paulc> See David's previous changes: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26372#c2 paulc: you provided a changeset with this comment ddorwin: I closed the old bug and opened this one <paulc> See Joe's feedback: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26372#c3 ddorwin: listed some of the scenarios that are not covered by Promises ... still a question about how to return them -- error attribute does not seem to make sense ... looking for input from the group, both on errors and how to report <paulc> See Joe's question: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26372#c4 paulc: do you have an answer to comment#4? ddorwin: loading would be a Promise rejected with DOMException - general problem of how to report system codes in this case paulc: is there a separate bug for this? ddorwin: no we closed the earlier bug, Jerry is going to think about how to do system codes <paulc> Previous bug was https://www.w3.org/Bugs/Public/show_bug.cgi?id=21798 related to this. paulc: old bug was 21798 jdsmith: we still have interest in a system code, but still looking for a way to add back into the spec ... in the discussion I mentioned putting systemCode as an attribute on the exception but that was viewed as unacceptable <ddorwin> subclassing DOMException bug where systemCode was discussed: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25896 jdsmith: do others have opinions? ... we think they are useful for debugging errors in actual use -- need to retain somehow paul: any alternatives? <markw> My comment is just that it is essential for us to expose the system code in failure cases jdsmith: only one I floated was attaching the value to the MediaKeySession - but only captures last error encountered paulc: was that discussed? jdsmith: we had a derivative that returned as a sub-class of DOMException but that is gone now ... DOMException has no provision for this -- only named values ... I will open a new bug and make a proposal EME bugs awaiting input from Task Force or actions Bug 25268 - Reduce the burden on applications to deduplicate initData from many needkey events <paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=25268#c6 paulc: David has a proposal in comment #6 reverted earlier change and has been that way since July 11th ddorwin: waiting for a bright idea here -- has been no good proposal yet paulc: can someone volunteer to take a look ... propose a new solution? glenn: this is on dedup of initData? ... is this considered an optimization? would it impact functionality if not addressed? ddorwin: correct -- its an optimization glenn: this could be delayed to a later version if needed ddorwin: correct - does not block the standards progress paulc: wish there was a status for this ... leave this on the list for now ... Glenn please add your comment to the bug [Bug 26332] Applications should only use EME APIs on secure origins (e.g. HTTPS) <paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=26332 paulc: seemed to be a consensus at last meeting to use RFC SHOULD <paulc> At the Jul 22 meeting we agreed that recommending that HTTPS SHOULD be used was a possible consensus position. Jerry offered to add a comment to the bug. paulc: not a requirement ... since you were not there -- put back on the queue markw: ... don't recall that concensus, don't think this is specific to EME, this is general to all web apps ... should not be just for our spec jdsmith: don't know about concensus, but we did make that statement ... not sure we've all agreed that's appropriate <paulc> Jul 22 minutes: http://www.w3.org/2014/07/22-html-media-minutes.html#item07 ddorwin: this was not last mtg <paulc> Jul 29 minutes reference: http://www.w3.org/2014/07/29-html-media-minutes.html#item10 paulc: so Mark you are not convinced this should be a statement? markw: yes I don't think this should be a normative statement <paulc> See Jerry's comment https://www.w3.org/Bugs/Public/show_bug.cgi?id=26332#c18 and Mark's reply https://www.w3.org/Bugs/Public/show_bug.cgi?id=26332#c19 markw: think people were concerned about identifiers, we have some text about that already. HTTPS might be one of the mitigations but should not go so far as normative language ddorwin: this is pretty much what we know, the difference is that this exposes a permanent or semi-permanent identifier. Will continue to be discussion in and out of bug paulc: this is the only bug that shows up on social media streams, personal issue maybe even public policy issue ... but not sure how to resolve it ... reluctant to leave it open so we can make progress ... what will change folks opinion here? ddorwin: this bug has only been open a month, think its fine to leave it open a while paulc: If we can't get concensus by end of August let's revisit glenn: Cox would like to oppose making that change. Think it's an application/policy issue [Bug 26401] Key message destinationURL usage is not reflected in examples https://www.w3.org/Bugs/Public/show_bug.cgi?id=26401 joesteele: I have not updated the bug as yet ... will follow up on this this week Bug 26207 - Provide a way to check system capabilities required for UHD playback paulc: Jerry was going to provide more data jdsmith: don't remember the extra data, but there has been a lot of discussion <paulc> See http://www.w3.org/2014/07/29-html-media-minutes.html#item12 <paulc> From the minutes: "jdsmith: yes that is on our list, we considered testing a small piece of content. Will have more data next week" jdsmith: think it is unnatural to require apps to remember the session <adrianba> https://www.w3.org/Bugs/Public/show_bug.cgi?id=26207#c5 jdsmith: for earlier comment I had skipped ahead -- ... I have added a comment and would like to resolve that bug (26207) ... concensus that addressing the broader set of capabilities is outside scope of EME ... that leaves pre-testing for certain conditions, but don't have the information yet ... should not leave bug open while we wait for results there, if something changes we can re-open <scribe> ... closed it this morning paulc: any objections to this? jdmith: as RESOLVED FIXED, but no changes paulc: WORKSFORME sounds good ... add a comment as to exactly why this is being resolved that way Do we need LoadSession? http://lists.w3.org/Archives/Public/public-html-media/2014Aug/0004.html paulc: best summary statement ... Joe is asking for feedback, gave some himself ... how should we proceed? <paulc> joesteele: Looking for Jerry's feedback and feedback from other providers <paulc> ... Maybe I am wrong but it does not work well for my situation <paulc> ... I feel this is overkill for the situation jdsmith: there may be a need in this area to allow for different CDM behavior, know that is not popular ... right now loadSession is optional, might not be a value-add for Playready, trying to model this ... feel like it is more natural for persistent licenses to be re-used automatically ... that does not seem like a good fit ddorwin: from Jerry and Joe would like the use cases or app models where persistent licenses are used ... not clear why persistent licenses are used in all cases ... would like to know the different models ... people have said they would like to re-use on createSession -- would like that to be more concrete joesteele: will provide the links to my earlier comments on this ddorwin: documentation would be good EME Use cases wiki <paulc> https://www.w3.org/wiki/HTML/Media_Task_Force/EME_Use_Cases <paulc> - joesteele: the Key Release section will change still joesteele: The Key Release section has not changed because it is dependant on the loadSession discussion <paulc> - paulc: maybe send an email making the connection between the bugs and the use cases to draw interest from the group paulc: we also discussed linking the bugs back to the use cases joesteele: that has not been done yet either <paulc> Notes from Joe and Paul are from Jul 29 minutes: http://www.w3.org/2014/07/29-html-media-minutes.html#item14 paulc: so those items are pending Timing, Scribe, Chair for next meeting paulc: two outstanding MSE bugs -- asked editors for feedback ... would like to put test suite on the next agenda ... then follow with EME status ... still waiting for information from poll on the test suite, need information for CR ddorwin: FYI -- I will fix a few bugs we discussed today and then start the move to ReSpec ... spec may look ugly for awhile paulc: before or after heartbeat? ddorwin: after paulc: sent a note that suggested we update the latest page as it is getting stale ... David will do this first. Couple of bugs pending this reorg right? ddorwin: yes Adjourn paulc: any other business? paulc: thanks! Summary of Action Items [End of minutes] Minutes formatted by David Booth's scribe.perl version 1.138 (CVS log) $Date: 2014-08-12 16:10:43 $
Received on Tuesday, 12 August 2014 16:15:17 UTC