- From: Paul Cotton <Paul.Cotton@microsoft.com>
- Date: Wed, 6 Feb 2013 18:07:09 +0000
- To: "public-html-media@w3.org" <public-html-media@w3.org>
- CC: "Joe Steele (steele@adobe.com)" <steele@adobe.com>
- Message-ID: <AB5704B0EEC35B4691114DC04366B37F1F800E13@TK5EX14MBXC291.redmond.corp.microsoft.>
Re-posting to public-html-media@w3.org<mailto:public-html-media@w3.org> /paulc Paul Cotton, Microsoft Canada 17 Eleanor Drive, Ottawa, Ontario K2E 6A3 Tel: (425) 705-9596 Fax: (425) 936-7329 From: Joe Steele [mailto:steele@adobe.com] Sent: Tuesday, February 05, 2013 12:11 PM To: public-html-admin@w3.org Subject: {minutes} HTML EME telcon 2013-02-05 http://www.w3.org/2013/02/05-html-media-minutes.html ________________________________ - DRAFT - HTML Media Task Force Teleconference 05 Feb 2013 Agenda<http://lists.w3.org/Archives/Public/public-html-media/2013Feb/0002.html> See also: IRC log<http://www.w3.org/2013/02/05-html-media-irc> Attendees Present joesteele, pal, Michael_Thornburgh, +1.425.269.aaaa, KevinStreeter, ddorwin, adrianba, johnsim, paulc, BobLund, Aaron_Colwell, Mick_Hakobyan, MartinSoukup Regrets Chair Paul Cotton Scribe joesteele Contents * Topics<http://www.w3.org/2013/02/05-html-media-minutes.html#agenda> * Agenda/Roll call/Scribe<http://www.w3.org/2013/02/05-html-media-minutes.html#item01> * Previous minutes<http://www.w3.org/2013/02/05-html-media-minutes.html#item02> * Review Action items<http://www.w3.org/2013/02/05-html-media-minutes.html#item03> * baseline docs<http://www.w3.org/2013/02/05-html-media-minutes.html#item04> * Candidate FPWD<http://www.w3.org/2013/02/05-html-media-minutes.html#item05> * Outstanding Bugs<http://www.w3.org/2013/02/05-html-media-minutes.html#item06> * Summary of Action Items<http://www.w3.org/2013/02/05-html-media-minutes.html#ActionSummary> ________________________________ <adrianba> trackbot, start telcon <trackbot> Meeting: HTML Media Task Force Teleconference <trackbot> Date: 05 February 2013 <joesteele> Scribe: joesteele <joesteele> Chair: Paul Cotton Agenda/Roll call/Scribe <joesteele> done Previous minutes paulc: no comments Review Action items paulc: none outstanding baseline docs paulc: Editors draft updated Jan 22 -- any updates since then? ddorwin: no <paulc> Editors draft: https://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html Candidate FPWD paulc: stalled <paulc> FPWD candidate: https://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media-fpwd.html paulc: folks on call have been participating - chairs met with W3C team and trying to figure out how to handle dissent versus support ... expect a breakthru this week pal: any data available? paulc: no questions at this time -- no missing information ... lets spend time on the bugs Outstanding Bugs <paulc> http://tinyurl.com/7tfambo paulc: 32 bugs this weekend - some discussion with editors about which to cover and build two lists to look at under 6/7 ... 7 is a batch of bugs from David ... error related bugs ddorwin: bug list looks incorrect -- 6/7 run togethers paulc: ok - let's look at B-F and A-D -- could do them in the order specified ... or someone suggest an order ddorwin: B has been discussed for two calls paulc: not sure whether we wanted to talk about this one ... I am ok with skipping joesteele: I am ok as well Bug -- Should we validate defaultURL/destinationURL? http://lists.w3.org/Archives/Public/public-html-media/2013Jan/0062.html <paulc> Should we validate? <paulc> http://lists.w3.org/Archives/Public/public-html-media/2013Jan/0062.html paulc: believe this message is from David <paulc> Good morning Adrian. ddorwin: background is -- when adding this to webkit, got the feedback that this should be a URL ... this implementation does validation of the URL ... so I sent to the list ... otherwise need to push back on Webkit folks adrianba: problem here is - where is the definition of the validation? ... not a big enough issue for us to try and solve ... (last part is a question) ... we run into this issue when one UA does different validation, one is considered a bug when its just underspecified paulc: you are asking a question about where this is specified? adrianba: no -- if we require it -- where is it specified? extra work for us ddorwin: makes sense -- we should specify one way or the other ... or this will be a bug ... I will take action item to look where we are using this type paulc: you will open a bug one way ot the other based on research ddorwin: Adrians reasoning was good -- maybe reply to email so we have a record Bug 17199 -Provide examples for and get feedback on Key Release https://www.w3.org/Bugs/Public/show_bug.cgi?id=17199 ddorwin: Mark is not here -- should skip paulc: Mick is here -- ok with skipping? Mick_Hakobyan: ok Bug 19810 -Should key IDs be required in content and addKey()'s parameter? https://www.w3.org/Bugs/Public/show_bug.cgi?id=19810 paulc: no updates for a while ddorwin: original spec handled the case where media did not have key ids ... should we eliminate the handling to simplify the algorithm ... current formats specify this ... would this cause problems for anyone MartinSoukup: HLS also uses a key ID johnsim: my point was that key ids could be overwritten ... or provided by the application or metadata ... what provisions are in the spec for this? ddorwin: in the addKey definition and the encrypted block algorithm <adrianba> https://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html#dom-update ddorwin: could drop the decision login around the key ID johnsim: I agree with you then -- should always be there at this point in the algorithm ddorwin: 3 formats we have talked about all have it -- propose to eliminate it. <adrianba> +1 Bug 20798 -keySystem strings should be compared case-sensitively https://www.w3.org/Bugs/Public/show_bug.cgi?id=20798 paulc: last updated last week adrianba: this is about how you should look at the keysystem string ... some questions from Microsoft people about this ... not described in the spec +q adrianba: propose case sensitive spec ... looks like reverse domain names which are not commonly case sensitive ... we need to specifiy paulc: did that answer your question David? <ddorwin> https://bugzilla.mozilla.org/show_bug.cgi?id=800600 ddorwin: I just had some initial thoughts -- found another bug <paulc> David's questions: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20798#c1 ddorwin: some specs do not mention - canPLayType does not mention ... should say something paulc: Adrian your recommendation was case-sensitive? ... sounds like we need to specify ... do you know what the behavior of IE is? joesteele: what about Unicode strings? adrianba: could be a Unicode string -- David raised this ... in the end it is just a string Bug 20338 -Explicitly specify whether initData is required for Clear Key https://www.w3.org/Bugs/Public/show_bug.cgi?id=20338 paulc: skip this for now ... (never mind -- bad scribing) ddorwin: currently allows data and type to be optional ... not clear whether ClearKey supports this ... propose to make it clear whether it is optional -- leaning towards not optional joesteele: +1 <Mick_Hakobyan> +1 <adrianba> +1 paulc: any other opinions? ddorwin: great -- sounds like a decision Bug 20688 -Provide more details on when keyadded should be fired https://www.w3.org/Bugs/Public/show_bug.cgi?id=20688 ddorwin: keyAdded was originally intended to indicate a key was added this was important ... key add could also be seen as a response to add key ... bug to define when this is fired joesteele: +q ddorwin: most of this is in the bug ... new unique key, update operation, key renewal are all possibles <ddorwin> Possible purposes: <ddorwin> 1) New (unique) key added. <ddorwin> 2) New key info added, possibly for an existing key. <ddorwin> 3) update() operation completed successfully, regardless of whether it involved addition of a key. (This would likely result in renaming this method.) <ddorwin> Example questions to address: <ddorwin> * Should keyadded be fired once for each key that is added (if a license contains multiple keys)? <ddorwin> * Should keyadded be fired if the key was already known? <ddorwin> * Should keyadded be fired if the license/key policy was updated? <ddorwin> * Should keyadded be fired for successful completion of update() when no further messages need to be sent to the server? <ddorwin> https://www.w3.org/Bugs/Public/show_bug.cgi?id=20689 joesteele: would like to use this channel for generic comm -- does this interact? <ddorwin> "Specify how CDM should indicate successful completion with no message for server" ddorwin: same as last possible use of add Key <johnsim> +q joesteele: does this mean ready to play? ddorwin: question is -- what should it mean? adrianba: mental model for this I will describe ... may need an additional event ... way I have in mind is that they are for working with the session representing comm with the license server ... after a create session, I get either a key message to send to license server ... or I get told that all of the information is already there -- which is key added ... end of that comm has been reached ... keyadded simply means the session comm has succesfully completed ... could be multiple keys, but you should not expect another key message paulc; any repsonse? johnsim: I had a similar perception to Adrian ... are there other events we need to define? ... not suggesting they do need to be, but if there are distinct events do they need to be identified? ddorwin: I like Adrians model - less ambiguity ... maybe not as use case for key added as defined ... could be multiple key message transactions in progress though ... meaning could be ambiguous then adrianba: expectation is that other messages from the CDM would be in a different session ... maybe I created a different session ... sessions would correlate that way ... session would be waiting for the update in that case ... would mean end of that conversation thread ddorwin: I did not mean that would be the end of conversation ... one variation would be a renewal request joesteele: +q joesteele: this would prompt the app to try again ... this scenario could be handled fine ... just need to define it correctly adrianba: need more time to think through the consequences ddorwin: sounds like Adrian is assuming a new session when you switch between two licenses joesteele: my use case was license rotation due to blackout with short lived keys ddorwin: we have said that createSession was for an initData ... this was discussed related to heartbeat ... should we implement heartbeat as multiple sessions or reuse the session paulc: do we want to move on to another> <ddorwin> https://www.w3.org/Bugs/Public/show_bug.cgi?id=20689 Bug 20689 -Specify how CDM should indicate successful completion with no message for server https://www.w3.org/Bugs/Public/show_bug.cgi?id=20689 ddorwin: same discussion we just had ... sounds like we convert the addKey to done ... addresses the previous bug Bug 20691 -Should createSession()'s type parameter be required? https://www.w3.org/Bugs/Public/show_bug.cgi?id=20691 paulc: last item on this bug list ddorwin: this is simplifying things a bit ... primary purpose of type was to specify the initData ... seems like we could just make it required ... CDM could define a string for their "default" use case paulc: feedback? adrianba: I think I agree with David ... we have specified that the format depends on media type ... we don't yet have a use case where that is not necessary ... could always change in the future paulc: believe that takes us through the agenda items except error related bugs adrianba: there are error bugs assigned to me - we have been working on the proposal ... not quite ready yet ... will try to have by next EME call in two weeks paulc: do you have the list handy? adrianba: no adrianba: between 1-5 bugs <ddorwin> Error bugs: 16617, 16737, 16857 paulc: done for today if no other business adrianba: will not be able to make next weeks call paulc: will need a scribe for next week ... adjourned 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.137 (CVS log<http://dev.w3.org/cvsweb/2002/scribe/>) $Date: 2013-02-05 17:01:35 $ Joe Steele steele@adobe.com<mailto:steele@adobe.com>
Received on Wednesday, 6 February 2013 18:08:09 UTC