See also: IRC log
<trackbot> Date: 23 September 2014
<paulc> Agenda: http://lists.w3.org/Archives/Public/public-html-media/2014Sep/0017.html
<scribe> scribe: joesteele
<paulc> Agenda: http://lists.w3.org/Archives/Public/public-html-media/2014Sep/0017.html
<paulc> Bugs: http://tinyurl.com/7tfambo
paulc: looks like 18-19
bugs
... any recent changes from the editors?
<paulc> Current editor's draft: https://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html
ddorwin: recent edit was just a fix for the events that were not split up
<paulc> Bug 26776 - Diagnosing and resolving CDM errors needs a numeric systemCode (deleted with MediaKeyError)
paulc: Mark asked some questions
in comment 5 -- think they were answered in comment 6
... Mark did you get what you needed?
markw: think so, if i understand what they are saying
<paulc> latest question is in: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26776#c7
markw: implies that anything like DOMEception might not be a good match though
paulc: any other opinions on this? here or in the bug would work
jdsmith: I have been meaning to make a proposal, will try to summarize with a proposal going forward
paulc: spun off from 26738
<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=26811
<paulc> Backburner proposal: We should have a table and page for Initialization Data Types and separate pages for stream/container parsing information. Maybe we can use the MIME type as the index for a table pointing to the latter pages.
ddorwin: this is just a separation of the registry, on the back burner now as it does not affect the main spec
paulc: so this is lower priority
<paulc> http://lists.w3.org/Archives/Public/public-html-media/2014Sep/0019.html
<paulc> Very recent response from Mark: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26887#c1
jdsmith: I want repeat whats in
the bug - issue I raised is that we have been trying to make
the session load model work for our implementation and it does
not work
... our model the license server controls things like this, for
secure release we have a condition in the license itself that
controls the secure release
... session type for us does not make sense, reloading does not
make sense
... temporary licenses would still be compatible with secure
release, does not fit the model today
... we have been working on a proposal for the app to query
that data about secure release information not yet
complete
... problem it raises is that between that model and the
app-centric model have not come up with a common abstraction
yet
... have a draft proposal that discusses enumerating but have
not posted yet
paulc: I put a link to marks coments
<Zakim> ddorwin, you wanted to clarify whether this bug is specifically about Netflix' secure proof of key release or (also) something else (i.e. offline in general)?
ddorwin: my comments are also in
the queue
... is this specifically about the Netflix secure proof of key
release case? or something else?
jdsmith: there are similar issues
with offline playback, but tried to focus on the secure key
release
... we would prefer the keys to just be re-used
automatically
ddorwin: have discussed many
times on many threads but have not come up with a better
proposal
... persistent sessions are not the same as persistent licenses
-- Mark has cleaned up that text
... some ambiguity maybe still needs to be addressed
Markw: don't see a problem with a
superset of the two models
... clear that license server gets to approve any persistence,
also approves any expected key release
... question is how much can the application exercise
control
... we also need some concept of the group of keys that have
been installed
... need to be able to associate the original session with the
key release messages
... can't be entirely be opaque -- the application needs to
know that this is a key release related to that earlier
session
<paulc> Joe: I agree with Jerry's bug that we have had problems with loading persistent keys
<paulc> ... it is possible to do but ungainly
<paulc> ... We expect that keys will be discovered automatically and don't expect the app to know what keys need for a particular content
<paulc> ... the current model seems to imply the app needs this information BUT it is does not say it explicitly
<ddorwin> The current text is designed to provide the app control while allowing the license to specify the exact details (for robustness reasons). Basically, what Mark said I believe.
<Zakim> ddorwin, you wanted to note that the current text is designed to provide the app control while allowing the license to specify the exact details (for robustness reasons).
ddorwin: pasting my comments ...
<ddorwin> As with all other web APIs, the application must be in control. What Joe said is by design.
<ddorwin> The current text is designed to provide the app control while allowing the license to specify the exact details (for robustness reasons).
<ddorwin> I think this is what Mark described.
<ddorwin> The important thing is that the application knows what will happen and the behavior is consistent across implementations.
ddorwin: what Mark described is
in the spec
... it is intentional that the license cannot tell you to store
things when you did not request a persistent license
... the important thing is that the application is in
control
... consistent with other web APIs
... don't think some things should just be loaded
markw: if we did remove
loadSession --
... if it was made clear that reloading was happening when
createSession reloaded a perisstent license, would that meet
your need for application control?
... if not why?
ddorwin: I think generateRequest() would take initiData and then say we loaded it, might be ok from a web api model, but then we have some ambiguity
markw: is that ambiuguity ok from
the point of loading?
... maybe still have something explicitly for key release
ddorwin: would need to store the
iniData in your app for key release?
... offline pinning case would be similar -- you would have two
models
... would like to hear from Joe and Jerry what specific use
cases we would want to use initData in
jdsmith: I focused the bug on the
secure release, but the offline playback case -- a transaction
happens
... where a persistent license is issued, we would recognize
that it is persistent whether or not the app recognized
it
... the server would drive the storage
... they were issued and the service directed the client to
store them
... they should be reusable in the easiest manner possible,
would be positive that in session startup they are discovered
and reused
... don't understand marks comment about the key release
obligation
<ddorwin> How does the application manage the license? For example, to unpin?
ddorwin: my understanding is that in jerrys model the licenses are persisted and used, but how does the application manage the license?
jdsmith: that is part of the CDM awareness of the persistent licenses stored - would like to see a specific API for enumerating and removing
ddorwin: I would be interested in seeing that
<paulc> Joe: From the use cases perspective, I would like to see the InitData retained in two cases:
<paulc> a) if the app wants to release keys it would be useful for the apps to have the InitData
<paulc> b) in line with what Jerry said, when you acquire keys then you would provide the InitData
<paulc> ... The CDN should be able to find the keys from the supplied InitData
<paulc> ... I want the app to be able to say explicitly say if the keys should be persisted (since the user may be on a public computer and the CDN does not know this)
<paulc> ... The app may not want to cache a persistent key so the CDN should not always assume this is being done
markw: re: Jerrys question about
associated information with the keys
... we associated some information with the session the keys
were originally requested in -- we need to maintain that
association when the keys are released
... needs to be some notion of a group of keys which needs to
be associated with that original session data
jdsmith: re: Joe's comment about
app having control
... in our view the app participates in determining what type
of license gets issued, but not necessarily getting
stored
... something like a buy/purchase that aligns the license type
with the session type
... want to avoid having the app create a session where storage
is authorized but the app is not allowed to request that type
of license
... re: marks comment -- we have retained the idea that the app
would retain the information that the information that the
license were removed using
markw: that would work
ddorwin: pasting --
<ddorwin> Counterexample to not needing app control: There have been real problems with PlayReady servers being configured to send persistent licenses (possibly to get some related behavior) and unexpectedly leaving licenses on the client causing problems.
ddorwin: this is an example of
the app not needing to be in control or not needing to be
persistent
... unexpected licenses on the client is a real concern
... especially when app and server teams are different
paulc: spent 30min on this --
should we continue or move on?
... any recommendations on which item we could go to
next?
... security bugs or new bug from David?
<ddorwin> I will send emails on bug 25923 and bug 26372 this week. Please provide feedback and suggestions
jdsmith: on last bug -- referred to a proposal we are drafting -- will post it
<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=26838#c2
paulc: comment 2 had some
pointers to changes made
... Joe responded with questions this morning
<paulc> Joe's questions in https://www.w3.org/Bugs/Public/show_bug.cgi?id=26838#c3
ddorwin: I was aware of the
things you mentioned -- Joe's format cannot be validated or
pre-parsed
... that is why there are SHOULDs in that text
... can he tell us why it is encrypted?
<paulc> Joe: In our case the only thing that is encrypted is the keys
<paulc> ... The context is that metadata can be delivered separate
<paulc> ... The metadata can be provided in a manifest separately
<paulc> ... The policies in the metadata may be confidential and therefore some customers want it encrypted
<paulc> ... David: Why shouldn't the customer see the policy?
<paulc> ... No it is hide the metadata in transit.
<paulc> David: Maybe HTTPS would be a better solution for transfering the manifest
<paulc> Joe: My concern is more about the signature
<paulc> David: That is why there is an AND/OR in the text.
<paulc> Joe: My first concern about the proprietary nature of the PSSH - you may need need an NDA to get the format
<paulc> ... it might be hard to implement in an OSS browser if the code exposes the proprietary format of the PSSH
<paulc> Joe: The Initidata can be under NDA as well
<paulc> ... it is relatively recent (4-5 years) that solutions to private InitData are provided
<paulc> ... older CDMs likely have these private formats
<paulc> Joe; i will go back and review it with this input
<paulc> ... My concern is that making it a SHOULD may make it not applicable to Adobe and MSFT - not sure about Google
<paulc> David: These could be useful hints to the implementer
<paulc> Joe: Having a hint to an implementer is okay
<paulc> ... I will add my concern but I am not blocking the solution moving forward
paulc: going back to the
agenda
... Joe appealed for more discussion on the HTTPS issue -- more
came in
... be aware of the TAG comments
<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=26738
<paulc> Paul: I think we have dealt with the Patent Policy question and can now return to the original technical request.
UNKNOWN_SPEAKER: extending it to
covers MPEG2 Commoon encryption is ok as long as that does not
imply it is mandatory
... should restate any objections so that folks who care can
provide feedback
ddorwin: someone needs to writeup how this information is extracted
paulc: ask the TF for that --
maybe Bob will respond as he has been active
... any particular bugs we should move on?
ddorwin: title of A has changed to reflct what we have been talking about
<ddorwin> I will send emails on bug 25923 and bug 26372 this week. Please provide feedback and suggestions
<paulc> Title of 26738 is now Add entry for MPEG-2 TS CENC to the Stream Format Registry
ddorwin: trying to get
clarification on Object.observe
... there is agreement we want to address just trying to figure
out how
... please comment on those bugs
paulc: 24771 is an old bug -- you said you will make the change after the re-org -- is this in your pending queue?
ddorwin: yes, trying to get the design issues out of the way first
<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=24771#c5 is behind other large design issues.
paulc: one last item
paulc: Think Media TF will meet
during TPAC week
... don't expect confirmation now -- will start a thread to
collect opinions and for how long
... if you are planning to stay at the conference hotel, block
booking is released on Oct 3rd
... any comments?
... I will start a thread to discus next week
I would attend
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/thnk/think/ Succeeded: s/...question/... question/ Succeeded: s/associate the original session with the group of keys/associate the original session with the key release messages/ Succeeded: s/ungaimly/ungainly/ Succeeded: s/htis/this/ Succeeded: s/CDN's/CDMs/ Succeeded: s/i f I /if i / Found Scribe: joesteele Inferring ScribeNick: joesteele Default Present: jdsmith, +1.215.286.aaaa, paulc, joesteele, davide, markw, ddorwin, +1.425.605.aabb Present: jdsmith +1.215.286.aaaa paulc joesteele davide markw ddorwin +1.425.605.aabb Agenda: http://lists.w3.org/Archives/Public/public-html-media/2014Sep/0017.html Found Date: 23 Sep 2014 Guessing minutes URL: http://www.w3.org/2014/09/23-html-media-minutes.html People with action items:[End of scribe.perl diagnostic output]