See also: IRC log
<trackbot> Date: 18 September 2012
<whadar> hi
<adrianba> ScribeNick: joesteele
paulc: make sure we get the attendees correct
paulc: on the agenda
<paulc> http://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html
paulc: did click on the link -- did not look like it has been worked on
ddorwin: added some update last night
paulc: encrypted media bugs have
more open now
... regressed a bit?
joesteele: I reopened a few
<paulc> http://tinyurl.com/7tfambo
paulc: added those bugs to the agenda
paulc: any progress?
... Action 2?
<paulc> ACTION-2?
<trackbot> ACTION-2 -- Mark Watson to propose a resolution to bug 17673 -- due 2012-08-17 -- CLOSED
<trackbot> http://www.w3.org/html/wg/media/track/actions/2
johnsim: not at this time now
paulc: ETA?
johnsim: should have something
this week
... spent some time on the common key question
<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=17673 is assigned to John Simmons. No progress at this time
<adrianba> ACTION-3?
<trackbot> ACTION-3 -- John Simmons to propose resolution to bug 17682 -- due 2012-09-11 -- OPEN
<trackbot> http://www.w3.org/html/wg/media/track/actions/3
paulc: last time we changed the
due date for this to Sept 11
... john you mentioned you did some work
<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=17682
johnsim: did some research, adrian and I discussed this yesterday
… there is some lack of clarity on how the key is used
… up till now discussed as a key acquiisition proposal
johnsim: but how do you use that key?
… assumption is by examination of the media
… ISO based format, Common Encryption Format, etc.
… would know intrinsically how to handle it
… problem with this approach is that if goal is to produce interoperable solution between browsers
… common encryption modality without reference to DRM
… how do you assure that all the browsers understand the different media types?
johnsim: need to understand the intent behind clearkey
… we can consider it good if it only handles key acquisition
scribe: but if goal is to create an interoperable solution, we need to be normative about the encryption
… modes algorithms etc.
ddorwin: intent was the
latter
... at the encryption level as well
… could call AddKey multiple times
… AES-128 CTR seems to be common, if there are containers that do not specify that we need to deal with that
… WebM does not need to specify that? (please correct if I mistated)
johnsim: if you don't know that it is encrypted it will just be unrecognizable
ddorwin: container format specifies how it is encrypted
johnsim: container level encryption is not covered by this spec then?
… i.e. HLS
… so the media stack can always determine the type of encryption to be used
ddorwin: that was the intent -- have not thought deeply
adrianba: think this is slightly different than what john summarized
… clearkey should work the same way for content encrypted at the container format
… if possible for other DRMs
<adrianba> clear key should be as usable with media files as with a DRM system
<adrianba> if the media format supports envelope encryption (e.g. HLS) then this would also work with Clear Key
johnsim: if it is container level
encryption - the CDM will not be able to examine the container
to determine how the encryption was performed
... you could set up a mime-handler that knows how to handle
it
... does not seem like this was envisioned to support container
level encryption
... does not seem practical to implement clearkey for container
level encryption
adrianba: I think as interoperable code you have to understand how the format works in either case
… this is related to a later agenda item
… being able to start the key request without knowing the content/media type
… think we need to understand the media type to be able to fire up the approp. CDM
… need indicator of what is encrypted and how
… this will need to be defined normatively somewhere
paulc: high level comment -- sounds like this should be written down in an email thread
… need a wider group to review it
ddorwin: it was intended to be
clear that the container specifies this stuff
... what john was talking about should be separate from
clearkey -- e.g. needKey event is independent fro a key
system
… for any of these events we want to be commonly supported need specification
<adrianba> ACTION-3 due in 1 week
<trackbot> ACTION-3 Propose resolution to bug 17682 due date now in 1 week
paulc: moving on. need to extend
ACTION-3
... ACITON-4
<adrianba> ACTION-4?
<trackbot> ACTION-4 -- David Dorwin to propose a solution for bug 17672 -- due 2012-09-18 -- CLOSED
<trackbot> http://www.w3.org/html/wg/media/track/actions/4
ddorwin: added a new section 7.1
… rest of the document is container independent
<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=17672
… defines how WebM is encrypted
<adrianba> http://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html#webm
paulc: is this what is needed?
ddorwin: yes, content is correct
paulc: marked as RESOLVED, FIXED
ACTION-5?
<trackbot> ACTION-5 -- Mark Watson to follow-up on Key Release mail thread now that the OO changes have been made - discuss on next call -- due 2012-08-28 -- CLOSED
<trackbot> http://www.w3.org/html/wg/media/track/actions/5
paulc: have not checked whether
this is done -- no record of emails on it
... not sure what the status is -- was assigned to Mark?
... Mark can you update us?
markw: no followup yet, have some notes in the bug itself I think
<ddorwin> http://lists.w3.org/Archives/Public/public-html-media/2012Sep/0004.html
paulc: don't see an associated bug
markw: there is a bug for key release
<adrianba> https://www.w3.org/Bugs/Public/show_bug.cgi?id=17199
ddorwin: posted a link with a proposed solution, next step is for Mark to add to the spec
<ddorwin> https://www.w3.org/Bugs/Public/show_bug.cgi?id=17199
paulc: Mark should either respond to the proposal or update the spec
paulc: reopened bugs by Joe
<ddorwin> previous topic: last email on action 5: http://lists.w3.org/Archives/Public/public-html-media/2012Sep/0012.html
<adrianba> https://www.w3.org/Bugs/Public/show_bug.cgi?id=17470
<paulc> "Provide specific guidance on when generateKeyRequest should be called "
<adrianba> joesteele: the use case i'm thinking of is for the access DRM there are certain keys i can preload ahead of time
<adrianba> ... there might be a substantial cost in requesting the keys that would affect the user experience
<adrianba> ... i don't know what the media format is going to be yet
<adrianba> ... i can make some guesses
<adrianba> ... in most cases i probably would know the media type but in the general case i don't know the type
<adrianba> ... but i do know that a particular set of domain keys will be needed
<adrianba> ... so i want to be able to do a key request without having seen any media yet
<adrianba> ddorwin: i think you can create a MediaKeys object without a media type
<adrianba> joesteele: it's not clear where the errors go
<adrianba> ddorwin: you can create a MediaKeys object and then createSession to get a MediaKeySession object and events get fired here
<adrianba> adrianba: is it not true that you need the media file format to know the format of the initdata
<adrianba> ... for example in ISO BMFF we've assumed that initdata is a concatenated list of pssh boxes
<adrianba> ddorwin: i don't think there is initdata in this situation
<adrianba> joesteele: that brings up one of the issues, if you create a session without initdata then an error is thrown
<adrianba> ... i'm okay if you have to say there is initdata we can fake it up
<adrianba> ddorwin: the spec says you must have initdata and mime type or neither?
<ddorwin> createSession() may be called with no parameters
<johnsim> +q
<adrianba> ddorwin: the algorithm says that if the type is null and initdata is NOT null then it's an error - anything else is allowed
joesteele: I would like to see an example in the spec of how to initialize
paulc: can you provide the example for us?
joesteele: ye s-- I will do that
johnsim: the wording is ambiguous for step 1 of createSession steps
paulc: maybe put (or an empty
string) in parens
... suggest to joe to provide the sample
... editors can then decide how to handle
<adrianba> https://www.w3.org/Bugs/Public/show_bug.cgi?id=17660
<adrianba> joesteele: this is a related issue
<adrianba> ... when i asked about authentication at the F2F
<adrianba> ... i was told it would done at the app level not in the CDM
<adrianba> ... but in the Access case, authentication is bound into th ekey request channel
<adrianba> ... and we have a lot of customers that use this channel
<adrianba> ... we think it is more secure than TLS auth
<adrianba> ... but i don't see another way to pass additional parameters down
<adrianba> ... without having to parse the key data coming back
<adrianba> ... which we want to avoid
<adrianba> ... in Access, you would understand that you need to do a key request
<johnsim> +q
<adrianba> ... and you would get a flag from the DRM system saying you need to get auth information
<adrianba> ... and you might prompt for username password and then pass it down into the DRM system
<adrianba> ... and there doesn't seem to be a mechanism to pass that in
<adrianba> joesteele: this is user authentication
<adrianba> johnsim: so user credentials associated with the event
<adrianba> joesteele: example: i log in to a web site where my queue of videos is but when i play a particular video it has credentials from a different service and so now i have to provide those to authenticate for it
paulc: start an email thread pointing back to this comment
… add more details to the question in the comment
paulc: discussing 17682
... this was discussed above under ACTION-3
paulc: have a large number of
bugs with no progress on them yet -- work going on in the
background?
... would like to know which items we can get done in next two
weeks
... if so -- can editors propose which ones
adrianba: a lot of them are related to error which is being discussed
paulc: what about items we discussed today -- david any others?
ddorwin: some pending bugs to file ;-)
<whadar> Considering Media Source Extensions, I would like to feedback as a user of the API. There are great benefits of having a low-level API that can append bytes. But, the implementation underneath should help the developer and even defend the developer when setting up a stream and appending bytes. Specifically 1) the browser level should help understanding the type of CODEC and not require it on init. 2) Appending should not necessarily begin at the beginning
paulc: will watch for those then
ddorwin: focusing on the implementation bugs
paulc: mark -- any to queue up?
markw: should be able to make
progress on all of them in the next two weeks
... assigned to 4
paulc: we might be stable in two
weeks then, with David and Mark's work
... nothing else on the agenda
... Oct 2 is next meeting
... should be able to do the next meeting
... any other comments?
... ready to adjourn
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 1.00) Succeeded: s/Baselin/Baseline/ Succeeded: s/Zakim: who is on the call?// Succeeded: s/act./acquiisition/ Succeeded: s/ddorwing/ddorwin/ Succeeded: s/sumarized/summarized/ Succeeded: s/clear key/clearkey/ Succeeded: s/johsim/johnsim/ Found ScribeNick: joesteele Inferring Scribes: joesteele Default Present: markw, Matt, Clarke, ddorwin, paulc, adrianba, [Microsoft], +1.408.536.aaaa, joesteele, johnsim, pal, +1.858.677.aabb Present: markw Matt Clarke ddorwin paulc adrianba [Microsoft] +1.408.536.aaaa joesteele johnsim pal +1.858.677.aabb Agenda: http://lists.w3.org/Archives/Public/public-html-media/2012Sep/0015.html WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Found Date: 18 Sep 2012 Guessing minutes URL: http://www.w3.org/2012/09/18-html-media-minutes.html People with action items:[End of scribe.perl diagnostic output]