See also: IRC log
<trackbot> Date: 26 June 2012
<nixu> nixu, Disney Technology Solutions and Services, i'm the 352 number
<Petr> 858 is Petr Peterka
<MikeSmithW3C> I will be on IRC only, today, from my mobile
<Clarke> zakim +1.303.503.aacc is BobLund
<MikeSmithW3C> paulc, so if you need me for anything please ping me here on irc
<mahesh> <Zakim>, +1-818-560-0523, it's me
<mahesh> I am on the phone
<mahesh> <Zakim>, +1-818-560-0523 is mahesh
Paul: Jason is scribe, Paul is Chair
<paulc> 26 attendees
Paul: Topic discuss previous
minutes, last meeting of this group 2 weeks ago. There has been
some discussion on mailing lists.
... Action items. There are none
Noted. No action required
David: Do we need multiple
initData? And to associate with sessions.
... Associating messages and tracking lifetimes is simpler if we only allow one initData
<ddorwin> …per session ID
Yang: Currently initData is
one-to-one mapping, if changed then we may need to multiple key
... Is there a relative mapping between initData and Key?
David: initData may be a Key , or
reference to key.
... there may be some issue of replay attacks, but this is responsibility of CDM
Adrian: my preference is to keep things as simple as possible. Haven't seen a compelling enough reason to move away from single initData. Prefer to keep existing structure until there is a hard requirement needing this to change.
<yang> agree with Adrian
Mark W: There is a scenario with multiple calls and multiple keys.
Mark W: Question is how to coordinate these requests..as a bundle? then there will need to be more information from initData
<Martin> if an initData and key request map to a single request / transaction then a one-to-one mapping is simpler and there is no reason multiple KIDs can't be included in a single "key request"
Mark W: Impact is whether you can write generic application without knowledge of how media keys and structure were handled in the files
Martin: It seems one-to-one mapping is simpler
Mark W: issue is that initData may not actually require delivery of new key
Mark W: Application needs to know if it needs to create to be a session
Paul: What does current spec say about this?
<ddorwin> the current spec assumes one session at a time I believe
Mark W: Does say anything about key exchange if CDM already knows the key data
<yang> we do not need multiple needkey event in 1 session,even iif we support multiple initdata in one session
<yang> because it is meaningless for application to see the following needkey event because we only need 1 key in this session.
Adrian: Mark outlined one scenario that was possible. But are we ok with keeping it simple for now until a hard use case arises that justifies this?
<paulc> This is a sub-issue of https://www.w3.org/Bugs/Public/show_bug.cgi?id=16613
Mark V: if we applied the initData in createNewSession method...that would give CDM option to decide whether new data would be needed
David: Like this
Adrian: Have questions about this...and general object oriented discussion
<markw> createNewSession would return an existing session object if no new message exchange was required based on the provided initData
<markw> we would still need generateKeyRequest() to trigger the events as we need time to register event handlers
<ddorwin> One question is whether generateKeyRequest() should create the session object or be a method on that object. Having it create the object is attractive because it enforces calling order without explicit checks.
David: if we did have createSession with initData ... and the CDM returns session... There may be an issue if this is asynchronous in the CDM
<ddorwin> The biggest problem with geneerateKeyRequest() creating the object is that it requires the following pattern:
<ddorwin> var obj = doSomethingThatFiresEventFoo();
<ddorwin> obj.onfoo = myhandler;
<ddorwin> In other words, the constructor can fire events at the object it is creating that we want to handle.
Paul: Let's please get everyone's opinion
Adrian: My opinion is that we should pick the object-oriented approach
<Martin> my opinion is we should pick the object oriented approach
Adrian: Design we proposed allows
JS to iterate through the systems that a website supports...
originally in spec this was done by calling generateKeyRequest
... seems that we throw away objects very quickly
David: If we added initData we may have been able to simply get null objects
<markw> What if you do support the keysystem but the initData does not contain information for that keysystem ?
Adrian: it will still be necessary to allow async behavior. But would like to support fast fail
David: issue; we would have to start throwing errors at the object
Mark W: What if you do support the keysystem but the initData does not contain information for that keysystem ?
Mark W: do you have to fire up the CDM to determine support? or can the browser do this based on initData?
Paul: The spec doesn't make it mandatory to spin up CDM, so this is optional from browser...but probably shoul
<ddorwin> What type of error should occur in the case where we have to spin up the CDM?
<ddorwin> synchronous null session object or asynchronous keyerror at the object?
Mark W: seems like both; if browser can determine quickly , but also need to support async when CDM has to be started to determine it
<ddorwin> we can specify both types of errors are possible.
Paul: This isn't yet included in proposal
<paulc> adk adrian
David: ran into roadblock that object created also is event handler; is this pattern acceptable?
Adrian: this is a common pattern. if you add event listener to object then events are queued. May feel odd, but it is supported by the way event handlers are implemented
Paul: is there another API that has similar handler
<markw> It still might be better for the HTMLMediaElement method to be "createSession" and just remove generateKeyRequest altogether
Adrian: XHR is similar;
<ddorwin> Okay, great. I wasn't sure, but that helps a lot.
David: Yes, i can find the
Websocket api/implementation for reference
... sessionId is a part of the object, but it would have to stay not valid .. until we receive the first key response
Paul: a) Have we answered the questions that we've talked in email? or b) do we have enough data to decide how to implement this ?
<glenn> is that initData object mutable or immutable?
<SethHodgson> Should be, or should be spec'ed as only read @ input time
David: it is an input. So it's currently not exposed.
<glenn> but if it has members, does mutating those members mean that the changes are intended to be used?
<glenn> i'm on the phone, but muted
Paul: trying to clarify; is it read only?
<glenn> ok, so there is no initData object per se?
<adrianba> initData is a Uint8Array
David: initData is blob, that
probably came from a file
... session object is mutable, but properties like sessionid are read only
<adrianba> generateKeyRequest reads the data and then uses it - it doesn't keep a reference
<glenn> ok, thanks;
<glenn> be careful about mutability / liveness of session object
Paul: Solved by previous discussion
Paul: seems that we need a change proposal for items a, b, c from agenda and bring this to meeting by July 10
David: I will get this out today
Adrian: is it possible to get from keySession object from mediaElement
<Martin> +1 to being able to get from key session object to media element
Adrian: if an event fires, how do you associate it with the mediaElement
Paul: Is there a volunteer scribe
for next week?
... Meeting adjourned
This is scribe.perl Revision: 1.136 of Date: 2011/05/12 12:01:43 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 0.99) Succeeded: s/on/one/ Succeeded: s/this/this?/ Succeeded: s/Andrian/Adrian/ Succeeded: s/createKeyRequest/generateKeyRequest/ Succeeded: s/HTMLMediaElement/HTMLMediaElement method/ Succeeded: s/mutede/muted/ No ScribeNick specified. Guessing ScribeNick: jasonlewis Inferring Scribes: jasonlewis WARNING: Replacing list of attendees. Old list: +1.206.664.aaaa duncanr +1.352.870.aabb markw +1.303.503.aacc Martin +1.858.677.aadd +1.858.735.aaee pladd kstreeter glenn adrianba paulc yang ddorwin jasonlewis johnsim-microsoft Petr +1.415.832.aagg whitech Adobe Clarke nixu Mark_Vickers +1.818.560.aahh BobLund acolwell mahesh New list: +1.206.664.aaaa duncanr +1.352.870.aabb markw +1.303.503.aacc Martin +1.858.677.aadd +1.858.735.aaee pladd kstreeter glenn adrianba paulc yang ddorwin jasonlewis johnsim-microsoft Petr +1.415.832.aagg whitech Clarke nixu Mark_Vickers +1.818.560.aahh BobLund acolwell mahesh Plh SethHodgson Default Present: +1.206.664.aaaa, duncanr, +1.352.870.aabb, markw, +1.303.503.aacc, Martin, +1.858.677.aadd, +1.858.735.aaee, pladd, kstreeter, glenn, adrianba, paulc, yang, ddorwin, jasonlewis, johnsim-microsoft, Petr, +1.415.832.aagg, whitech, Clarke, nixu, Mark_Vickers, +1.818.560.aahh, BobLund, acolwell, mahesh, Plh, SethHodgson Present: +1.206.664.aaaa duncanr +1.352.870.aabb markw +1.303.503.aacc Martin +1.858.677.aadd +1.858.735.aaee pladd kstreeter glenn adrianba paulc yang ddorwin jasonlewis johnsim-microsoft Petr +1.415.832.aagg whitech Clarke nixu Mark_Vickers +1.818.560.aahh BobLund acolwell mahesh Plh SethHodgson Found Date: 26 Jun 2012 Guessing minutes URL: http://www.w3.org/2012/06/26-html-media-minutes.html People with action items: WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]