[HOME_NETWORK_TF] Common content security requirements

Giuseppe, Juhani, Mark and others,

I'd like to see if we can finish up the discussion we were having on the requirement 2.2

"If the user-agent doesn’t have support for a DRM required by the content it should be able to download an available module that supports playback of content using that DRM."

I think you were saying this is supported by existing user agent plugin mechanisms.
I agree but it seems that using existing HTML5 support for DRM plugins would not result in requirement 3.1 also being met 

"Web content should use the video and audio element interfaces to playback DRM protected content. All of the features that exist for the video and audio element should be available when playing protected content, e.g. have child track elements, be assignable to a media controller object."

Is there a rewording of 2.2 that you’d suggest?

Bob 

> -----Original Message-----
> From: public-web-and-tv-request@w3.org [mailto:public-web-and-tv-
> request@w3.org] On Behalf Of Kazuyuki Ashimura
> Sent: Thursday, August 25, 2011 10:36 AM
> To: public-web-and-tv@w3.org
> Subject: [HOME_NETWORK_TF] minutes - 23 August 2011
> 
> available at:
> http://www.w3.org/2011/08/23-webtv-minutes.html

> 
> also as text below.
> 
> Thanks a lot for taking these minutes, Clarke!
> 
> Kazuyuki
> 
> ---
> [1]W3C
> 
>        [1] http://www.w3.org/

> 
>                                 - DRAFT -
> 
>                        Home Networking Task Force
> 
> 23 Aug 2011
> 
>     [2]Agenda
> 
>        [2] http://lists.w3.org/Archives/Public/public-web-and-

> tv/2011Aug/0116.html
> 
>     See also: [3]IRC log
> 
>        [3] http://www.w3.org/2011/08/23-webtv-irc
> 
> Attendees
> 
>     Present
>            rbardini, JanL, jcdufourd, dcorvoysier, aizu, igarashi,
>            davidmays, Clarke, giuseppe, MattH, Russell_Berkoff, panze,
>            Bob, narm_gadiraju, mav, kaz
> 
>     Regrets
>     Chair
>            giuseppe
> 
>     Scribe
>            Clarke
> 
> Contents
> 
>       * [4]Topics
>           1. [5]Requirement document review
>           2. [6]Pending comments on Home Network Enabled User-Agent use
>              cases
>           3. [7]Additional section about Related Works
>           4. [8]Prioritization
>       * [9]Summary of Action Items
>       _________________________________________________________
> 
> Requirement document review
> 
>     ->[10]http://www.w3.org/2011/webtv/wiki/HNTF/Home_Network_TF_Require

>     ments
> 
>       [10]
> http://www.w3.org/2011/webtv/wiki/HNTF/Home_Network_TF_Requirements

> 
>     giuseppe: review requirements document
>     a ... what do you think about just having use cases and requirements
>     in requirements document and removing other sections?
> 
> Pending comments on Home Network Enabled User-Agent use cases
> 
>     ->
>     [11]http://lists.w3.org/Archives/Public/public-web-and-tv/2011Aug/00

>     85.html
> 
>       [11] http://lists.w3.org/Archives/Public/public-web-and-

> tv/2011Aug/0085.html
> 
>     Kaz, I'm acting as scribe, but I'm not sure I'm doing it right. You
>     may want to check that things are getting recorded.
> 
>     giuseppe: Do people agree with the change I proposed about the
>     header?
> 
>     russell: I'm okay with dropping the backwards compatibility
>     requirement
> 
>     Russell_Berkoff: we may want to continue to work on item number 1
>     (requirement that headers can issue commands, working information
>     for UA, etc.)
>     ... requirements should explicitly cover the three cases
> 
>     Kaz, I knew I was forgetting something. Thanks
> 
>     giuseppe: I'm concerned that the header issue may restrict
>     application to a particular protocol.
> 
>     Russell_Berkoff: why don't we split the difference and just identify
>     the broad categories?
> 
>     <mav> I'm not able to dial in. Keeps saying the conference is full.
> 
>     giuseppe: look at the text I provided and make comments.
> 
>     Russell_Berkoff: examples may clarify what the requirements should
>     be
>     ... so you will merge and make my requirements informative?
> 
>     giuseppe: yes
> 
> Additional section about Related Works
> 
>     ->
>     [12]http://lists.w3.org/Archives/Public/public-web-and-tv/2011Aug/01

