W3C home > Mailing lists > Public > public-web-and-tv@w3.org > March 2012

[MEDIA_PIPELINE_TF] minutes - 8 March 2012

From: Kazuyuki Ashimura <ashimura@w3.org>
Date: Fri, 09 Mar 2012 02:39:23 +0900
Message-ID: <4F58EECB.1050906@w3.org>
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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:44:06 UTC