{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

See also: IRC log

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
Agenda/Roll call/Scribe
Previous minutes
Review Action items
baseline docs
Candidate FPWD
Outstanding Bugs
Summary of Action Items
<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 version 1.137 (CVS log)
$Date: 2013-02-05 17:01:35 $

Joe Steele
steele@adobe.com