See also: IRC log
<trackbot> Date: 20 January 2015
<paulc> waiting for quorum
<paulc> waiting for quorum
<paulc> scribe: paulc
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27738
David: Anne's latest message says the name change is not needed: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27738#c5
<markw> +1 to leaving the name as it is
Paul: Proposal on the table is to
NOT change the name
... So far David and Mark support not changing the name
<joesteele> +1 to not changing
Jerry: I agree with no change
Paul: Any objections to closing
bug 27738 was WONTFIX?
... No objections
<scribe> scribe: joesteele
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27738
<scribe> Scribe: paulc
<joesteele_> scribe: joesteele
<joesteele_> ddorwin: that was the original proposal -- did some research on HTML5 media elements
<joesteele_> ... usually when we have change events it the attribute name
<joesteele_> ... example volume and queue
David: In general, the pattern appears to be "<attribute-name>change"
<joesteele_> ... given we have keystatuses -- keystatuseschange would be apporpriate
<ddorwin> keystatuseschange
<markw> are we going to change the attribute to KeyStatus, though ?
<joesteele_> ddorwin: no -- that was resolved in bug 27740
<markw> in another bug
<ddorwin> The pattern of "<attribute-name>change" would imply "keystatuseschange"
<joesteele_> Zaki, aabb is me
Bugzilla 27740: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27740
<markw> ok, makes sense
<joesteele_> ok
<joesteele_> paulc: what is the change we will make?
<ddorwin> proposal: Change keyschange to keystatuseschange
<joesteele_> +1 to proposal
<ddorwin> (per comment 2 in the bug)
<joesteele_> paulc: seems to meet Glenns original concern
<joesteele_> ... anyone objecting?
<joesteele_> RESOLVED to fix as per the proposal
<joesteele_> https://github.com/w3c/encrypted-media/issues/14
https://github.com/w3c/encrypted-media/issues/14
<joesteele_> ddorwin: bug was originally about having the async CDM algorithms firing events directly
Original bugs is: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27138
<joesteele_> ... after thinking more, realized whether this was application visible is an issue
<joesteele_> ... when application is calling generateRequest it is not clear that the promise will be resolved before the message is received
<joesteele_> ... this might be problematic
<joesteele_> ... is there any guarantee to ordering?
<joesteele_> ... if not we have this problem that reslolving the promise at the end does not help at all except knowing you did not fail
<joesteele_> ... can we resolve this another way? or should we instruct apps to rely on the message?
<joesteele_> ddorwin: I meant resolve the problem
<joesteele_> ... one way is that the promise has the message
<joesteele_> ... not great implementation-wise
<joesteele_> ... might need to do something to make things better for apps here
<joesteele_> paulc: mark commented recently
joesteele: Any change will impact
us and we are discussing it. Need more time.
... Chris is not on the call and it would be good to get his
input.
... We are resolving the promise after receiving messages and I
don't know if this is required or if it is just how I
implemented it originally
<joesteele_> joesteele_: still waiting for input internally
<joesteele_> ddorwin: I wrote this the way they are assuming that the promises would be resolved first
<joesteele_> ... goal was that the promise would be resolve before the message is received
<joesteele_> ... but not sure whether we can easily guarantee either
<joesteele_> ... but important thing to do is make this reasonable for the apps
<joesteele_> first thing to guarantee is that the promise is resolved before the message handler
<joesteele_> ddorwin: joe please ping Mozilla folks
<joesteele_> paulc: no other comments, let's move on
<joesteele_> issue-7?
<trackbot> Sorry, but issue-7 does not exist.
https://github.com/w3c/encrypted-media/issues/7
<joesteele_> https://github.com/w3c/encrypted-media/issues/7
<joesteele_> paulc: this one is to finalize the agreement
<joesteele_> jdsmith: the bug proposed stripping out the attribute for waitingFor and canPlay waiting mechanisms
See Jerry's comment: https://github.com/w3c/encrypted-media/issues/7#issuecomment-70595972
<joesteele_> ... last week we agreed it was acceptable
<joesteele_> ... we use it in one algorithm
<joesteele_> ... don't think that is enough to keep it in the spec
Joe agreed with Jerry's proposal https://github.com/w3c/encrypted-media/issues/7#issuecomment-70663182
<joesteele_> ... CDM can determine without the attribute
<joesteele_> ... this was just our attempt to keep attribute
<joesteele_> paulc: so agreement from last week there is no objection to?
<joesteele_> jdsmith: correct
No objection to the proposal from last week https://github.com/w3c/encrypted-media/issues/7#issuecomment-70168165
last week's discussion: http://www.w3.org/2015/01/13-html-media-minutes.html#item11
<joesteele_> paulc: any more discussion? david you know what to do?
<joesteele_> RESOVLED to fix as per discussion last week
<joesteele_> https://github.com/w3c/encrypted-media/issues/8
<joesteele_> jdsmith: just looked this morning -- need another day or two to review
<joesteele_> ... think I agree with David's logic
<joesteele_> ... this applies to next one (ISSUE-9) as well
<joesteele_> paulc: Jerry has 72 hours to respond to issues 8 & 9
<joesteele_> https://github.com/w3c/encrypted-media/issues/9
http://lists.w3.org/Archives/Public/public-html-media/2015Jan/0030.html
<joesteele_> paulc: believe naming items are done, job is in the editors hands
<joesteele_> paulc: we said we would give MSE a month, so EME mtg next week and week after?
<joesteele_> markw: since we have some additional time, some naming related bugs are still around. can we handle?
<joesteele_> ddorwin: I will not be available the next two Tuesdays, only available on the 10th
<joesteele_> ... available after the next two weeks
<joesteele_> ddorwin: next week all day mtg and then on vacation
<joesteele_> paulc: proposal is to meet again on Feb 10th
<joesteele_> ... any objections?
<joesteele_> ddorwin: hopefully make progress in the bugs
<joesteele_> paulc: so EME mtg on Feb 10th, Paul to decide whether we have MSE mtg on Feb 3rd
<markw> https://www.w3.org/Bugs/Public/show_bug.cgi?id=25092
<joesteele_> markw: think we concluded in the bug
<joesteele_> ... need to finalize that
<joesteele_> ddorwin: haven't read the reply yet
<ddorwin> "downscaling" or "output-downscaled"? I prefer the latter since it's consistent with "output-not-allowed".
<joesteele_> https://www.w3.org/Bugs/Public/show_bug.cgi?id=25092
<joesteele_> markw: I am fine with that
<joesteele_> +1
<jdsmith> +1
<joesteele_> paulc: any objection to resolving with the name "output-downscaled"
<joesteele_> markw: I think it is unavoidable that the keystate changes when content is downloaded
<joesteele_> paulc: david can resolve the bug with that name
<markw> https://www.w3.org/Bugs/Public/show_bug.cgi?id=27124
Henri's email appeal to fix all naming items: http://lists.w3.org/Archives/Public/public-html-media/2015Jan/0023.html
<joesteele_> Add "individualizationrequest" to the MediaKeyMessageType enum
<joesteele_> paulc: Henri says this is blocked on a naming issue
see Mark's support for individualization-request https://www.w3.org/Bugs/Public/show_bug.cgi?id=27124#c20
<joesteele_> paulc: marks comment points to individualization-request
<joesteele_> paulc: any additional discussion?
<joesteele_> +1
<joesteele_> jdsmith: ok
<joesteele_> RESOLVED to fix 27124 with individualization-request
<joesteele_> https://www.w3.org/Bugs/Public/show_bug.cgi?id=27283
<joesteele_> ddorwin: don't think this is a big deal, app will get a rejected promise
<joesteele_> ... don't think the difference will be checked
Depends on WebIDL bug https://www.w3.org/Bugs/Public/show_bug.cgi?id=27284
<joesteele_> paulc: continue to wait on bug 27284
<joesteele_> paulc: David to you have everything you need to do the heartbeat? 4-5 bugs to resolve
<joesteele_> ... lots of work
<joesteele_> ... think we are done
<joesteele_> ddorwin: there are probably 5 or so other bugs folks should look at in github
<joesteele_> paulc: thanks everyone!
<ddorwin> Please take a look at new bugs at https://github.com/w3c/encrypted-media/issues
<joesteele_> ... back on Feb 10th to discuss
<joesteele_> s/concenr/concern/
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/keystatuschange/keystatuseschange/ Succeeded: s/or keystatusisChanged// Succeeded: s/concenr/concern/ Succeeded: s/weke/week/ Succeeded: s/wiatingFor/waitingFor/ Succeeded: s/primise/promise/ Succeeded: s/heartbeta/heartbeat/ Succeeded: s/ for the next two weeks// Succeeded: s/Bug 25892/Bug 25092/ Succeeded: s/fnialize/finalize/ Succeeded: s/Bug 27283/Bug 27283 - InvalidAccessError usage is questionable; use TypeError instead?/ FAILED: s/concenr/concern/ Succeeded: s/disucssion/discussion/ Succeeded: s/pubs/publications/ Succeeded: s/Bug 25092/Bug 25092 - Need a way to inform script that resolution restrictions are applied/ Succeeded: s/Bug 27124/Bug 27124 - Add "individualizationrequest" to the MediaKeyMessageType enum/ Succeeded: s/Issue 14: Consider/ISSUE-14 Consider/ Succeeded: s/usuaulyll/usually/ Succeeded: s/realized whether this was application visible/realized whether this was application visible is an issue/ Succeeded: s/just how I implemented it/just how I implemented it originally/ Succeeded: s/David logic/David's logic/ Found Scribe: paulc Inferring ScribeNick: paulc Found Scribe: joesteele Found Scribe: paulc Found Scribe: joesteele Scribes: paulc, joesteele WARNING: No "Present: ... " found! Possibly Present: BobLund David Jerry Microsoft P2 Paul aaaa aabb adrianba davide ddorwin html-media https jdsmith joesteele joesteele_ joined markw paulc proposal trackbot You can indicate people for the Present list like this: <dbooth> Present: dbooth jonathan mary <dbooth> Present+ amy Agenda: http://lists.w3.org/Archives/Public/public-html-media/2015Jan/0036.html Found Date: 20 Jan 2015 Guessing minutes URL: http://www.w3.org/2015/01/20-html-media-minutes.html People with action items:[End of scribe.perl diagnostic output]