- From: Kazuyuki Ashimura <ashimura@w3.org>
- Date: Fri, 09 Mar 2012 02:39:23 +0900
- To: public-web-and-tv@w3.org
available at:
http://www.w3.org/2012/03/08-webtv-minutes.html
also as text below.
Thanks a lot for taking these minutes, Bryan!
Thanks,
Kazuyuki
---
[1]W3C
[1] http://www.w3.org/
- DRAFT -
Media Pipeline Task Force Teleconference
8 Mar 2012
[2]Agenda
[2]
http://www.w3.org/2011/webtv/wiki/MPTF/Agenda_Telco_8th_March_2012
See also: [3]IRC log
[3] http://www.w3.org/2012/03/08-webtv-irc
Attendees
Present
Kaz_Ashimura, Clarke_Stevens, Bryan_Sullivan, John_Simmons,
Juhani_Huttunen, Bob_Lund, Mark_Vickers, Joe_Steele,
Glenn_Adams, David_Corvoysier, Aaron_Colwell, Franck_Denoual,
Paul_Gausman, Mark_Watson, Adrian_Bateman
Regrets
Chair
Clarke
Scribe
bryan
Contents
* [4]Topics
1. [5]agenda
2. [6]requirements on dashbard page
* [7]Summary of Action Items
_________________________________________________________
agenda
<kaz> [8]Dashboard page
[8] http://www.w3.org/2011/webtv/wiki/MPTF
clarke: today we plan to go thru reqs & compare to the proposal
... we can continue with the adaptive streaming proposal if time
permits e.g. the chromium proposal
juhani relationship of security proposal to the new HTML WG task
force - a new list, and would Web & TV be able to join
automatically, or need to be a HTML member?
scribe: can we as an IG push to auto join ?
clarke: some admin questions there... the TF objective is to provide
input to Web & TV relevant to content protection. The HTML WG TF is
focusing on getting those reqs into HTML
kaz: all participants in MPTF are encouraged to join, if the
preference is to auto-join, can discuss that with W3C
johnsimmons: don't you have to be a member of HTML WG?
kaz: yes
mark: there will be a separate mail list, to clarify that point.
kaz: MPTF members can join in the mail list discussion but to join
in meetings, you need to be a member
clarke: how would joint TF work?
kaz: have not talked about that yet with the HTML WG
clarke: easiest would seem to be just joining HTML WG, but concerns
with that should be clarified
juhani: that clarifies the situation, participating on the mail list
is OK but beyond that joining is needed. The joint TF is another
option but I'm not pushing that.
markv: You can subscribe and read the HTML WG list but cannot post
unless you are a member - this might be the same for the new TF
kaz: another possibility is to create a separate WG
lynn: agree that as a possibility, but has not been discussed in the
HTML WG meetings
clarke: seems most people interested are OK with a TF in HTML WG
joesteele: a new WG would have IPR restrictions, which might be a
good thing
joesteele: haven't seen a specific comment re IPR but there are
concerns
johnsimmons: don't see that as a genuine issue
clarke: IPR limitations of the TF would not seems to be real
limitations
johnsimmons: nothing in the spec deals with content protection IPR
aspects
joesteele: the spec as it is today is generic enough, but the
linkage with the decoder module may have IPR. without further spec
in that area it may not move forward and thats where the issues may
occur - the spec is not complete
clarke: adrian and mark - are you comfortable moving forward with
the TF as is?
adrian: the current spec proposal is a framework. there are content
protection implementation details of the UA which should be outside
the discussion and not needed to be specified
clarke: if we run into a hard issue we still have the option of
creating a WG
glenn: note that there is no difference between the IPR policy in
W3C. just that the disclosure rules only apply to the members of the
WG. the HTML WG with such a large # of members may have more that
are reluctant to disclose
glenn: on the linkage to the CDM, implementations of CDM interfaces
may relate to IPR but a plugin CDM architecture is a separate thing
requirements on dashbard page
clarke: now to dashboard reqs and content protection proposal
<adrianba> Media task force proposal:
[9]http://lists.w3.org/Archives/Public/public-html/2012Mar/0275.html
[9] http://lists.w3.org/Archives/Public/public-html/2012Mar/0275.html
<kaz> [10]Dashboard page
[10] http://www.w3.org/2011/webtv/wiki/MPTF
<kaz> [11]Content Protection topic
[11] http://www.w3.org/2011/webtv/wiki/MPTF#Content_Protection
clarke: "Content protection methods must enable the rights of the
user as specified in the agreement. "
<glenn> to clarify my comments: disclosure rules apply to members of
a WG; if work is done in a separate (e.g., new) WG, then the members
may be different that HTTML WG members; this could alleviate
objections by current HTML WG members who may not be willing to
agree to disclosure rules if work is done in HTML WG
clarke: from the wiki [12]http://www.w3.org/2011/webtv/wiki/MPTF
... anyone disagree that the proposal supports that requirement?
... note that there was no statement that the requirement is not
fulfillled
[12] http://www.w3.org/2011/webtv/wiki/MPTF
glenn: clarify the term "user" in the requirement?
clarke: that means the end user (consumer) of the content.
... background to this requirement is "The Media Pipeline Task Force
takes no position on the specifics of legal agreement between users,
content owners and content distribution service providers (the
agreement). The objective of the MPTF regarding content protection
is to provide the technical tools to enable the terms of those
agreements. "
... there are rights of the content owner, then there are
agreeements with content distribution services on how it must be
protected, and then agreements that users make when they consume
that content
... they can be complex and beyond the scope of this group, but the
suggestion is that the "agreement" refers to all of those
... we should enable the agreements to be fulfilled
glenn: seriously suggest rewording the phrase re "rights of the
user" - that may be taken too broadly
clarke: clarifying the intent, the user has the rights to use the
content as legally specified by the service
clarke: there may be other unspecified rights beyond use, e.g.
copying and redistribution within some realm - maybe those rights do
exist, but not explicitly through the service
... we should not try to address legals issues directly but should
be respective of them
glenn: just concerned that the statement of rights will overshadow
the role of the agreement
clarke: will take action to edit the phrase
... the next requirement "Content protection methods must protect
the rights of the content owners as specified in the agreement. "
... assume the same concerns may exist for that as well
clarke: anyone else have any comments?
... (no one disagreed)
<glenn> yes, same concerns exist
joesteele: please number the requirements
clarke: requirement "3. Content protection methods must protect the
rights of the distribution service provider as specified in the
agreement. "
... IMO the proposal does try to protect the rights of those 3
groups... is there any party left out there, and any concern on the
proposal fulfilling those requirements?
... (no objections)
... the req "4. The content protection system must not advantage one
specific method over another. "
... this has some of the same wording weaknesses, e.g. "advantage",
so I will clarify
... e.g. any CDM advantage over another would not be in the spirit
of the proposal
bryan: suggest to add that clarification as an example
clarke: yes, as the goal that a new CDM vendor should not be
restricted from adding their CDM to this infrastructure
clarke: (no comments)
<glenn> notes that Paul Cotton (HTML WG chair) as posted
"ACTION-209: Set up an encrypted media proposal task force"
<glenn> [13]Paul's email HTML-WG's ACTION-209
[13] http://lists.w3.org/Archives/Public/public-html/2012Mar/0275.html
<glenn> and requests comments
<glenn> note proposed "Any member of the Media TF MUST be a member
of the HTML WG."
clarke: the req "5. The content protection solution must support at
least one mandatory method that can be used to enable
interoperability between different systems. "
... a lot of discussion on this point so far
... suggestion of the clearkey system as a recommendation - any
comment?
joesteele: confused whether this relates to the packaging or ???
clarke: it means e.g. AES encryption should be common regardless of
the key system
joesteele: wanted clarification that packaging would not be
encumbered by the requirement
(did not catch the last comment)
markw: the encryption should be clearly specified by the container
(scribe: please correct if mis-stated)
johnsimmons: the requirement should not disadvantage CDMs that
cannot comply
clarke: there may be conflicting goals... the idea of fully defining
an interoperable set of requirements is good but the broader set of
forces affecting this may put the advantage of clearkey at risk
aaron: arent there advantages to already being a standard? e.g.
well-established containers have methods
joesteele: adding a sub-bullet that the method should be independent
of the container format would satisfy the concern, and that we are
not specifying the details as part of the interoperability goal
clarke: will add a sub-bullet to separate the key system from the
container format, that might clarify
... any other comments? with those changes, any concerns about the
requirement being fulfilled?
... (no comment)
... the req "6. Content protection methods must work with "open
source" browsers. "
... getting a lot of discussion... the goal is that open-source
implementations are possible
<joesteele> +1
clarke: any concerns?
glenn: content protection methods are a broad field, and could have
various impacts on CDMs, and some CDMs cannot be implemented in
open-source browsers
clarke: the proposal addresses browser implementation, and the
proposal is intended to avoid it being implementation blocking to
CDMs
clarke: will re-write that requirement to address the concern
... the req "7. Content protection must be useable in HTML5 "
... apple pie, any comments?
... (none)
... the req "8. Content protection must be useable with specific
HTML5 features such as media elements (whenand features (such as
timed tracks) within these elements. "
... reflective of the ABR requirement that we wanted to use the
media element, not objects, and timed text tracks within that
element
... the proposal should not prevent use of those features
... parts of the stream should be in the clear e.g. open to search
to enable functions
... any concerns that the proposal is not responsive to the reqs?
joesteele: some concerns about that, it probably needs some more
specification in that area
clarke: will rewrite the requirement to be more specific, and take
another look at the proposal based upon that
... next week, we will continue with the rest of the reqs
... please bring up any concerns on the list. we will continue the
process with the ABR proposal
[ adjourned ]
Summary of Action Items
[End of minutes]
_________________________________________________________
Minutes formatted by David Booth's [14]scribe.perl version 1.128
([15]CVS log)
$Date: 2012/03/08 17:24:00 $
[14] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[15] http://dev.w3.org/cvsweb/2002/scribe/
--
Kaz Ashimura, W3C Staff Contact for Web&TV, MMI and Voice
Tel: +81 466 49 1170
Received on Thursday, 8 March 2012 17:40:30 UTC