HTML Media Task Force Teleconference

05 Feb 2013


See also: IRC log


joesteele, pal, Michael_Thornburgh, +1.425.269.aaaa, KevinStreeter, ddorwin, adrianba, johnsim, paulc, BobLund, Aaron_Colwell
Paul Cotton


<adrianba> trackbot, start telcon

<trackbot> Date: 05 February 2013

<scribe> scribe: joesteele

<Mick_Hakobyan> how do I get zakim to list phone numbers?

trackbot-ng, start telcon

<Mick_Hakobyan> thank you, I see it remembered my phone #

<trackbot> Meeting: HTML Media Task Force Teleconference

<trackbot> Date: 05 February 2013

<scribe> Scribe: joesteele

<scribe> Chair: Paul Cotton

<BobLund> *6

Agenda/Roll call/Scribe

<scribe> 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: 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


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


<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


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


scribe: 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 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.137  of Date: 2012/09/20 20:19:01  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/?1/pal/
Succeeded: s/correllate/correlate/
Succeeded: s/uses case/use case/
FAILED: s/adrianba;adrianba://
Succeeded: s/adrianba;/adrianba:/
Succeeded: s/ddorwin: will/adrianba: will/
FAILED: s/adrianba[;]/adrianba:/
Found Scribe: joesteele
Inferring ScribeNick: joesteele
Found Scribe: joesteele
Inferring ScribeNick: joesteele
Default Present: joesteele, pal, Michael_Thornburgh, +1.425.269.aaaa, KevinStreeter, ddorwin, adrianba, johnsim, paulc, BobLund, Aaron_Colwell
Present: joesteele pal Michael_Thornburgh +1.425.269.aaaa KevinStreeter ddorwin adrianba johnsim paulc BobLund Aaron_Colwell
Agenda: http://lists.w3.org/Archives/Public/public-html-media/2013Feb/0002.html
Found Date: 05 Feb 2013
Guessing minutes URL: http://www.w3.org/2013/02/05-html-media-minutes.html
People with action items: 

[End of scribe.perl diagnostic output]