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

RE: [HOME_NETWORK_TF] Minutes - 19 July 2011

From: Igarashi, Tatsuya <Tatsuya.Igarashi@jp.sony.com>
Date: Wed, 20 Jul 2011 10:05:04 +0900
To: Kazuyuki Ashimura <ashimura@w3.org>, "public-web-and-tv@w3.org" <public-web-and-tv@w3.org>
Message-ID: <DAB1CC3FAB54D3438F667F8E7B7599A201E20C415294@JPTKYXMS218.jp.sony.com>
Hi,

According to the discussion on the last phone call, I have updated the ISSUE-24 by changing "service/application agnostic API" to "generic API" as follows; 

What needs to be standardized: 
Type of use case: Generic API
	General service discovery and messaging APIs should be standardized 
	Network protocols for the APIs should be specified

Some submitters had already input the type of use case. If you have not yet, would you include your intent about "What needs to be standardized" including one of three following options ?

(1) Generic API
(2) Service specific API
(3) Generic API + Service specific document format

To clarify what is generic API, I would like to identify some examples of generic API as follows;

[a] Implementation Alternatives (ISSUE-9): Examples and Alternatives for a Generalized HTML-5 Home Networking Interface
     Clarke Stevens (CableLabs):
http://www.w3.org/2011/webtv/wiki/HNTF/Home_Network_TF_Discussions/Alternatives

[b] Local Network Service Messaging
    Unofficial Draft 18 July 2011, Richard Tibbett, Opera Software ASA
http://people.opera.com/richt/release/specs/discovery/Overview.html

The above two APIs are the general purpose API and does not depend on specific service/applications. The above option (3) is the approach to standardize the message payload format which are service/application in addition to the option (1). For example, in the case of [b], defining format of JSON message or SOAP message is an example of "Service specific document format".

There are some argument on whether "generic API" is beneficial to ecosystem. Anyway, the categorization by the type of use case is useful to proceed the discussion on requirements and what should be standardized in a working group.

Thank you.

-***---***---***---***---***---***---***---***---***--***---***---***-
Tatsuya Igarashi (Tatsuya.Igarashi@jp.sony.com)
NS Development Dept. Technology Development Group 
Sony Corporation
(Voice) +81-3-5435-3252 (Fax) +81-3-5435-3274