>     01.html Opera, CableLabs
> 
>       [12] http://lists.w3.org/Archives/Public/public-web-and-

> tv/2011Aug/0101.html
> 
>     ->
>     [13]http://lists.w3.org/Archives/Public/public-web-and-tv/2011Aug/01

>     12.html BBC
> 
>       [13] http://lists.w3.org/Archives/Public/public-web-and-

> tv/2011Aug/0112.html
> 
>     giuseppe: next, additional section about related work
>     ... just informative part for work members have done that helped
>     generate use cases
>     ... Do people agree with including this secion?
>     ... referring to section in requirements document mentioning work
>     from BBC, Opera, CableLabs
> 
>     Russell_Berkoff: I'd like to add a submission to that section
> 
>     <MattH> +q
> 
>     giuseppe: You can mention material that is related to use cases
>     (e.g. prototypes, previous work, etc.)
> 
>     MattH: I think it sounds like an excellent idea to also include a
>     reference to CEA 2014 with an explanation about why it is useful
>     ... I'd also like to see some additional text about the CableLabs
>     submission
>     ... it should highlight thinks people would like to know.
> 
>     Russell_Berkoff: I will include some additional text about CEA 2014
> 
>     <giuseppe> ack
> 
>     Narm: what is the reason for including this section?
> 
>     giuseppe: It is just informative. It is good to provide the reader
>     about related work people have been doing. It shows real prototyping
>     work. It's just informative. No recommendation.
>     ... having links to things we have to pay for or that are
>     proprietary is not useful, but other things can be included. We
>     should try not to let the section get too big.
>     ... I will include submissions that have already been proposed.
>     People can start proposing other items.
> 
>     MattH: The particular work of this task force is a direct link that
>     would enable communication on the home network. This is not a
>     cloud-based service.
> 
>     Bob: I agree. My comment was more focussed on being more specific on
>     application to application on accessing a home networked service.
>     You can see my suggested text.
> 
>     giuseppe: I'm concerned about the term "client." It seems too vague.
>     ... Maybe we can clarify using "services" and "devices"
> 
>     MattH: Maybe use "application" instead of "client"
> 
>     Bob: That's fine
> 
>     <scribe> ACTION: giuseppe to replace "client" with "application"
>     [recorded in
>     [14]http://www.w3.org/2011/08/23-webtv-minutes.html#action01]
> 
>     <trackbot> Sorry, couldn't find user - replace
> 
> Prioritization
> 
>     giuseppe: next on the agenda is about priority of requirements
>     ... Francois, and Matt and Bob have commented
>     ... Mark V. suggested rating based on the value of "enabling" use
>     cases
> 
>     Russell_Berkoff: what are the relative advantages of this exercise?
>     ... maybe working groups should determine importance of requirements
> 
>     giuseppe: It is more feedback from the participants. Important
>     requirements may help to make decisions so implementations can begin
>     ... it doesn't limit the specification, but gives some guidance for
>     the specification
>     ... some use requirements enable many use cases. They may be more
>     urgent
>     ... it may be useful for the working committee
>     ... Bob, do you want to go through your requirements?
> 
>     Bob: Yes
>     ... my first comment is on application trust level
>     ... I think this is a second level priority. We've discussed low and
>     high-level APIs and we decided that low-level were more important.
>     This requirement implies a certain level of API in the user agent.
> 
>     giuseppe: One option could indicate security requirements as
>     high-priority
> 
>     <MattH> +q
> 
>     giuseppe: this will drive the solution. If a particular solution
>     can't meet the requirement, then it points to a different solution.
> 
>     Bob: By definition it's in scope if we make it a requirement.
> 
>     <mav> i just joined (finally)
> 
>     giuseppe: even with a low-level API you can have the discussion
> 
>     Bob: it's not obvious to me that that is true
>     ... without providing some generic JavaScript level trust
>     infrastructure
> 
>     giuseppe: we could remove security from a discussion of priority and
>     just say separately that security is required.
> 
>     Bob: can we put some language in the requirment and maybe the scope
>     of that is dependent upon the architecture
>     ... removing security from the priority discussion is fine
> 
>     giuseppe: content protection
> 
>     Bob: I don't think the API generated by this group will address that
> 
>     <igarashi> would u spealk loundly? Russel.
> 
>     Bob: maybe make it clear that the implementation must support DRM
>     ... I think the requirement is out of scope.
> 
>     giuseppe: I'm fine with removing it from scope
> 
>     I think it's out of scope
> 
>     I think "compatibility" with DRM systems is okay but more specifics
>     are out of scope
> 
>     giuseppe: take a look at the actual text and make suggestions to
>     change or drop. I'm okay with dropping it.
> 
>     narm_gadiraju: I think we can drop it
> 
>     Russell_Berkoff: in CEA 2014 it just identifies DRM so the player
>     can know what to do
> 
>     Bob: I can provide some suggested text
> 
>     <narm_gadiraju> I said we should not drop it but consider changing
>     to include identification of DRMs
> 
>     Russell_Berkoff: I will submit some text also
> 
>     giuseppe: we will try to propose by next week since it's supposed to
>     be our last call
>     ... next is media identification
> 
>     <narm_gadiraju> can the speaker, please speak up
> 
>     Bob: my comment is that the API may determine the level that content
>     indentificatio is relevant
> 
>     <giuseppe> kaz, is priobably also "giuseppe" (I accidentaly attached
>     it to me)
> 
>     MattH: Do we need to split the discussion on requirements based on
>     low or high-level APIs?
> 
>     Bob: Whether they will ultimately be covered by an implementation is
>     dependent on the API level
> 
>     giuseppe: This may be a more generic requirement. Maybe it should be
>     handled outside the priority discussion.
>     ... maybe we consider it like security.
> 
>     MattH: that makes sense
> 
>     Russell_Berkoff: one thing not covered in requirements is any notion
>     of home-to-home or groups of homes.
>     ... not commonly discussed. UPnP says something about it in
>     RemoteAccess:2. This may become more important.
>     ... May want more discussion on this on reflector
> 
>     giueseppe: I would rather say we have talked about it, but never
>     really discussed it in detail. It may be a "phase 2" discussion.
> 
>     Russell_Berkoff: maybe reference to future work
> 
>     giuseppe: Just a metion would be too vague. I prefer to keep the
>     document clear and address items the working group can work on.
> 
>     MattH: maybe make a note to the task force to take this topic up
>     later
> 
>     Russell_Berkoff: some mention of it would be okay.
> 
>     giuseppe: we can discuss it later
> 
>     Bob: maybe there are several things like this that we want to
>     consider in the future. Maybe a section of the report to document
>     this.
> 
>     giuseppe: that may be a good solution
> 
> Summary of Action Items
> 
>     [NEW] ACTION: giuseppe to replace "client" with "application"
>     [recorded in
>     [15]http://www.w3.org/2011/08/23-webtv-minutes.html#action01]
> 
>     [End of minutes]
>       _________________________________________________________
> 
> 
>      Minutes formatted by David Booth's [16]scribe.perl version 1.136
>      ([17]CVS log)
>      $Date: 2011/08/25 16:33:33 $
>       _________________________________________________________
> 
>       [16] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm

>       [17] http://dev.w3.org/cvsweb/2002/scribe/

> 
> Scribe.perl diagnostic output
> 
>     [Delete this section before finalizing the minutes.] This is
> scribe.perl Revision: 1.136  of Date: 2011/05/12 12:01:43 Check for
> newer version at [18]http://dev.w3.org/cvsweb/~checkout~/2002

> /scribe/
> 
>       [18] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

> 
> Guessing input format: RRSAgent_Text_Format (score 1.00)
> 
> Succeeded: i/Home_Network_TF_Requirements/topic: Requirement document r
> eview No ScribeNick specified.  Guessing ScribeNick: Clarke Inferring
> Scribes: Clarke
> Present: rbardini JanL jcdufourd dcorvoysier aizu igarashi davidmays Cl
> arke giuseppe MattH Russell_Berkoff panze Bob narm_gadiraju mav kaz
> Agenda: [19]http://lists.w3.org/Archives/Public/public-web-and-tv/2011A

> ug/0116.html
> Got date from IRC log name: 23 Aug 2011
> Guessing minutes URL: [20]http://www.w3.org/2011/08/23-webtv-minutes.ht

> ml
> People with action items: replace
> 
>       [19] http://lists.w3.org/Archives/Public/public-web-and-

> tv/2011Aug/0116.html
>       [20] http://www.w3.org/2011/08/23-webtv-minutes.html

> 
>     End of [21]scribe.perl diagnostic output]
> 
>       [21] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm

Received on Thursday, 25 August 2011 16:59:26 UTC