W3C home > Mailing lists > Public > public-web-and-tv@w3.org > August 2011

[HOME_NETWORK_TF] minutes - 23 August 2011

From: Kazuyuki Ashimura <ashimura@w3.org>
Date: Fri, 26 Aug 2011 01:35:33 +0900
Message-ID: <4E5679D5.8050602@w3.org>
To: public-web-and-tv@w3.org
available at:

also as text below.

Thanks a lot for taking these minutes, Clarke!



       [1] http://www.w3.org/

                                - DRAFT -

                       Home Networking Task Force

23 Aug 2011


       [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


           rbardini, JanL, jcdufourd, dcorvoysier, aizu, igarashi,
           davidmays, Clarke, giuseppe, MattH, Russell_Berkoff, panze,
           Bob, narm_gadiraju, mav, kaz




      * [4]Topics
          1. [5]Requirement document review
          2. [6]Pending comments on Home Network Enabled User-Agent use
          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_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/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

    russell: I'm okay with dropping the backwards compatibility

    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
    ... so you will merge and make my requirements informative?

    giuseppe: yes

Additional section about Related Works

    01.html Opera, CableLabs

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

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

    <trackbot> Sorry, couldn't find user - replace


    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

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

    <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

    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

    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

    giuseppe: that may be a good solution

Summary of Action Items

    [NEW] ACTION: giuseppe to replace "client" with "application"
    [recorded in

    [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

      [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
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
Got date from IRC log name: 23 Aug 2011
Guessing minutes URL: [20]http://www.w3.org/2011/08/23-webtv-minutes.ht
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:35:22 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:57:07 UTC