See also: IRC log
<trackbot> Date: 09 September 2014
trackbot, start meeting
<trackbot> Meeting: HTML Media Task Force Teleconference
<trackbot> Date: 09 September 2014
trackbot, start meeting
<trackbot> Meeting: HTML Media Task Force Teleconference
<trackbot> Date: 09 September 2014
<scribe> ScribeNick: paulc
Bug 26575 - Separate creation of the MediaKeySession from "message" event generation
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26575
Bug 24322 - Reorganize spec by object
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24322
paulc: how many changes for 24322.
David: no content changes and conversion to Respec is next on list.
paulc: See 25506 for conversion to Respec
Bug 26678 - MediaKeySession.generateRequest() should not fail if callable is false
<ddorwin> Just a typo
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26678
That ends the three bugs that were resolved except for items noted below.
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26738
See lively discussion.
We need someone that has access to "ISO Common Encryption EME Stream Format and Initialization Data" [1]
<ddorwin> See https://www.w3.org/Bugs/Public/show_bug.cgi?id=26738#c9
The initdata types are conflated the container parsing and we may have split those up.
David will file a separate bug for that which would change the registery.
Bob has access to the spec and will work with the Editors on getting proposed text for 26738
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26758
This bug has no solution yet but David proposes to move responsibility for preventing duplicate sessions to the CDM
We will leave 26758 for David to propose a concrete change and/or to make the change.
See Agenda: http://lists.w3.org/Archives/Public/public-html-media/2014Sep/0004.html
<joesteele> scribe: joesteele
<paulc> Cluster of related bugs: 26683, 26575, 25920, 26401
paulc: cluster of related 26683,
25920, 26401, 26575 are all related
... need some help figuring out where to attack the
cluster
... David, I think you suggested 26683
<paulc> Discussion also relates the URL processing to the HTTPS bug: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26332
ddorwin: some were open for
related reasons, 26401 is an effect
... would like to close the old bugs and file a new bug if we
can
paulc: I am not the subject
matter expert here, but I would like to resolve. This is also
related to 26332 as part of the rationale
... David you said two things. You wanted to open a new bug and
you wanted to close all except 26683.
ddorwin: if folks are not happy with that, then would rather have a new bug that states exactly what we want
paulc: you have a concrete proposal
<paulc> Core issue is one of two things a) we have a concept of CRM specific meta-data OR b) need for routing information like a URL
<paulc> Joe: I and Jerry are arguing for a) but David is arguing against that
markw: I agree with Joe - we
could move this under one bug. The argument is about this
routing information - should be enum or routing field
... there is a design for free-form information and folks will
just prepend to the other information if we do not provide
it
... think that there was confusion about where this information
was extracted from - didn't realize we were removing the
possibility to populate destinationURL
<ddorwin> If the federated case is the only use case, we should either think through how that works or add support when necessary.
s/realizerealize/
ddorwin: I think the federated use case will come with some metadata as well - don't want to add something that may never be used
paulc: do you think the current document handles either case today?
ddorwin: there is an assumption
that this means urls in the PSSH - don't think that is
desirable
... has been brought up as a reason for why to have the
URL
... don't want to overallow -- be more explicit
... don't add stuff we may not need
joesteele: the PSSH solution was
the compromise solution adopted by the DASH group -- before we
move away should have a lot of discussion
... in my mind we are removing existing flexibility not adding
a new feature if we do not support this
<ddorwin> This is a web API, so we have different constraints (and capabilities/assumptions) than DASH.
ddorwin: DASH is going after other use cases than the web so maybe this does not apply, DASH should not force us to do anything
paulc: can we ask the editors to
close those bugs (possibly marking as dups of 26683)
... perhaps topic should be generalized or changed to reflect
this
... David - would you mind handling that?
ddorwin: will do - will close some as they were
<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=25092
paulc: this was an old bug with
new comments just recently
... Joe - take a personal note to review
markw: I agree with David in that
bug - it would be great to have a more more general
solution
... someone on the browser side needs to coordinate on this for
a more general solution
paulc: You are saying the CSS working group is not interested in the problem unless there is a proposed solution. Do you see this in their domain?
markw: there was not a statement of intent -- just lack of interest
paulc: can you add that message
to the bug? from the CSS archive?
... browser vendors on the call should look at this as well
ddorwin: it was my proposal to make it more generic on MSE or HTML Media Element -- I was just providing feedback though
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26372
<ddorwin> Current title is
<ddorwin> https://www.w3.org/Bugs/Public/show_bug.cgi?id=26372 - Report issues/events not related to a specific method call
paulc: looks like pretty active
discussion
... Mark responded on the 26th. Mark, Joe David all active
here.
... are there questions to resolve here?
joesteele: I thought there was general agreement we need to solve, I thought a specific event would be fine. Are you ok with that David?
<ddorwin> The latest discussion starts at https://www.w3.org/Bugs/Public/show_bug.cgi?id=26372#c10
joesteele: I thought downscaling was an example of this message to send
ddorwin: is the key usable event
already exists, seems like remaining events are tied to keys
like this
... could return a list of all keys (not just usable) instead
with associated statuses/codes
... please provide feedback
markw: question here was more
general - we have exceptions that can be returned, but no way
to return the detailed system code
... that still seems like an outstanding problem
ddorwin: that was not the intent of this bug although it was discussed - Jerry was going to file a bug on that
jdsmith: I thought this bug was
the system code topic, appears to have been re-titled
... possible I need to add a new bug
ddorwin: the intent here was always to handle the non-promise errors
jdsmith: I think it would make sense to add the system code issue as a specific bug
paulc: so David, bug 26372 is dealing with the proposal in comment 10. Jerry will separate out the system code issue
joesteele: I think system codes would apply to the non-promise bugs as well
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26600#c2
paulc: what is the status?
... not much discussion in last few weeks
<paulc> See https://www.w3.org/Bugs/Public/show_bug.cgi?id=26600#c4
ddorwin: I was planning to implement my proposal in comment 4
paulc: bug 26600 is in the hands of the editors then
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25923#c20
<paulc> See Jerry's https://www.w3.org/Bugs/Public/show_bug.cgi?id=25923#c12
<paulc> See also https://www.w3.org/Bugs/Public/show_bug.cgi?id=25923#c19
paulc: maybe we can start with Jerrys comment 19
jdsmith: Anne added a comment since that, that says that the key system must be asynchronous
paulc: where do we stand then?
jdsmith: we had requested a
separate bug for CDM downloads so we could have a larger
discussion
... Anne is focusing on isTypeSupported for an approval
process. Because this is a user-conditional format and the user
needs time to respond.
joesteele: this type of
conditional access will drastically reduce usage we have
seen
... off topic
ddorwin: have to figure out how to support this for browsers that choose to do it
jdsmith: I would still like to
look at another way to get user authorization, might have to
look at other use cases
... this is why we suggested a separate bug
ddorwin: isTypeSupported allows the application to decide about content downloading - blocking it might slow that down
jdsmith: is plan one time per use or one-time per origin?
ddorwin: we don't know
joesteele: have to assume the worst case
ddorwin: also don't know when prompting will happen, separate from when the download happens
jdsmith: seems like there is a flow where it returns "maybe" to allow downloading until ready for use. I woul dfavor that
paulc: Jerry - any other cases we should consider?
jdsmith: would like isTypeSupported to be synchronous and split the async portion into separate bug
ddorwin: other specs have places where they say -- is you are going to handle permissions - do it here. Maybe we should have that as well
paulc: is Anne the right Mozilla representative for this and the person to inform when the bug is created?
ddorwin: Boris has commented as well
paulc: we are out of time
rrsagent: generate minutes
paulc: the editors should continue to update us on changes and agenda items for next week
rrsagent: generate minutes
rrsagent: generate minutes
s/s\/realizerealize\///
rrsagent: generate minutes
rrsagent: generate minutes
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/theat/that/ FAILED: s/rewalizerealize// Succeeded: s/rewalize/realize/ Succeeded: s/didn't rewalize we were removing/didn't realize we were removing the possibility to populate destinationURL/ Succeeded: s/bug 25092/Bug 25092 - Need a way to inform script that resolution restrictions are applied/ Succeeded: s/reently/recently/ Succeeded: s/take a personal/Joe - take a personal/ Succeeded: s/26373/26372/ Succeeded: s/aguring/arguing/ WARNING: Bad s/// command: s/s\/realizerealize\/// Succeeded: s/they added a/Anne added a/ Found ScribeNick: paulc Found Scribe: joesteele Inferring ScribeNick: joesteele ScribeNicks: paulc, joesteele Default Present: markw, jdsmith, ddorwin, davide, paulc, BobLund, joesteele Present: markw jdsmith ddorwin davide paulc BobLund joesteele Agenda: http://lists.w3.org/Archives/Public/public-html-media/2014Sep/0004.html Found Date: 09 Sep 2014 Guessing minutes URL: http://www.w3.org/2014/09/09-html-media-minutes.html People with action items:[End of scribe.perl diagnostic output]