See also: IRC log
<trackbot> Date: 01 April 2014
<scribe> scribe: joesteele
<paulc> trackbot, start meeting
<trackbot> Meeting: HTML Media Task Force Teleconference
<trackbot> Date: 01 April 2014
Discussin F2F next week
Two groups to handle in the agenda
Promises, extensibility, ...
scribe: want to get a clear understanding
<paulc> s/accessibility/extensibility/
paulc: start the agenda with item
#5
... first section is 25199
... David filed and made 5 other bugs dependent on it
<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=25199
<paulc> Blocks: 17750 21798 24081 24216 24771
paulc: this bug blocks 5 other
bugs -- David thinks this is a solution to those other
bugs
... like to hear what others think on this
ddorwin: Promises is a way of
returning async results -- WebCrypto going to LC with
them
... we have async operations, previously used the Error event
but kinda inconsistent
... but if you add methods have no idea where errors are coming
from
... think Promises solve some of this issue
paulc: willing to spend time
discussing as this group of bugs covers over 25%
... need to discuss or at least come up with a plan
ddorwin: it's four pages long -- happy to discuss
joesteele: I think it is a good idea -- but have to review fully
glenn: agree with the proposal
paulc: anyone else?
<pal> @paulc: very choppy
paulc: what is our plan for
processing the 6 bugs?
... should I add this an an agenda at the F2F?
joesteele: I think we should
discuss at the F2F
... only because I need time to review
paulc: would like to know this will let us clear those bugs
very choppy
reconnecting
<paulc> zakim is not answering
<ddorwin> i had that problem the first time i tried
<ddorwin> …this morning
Zakim?
not answering me either :-)
joesteele: has everyone had a chance to read David's proposal -- this would be a good time
paulc: will I have a concrete proposal at the F2F to handle these bugs?
ddorwin: the Promises API
reshapes all these APIs
... we have committed to some of the changes, others change
completely, it will be a drastic change
johnsim: is it the decision that we will change to Promises?
paulc: only two folks in agreement so far
joesteele: 3 including David
paulc: would like to get some
sense from the group today what the impact would be on the
other bugs
... would be a staged solution, if we decide to go that way in
first 5 minutes, won't know how to process the other 5
bugs
... could review the impact of this change today
<ddorwin> 17750 - implemented but there are some remaining details being discussed; these are resolved by Promises.
<ddorwin> 21798 - errors will change drastically. still need to evaluate
paulc: proposals may look different for the other bugs if we go in this direction
<ddorwin> 24081 - resolved (mostly?) by Promises
<ddorwin> 24216 - agreed to do. Promises affect the API
paulc: 24771 Microsoft agreed to review, David marked it as dependent, Microsoft has made no comment as yet
<ddorwin> 24771 - jdsmith agreed. Potentially simplified by promises.
paulc: if we make the decision to move to this, not sure what we will do with the other bugs at the F2F
ddorwin: updated IRC with the
status of the bugs you mentioned
... for the most part we have agreed on a solution
johnsim: has Mark made a comment yet? he is active there
ddorwin: not yet
paulc: will put this cluster on
the F2F agenda
... we will try to make a decision on 25199 -- if you are not
going to make a decision, make your position known before the
F2F so folks can review and respond
<adrianba> i think moving in the direction of promises for async is good - i haven't reviewed the details of the proposal - my initial reaction is that promises might not map very well to the unordered events that can fire in EME
<adrianba> but i can see it making some of the error handling better
paulc: folks who own the other bugs should review Davids synopsis and determine if feasible/reasonable and how the bugs would change
<adrianba> is this an all or nothing proposal?
<pal> i have a question about promises
paulc: looks like Microsofts comment on 25771 is positive so we won't review further
ddorwin: Promises is not replacing all events, errors cannot be replaced by Promises
pal: looks like client support for desktop browsers, but not a core feature of ECMAscript, what about support outside of desktop browsers?
ddorwin: defined by ECMAScript now -- it is the future of async APIs
brad: is there a compelling reason to make the move now instead of resolving the bugs first and then moving later?
ddorwin: now is the time because it is a major change before LC
<glenn> +1 to what ddorwin said; the time is now, ... or never
<pal> ECMAScript 7?
paulc: this would be called out
in LC review - so obvious thing to address now
... was this published as sidebar to ECMAScript 6?
<adrianba> it will be in ES6
ddorwin: thought it was in 6
pal: want to make sure we have a normative reference
ddorwin: WebCrypto is in LC (so would have this problem)
pal: we are not that group
paulc: understood
<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=25092
paulc: filed by Mark -- not
here
... David do you want to summarize?
<paulc> See David's response in https://www.w3.org/Bugs/Public/show_bug.cgi?id=25092#c1
ddorwin: it appears some
implementations will downscale content based on the license, he
wants a way for app to know that
... this is specific to that use case, perhaps what apps really
need to know is what KIDs are usable at the moment
... previously the way to know what is usable was to play
it
... this way app could query the available keys
joesteele: in this situation, the key may be the same for both resolutions. this is a specific example of the CDM needing to communicate to the application
ddorwin: did think about that -
could issue licenses to fake KIDs and use those as a proxy for
this
... what can you communicate in the same key case? need to
figure that out in a consistent common and interoperable
way
... think fake KIDs solves this in a generic way
paulc: let's move on - Joe please
respond in the bug with your explanation. David can respond in
kind
... more can be done at the F2F
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25200
paulc: persistent license
thread
... David you filed this bug
<paulc> Email thread: http://lists.w3.org/Archives/Public/public-html-media/2014Mar/0020.html
<glenn> re: promises in ES6, see sections 25.4 and 7.5 in http://wiki.ecmascript.org/lib/exe/fetch.php?id=harmony%3Aspecification_drafts&cache=cache&media=harmony:working_draft_ecma-262_edition_6_01-20-14-nomarkup.pdf
paulc: of course original requester is not an active participant
<ddorwin> This bug actually came out of https://www.w3.org/Bugs/Public/show_bug.cgi?id=24025
paulc: Joe responded to the request
<paulc> Joe's response: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25200#c1
paulc: handle here or at F2F
dorwin: this was actually my bug
-- pasted above
... really talking about offline licenses
... Joe and Shinya have other models in mind
... might not match with EME
... this is mostly about offline storage and the license
request
paulc: so it looks like there is a response from Shinya from this morning
<paulc> Shinya response: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25200#c2
johnsim: in some cases whether
the license can be persisted in dependent on the DRM not within
the applications control
... lot of the discussion is around the application not being
able to override what the DRM is saying
... I think that the question is whether EME should handle this
at all or just handled by the DRM?
... also asking David -- what do you mean by offline
licenses?
ddorwin: agree that DRM is
ultimately responsible for the licenses
... talking about Netflix model .. if Netflix allowed you to
get on a plane and still playback your content -- that is what
I am talking about
johnsim: so you mean a licenses
that can be used when offline
... that is what we mean as well -- no need to request a
license when playing back
... in our model the decision is made by the service sending
down the license
... at the DRM level not the application level
dorwin: I am thinking about watching online versus offline
<paulc> It looks like there is a cluster of 24025 (RESOLVED), 25200 and 25201 and possibly a bug filed by Joe.
johnsim: in the scenario where
the app wants to do something - this is independent of what is
negotiated with the service
... the application wants to prevent caching when it could be
cahced
ddorwin: this flag would tell the
CDM what the app wants to do
... can't override the DRM policy
... with the store() method would directly control whether
stored or not
johnsim: what would the difference. be?
ddorwin: depends on the DRM
johnsim: would have to store it
somewhere though.
... if I wanted to build a solution where I built the app and
own the key server
... I can let the app/user decide whether to store the
license
... then the DRM would issue the right kind of license (that
could be persisted)
... as opposed to having it be a fixed policy at the server
ddorwin: the main proposal is
that a flag is passed to allow the CDM to say I want a
persistent license
... a flag to NOT store it is not what I meant
joesteele: this would not be used by anyone in my opinion
ddorwin: getting the persistent license and not storing it was not what I was proposing
paulc: this sounds like 24025 -- Joe says he would file a bug (25217)
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25217
<paulc> It looks like there is a cluster of 24025 (RESOLVED), 25200 and 25201 and 25217.
paulc: so this is another cluster
of bugs that are related
... should be close to each other in the F2F
... I will skip the next two bugs then as they are related
<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=25218
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25218
<paulc> Note to Paul: consider adding 25218 to the cluster of 24025 (RESOLVED), 25200 and 25201 and 25217.
<paulc> 25218 deals with sessions not be granular enough and it allows for the application to manage licenses/keys
ddorwin: want a clarification on what is in a session versus
<ddorwin> "A Key Session, or simply Session, represents the lifetime of the license(s)/key(s) it contains and associates all messages related to them."
paulc: will have to deal with this in the F2F -- not all scribed
<ddorwin> Sessions can only be created with initData.
<paulc> David's comment: https://www.w3.org/Bugs/Public/show_bug.cgi?id=18515#c23
https://www.w3.org/Bugs/Public/show_bug.cgi?id=18515
<pal> @ddorwin: will you be at F2F on Wednesday?
paulc: looks like it has been reopened
adrianba: think I implemented
this -- was not my proposal
... think is was Jerry
jernoble: yes this is my bug
paulc: Jerry will look at David's comment
UNKNOWN_SPEAKER: paulc: 24951,
24673, 24873, 17673, 17682, 24027, 24419
... all of these bugs are interconnected as explained in the
agenda
... some bugs block each other, some have transitive
relationships
... some are waiting for actions from David, some are waiting
for implementation from David or Adrian
... all are effectively in this cluster -- not sure which to
pull to the top to discuss
... want to point out that the cluster exists and processing
would resolve 30% of our bugs
<adrianba> I've made lots of changes for 24951 this morning.
UNKNOWN_SPEAKER: paulc: would be really good if you could come to the F2F knowing how you would like to process these bugs
adrianba: think this somewhat
unblocked the other bugs
... the content type strings checks will probably not be an
issue now
... some open questions will -- but think it unblocks 17673 for
ISOBMFF
... might need some help for the archeology -- some older text
might be resurrected
paulc: ok -- we are out of
time
... think there are 4 main clusters to eal with at the
F2F
... Promises
... License persistence
... and this last cluster
... plus extensibility cluster (2-3 bugs)
... that is most of the significant technical discussion. That
is how I will organize the F2F agenda
... please let me know if you think that is the wrong
thing
... will send a draft agenda for the media session in advance
of the F2F so we have a written list of the order to do them
in
... send me any suggestions you have
<scribe> ... done for today.
UNKNOWN_SPEAKER: adjourned
s/diff./difference/
This is scribe.perl Revision: 1.138 of Date: 2013-04-25 13:59:11 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/accessibility/extensibility/ FAILED: s/accessibility/extensibility/ Succeeded: s/17750 - details being discussed - resolved by Promises/17750 - implemented but there are some remaining details being discussed; these are resolved by Promises./ Succeeded: s/David comment/David's comment/ Succeeded: s/paulc: last topic -- /Topic: Last Topic --/ Succeeded: s/its 4 pages/it's four pages long/ Succeeded: s/have Mark/has Mark/ Succeeded: s/repsond/respond/ Succeeded: s/EC 6/ECMAScript 6/ Succeeded: s/a s a /as a / Succeeded: s/original request is/original requester is/ Succeeded: s/cacheing/caching/ Succeeded: s/diff./difference./ FAILED: s/diff./difference/ Succeeded: s/not storing is not what I meant/a flag to NOT store it is not what I meant/ Succeeded: s/24951, 24673, /paulc: 24951, 24673, / Succeeded: s/--complex/ - Complex/ Succeeded: s/would be really good/paulc: would be really good/ Found Scribe: joesteele Inferring ScribeNick: joesteele Default Present: pladd, davide, +1.781.221.aaaa, +1.720.897.aabb, johnsim, glenn, paulc, +1.425.936.aacc, pal, ddorwin, joesteele, +1.425.614.aadd, adrianba, BobLund, [Microsoft] Present: pladd davide +1.781.221.aaaa +1.720.897.aabb johnsim glenn paulc +1.425.936.aacc pal ddorwin joesteele +1.425.614.aadd adrianba BobLund [Microsoft] Agenda: http://lists.w3.org/Archives/Public/public-html-media/2014Apr/0000.html Found Date: 01 Apr 2014 Guessing minutes URL: http://www.w3.org/2014/04/01-html-media-minutes.html People with action items:[End of scribe.perl diagnostic output]