My proposal would be to add the following to Section 4: Note: it is an open issue whether further notmative specification of this feature is required. See Bug 17199.
16:15:13 +1 to calling out the issue
16:15:15 I think we should also rename the bug
16:15:23 david: plan on adding the health warning. agree on that text in this meeting and have consensus here...
16:15:32 +1 seems reasonable
16:15:38 +1 to calling out the issue
16:15:43 +1
16:15:53 +1 (and +1 to bug rename)
16:16:21 paulc: mark has put candidate text in the IRC (see above)
16:16:21 s/notmative/normative/
16:16:50 jdsmith_ has joined #html-media
16:17:03 paulc: does anyone object to adding the proposed text
16:17:28 paulc: no objections raised
16:18:09 q+
16:18:44 joesteele: once to FPWD what are the changes permitted
16:18:48 paulc: anything
16:18:54 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:
16:19:05 a) the date would be changed to at least Jan 31
16:19:19 b) the health warning about bug 17199 added to Section 4
16:20:12 what target date should we use?
16:20:14 paulc: anyone objects to this proposal?
16:20:21 no objection
16:20:42 paulc: how about Feb 5th?
16:20:56 Publications often occur on Tuesdays
16:21:14 +1 on proposal
16:21:17 paulc: can i have some affirmatives please?
16:21:20 +1
16:21:28 +1
16:21:30 +1
16:21:30 +1
16:21:53 +1
16:21:58 +1
16:22:14 paulc: not hearing any objections -
16:22:26 paulc: i will take this to the working group immediately.
16:22:44 Proposed bug 17199 rename: Provide normative specification in support of secure proof of key release, if necessary
16:22:50 paulc: Adrian and editors - when can you get revised candidate document for me?
16:22:56 adrianba: in middle of it now
16:23:15 paulc: since likely doing it in place, please provide confirmation when done
16:23:32 would like to discuss https://www.w3.org/Bugs/Public/show_bug.cgi?id=17673 while strobe is here
16:23:47 paulc: 32 bugs - editors where should we spend time on call?
16:24:13 david: FPWD bug, concerns about changes in comment 9
16:24:52 s/comment 9/comment 10/
16:25:02 https://www.w3.org/Bugs/Public/show_bug.cgi?id=17673#c10
16:25:08 strobe: not pluralized, elements, multiple events, one per track, some clarity on how to deal with multiple tracks, sample descriptors per track
16:26:41 strobe: suggest to allow multiple snif boxes that might occur
16:26:42 q+
16:27:00 ack Joe
16:27:00 q-
16:27:07 ack mark
16:27:38 markw: just to clarify, there would be multiple scheme information in the initdata for media source, but there could be sample groups
16:27:46 jdsmith__ has joined #html-media
16:27:53 jdsmith_ has left #html-media
16:28:29 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....
16:28:55 markw: Making a differentiation in the initdata from the ???
16:29:27 markw: Originally pssh boxes and now sample information boxes.
16:29:50 markw: Should exclude sample group information in the media from a media source perspective
16:30:16 markw: When you suggested excluding sample groups, was the suggestion to exclude them altogether or just to exclude them from the initdata field.
16:30:43 -ppeterka
16:30:47 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.
16:31:36 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
16:31:46 strobe: Why aren't they necessary?
16:31:55 markw:
16:32:15 strobe: The purpose of initdata is not to specify all the keys that are needed
16:32:23 markw: That information is in the PSSH.
16:32:35 strobe: not necessarily, but in all cases i've seen.
16:32:50 strobe: There is still an issue of multiplicity of boxes
16:33:37 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
16:33:51 strobe: agreed.
16:34:06 … (essentially)
16:34:21 strobe: Upgrade to say all snifs instead of an snif
16:34:43 paulc: Could you add a comment with the explicit change that you want and the editors will process
16:35:22 -strobe
16:35:24 strobe: i will add a comment to the text to make explicit the proposed change regarding sample groups
16:36:29 joesteele: 17660 - but what i am proposing might not fit this bug anymore
16:36:53 Bug 17660: https://www.w3.org/Bugs/Public/show_bug.cgi?id=17660
16:36:59 joesteele: has to do with use cases i added to action #7 (?)
16:37:17 david: we can discuss. i did read your reply to my email
16:37:36 david: two main issues - application can work with arbitrary key systems, and license servers not matched with the CDMs
16:37:51 joesteele: affirming or asking?
16:38:04 joesteele: first is true - an application may have to deal with multiple key systems
16:38:33 joesteele: since key systems are intimiately associated with license servers, more appropriate for CDM to know what the License Servers wishes are
16:38:45 david: what is a license server configuration?
16:39:12 joesteele: license server password, open id, unbounded set of ways to authenticate a user, haven't specified they can't use an unbounded set
16:39:52 markw_ has joined #html-media
16:39:56 david: yes, many key systems but not arbitrary, and i think that is supported
16:39:56 q+
16:40:13 david: the application knows something about the license servers
16:42:14 q+
16:42:18 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
16:42:39 ack mark
16:43:17 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
16:43:31 markw: so didn't know what you meant
16:44:13 This is use case #1 from my ACTION-7 response: https://docs.google.com/drawings/pub?id=15dnxQHHSTY64YSnMSihfBa9w-oxCVuOsFUBOfBMJDVY&w=960&h=720
16:44:30 This is use case #2: https://docs.google.com/drawings/pub?id=1ybZ1tDbrwO9jX372nSpJuQKnAzdtSTJ5dmVuZLwM4kA&w=960&h=720
16:45:02 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
16:45:45 joesteele: 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
16:46:02 q+
16:46:16 joesteele: CDM says here is the URL, but don't know what protocol is required, i have no way in spec to know required authentication
16:46:35 joesteele: in our CDM our LS communicates the authentication needed in the key system package
16:46:36 q+
16:47:17 note that you need to know the key system before you get the URL
16:47:21 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
16:47:31 once you know the key system, you know at least a bit about the protocol
16:47:39 ack adrian
16:47:41 (or can)
16:48:10 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
16:48:29 +q
16:48:54 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
16:49:07 ack dd
16:49:52 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
16:50:06 ack pal
16:50:57 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?
16:51:45 joesteele: one example, live today, they may want content to have ads, and content may be protected ... use the authentication to count ads
16:51:55 pierre: content protection just way to count views?
16:52:04 joesteele: yes
16:52:22 pierre: using EME system - solely - to count the number of times content is viewed
16:52:57 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
16:53:17 pierre: is the content being played through the application of search provider or original provider?
16:53:28 joesteele: search provider?
16:53:30 q+
16:55:30 q+
16:55:33 joesteele: 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
16:56:28 joesteele: 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
16:56:43 q+ to talk about other business
16:57:18 joesteele: ask the app for data from the user directly - no formal way to do this in the spec.
16:57:34 THis is the mechanism I was referrign to:
16:57:35 http://lists.w3.org/Archives/Public/public-html-media/2012Oct/0076.html
16:57:35 q+
16:57:39 You could solve the authentication protocol within a key system, but not all key systems or implementations need to support it.
16:57:42 ack markw
16:57:43 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.
16:57:46 ack joe
16:58:17 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
16:58:48 ack dd
16:58:54 q- later
16:59:27 I would encourage others to look at the three use cases I laid out. Video search engine is only one
16:59:39 ack pal
16:59:43 +q
17:00:11 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?
17:00:43 paulc: hard pressed to call a special meeting. 30 bugs outstanding. strongly suggest tackling by email first.
17:00:54 q- later
17:01:10 joesteele: only thing i wanted to say, there are other use cases out there, i will be more diligent to responding to email
17:01:18 paulc: bring meeting to a close.
17:01:19 ack joesteele
17:01:21 q-
17:01:24 adrianba: other business topic
17:01:59 adrianba: just joined call, MSE first public working draft to be published on THURSDAY
17:02:16 Candidate FPWD for EME -> https://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media-fpwd.html
17:02:31 rrsagent, make minutes
17:02:31 I have made the request to generate http://www.w3.org/2013/01/22-html-media-minutes.html paulc
17:03:17 -adrianba
17:03:19 -pal
17:03:20 bye
17:03:20 -joesteele
17:03:20 -ddorwin
17:03:21 -[Microsoft]
17:03:24 -johnsim
17:03:26 -markw
17:03:29 -BobLund
17:03:34 joesteele has left #html-media
17:03:50 -paulc
17:03:52 HTML_WG()11:00AM has ended
17:03:52 Attendees were markw, pal, +1.408.536.aaaa, joesteele, ddorwin, paulc, johnsim, adrianba, [Microsoft], +1.858.755.aabb, ppeterka, strobe, BobLund
18:00:48 ddorwin has joined #html-media
19:12:06 Zakim has left #html-media