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

RE: [Network Service Discovery API] device type search

From: Sato, Naoyuki (TDG) <NaoyukiB.Sato@jp.sony.com>
Date: Thu, 10 Jan 2013 17:05:44 +0900
To: Jean-Claude Dufourd <jean-claude.dufourd@telecom-paristech.fr>, "public-device-apis@w3.org" <public-device-apis@w3.org>
Message-ID: <1A785CE0CEDCBB4E9DF8581EE72F5D610119486BCC0A@JPTKYXMS207.jp.sony.com>
Hello,

> I am not sure I support cross-domain or more access to UPnP specific stuff.

I propose Network Service Discovery should allow the cross domain access to the device description page and all network resource that is defined in the device description page. The current implementation of Network Service Discovery from Opera allows the cross domain access to the control url. this will not enough for UPnP controller application.

The reasons why I am proposing are
- showing the device icon to the end user
The normal UPnP application will show the end user UPnP device list w/ the device icon and friendly name to select which UPnP device is controlled. The device icon url and friendly name are specified in the device description page. So, we need to access the device description page and the device icon resource. Otherwise, the application may not provide the good UI to the end user.

- check what command is supported
The normal UPnP application will check the service description page, because the service description page has UPnP command list and the application can know what option command UPnP device supports. The service description page url  is specified in the device description page. So, we need to access the device description page and the service description page resource. Otherwise, the application may use only mandatory commands and miss the chance to use the optional command.

Thank you,

Naoyuki Sato



From: Jean-Claude Dufourd [mailto:jean-claude.dufourd@telecom-paristech.fr]
Sent: Wednesday, January 09, 2013 5:53 PM
To: public-device-apis@w3.org
Subject: Re: [Network Service Discovery API] device type search

I support what Igarashi-san says about device type.
I am not sure I support cross-domain or more access to UPnP specific stuff.
Best regards
JC

On 9/1/13 08:59 , Igarashi, Tatsuya wrote:
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<mailto: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





--

JC Dufourd

Directeur d'Etudes/Professor

Groupe Multimedia/Multimedia Group

Traitement du Signal et Images/Signal and Image Processing

Telecom ParisTech, 37-39 rue Dareau, 75014 Paris, France

Tel: +33145817733 - Mob: +33677843843 - Fax: +33145817144
Received on Thursday, 10 January 2013 08:06:17 UTC

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