W3C home > Mailing lists > Public > public-device-apis@w3.org > January 2013

RE: [Network Service Discovery API] device type search

From: Igarashi, Tatsuya <Tatsuya.Igarashi@jp.sony.com>
Date: Wed, 9 Jan 2013 16:59:13 +0900
To: "Sato, Naoyuki (TDG)" <NaoyukiB.Sato@jp.sony.com>, "public-device-apis@w3.org" <public-device-apis@w3.org>
Message-ID: <DAB1CC3FAB54D3438F667F8E7B7599A201EC6268F297@JPTKYXMS218.jp.sony.com>
Hi,

About Network Service Discovery [1], Nao suggested that the API should support searching by “device type” in the following email. Any comments ?


[1] http://www.w3.org/TR/2012/WD-discovery-api-20121004/

I used to work on the UPnP standardization more than 10 years ago (in very early stage of the UPnP Forum). IMHO or not, I would say  that there is a misleading about “device type” and “service type” due to its names. Actually,  “device type”, i.e. UPnP device, does not represent a physical device, e.g. TV, but does a logical entity which contains UPnP services (a functional module). The concept of UPnP service was introduced to define  what  is optional module and to reuse a module in definition of other UPnP devices . Many UPnP devices can co-exist on a physical device.  In this sense,  “device type” of UPnP corresponds to “service type” of Bonjour. As Nao explained that a UPnP controller typically searches a UPnP device. So that it would be very beneficial if the API supports searching by  “device type” of UPnP device.

The following [2]  is the reference to the UPnP Device Architecture. It would be appreciated if other UPnP experts support what I explain above..

[2] http://upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v1.0.pdf

Thank you.

-***---***---***---***---***---***---***---***---***--***---***---***-
Tatsuya Igarashi (Tatsuya.Igarashi@jp.sony.com<mailto:Tatsuya.Igarashi@jp.sony.com>)
Section 1, Dept. 2. Cloud Technology Development Div. Corp R&D
Sony Corporation



From: Sato, Naoyuki (TDG) [mailto:NaoyukiB.Sato@jp.sony.com]
Sent: Friday, November 30, 2012 4:11 PM
To: public-device-apis@w3.org
Subject: [Network Service Discovery API] device type search


Hello,



Thank you for providing the Network Service Discovery API draft and its implementation.

We are reviewing Network Service Discovery API w/ the simple prototype. from the feedback of this prototype, we'd like to request the following functions into Network Service Discovery APIs.



- device type search and cross domain access

When we make a UPnP controller application, we believe that a controller typically searches by "deviceType" such as "urn:schemas-upnp-org:device:MediaRenderer:1" or "urn:schemas-upnp-org:device:MediaServer:1" at first rather than serviceType such as "urn:schemas-upnp-org:service:AVTransport".



This is because a controller tends to expose device list for user to select one to be controlled and presentation name, icon etc for the list belong to deviceType.



For the media renderer example, after locating a MediaRenderer deviceType to be controlled, a controller may use its AVTransport serviceType to control the media playback and also use the RenderingControl serviceType of the same device to control the rendering functions.



For this case, it will be better to be able to search by "deviceType" to ease a controller to get these two services from the device.



Likewise, other search target (ST) values alllowed in SSDP such as "ssdp:all", "upnp:rootdevice" and "uuid:<UUID>" should also be allowed in the Network Discovery API, shouldn't it?



We suppose all those are "service" in the sense of general term.

Therefore it seems natural to us that the Network Service Discovery API can discover UPnP deviceType.



If the above is a good idea, the cross domain should be allowed to access the UPnP device resources such as the device description page, the service description page, the device icon or etc in addition to than controlUrl written in the device description.



Thank you,



nao
Received on Wednesday, 9 January 2013 07:59:47 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:53:57 UTC