> -----Original Message-----
> From: public-web-and-tv-request@w3.org
> [mailto:public-web-and-tv-request@w3.org] On Behalf Of Kazuyuki Ashimura
> Sent: Wednesday, July 20, 2011 3:07 AM
> To: public-web-and-tv@w3.org
> Subject: [HOME_NETWORK_TF] Minutes - 19 July 2011
> 
> available at:
> http://www.w3.org/2011/07/19-webtv-minutes.html
> 
> also as text below.
> 
> The next call will be July 26.
> 
> Thanks,
> 
> Kazuyuki
> 
> ---
>     [1]W3C
> 
>        [1] http://www.w3.org/
> 
>                                 - DRAFT -
> 
>                      Home Networking Task Force call
> 
> 19 Jul 2011
> 
>     [2]Agenda
> 
>        [2]
> http://lists.w3.org/Archives/Public/public-web-and-tv/2011Jul/0036.htm
> l
> 
> Attendees
> 
>     Present
>            Russell, davidmays, Igarashi, Jan, kaz, Joseph_Scheuhammer,
>            Richard_Bardini, MattH, aizu, Yosuke, Narm
> 
>     Regrets
>            Giuseppe, Francois
> 
>     Chair
>            Kaz
> 
>     Scribe
>            kaz
> 
> Contents
> 
>       * [3]Topics
>           1. [4]HNTF deadline
>           2. [5]HTML5 review
>           3. [6]remaining issues
>       * [7]Summary of Action Items
>       _________________________________________________________
> 
> HNTF deadline
> 
>     kaz: we'll extend the charter period by one month
> 
>     all: agree
> 
>     RESOLUTION: HNTF will extend the charter period until the end of
>     August
> 
> HTML5 review
> 
>     kaz: is anybody interested in reviewing HTML5 spec from Home
>     Networking viewpoint?
> 
>     igarashi: no particular idea on HTML5
> 
>     <yosuke> [FYI: I've been reviewing the spec with some broadcasters
>     from broadcasters' point of view.]
> 
>     kaz: just reviewing part of the spec is fine
>     ... because the spec is huge
> 
>     matt: no specific interest
> 
>     russell: can commit
>     ... HTML5 has number of options
> 
>     kaz: great
> 
>     <davidmays> there is a lot of noise on the line
> 
>     <davidmays> it is very difficult to understand
> 
>     kaz: please send a message to the IG list on your interested
>     section, etc.
> 
>     <davidmays> yes the noise is gone
> 
>     <MattH> yes
> 
>     kaz: yosuke, could you please also make contribution?
> 
>     yosuke: ok
> 
>     <r> Kaz - I dont understand - is this the html5 item>???
> 
>     <r> no - I indicated we would *not* be interested!!
> 
>     <yosuke> [I'd like to mention that my/our review on HTML5 spec will
>     be mainly from broadcasters' point of view, and it may not be in
>     line with HNTF's point of view.]
> 
>     yosuke, ok
> 
>     RESOLUTION: Yosuke is interested in HTML5 review. Note that his
>     review will be not from HNTF viewpoint but from broadcasters'
>     viewpoint
> 
> remaining issues
> 
>     kaz: first one is Igarashi's issue-24
> 
>     ->
> 
> [8]http://www.w3.org/2011/webtv/wiki/HNTF/Home_Network_TF_Discussion
>     s/LocalLink issue-24
> 
>        [8]
> http://www.w3.org/2011/webtv/wiki/HNTF/Home_Network_TF_Discussions/Loc
> alLink
> 
>     issue-24?
> 
>     <trackbot> ISSUE-24 -- Local Link of web applications -- raised
> 
>     <trackbot> [9]http://www.w3.org/2011/webtv/track/issues/24
> 
>        [9] http://www.w3.org/2011/webtv/track/issues/24
> 
>     russell: similar to the one we submitted
> 
>     kaz: which one?
> 
>     russell: network player
> 
>     kaz: the one derived from 17?
> 
>     russell: yes
> 
>     kaz: igarashi, what do you think?
> 
>     igarashi: we may discuss what the difference is
>     ... most use cases are similar
>     ... not only 17 but also 15 etc.
>     ... use cases on generic use cases
>     ... so I'd suggest we add type of use cases first, and then talk
>     about the difference between use cases
>     ... ISSUE-14 is very generic
>     ... and Francois asked about the difference between 14 and 24
> 
>     <r> This is objectionable in Issue 24 - Type of use case:
>     Application/service agnostic APIs
> 
>     kaz: igarashi needs to modify that term to "generic"
> 
>     <r> Should be no mention - just requirements
> 
>     <r> There are generic and specific solutions deployed
> 
>     <r> W3C needs to address both
> 
>     <r> Issue 17 does this already
> 
>     <r> Issue 23 discusses support for specific deployed implementations
> 
>     kaz: russell, you're suggesting ISSUE-24 should also mention both
>     the generic APIS and application-specific APIs?
> 
>     <r> Use cases should describe requirements absent implementation
> 
>     russell: yes
> 
>     igarashi: this is not solution discussion, but requirements
>     discussion
> 
>     <r> We think a Requirement to support Generic APIs is problematic
> 
>     <r> Generic APIs defeat interoperability!
> 
>     <r> The use case should specifically discuss Generic APIs and
>     explain their impact on interoperability
> 
>     <r> This is what ISSUE-24 should do
> 
>     <r> Then what is the use-case for Issue-24?
> 
>     igarashi: what we should do first is clarify use cases
> 
>     <r> How is it different from ISSUE-17?
> 
>     <r> I think its a valid approach - The use case should clearly state
>     the requirement
> 
>     <r> For generic API support
> 
>     <r> Vs standardized API support
> 
>     <r> Both seem to be valid approaches?
> 
>     <r> Maybe we should have end-user use-cases and implementation
>     use-cases
> 
>     kaz: maybe we could ask igarashi to provide some example of generic
>     APIs?
> 
>     igarashi: Opera's proposal is one of the possible generic APIs
> 
>     kaz: russell, did you by chance see the generic APIs proposal by
>     Opera (Rich)?
> 
>     russell: had some private discussion with him
> 
>     <r> agree with you comment that discussion is out of scope for HNTF
> 
>     russell: think Opera's proposal is different from ISSUE-24...
> 
>     igarashi: that is 80% similar to my proposed use case
>     ... they identify services
> 
>     russell: Opera's target is not generic API but based on existing
>     solutions
>     ... it has binding to existing solutions like JSON
> 
>     igarashi: that (how to solve use case requirements) is a different
>     level from use cases discussion itself
>     ... what do you want to clarify?
> 
>     russell: need to identify which home network technology should be
>     used
> 
>     kaz: are you suggesting each use case should mention which existing
>     technology should be used?
> 
>     russell: that should be guidance to the other groups
>     ... would be helpful for the discussion in the other WGs
> 
>     kaz: we should concentrate on clarifying use cases and requirements
>     for this HNTF charter period, and then talk about expectation for
>     binding to existing standards, e.g., UPnP, DLNA.
> 
>     russell: agree
>     ... and at later stage, we need to consider eco-system specific use
>     cases, etc.
>     ... is it possible to add eco-system specific use cases category to
>     the requirements document
> 
>     kaz: we need to talk with Giuseppe as well, but should be ok
>     ... could you please add some note or description to your use case
>     about that point (=eco-system specific, etc.)
> 
>     russell: e.g., ISSUE-23
>     ... also would like to provide some proposal for requirements
>     document construction
> 
>     kaz: great
> 
>     [ adjourned ]
> 
> Summary of Action Items
> 
>     [End of minutes]
>       _________________________________________________________
> 
> 
>      Minutes formatted by David Booth's [10]scribe.perl version 1.128
>      ([11]CVS log)
>      $Date: 2011/07/19 18:05:19 $
> 
>       [10]
> http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
>       [11] http://dev.w3.org/cvsweb/2002/scribe/
> 
> 
> 
Received on Wednesday, 20 July 2011 01:05:40 UTC

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