{minutes} HTML WG media telcon 2013-01-22

http://www.w3.org/2013/01/22-html-media-minutes.html

________________________________
- DRAFT -
HTML Media Task Force Teleconference
22 Jan 2013
Agenda<http://lists.w3.org/Archives/Public/public-html-media/2013Jan/0039.html>
See also: IRC log<http://www.w3.org/2013/01/22-html-media-irc>
Attendees
Present
Regrets
Chair
Paul Cotton
Scribe
John Simmons
Contents

  *   Topics<http://www.w3.org/2013/01/22-html-media-minutes.html#agenda>
     *   Roll call, introductions and selection of scribe<http://www.w3.org/2013/01/22-html-media-minutes.html#item01>
     *   Previous minutes<http://www.w3.org/2013/01/22-html-media-minutes.html#item02>
     *   Review of action items<http://www.w3.org/2013/01/22-html-media-minutes.html#item03>
     *   baseline documents<http://www.w3.org/2013/01/22-html-media-minutes.html#item04>
  *   Summary of Action Items<http://www.w3.org/2013/01/22-html-media-minutes.html#ActionSummary>

________________________________
<trackbot> Date: 22 January 2013
<adrianba> ScribeNick: johnsim
<adrianba> Scribe: John Simmons
<paulc> Agenda: http://lists.w3.org/Archives/Public/public-html-media/2013Jan/0039.html
<paulc> rssagent, generate minutes
Roll call, introductions and selection of scribe
<scribe> Done
Previous minutes
noted
Review of action items
<paulc> ACTION-8?
<trackbot> ACTION-8 -- John Simmons to discuss 17673 with dsinger -- due 2012-12-18 -- CLOSED
<trackbot> http://www.w3.org/html/wg/media/track/actions/8
<paulc> ACTIOIN-9?
<paulc> ACTION-9?
<trackbot> ACTION-9 -- John Simmons to discuss 17682 with markw and propose text for JSON solution -- due 2012-12-18 -- CLOSED
<trackbot> http://www.w3.org/html/wg/media/track/actions/9
paulc: johnsim sent email after agenda sent that action 8 & 9 are closed
baseline documents
paulc: there are two - EME editors draft, not updated yesterday by January 14th, and second document is candidate FPWD
... not sure when last updated
... main item today is bug left outstanding last week:
<paulc> Bug 17199: https://www.w3.org/Bugs/Public/show_bug.cgi?id=17199
paulc: to summarize from last week, couldn't reach consensus on resolving, still not 100% agreement, now people are suggesting we not hold up FPWD on this bug
... put health warning on this
... mark, david?
markw: we would be able to resolve it with generic capabilities in the document, were not able to work out a way to do that over the week and i don't believe david wants to include the
... proposed spec... from my perspective an important feature... link to the bug with the point of disagreement
paulc: you can live with FPWD as long as it has a health warning on this issue?
markw: yes
<markw> My proposal would be to add the following to Section 4: <p class="non-normative">Note: it is an open issue whether further normative specification of this feature is required. See <a href="https://www.w3.org/Bugs/Public/show_bug.cgi?id=17199">Bug 17199</a>.</p>
<adrianba> +1 to calling out the issue
<markw> I think we should also rename the bug
david: plan on adding the health warning. agree on that text in this meeting and have consensus here...
<joesteele> +1 seems reasonable
+1 to calling out the issue
<BobLund> +1
<ddorwin> +1 (and +1 to bug rename)
paulc: mark has put candidate text in the IRC (see above)
... does anyone object to adding the proposed text
... no objections raised
joesteele: once to FPWD what are the changes permitted
paulc: anything
<paulc> Proposal: Propose to the HTML WG that the EME spec be published as FPWD. The draft at https://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media-fpwd.html would be changed to:
<paulc> a) the date would be changed to at least Jan 31
<paulc> b) the health warning about bug 17199 added to Section 4
<adrianba> what target date should we use?
paulc: anyone objects to this proposal?
<joesteele> no objection
paulc: how about Feb 5th?
<paulc> Publications often occur on Tuesdays
<ddorwin> +1 on proposal
paulc: can i have some affirmatives please?
<markw> +1
<adrianba> +1
+1
<strobe> +1
<pal> +1
<BobLund> +1
paulc: not hearing any objections -
... i will take this to the working group immediately.
<markw> Proposed bug 17199 rename: Provide normative specification in support of secure proof of key release, if necessary
paulc: Adrian and editors - when can you get revised candidate document for me?
adrianba: in middle of it now
paulc: since likely doing it in place, please provide confirmation when done
<ddorwin> would like to discuss https://www.w3.org/Bugs/Public/show_bug.cgi?id=17673 while strobe is here
paulc: 32 bugs - editors where should we spend time on call?
david: FPWD bug, concerns about changes in comment 10
<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=17673#c10
strobe: not pluralized, elements, multiple events, one per track, some clarity on how to deal with multiple tracks, sample descriptors per track
<ddorwin> strobe: suggest to allow multiple snif boxes that might occur
<ddorwin> markw: just to clarify, there would be multiple scheme information in the initdata for media source, but there could be sample groups
<ddorwin> strobe: They should be equivalent. A keymessage might arise from parsing a top-level box that contains multiple sample descriptors either because there are multiple tracks containing sinf or a track with multiple sinfs in multiple....
<ddorwin> markw: Making a differentiation in the initdata from the ???
<ddorwin> markw: Originally pssh boxes and now sample information boxes.
<ddorwin> markw: Should exclude sample group information in the media from a media source perspective
<ddorwin> markw: When you suggested excluding sample groups, was the suggestion to exclude them altogether or just to exclude them from the initdata field.
<ddorwin> strobe: I wasn't suggesting excluding sample groups; it seems they are excluded today. It wasn't a priority, but maybe it should be now that FPWD is out the door.
<ddorwin> markw: I think that as things stand, if there are sample groups in the media stream and you support that part of the CENC, then the current spec should support them. they just aren't part of the initdata
<ddorwin> strobe: Why aren't they necessary?
<ddorwin> markw: <missed>
<ddorwin> strobe: The purpose of initdata is not to specify all the keys that are needed
<ddorwin> markw: That information is in the PSSH.
<ddorwin> strobe: not necessarily, but in all cases i've seen.
<ddorwin> strobe: There is still an issue of multiplicity of boxes
<ddorwin> markw: You are right that if you exposed sample groups, you could expose this information in a key-system independent way, but I don't think that is necessary
<ddorwin> strobe: agreed.
<ddorwin> ... (essentially)
<ddorwin> strobe: Upgrade to say all snifs instead of an snif
<ddorwin> paulc: Could you add a comment with the explicit change that you want and the editors will process
strobe: i will add a comment to the text to make explicit the proposed change regarding sample groups
joesteele: 17660 - but what i am proposing might not fit this bug anymore
<paulc> Bug 17660: https://www.w3.org/Bugs/Public/show_bug.cgi?id=17660
joesteele: has to do with use cases i added to action #7 (?)
david: we can discuss. i did read your reply to my email
... two main issues - application can work with arbitrary key systems, and license servers not matched with the CDMs
joesteele: affirming or asking?
... first is true - an application may have to deal with multiple key systems
... since key systems are intimiately associated with license servers, more appropriate for CDM to know what the License Servers wishes are
david: what is a license server configuration?
joesteele: license server password, open id, unbounded set of ways to authenticate a user, haven't specified they can't use an unbounded set
david: yes, many key systems but not arbitrary, and i think that is supported
... the application knows something about the license servers
joesteele: we haven't standardized how the web server says to the application - application doens't know in advance which web server to communicate with
markw: on this point, the application doesn't know which server it will be talking to, but it does need to know which protocol it will use, and definition of that protocol is outside EME
... so didn't know what you meant
<joesteele> This is use case #1 from my ACTION-7 response: https://docs.google.com/drawings/pub?id=15dnxQHHSTY64YSnMSihfBa9w-oxCVuOsFUBOfBMJDVY&w=960&h=720
<joesteele> This is use case #2: https://docs.google.com/drawings/pub?id=1ybZ1tDbrwO9jX372nSpJuQKnAzdtSTJ5dmVuZLwM4kA&w=960&h=720
joesteele: use case #1, a video search engine, in this caes i get back playlist references but i don't know where they are hosted
... scrapped an M3U8 off that site, i can download, extract metadata for licenses, but once i have that and do createsession(), application does not know what protocol is required
... CDM says here is the URL, but don't know what protocol is required, i have no way in spec to know required authentication
... in our CDM our LS communicates the authentication needed in the key system package
<ddorwin> note that you need to know the key system before you get the URL
markw: spec doesn't imply - big gap doesn't say what to do with the blob to get it to the server, what port, what text encoding, huge number of gaps we don't intend to specify
<ddorwin> once you know the key system, you know at least a bit about the protocol
<ddorwin> (or can)
adrianba: mark said most of what i intended to say, i reiterate we didn't plan to solve the standard protocol problem in EME, but to abstract away the network differences so application can handle that
<joesteele> +q
adrianba: standardization of that would be okay but should be a separate specification, standardizing communication server and client , required for the scenarios joe outlined but not what we are trying to solve for EME
david: agree with mark and adrian. before you get the destination URL, you have chosen the key system, so in ISO CENC case would be destination URL, so you know something about what you are do do with the URL which could tell you something about the tprotocol
pierre: back to the use case alittle bit to understand better. content provider, control distribution, what makes us think a content provider/aggregagtor would let application play their content in players other than theirs without prior approval?
joesteele: one example, live today, they may want content to have ads, and content may be protected ... use the authentication to count ads
pierre: content protection just way to count views?
joesteele: yes
pierre: using EME system - solely - to count the number of times content is viewed
joesteele: one example. another, i am netflix, and i am happy to play content the first time, give me an upsell opportunity, to capture a license, now i have an upsell possibility
pierre: is the content being played through the application of search provider or original provider?
joesteele: search provider?
... one of the issues - you do know what key system it is - but using authentication as an example - there can be many different authentication systems
... there is also a meta-problem - there is a relationship between CDM and license server that application does not necessarily need to be aware of but may be useful for CDM to ask information from application in a key system specific format
... ask the app for data from the user directly - no formal way to do this in the spec.
<joesteele> THis is the mechanism I was referrign to:
<joesteele> http://lists.w3.org/Archives/Public/public-html-media/2012Oct/0076.html
<ddorwin> You could solve the authentication protocol within a key system, but not all key systems or implementations need to support it.
<ddorwin> There is a general problem of authentication to access random files (images, etc.) found on the Internet. I'm not sure why it is specific to EME.
markw: briefly - on the technical aspect - someeone wants to access content - that would be technically possible, but would provide them with the details on authentication services, maybe even an library
<joesteele> I would encourage others to look at the three use cases I laid out. Video search engine is only one
<joesteele> +q
pierre: for background, i have seen this bug discussed a number of times and we always run out of time. can we set an hour dedicated to this bug?
paulc: hard pressed to call a special meeting. 30 bugs outstanding. strongly suggest tackling by email first.
joesteele: only thing i wanted to say, there are other use cases out there, i will be more diligent to responding to email
paulc: bring meeting to a close.
adrianba: other business topic
... just joined call, MSE first public working draft to be published on THURSDAY
<adrianba> Candidate FPWD for EME -> https://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media-fpwd.html
Summary of Action Items
[End of minutes]


John C. Simmons | Media Platform Architect | Microsoft Corporation | direct 425-707-2911 | mobile 425-269-5759