- From: Paul Cotton <Paul.Cotton@microsoft.com>
- Date: Sat, 31 Oct 2015 01:09:27 +0000
- To: "public-html-media@w3.org" <public-html-media@w3.org>
- Message-ID: <CY1PR0301MB1196BEE8BEA6FD16F95034D0EA2E0@CY1PR0301MB1196.namprd03.prod.outlook.>
See http://www.w3.org/2015/10/30-html-media-minutes.html
and below:
[W3C]<http://www.w3.org/>
- DRAFT -
HTML Media F2F
30 Oct 2015
Agenda<https://www.w3.org/wiki/HTML/wg/2015-10-Agenda#EME>
See also: IRC log<http://www.w3.org/2015/10/30-html-media-irc>
Attendees
Present
Tatsuya_Igarashi, paulc, markw, rus, Josh_Soref, joesteele, MarkVickers, toddg, Yves, Yosuke, ddorwin, plh
Regrets
Chair
paulc
Scribe
timeless, joesteele
Contents
* Topics<http://www.w3.org/2015/10/30-html-media-minutes.html#agenda>
* ISSUE-68 Define key ID representation (byte order)<http://www.w3.org/2015/10/30-html-media-minutes.html#item01>
* ISSUE-85 "tracked" sessions: architectural concerns pending resolution with TAG<http://www.w3.org/2015/10/30-html-media-minutes.html#item02>
* ISSUE-98 Decide on ideal "waitingforkey" event behavior when update() doesn't resume playback<http://www.w3.org/2015/10/30-html-media-minutes.html#item03>
* ISSUE-100 Is "running the Encrypted Block Encountered algorithm" the correct way to Attempt to Resume Playback If Necessary?<http://www.w3.org/2015/10/30-html-media-minutes.html#item04>
* ISSUE-102 Define what to do when CDM becomes unavailable<http://www.w3.org/2015/10/30-html-media-minutes.html#item05>
* ISSUE-112 Encrypted Block Encountered algorithm: Steps to abort playback are insufficient<http://www.w3.org/2015/10/30-html-media-minutes.html#item06>
* ISSUE-118 Can EME support link protection, such as DTCP-IP?<http://www.w3.org/2015/10/30-html-media-minutes.html#item07>
* Outstanding action items<http://www.w3.org/2015/10/30-html-media-minutes.html#item08>
* ACTION-93: Get in touch with webappsec wg about the "privileged context" which is more generic than saying https, etc."<http://www.w3.org/2015/10/30-html-media-minutes.html#item09>
* Meeting Logistics<http://www.w3.org/2015/10/30-html-media-minutes.html#item10>
* Formal Objections<http://www.w3.org/2015/10/30-html-media-minutes.html#item11>
* "Secure release" discussion with TAG<http://www.w3.org/2015/10/30-html-media-minutes.html#item12>
* ISSUE-85 "tracked" sessions: architectural concerns pending resolution with TAG<http://www.w3.org/2015/10/30-html-media-minutes.html#item13>
* Email items that might be issues<http://www.w3.org/2015/10/30-html-media-minutes.html#item14>
* EME Initialization Data Correlation<http://www.w3.org/2015/10/30-html-media-minutes.html#item15>
* Items David would like feedback on<http://www.w3.org/2015/10/30-html-media-minutes.html#item16>
* New issues since last meeting<http://www.w3.org/2015/10/30-html-media-minutes.html#item17>
* Recent EME issues with outstanding pull requests<http://www.w3.org/2015/10/30-html-media-minutes.html#item18>
* ISSUE-80 - "tracked" sessions: record of usage should track session usage, not individual key usage<http://www.w3.org/2015/10/30-html-media-minutes.html#item19>
* ISSUE-84 - "tracked" sessions: document usage for limiting concurrent streams<http://www.w3.org/2015/10/30-html-media-minutes.html#item20>
* ISSUE-41 https://github.com/w3c/encrypted-media/issues/41<http://www.w3.org/2015/10/30-html-media-minutes.html#item21>
* ISSUE-19 (Jerry) Ensure promises returned by methods are fulfilled before event handlers are executed<http://www.w3.org/2015/10/30-html-media-minutes.html#item22>
* ISSUE-59 |expiration| should be Unix time like Date()<http://www.w3.org/2015/10/30-html-media-minutes.html#item23>
* ISSUE-75 MediaKeyStatusMap: iterable declaration has unexpected behavior; ForEachCallback definition is incorrect<http://www.w3.org/2015/10/30-html-media-minutes.html#item24>
* ISSUE-101 Normatively require distinctive identifiers to be different by top-level and EME-using origin<http://www.w3.org/2015/10/30-html-media-minutes.html#item25>
* ISSUE-105 EME registry: Separate definitions of Initialization Data Types from Stream Format parsing<http://www.w3.org/2015/10/30-html-media-minutes.html#item26>
* ISSUES 107 and 108<http://www.w3.org/2015/10/30-html-media-minutes.html#item27>
* Needs author input bugs<http://www.w3.org/2015/10/30-html-media-minutes.html#item28>
* ISSUE-99 Remove note recommending setMediaKeys() be called before providing media data<http://www.w3.org/2015/10/30-html-media-minutes.html#item29>
* ISSUE-110 Individualization text regarding device identifiers is overly broad and restrictive<http://www.w3.org/2015/10/30-html-media-minutes.html#item30>
* Open Bugzilla bugs<http://www.w3.org/2015/10/30-html-media-minutes.html#item31>
* EME issues "to be implemented" by Editors<http://www.w3.org/2015/10/30-html-media-minutes.html#item32>
* TAG question<http://www.w3.org/2015/10/30-html-media-minutes.html#item33>
* Next Meeting<http://www.w3.org/2015/10/30-html-media-minutes.html#item34>
* Summary of Action Items<http://www.w3.org/2015/10/30-html-media-minutes.html#ActionSummary>
________________________________
<joesteele> paulc: the agenda is now on the EME section. David believes the issues in item #2 he has commented on all of them and we can discuss as a group and put feedback before David comes online at 10:30am our time. Some folks may have already responded. The work assignment until then is to review these issues. Take 5-10 minutes to go over them. We will start at 9:15 or so
<paulc> Chair: paulc
ISSUE-68 Define key ID representation (byte order)
<joesteele> https://github.com/w3c/encrypted-media/issues/68
<joesteele> paulc: Mark you responded 3 days ago
<joesteele> markw: there are many issues about key ids but this is standalone
<joesteele> ... if folks agree we can note it and move on
<joesteele> jdsmith: do we want feedback now?
<joesteele> paulc: I can poll the room
<joesteele> ... we can walk through again once David is online
<joesteele> paulc: we just want to close on these as much as possible before David gets here
<joesteele> ... Mark has a suggestion in this issue
<joesteele> markw: I responded that the key id is a sequence of octets - that should be uncontroversial
<joesteele> ... that has an order - it is a propertty of that thing
<joesteele> ... you have to be careful about how you represent the order
<joesteele> ... if you represent as a GUID there are multiple ways of doing it
<joesteele> ... but as a BufferSource there is no ambiguity
<joesteele> rus: treat as bytes then?
<joesteele> markw: yes - if someone wants to represent as a GUID that is their repsonbitilty to reolve then
<joesteele> paulc: so concensus seems to be that we could just add that it is a sequence of octets
<joesteele> markw: if clarifying that is useful , is that sufficient to address David concern?
<joesteele> ... do people agree with me?
<joesteele> joesteele: I agree
<joesteele> paulc: so when we have consensus I will mark on my list to come back to
ISSUE-85 "tracked" sessions: architectural concerns pending resolution with TAG
<joesteele> https://github.com/w3c/encrypted-media/issues/85
<joesteele> paulc: this is the TAG issue that we will skip for now
<joesteele> jdsmith: are we going to get an update from Travis on this?
<joesteele> paulc: no
ISSUE-98 Decide on ideal "waitingforkey" event behavior when update() doesn't resume playback
<joesteele> https://github.com/w3c/encrypted-media/issues/98
<joesteele> paulc: David had a proposal here to always fire the event and ensure consistency
<timeless> scribe: timeless
joesteele: not an implementer, don't know what the impact of this would be
... seems like it'd be something that would vary between CDMs
paulc: he has explicit questions here, and then a proposal
jdsmith: he has two proposals
... one is waiting for key-event multiple times
... i'm not sure about
... attempting to do playback multiple times
... if it fails, UA can try again
... he's proposing to remove it
paulc: he's referring to ISSUE-83
joesteele: if the CDM is downloadable, I don't know if the UA would know that resuming would fail
... I agree w/ jdsmith, I don't see a reason not to allow it to fire multiple times
... leave it alone, no incompatibility
jdsmith: i'm having trouble w/ a reason to keep the other language
... "where the UA has knowledge that resuming will fail"
... I doubt that's practical, unless an implementer is here
joesteele: ISSUE-83 on a Track
... markw does a key record need to be updated ...
... it's unrelated, but he's pointing to it
markw: he's pointing to it,
... there's a potential for an update to happen w/o keys delivered
... an update could come, and not provide keys
... the app should watch status event to see what happens
... not sure we need the subsequent waiting-for-key-events
... but it's a continuing state, you're waiting until you see it
rus: I agree w/ markw
... app shouldn't assume something it doesn't know about
... get specific events + notifications, should be zero assumptions from app
paulc: ok to fire more than once?
markw: only file when you transition from waiting-for-key to not-waiting-for-key
paulc: jdsmith, seems contrary to what you said originally?
jdsmith: i guess you could argue it's a spurious event, not very useful, doesn't tell you anything
... waiting-for-key-fires, key arrives, you try to resume playback, i think that's the desired flow
... on allowing the events, i don't know there's a strong negative if you trigger waiting-for-key-event
markw: only fire event when state changes
... i agree w/ ddorwin's suggestion that it should at least be consistent
... either we should only send event when state changes
... or we fire after every update that doesn't deliver the correct key
... question from author's PoV
... if you fire event after every event, you know there's an event waiting-for-key or key-status-change
... that might be useful
... otherwise, what happens
... you still know you'll get something
... either media-key-status-change, or another-message
joesteele: that's the issue
... you've put an update, you should get something indicating processing-is-done
... got-a-key, waiting-for-key, error
markw: if you're waiting for a key, you get a message
jdsmith: you're agreeing
joesteele: we're agreeing
markw: you will get a message if you're waiting
joesteele: you're waiting for a key, you'll get a message indicating what to do to go forward
[ paulc reads proposed comment for issue from github comment box ]
joesteele: which is the least amount of work?
paulc: this issue is marked for AUTHOR input
... ddorwin's suggestion is we need input from people writing authors
... we can suppose we're authors
jdsmith: but we aren't
markw: i can ask our implementers
paulc: that's a possible answer to the first question
<trackbot> Error finding 'for'. You can review and register nicknames at <http://www.w3.org/html/wg/media/track/users>.
paulc: there's a second question, do we have a position on removing this text?
<joesteele> action markw to ask his developers about issue-98
<trackbot> Created ACTION-103 - Ask his developers about issue-98 [on Mark Watson - due 2015-11-06].
markw: i agree w/ the suggestion to make it consistent, we can work it out
paulc: not confident that's the right solution, but you agree in general?
jdsmith: implication is, you're waiting for a key, you receive one, you're supposed to attempt to resume playback
... but UA knows in advance it won't work
rus: app should attempt and worst case it gets a failure
jdsmith: that's what i'd assume
paulc: so i hear a preference for removing the (short circuit) text?
jdsmith: +1
joesteele: +1
rus: +1
paulc: markw, you said you'd get that feedback?
markw: yep
[ paulc reads the proposed pending comment again ]
jdsmith: we're trying to button up the spec
... worried we're twiddling knobs
... value consistency over tweaking too much
... i think it's consistent to fire the event
markw: right now, as spec is written, they can't rely on the event
... so right now they don't rely on this event
... if you make it happen always, then it might encourage people to rely on it
jdsmith: instinct is that i doubt anyone is exercising the right to suppress now
... but that the option is in there for reasons no one remembers
markw: your way is editorially simpler
joesteele: Joe Steele, Adobe
... if we handle the second part of this, and remove that text
... would it then make more of a difference?
... would firing the event be more relevant to authors?
... it would be redundant, you'll get a message in every case where you're still waiting for a key, presumably
markw: if you have this separate event
... it's clearer, "waiting-for-key" if you're still waiting for key
... attaching semantics "can't-start-playback" would be wrong
joesteele: we have consensus: always send message
jdsmith: which is what ddorwin proposed
[ paulc reads the github proposed comment ]
markw: if we can resume playback, is there some other message that fires?
... you might be getting a different key than the one you need
paulc: is this orthogonal?
markw: related
joesteele: i think you're saying "not receiving waiting-for-key doesn't mean you have a key?"
markw: you always receive waiting-for-key if you're waiting for a key
... but do you get something explicit saying that playback will go?
joesteele: you'll get a key-status-change saying that something might happen
markw: when playback-resumes does an event fire?
Josh_Soref: i'm sure there is
paulc: ok, so we're done w/ that one
ISSUE-100 Is "running the Encrypted Block Encountered algorithm" the correct way to Attempt to Resume Playback If Necessary?
<joesteele> https://github.com/w3c/encrypted-media/issues/100
paulc: markw you responded w/in 2/3 days
... ddorwin said this was related to ISSUE-98
... (a) + (b)
... others should look at markw's response
markw: resource-fetch in html-media is hard to hook into
... it doesn't have extension points
... one thing i was surprised by, when looking at the text we have
... if you run into an encrypted block and we don't have the key, you're supposed to block downloading media data
... until you get the key
... i doubt that implementations would do that
paulc: they'll buffer and attempt to resolve key problem in parallel
markw: you don't need to decrypt to resolve time points
... encryption isn't a big problem
... this isn't how our spec describes things
... but that's a separate issue
... we're monkey-patching
... "writing requirements that get inserted into another specification"
... recommended good design pattern is to provide extension points
... those hooks warn people that "dragons might happen here"
paulc: anyone disagree w/ markw's proposal?
[ Silence ]
markw: the italicized text is from the resource-fetch algorithm
... we'd suppress the state changes listed here in our suspended state
... in an ideal world we'd have someone working on adding those extension points
paulc: there was a pointer to a bug in the whatwg spec to supply functionality in preload yesterday
... not 100% useful since our normative reference is to w3c's version
jdsmith: no one here disagrees that this is a problem
... some change is necessary
<joesteele> action joesteele to ask Adobe developers about issue-98
<trackbot> Created ACTION-104 - Ask adobe developers about issue-98 [on Joe Steele - due 2015-11-06].
jdsmith: weird to stop in the middle of an algorithm
paulc: who's creating the pull request?
markw: need to see if ddorwin agrees
... ideally we'd change things more substantially
... so encrypted block handling isn't in fetch, but somewhere further down the line
ISSUE-102 Define what to do when CDM becomes unavailable
<paulc> See also https://www.w3.org/Bugs/Public/show_bug.cgi?id=27067
paulc: there's a proposal
... joesteele agrees
jdsmith: i agree as well
rus: proposal is by cpearce
[ paulc reads cpearce's proposal ]
jdsmith: ddorwin restated the changes in his subsequent post
... more of a proposed implementation
rus: what i see that's missing from ddorwin's proposal
... in FF they state they fire an error message at the end
... i don't see that from ddorwin 's proposal
... no very specific way of saying "there was an error", "how do you propagate the error?"
joesteele: i think there should be an error
... oh, he says methods, not promises
... good point
Josh_Soref: this is for debugability?
rus: debugability and also troubleshooting
<joesteele> I believe an example of the text ddorwin is referring to is https://w3c.github.io/encrypted-media/#createMediaKeys section 2.10
ISSUE-112 Encrypted Block Encountered algorithm: Steps to abort playback are insufficient
joesteele: i think ddorwin misunderstood what i was saying
<inserted> https://github.com/w3c/encrypted-media/issues/112
joesteele: ddorwin says it's not generally possible to determine if you have the wrong key
... not what i'm talking about
... does it make sense, when we had decrypted some content, and now we're failing
... that's different from never decrypted content, and we're failing
... in my CDM those are two different error conditions
... my response to ddorwin
... he seems to imply that have-nothing means that you have no data
... you could have no encrypted data
... he's mapping the unencrypted data algorithm down
paulc: he's trying to refer to MSE's alg
joesteele: he's ...
... i'm giving a reason for handling one of the cases extra specially
... i agree w/ his point that we should handle one case
paulc: could we make it a separate issue?
joesteele: make it such that it won't be done
... but i don't feel strongly on it
... i think we could make the other thing a separate issue
... "as an enhancement, we can split this error case out"
... to improve debugging
ISSUE-118 Can EME support link protection, such as DTCP-IP?
<inserted> https://github.com/w3c/encrypted-media/issues/118
MarkVickers: i replied to this
... I agree w/ your comment about source, it's a detail of content protection DRM
... but if you have a web browser on the other end, a TV receiving the content
... and you have a app running there
... need to do two things, (1) as EME do...
... and (2) do you support media type and details
... alternative is horrible
... make up mime type and media type and other link content protection
... DTCPIP+ etc.
... although yes, a lot of machinery you're not using, passing keys, etc
... the machinery you're using is the only way to do it, via EME
... as a practical issue, one could say "that's a separate API"
... but as a practical matter, there will be 0 or 1 content protection APIs
markw: how does a browser on the other end identify DTCPIP content?
... file extension? what?
MarkVickers: i'd have to look
[ Break until 10:30 am ]
<paulc> ddorwin: Are you joining the teleconference?
Outstanding action items
paulc: i'd like to move on
<ddorwin> working on it
ACTION-93: Get in touch with webappsec wg about the "privileged context" which is more generic than saying https, etc."
paulc: do we need to do more?
... there was a sessions you, markw, ran yesterday?
... slides?
markw: the slides will be public when i put them up
MarkVickers: i sent boblund
... a link
paulc: when we deprecated support of EME on insecure contexts
<markw> Mark will respond to https://lists.w3.org/Archives/Public/public-html-media/2015Oct/0070.html with results of the TP session https://www.w3.org/wiki/TPAC2015/SessionIdeas#Secure_communication_with_local_network_devices
paulc: there was no support for pages to connect to insecure devices
... we discussed second screen UCs at a meeting
... before we didn't know of a way for apps to do stuff w/o a fix
... but since it was raised that there's at least one option that could work today, we have something we can experiment with
MarkVickers: and we've raised this to #webappsec (mkwst)
ddorwin: i'm on irc, and catching up on notes in github
Meeting Logistics
<paulc> https://www.w3.org/wiki/HTML/wg/2015-10-Agenda#EME
paulc: yesterday, Matt got the best results from being on mute when not speaking
... we've disconnected the cisco system from the room bridge
... Josh_Soref will be here until 11am (15mins)
... i've asked plh to give us an update on Charter
... before we turn into a pumpkin tomorrow
plh: on that, nothing
... update...
... we could at least extend the HTML WG
... but, we'd have an HTML WG that doesn't work on HTML
... nice aspect is that you guys keep doing what you're doing
... and no question about patent commitments, they carry over
... obviously i'd have to talk to Directors as well
... maybe we can change the name of the group w/o a full AC Review
... one proposal, strongest so far, is to extend HTMLWG for the purpose of the Media TF until June 30
... I think that's the bottom line proposal
paulc: ddorwin, if you look at the agenda, we spent the first 90 mins on topic 1
... let's do topic 3
... we have one formal objection against EME
Formal Objections
paulc: we don't have to do anything about EME-1 yet
... we have to do it before LC-CR
... under Process 2014
<inserted> EME-1<http://dev.w3.org/html5/status/formal-objection-status.html#EME-1>
paulc: "This formal objection will be handled no later than when EME progresses to LC/CR."
... ddorwin, don't bother moving it to github
ddorwin: +1
"Secure release" discussion with TAG
paulc: our issue-85 / tag issue-73
ISSUE-85 "tracked" sessions: architectural concerns pending resolution with TAG
paulc: i don't think there are any updates, and i've been pushing Travis regularly
... I don't think anything else until TAG does something
Email items that might be issues
paulc: I think jdsmith said he'd look
EME Initialization Data Correlation
paulc: I remembered the discussion
<paulc> https://lists.w3.org/Archives/Public/public-html-media/2015Oct/0020.html
paulc: jdsmith you asked during the meeting whether the second message
... in the last agenda, and i said, "well yeah", "it's a direct reply"
jdsmith: it's in my todo queue
<joesteele> action jdsmith to process the EME initData correlation issue
<trackbot> Created ACTION-105 - Process the eme initdata correlation issue [on Jerry Smith - due 2015-11-06].
Items David would like feedback on
paulc: i characterized this
... a set of issues, you sent me a private email saying it'd be good to have feedback on a query
... i took out the issues 80..84 as you suggested
... our results are in github and irc
... how would you like to process these?
... i think i met your request to get F2F processing
ddorwin: those were the ones w/o clear direction
... you've got feedback
... i've marked some as needs-implementation
... that's good
paulc: thanks ddorwin on the background work, and coaching me on maximum to declare victory and progress
... markw and MarkVickers, on ISSUE-118, is the ball in your court, MarkVickers ?
MarkVickers: yes
ddorwin: on ISSUE-118
markw: i'll send you the spec
<joesteele> http://www.dtcp.com/specifications.aspx
ddorwin: is it link-layer, or does communication come through the app?
MarkVickers: it's link-layer
... the notion is, could this link-layer be supported w/o change
... by only using EME that identifies part that determine encryption-system, and media-support
... w/o this, you have to use some combination of link-protection scheme + media type format
<ddorwin> Previous discussions on OOB: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25434 and https://www.w3.org/Bugs/Public/show_bug.cgi?id=17615
MarkVickers: and come up w/ some mime type that supports both
... that's the only part of EME that would be used
... there's never a Key, since it's link protection between two endpoints
<ddorwin> What was described is *not* EME. That's no more EME than HTML-CE is HTML.
ddorwin: not really EME
... there's no interop story
... i brought up a link to previous discussions
... i don't think it makes sense to fork EME
... maybe it's a use of requestMediaKeySystemAccess
<joesteele> scribe: joesteele
paulc: where is the information?
MarkVickers: its in IRC
... I am not interested in forking EME, but I think we can agree that when we get done with the process we will either have 0 or 1 Content Protection APIs in W3C.
... its a question of using the identification system in EME - don't think this is cinompatible
markw: this depends how you identify the DTCP-IP content
... the only reaone you would need this is that the ability of the devic eto protect content will vayr based on whether it can handle this type
... seems to me it would be an entirely different typ of content
... I maight be wrong though - need to know more about how it fits into the stack
MarkVickers: to flesh out a bit more - an operator proivdes two options for getting content - from the locao device using DTCP-IP, the other is from the cloud using DRM protection s we have discussed
... the application is also written by the service provider, so they know what options they have, but they don't know what the device looks like
... e.g. can this device support DTCP-IP? and can it decode this format?
... in which case it would come from the cloud
markw: the right way to do that might be to have a mime-type - there is no unprotedcted DTCP-IP content
MarkVickers: binding to a mime-type means that there are multiple variants on multiples axis which grows quickly
... we have 2 APIs that give a clean answer today
markw: there arent 2 sep questions for DTCP-IP - it is a problem with the canPlayType API - you have to call it multiple times
... requestMediaKeySystem is much better in that respect but if that is the only aspect of it that you want it's not clear it's appropriate
paulc: we know what next steps are -
MarkVickers: I took an action
jdsmith: I would like a very specific answer here eventually
New issues since last meeting
paulc: 3 of these issues have had progress since last meeting, excepting 112
... lets look at that and try to get an answer there
ddorwin: I already changed that to "needs implementation"
... so all are in the same state now
Recent EME issues with outstanding pull requests
paulc: Mark and I discussed this morning - pull requests for 80-84
... we probably need more discussion on 87 to get traction on the others (minus 84 which is orthogonal)
... let discuss issue 80 and its pull request
ISSUE-80 - "tracked" sessions: record of usage should track session usage, not individual key usage
ddorwin: I answrred Marks questions - plan to handle the rest tomorrow - nothing really pending there now.
paulc: so Mark and David will close on pull request 87 and once that is done Mark Watson can make the cascading changes required out of that
... markw it would help if you sent a summary email once you are done with step #1
markw: needs a rebae now and then will be easier to see
ISSUE-84 - "tracked" sessions: document usage for limiting concurrent streams
https://github.com/w3c/encrypted-media/issues/84
paulc: does not have a pull request - still waiting for feedback from people - might be able to just resolve this issue
... I think if no complaints before next week we may just close this issue
jdsmith: I was thinking we should be more proactive - we can always re-open
paulc: any objection to closing now?
ddorwin: had some discussion today and thinking that is more relevant - we can close it for now though
ISSUE-41 https://github.com/w3c/encrypted-media/issues/41
paulc: not convinced this we have concensus that this is a feature request
... we have been going around on this awhile
... should Joe talk about this?
joesteele: I will pass the mike to Mark on this first
https://github.com/w3c/encrypted-media/issues/41#issuecomment-152360391
markw: we have this idea at the beginning that CDMs control the timing of messages. When this message requirement of one was introduced not sure anyone noticed.
... thinkg we all agree that we must have interoperability,
<ddorwin> There was no introduction of requiring a message. It has been there since the very first version!
markw: we are really talking here about optimizations to cut down on the message exchanges - optiomizations that are already deployed
... the way CDMs determine what mesages to send have not been gone over in detail in this group
... that is one interpretation of the TAG review
... we can talk about whether that is a good thing - not sure that is a good thing to discuss yet
... there are many things that a CDM could do - but we are not yet at the place where we need to document this
<ddorwin> joesteele: Look at v0.1b
markw: for me it is not important when it changes - it is the higher level principle that CDM control the messages they sent
... maybe it did not occur to us at the beginning - but it was not an agreed principle that there must be a message exhange
<ddorwin> https://rawgit.com/w3c/encrypted-media/8f06759/encrypted-media.html#dom-generatekeyrequest
ddorwin: the claim that this was not in the spec is not true - this was in the first version
<ddorwin> ^ Very first version of the spec
ddorwin: this opens up things we need to consider, maybe there are specific use cases we can talk about
... figuring this out is going to take time
... and staying within the TAG requirements
... think we need to focus on all the other issues we should focus on for v1
markw: its about the level of scrutiny being applied here, always saying we need interoperability, this feels like it is getting a higher level of scrutiny
... I would be fine applying this level of scrutiny in v2 - when it is not for others
paulc: and those other features alo impact key flow
ddorwin: we would have to consider the impact because this impacts video format
... just because it is common encryption does not mean that it is interoperable
... the content encryption being different would cause a problem for other systems
... how you do renewal does not necessairly impact this
... it just happens that renewal is already within the spec
... applying more scrutiny is fine - and might be the fastest way to resolve htis
joesteele: the content encryption is exactly the same
ddorwin: we are not sure what you are doing here, would like to here more
... especailly with regards to the key chaining
... don't want to cause us problems now
... you can hide things but that is not necesarily good
markw: David you are saying you want to have interoperability, Joe is saying this content would be interoperable
... if we can produce text that crequires this - could we move forward?
paulc: is ths issue that the text says a single message is mandatory?
joesteele: yes
ddorwin: but that does not let you actually use the keys provided
... to Marks question yes - but think this changes core assumptions and would be far reaching
... just like with secure release this would take a long time
... would be fine to do this if we can guarantee interoperability - but will delay a lot
markw: dont think this has to delay us a lot - because I dont think we need the level of detail you are implying
... you are making assumptions we do not know what they are
... if the CDM wants to do lots of key related operations as long as the app behavior is clear and according to the spec, should be fine and does not change things significantly
... would be tractable to come up with something that requires interop
ddorwin: the spec is very clear on what the CDM can do with the initData - we would run afoul of the TAG discussion otherwise
paulc: we have an active thread - lots of discussion going on
... as the chair I may have to ask who believes that the initial messgae is mandatory, but who can live with the spec like that
... we disagree on how long it will take to change
... we will have to trade-off getting features in and finish v1
markw: I want to clarify one point of difference - you can implement the CDM to do anythngin it wants with the initData as long as it conforms to the specification
paulc: that is pretty standard spec behavior
- as long as you are not breaking the spec conformance
paulc: how many of these optimizations impact the visible perfomance?
ddorwin: think this break interoperability - citing HTML example
paulc: disgree with this - look at the conformance clause there.
markw: think we are in agreement on interoperability
... any CDM should be able to process any compliant media - that does not breka interoperability
joesteele: I believe that nothing in my proposal implies that the content would be non-interoperable and the process I mentioned for determining when a key is available is actually more interoperable across browsers than waiting for a message
ISSUE-19 (Jerry) Ensure promises returned by methods are fulfilled before event handlers are executed
https://github.com/w3c/encrypted-media/issues/19
jdsmith: I am not assigned to this, but I have an action to comment
... about sequencing of events and promise resolutions
... I am concerned that simply delaying events is not good API design
... comment from Joey
<paulc> https://github.com/w3c/encrypted-media/issues/19#issuecomment-126759849
jdsmith: I was suggesting we consider reviewing - he is stating renewal message are sent by events - I added a comment that speciyfing events are not fired until promises are resolved is good
... this gives clarity - want event to return only after the promise is resolved
<paulc> https://github.com/w3c/encrypted-media/issues/19#issue-54946877
ddorwin: guaranteeing the order is quite complex ... need to parse my notes on this
... need to spend time on this
action ddorwin to propose soluiton for issue-19
<trackbot> Created ACTION-106 - Propose soluiton for issue-19 [on David Dorwin - due 2015-11-06].
paulc: David will get to issue-19 as soon as he can
... he believes this fix is mandatory for v1
rus: one thing we can do in bubbling up the errors is having systemCodes - so we know what is really going on
paulc: we had that 19 blocks 14 and 31
ddorwin: still believe that is true
... believe this will change the algorithms
... don't want both changes to happen at the same time
<paulc> https://github.com/w3c/encrypted-media/issues/31#issuecomment-152273712
ISSUE-59 |expiration| should be Unix time like Date()
https://github.com/w3c/encrypted-media/issues/59
ddorwin: was assigned to me and progress has been made on the HTML spec which will let me make progress on this. New WebIDL spec will define time
... the primary Web IDL spec will remove date
... I expect there to be progress there and I will ping it - this is blocked on Web IDL - we know what the intended behavior
... just monitoring
paulc: isn't this a breaking interop problem?
ddorwin: we removed the use of Date but they had not removed Date. Boris said - yes we are really removing Date. He was supposed to send a patch.
... I will definie a new bug that says you should define Time as a concept
<paulc> https://github.com/w3c/encrypted-media/issues/59#issuecomment-151220498
paulc: in this comment, you point to a hash IDL Date in another github - that is the current one?
ddorwin: it is in both version and the TR - might get removed from the TR dont know
<Travis_> Note that DOM's Event interface defines its timestamp as: https://heycam.github.io/webidl/#common-domtimestamp
paulc: so you know what needs to happen here
ddorwin: yes
<Travis_> Yet, that domtimestamp is not actually defined :-(
plh: are you aware of the hires stamp?
<plh> http://w3c.github.io/hr-time/
travis_: this sounded familiar - went to the DOM spec and the type for the timestamp links to Web IDL and there is no definition in Web IDL
... you would probably be safe using that same link
... to answer PLH comment about highres timestamp - think they may need something different here. that would not be comparable because you need to compare the times and the hr-time time origin wouldn't work
ddorwin: would be great if Travis could update issue-59 with what he said
<ddorwin> https://github.com/w3c/encrypted-media/issues/59
ISSUE-75 MediaKeyStatusMap: iterable declaration has unexpected behavior; ForEachCallback definition is incorrect
https://github.com/w3c/encrypted-media/issues/75
paulc: where are we on this?
ddorwin: this is another dependency on Web IDL
... there is an outstanding thread on script-coord - we need them to figure out how iterable works. As defined it is buggy and not useful
<ddorwin> ^... in certain uses
Travis_: looks like this issue is being actively discussed and some movement on the Web IDL github issue
... sounds like the behavior will match the Array ForEeach syntax - if folks care
ddorwin: Cameron replied this morning but have not read yet
<paulc> see https://lists.w3.org/Archives/Public/public-script-coord/2015OctDec/0039.html
paulc: in active motion so lets go on
ISSUE-101 Normatively require distinctive identifiers to be different by top-level and EME-using origin
https://github.com/w3c/encrypted-media/issues/101
ddorwin: think this needs author input and followup a bit
<paulc> see also https://www.w3.org/Bugs/Public/show_bug.cgi?id=27269
ddorwin: there are two of these bugs now - some ambiguity now
... trying to figure out how to scribe the issues with Distinctive Identifier - coming soon
... this will be in issue 117 - should be up next week
paulc: this is one that is currently "needs implementation"?
ddorwin: it needs followup
... its assigned to me - I need to fill in the description
<paulc> https://github.com/w3c/encrypted-media/issues/117 should be updated with better desc
ISSUE-105 EME registry: Separate definitions of Initialization Data Types from Stream Format parsing
https://github.com/w3c/encrypted-media/issues/105
paulc: this blocks 104 and 106
ddorwin: also a Buggzilla bug - has been low priority
... it is now blcoking the MPEG-2 stuff as well as the registry - need to take some time to restructure
... proposed structure is there - needs feedback from the group
paulc: who will sign up to provide feedback?
... plh can you express an opinion?
plh: I will provide personal comments on this
ISSUES 107 and 108
paulc: PLH resolved these this week and they need implementation now
plh: I did an analysis of the references in the spec and opened another bug
https://github.com/w3c/encrypted-media/issues/107, https://github.com/w3c/encrypted-media/issues/108
Needs author input bugs
paulc: believe we have covered this
https://github.com/w3c/encrypted-media/issues/68
https://github.com/w3c/encrypted-media/issues/98
https://github.com/w3c/encrypted-media/issues/101
https://github.com/w3c/encrypted-media/issues/102
s/: https://github.com/w3c/encrypted-media/issues/101/: https://github.com/w3c/encrypted-media/issues/100/
paulc: these were processed earlier
ISSUE-99 Remove note recommending setMediaKeys() be called before providing media data
https://github.com/w3c/encrypted-media/issues/99
paulc: marked as needs implementation now
jdsmith: the comment was the action
... I commented on whether it was acceptable
... ready for implementation
ISSUE-110 Individualization text regarding device identifiers is overly broad and restrictive
https://github.com/w3c/encrypted-media/issues/110
paulc: David you pointed out this is related to 117
ddorwin: the description I am creating will point out why this is difficult
... changing the definition will change this - so this may not make sense in the end
paulc: so 110 is blocked by this work on 117
Open Bugzilla bugs
https://www.w3.org/Bugs/Public/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&component=Encrypted%20Media%20Extensions&list_id=60418&product=HTML%20WG&query_format=advanced
paulc: David converted the bulk of these to github issues
... recommended leaving the formal objection bug in Bugzilla for now
markw: I just moved the systemCode bug
paulc: some private discussion going on with Jerry to resolved before even moving right?
jdsmith: yes
paulc: would be useful to send a link to the group about the status
ddorwin: folks should be getting messages as these are moved - but not necessarily for each one
jdsmith: they should get a disposition message is they are closed
paulc: may end up with just one bug left in Bugzilla (to preserve the old links)
... suggest the editors continue as they have been doing
EME issues "to be implemented" by Editors
https://github.com/w3c/encrypted-media/labels/needs%20implementation
paulc: 24 ready to be implemented
TAG question
joesteele: if we do something that TAG did not approve of - what is the impact?
paulc: would suggest we go back to the TAG and discuss anything that we consider "not appropriate" for EME.
Next Meeting
paulc: would it be useful to get back together on Nov 17th?
ddorwin: I think github has worked really well - if we have stuff we need to discuss we can, but bring up things there.
paulc: I will try to craft an agenda even earlier than normal
... would like to point out the huge amount of work David has done in getting things done and providing suggestions on how to handle things
ddorwin: I will be out of time on the 17th
paulc: next week is 24th and Thankgiving in the US - don't want to skip a whole month
... would be useful if maybe we can work something out
ddorwin: yes Matt and I are both going to the same thing - we will try to do as much as possible offline
paulc: any other business?
<giuseppe> draft minutes
Summary of Action Items
[End of minutes]
________________________________
Minutes formatted by David Booth's scribe.perl<http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm> version 1.140 (CVS log<http://dev.w3.org/cvsweb/2002/scribe/>)
$Date: 2015/10/30 04:37:40 $
________________________________
Scribe.perl diagnostic output
[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.140 of Date: 2014-11-06 18:16:30
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/
Guessing input format: RRSAgent_Text_Format (score 1.00)
Succeeded: s|topci: ISSUE-68||
Succeeded: s/concensus/consensus/
Succeeded: s/... /... /G
Succeeded: s/present +/present+ /
Succeeded: s/Topic: ISSUE-68//
Succeeded: s|https://github.com/w3c/encrypted-media/issues/68|http://github.com/w3c/encrypted-media/issues/68|
Succeeded: s|https://github.com/w3c/encrypted-media/issues/68||
Succeeded: s|http://github.com/w3c/encrypted-media/issues/68|https://github.com/w3c/encrypted-media/issues/68|
Succeeded: s/MarkVickers/markw/
Succeeded: s/paulc_/paulc/G
Succeeded: s/action for markw to ask his developers about issue-98//
Succeeded: s/text/pending comment/
Succeeded: s/l/l?/
Succeeded: i|generally|https://github.com/w3c/encrypted-media/issues/112
Succeeded: s/optimization/enhancement/
Succeeded: s/this/this error case/
Succeeded: s/topic: ISSUE/topic: ISSUE/
Succeeded: i|rep|https://github.com/w3c/encrypted-media/issues/118
Succeeded: s/paulc/markw/
Succeeded: i/www/Topic: Meeting Logistics
Succeeded: s/that there's a workaround/that there's at least one option that could work today, we have something we can experiment with/
Succeeded: s|rrsagent, drat minutes||
Succeeded: i|formal|-> http://dev.w3.org/html5/status/formal-objection-status.html#EME-1 EME-1
Succeeded: s/on Wed/yesterday/
Succeeded: s/../.../
Succeeded: s/-layer/-system/
Succeeded: s/requestMediaKeySystem is much better in that respect/requestMediaKeySystem is much better in that respect but if that is the only aspect of it that you want it's not clear it's appropriate/
Succeeded: s/thinkg/thinking/
Succeeded: s/no convinced/not convinced/
Succeeded: s/makrw/markw/
Succeeded: s/thi gives/this gives/
Succeeded: s/remove data/remove date/
Succeeded: s/the are/are/
Succeeded: s/update issue-19/update issue-59/
Succeeded: s/comparable/comparable because you need to compare the times and the hr-time time origin wouldn't work/
Succeeded: s/folks cares/folks care/
Succeeded: s/rpelied/replied/
WARNING: Bad s/// command: s/: https://github.com/w3c/encrypted-media/issues/101/: https://github.com/w3c/encrypted-media/issues/100/
Succeeded: s/bulkd/bulk/
Succeeded: s/ISSUE-59 (David}/ISSUE-59 |expiration| should be Unix time like Date()/
Found Scribe: timeless
Inferring ScribeNick: timeless
Found Scribe: joesteele
Inferring ScribeNick: joesteele
Scribes: timeless, joesteele
ScribeNicks: timeless, joesteele
Present: Tatsuya_Igarashi paulc markw rus Josh_Soref joesteele MarkVickers toddg Yves Yosuke ddorwin plh
Agenda: https://www.w3.org/wiki/HTML/wg/2015-10-Agenda#EME
Got date from IRC log name: 30 Oct 2015
Guessing minutes URL: http://www.w3.org/2015/10/30-html-media-minutes.html
People with action items:
[End of scribe.perl<http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm> diagnostic output]
Paul Cotton, Microsoft Canada
17 Eleanor Drive, Ottawa, Ontario K2E 6A3
Tel: (425) 705-9596 Fax: (425) 936-7329
Attachments
- image/png attachment: image001.png
Received on Saturday, 31 October 2015 01:10:26 UTC