See also: IRC log
rssagent, generate the minutes
<ddorwin> yes
<scribe> Scribe: paulc
https://github.com/w3c/encrypted-media/issues/85
paulc: When will the TAG be ready to respond to this issue?
travis: TAG was very busy in Nov
and Dec and this kept TAG members busy and blocked
progress.
... I am on my way on vacation and therefore a resolution will
not occur until mid to late january
... Tag is meeting F2F in mid-January and this issue will be on
the F2F agenda
<slightlyoff> hey all
<slightlyoff> sorry, just joined
paulc: Does the TAG need any more input?
Travis: I think I have all the
input needed but will not speak for Alex.
... We might be able to use some contact time.
<markw> \me could you remind us the dates of the TAG F2F ?
<slightlyoff> January 12-15, IIRC
<slightlyoff> but in AUS, so calendar hijinks apply
paulc: Please let us know if you need any more input or time with the TF. We can either do that at the TAG F2F or on a separate TF call.
<slightlyoff> thanks
https://github.com/w3c/encrypted-media/issues/132
jdsmith: I have been concerned
about key rotation for some time.
... MSFT has received a lot of input from others that EME did
not support this feature of CENC
... We need to take into consideration the large amt of input
about this feature and we believe it should be in EME V1
... In band keys are one way to go. There has been lots of
input but we believe the use case is very important.
johnsimmons: The input has come
from DASH-IF, and others that are planning to use EME.
... They have struggled with the role of app and CDM on
handling of keys
... CENC specifically permits key rotation (... more
description of this)
... EME lack of support of this feature interferes with these
communities use of EME
joesteele: Adobe has several
media partner companies about limitations of EME
... mostly about performance requirements that each PSSH
requires message exchanges and was raised in a separate
issue
... I don't have a strong view of media data to CDM
... We should discuss who should handle the data
... This was raised at TPAC ATSC break-out session
... We should be encouraging people to use EME to move on to
the web platform
plh: My understanding is that
Google is pushing back on whether this is a V1 feature - We
should remember that every V1 feature needs to
implemented
... So far we don't have a V1 test suite and I don't think we
should not work on this given our status
<ddorwin> EME v1 was intentionally limited to a feature set we could reasonably address and ensure interoperability. Through this effort, we have learned about various optimization requests. These are all interesting and should be addressed, but this should be done in a thoughtful structured manner, not in a hurry and holding up four years of work.
<slightlyoff> so it sounds like this is about v1 vs. v2?
plh: it has taken 4 years to get
here for the limited feature set and we believe that this issue
needs thought and we need to take time to do this right
... we need to get V1 out the door and we should be working on
test suite instead of more features
... we should be focused on interoperability of current feature
set
<ddorwin> slightlyoff: yes
plh: and then start up next feature set and that can be done in parallel
johnsim: Its our view and others
in the broadcast side that this is a spec bug and NOT a new
feature
... it is related to inteface of license aquisition between app
and CDM
... we don't believe this is not a new feature but that we
should fix this in the current spec
... we agree that interoperability is very important but that
should not stop the implementation of this use case
... as long as the application does not have to know the CDM
that it is using this could be done in current spec
<ddorwin> Call it what you want - feature or "bug" - it is still a fundamental change in the behavior that has been mostly stabilized. The current design was not a mistake, oversight, or flaw - it was very intentional to limit the scope and drive interoperability.
markw: We should have more
technical discussion on the use case and we should have a PR
for the use case
... we need to know what "it" is and then we can determine when
it will be implemented by browsers and whether it would delay
v1 or not
BobLund: I second what Mark said and we should assess timing when we have a specific proposal on the table
<ddorwin> Any time spent on this is time not spent on the existing confirmed v1 bugs.
plh: I don't here disagreement here. Interop for V1 is important and the timing of this use case is a discussion point.
<slightlyoff> ISTM that the debate here is about wether or not there's a v2 spec to write diffs against?
<ddorwin> We should drive our bug count much lower before focusing on this. As plh said, people are welcome to take the lead, but let's not let it distract us.
<markw> \me @ddorwin That's not necessarily true if the people contributing to this are different from those who would spend time on the other bugs ;-)
joesteele: A possible way forward is to discuss this in ISSUE-132 and to remove the other issues that are pending
<ddorwin> @markw: Yes. I was having a difficult time communicating that nuance.
joesteele: We should also be
making progress on the other 40 open issues - they just require
work and it would be good "to clear the decks" for V1
... let's make progress on both fronts
<ddorwin> But still, would we delay CR to address this and the other feature requests?
jdsmith: I had two goals on
entering ISSUE-132 - 1st was to get agreement on the use case
2nd is to decide on when to add this feature
... We need to drill down into how to accommodate this
feature/use case in EME
... 1 direct consumption of keys in the stream
... 2 reducing the need for key requests ...
<markw> @ddorwin depends on the length of the delay which depends on the timing and number of the intent to implement from browsers
jdsmith: we need to figure out the nuts and bolts of this feature
<ddorwin> I am concerned about trying to just address this use case. I think we should consider all of these use cases together, and I think that would significantly delay v1 CR.
<ddorwin> Consider them together to ensure we have a consistent solution and the APIs make sense for all of them.
slightlyoff: First apologize for
not making enough progress on ISSUE-85
... I am surprized there is a V1 - V2 discussion and not a
living approach
... how is that being decided?
<ddorwin> The charter says CR is to be in Q1.
paulc: The TF has not really touched on the schedule or exit criteria for LC/CR for V1 since we have had > 40 issues open for some time
<plh> Pual: the task for ce has not really touched on it, or on our exit criteria . we have greater than 40 issues opened for sometimes
Status as of Dec 14: 41 open issues of which 15 are "needs implementation"
<plh> ... as Joe said if we're going to make on use cases like this, we need to make progress on other issues
<plh> Paul: we have 26 open issues, so not ready for LC/CR
slightyoff: I was just trying to understand how the group is thinking about the timeliness issue
ddorwin: I thought we had TPAC discussion about the schedule and we are going to have to make some hard decisions
ddowin: I think it is time to wrap up EME
markw: I don't agree with the
description of duplication of key requests and we need to flush
out those assumptions
... I have made this point in my responses to ISSUE-132
<ddorwin> +1 to what markw said. I don't think the use cases are clear. I understand the possible concepts, but what use cases are we trying to solve? I think several have been discussed in 132.
johnsim: As I said earlier I
don't believe the use case is a feature request but they are
bugs and there is a architectural problem here
... there is a fundamental error in how the application and CDM
interact
... these bugs are being raised by the industry and the
industry is asking for these to be fixed
<ddorwin> Is it uncommon for specs to ship with limitations that need to be addressed in future versions?
johnsim: we need to discuss how
DASH and key rotation are handled by EME
... let's spend the time looking at these two use cases from an
architectural point of view
... if there is a flaw in the architecture then it should be
fixed in V1
<ddorwin> johnsim: Are you proposing to change the architecture of EME at this point?
johnsim: if the architecture is okay and they can be handled then a delay could be discussed
ddorwin: EME was designed to handle a limited set of features. We address live and broadcast (eventually)
<slightlyoff> apologies, I need to leave the call
<slightlyoff> would encourage this group to ship-and-iterate
ddorwin: there are assumptions that narrowed the scope and I don't believe there are architectural problems
<slightlyoff> and you can't do that if you don't ship
ddorwin: a change to the architecture is really late
johnsim: I meant to mention that
keys cannot be delivered in the PSSH box is a architecture
problem
... and there is no way for new initialization to arrive
without a key acquistion since the app can always know if the
initialization it sees contains new keys
<ddorwin> re: keys in initData - it's a scope-limiting limitation, not necessarily an architectural one.
johnsim: DASH is doing weird
binary comparisons to test for this and it is not always
right
... only the CDM can know if the key acquistion is
required
... I agree we need to get EME done
... I agree that we need test suite for V1
interoperability
... I agree with the need for an interoperability design
... I disagree that EME is ONLY for Video on Demand
markw: 1. it would help if could be clarified if the key acquisition is required problem
2. to answer Alex about the future schedule, I believe that the most importnat question si when there is shipping code
<ddorwin> +100 to markw’s statement regarding current discussions treating the symptom without understanding the underlying problem.
<ddorwin> and that spec versions do not affect/prevent shipping code.
rssagent, generate the minutes
paulc: Several suggestions here:
<slightlyoff> so a few things (and apologies for needing to drop off the call)
1. Make progress on the already existing outstanding issues especially those that are "needs implementation" - get the bug count down
2. Continue the technical discuss as suggest by MarkW to clarify the problems and possibly create a pull request to more clearly define what is being proposed
<slightlyoff> 1.) specs are, by definition, backwards-looking. At the point where they are load-bearing, they aren't the state-of-the-art. So there's a real and useful tradeoff the group needs to make regarding when things show up in the "near" version vs. the "far" version
3. Make initial progress on a test suite of the existing features
<slightlyoff> 2.) the way to reduce the FOMO regarding v1 vs. v2 is to iterate faster
paulc: Every one can produce pull request for ANY issue
paulc; I am not expecting we will meet until the 2nd week in January ie maybe Jan 12
scribe: I hear lots of people
starting their end of year holiday this week and to be
realistic progress will probably only occur in early jan
... we could use Jan 12 for a) more discussion on -132 b) more
discussion with TAG on -85 or c) for MSE discussion
None
Safe holidays and safe travels to everyone.
Adjourned
This is scribe.perl Revision: 1.144 of Date: 2015/11/17 08:39:34 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/implemented by browsers/implemented by browsers and whether it would delay v1 or not/ Succeeded: s/2 reduce/2 reducing the need for key requests/ Succeeded: s/ISpecs ship with limitations that need to be addressed in future versions./Is it uncommon for specs to ship with limitations that need to be addressed in future versions?/ Succeeded: s/+q/q+/G Found Scribe: paulc Inferring ScribeNick: paulc Present: paulc markw joesteele Travis_Leithead ddorwin jdsmith BobLund plh slightlyoff davide johnsimmons Agenda: https://lists.w3.org/Archives/Public/public-html-media/2015Dec/0007.html Found Date: 15 Dec 2015 Guessing minutes URL: http://www.w3.org/2015/12/15-html-media-minutes.html People with action items:[End of scribe.perl diagnostic output]