RE: Categolize what APIs should be stardized

Sorry. There are typos in the previous email.

stardized -> standardized
scandalized -> standardized

Thank you.

_____________________________________________
From:   Igarashi, Tatsuya
Sent:   Wednesday, June 29, 2011 12:56 AM
To:     public-web-and-tv@w3.org
Subject:        Categolize what APIs should be stardized

Hi Home Network TF participants,

I would summarize my point which I tried to comment in the today's teleconference.

I believe that the most proposed user scenarios are meaningful and valid from user perspective. In the sense, I do not have any objection to accept all proposed user scenarios at this time.  But, at the next step, if we have to prioritize the user scenarios, we should be care of what type of APIs should be standardized to realize the proposed user scenario.

If the APIs are application(service) agnostic, e.g. generic discovery APIs and generic message exchange API, then the proposed user scenarios would be outstanding examples and we do not need to argue priority of each user scenarios so much. Hopefully, more attractive user scenarios will be realized based on the W3C standard.

If the APIs are application(service) specific, e.g,  Remote TV channel change APIs, then the prioritization of user scenarios is very crucial and we have to argue if it is important for the stakeholders to standardize such application specific APIs in W3C.

To avoid a confusion on the priority discussion, I suggest that the submitters of the user scenarios will add the description about what type of API's should be scandalized.  e.g. generic local network discovery and message exchange APIs. Depending on the description, we can categorize the proposed user scenarios into the following two general use cases as Giuseppe described in his email. Also, it makes easy to discuss the priority of user scenarios at the next step.

(General use case A)  enable communication with services using existing and established application protocols (UPnP services, Bonjour services, etc).
(General use case B)  enable communication between 2 applications with a "proprietary" protocol

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