agenda

<kaz> Dashboard page

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: http://lists.w3.org/Archives/Public/public-html/2012Mar/0275.html

<kaz> Dashboard page

<kaz> Content Protection topic

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 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

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> Paul's email HTML-WG's ACTION-209

<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 ]