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

RE: [Network Service Discovery API] device type search

From: <Cathy.Chan@nokia.com>
Date: Thu, 10 Jan 2013 19:32:04 +0000
To: <NaoyukiB.Sato@jp.sony.com>, <jean-claude.dufourd@telecom-paristech.fr>, <public-device-apis@w3.org>
Message-ID: <A46437648ECB3D4F852B077AFF9099F51C9198B5@008-AM1MPN1-062.mgdnok.nokia.com>
NaoyukiB.Sato@jp.sony.com wrote:

> Hello,
> > I am not sure I support cross-domain or more access to UPnP specific
> 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
> - 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

I think those are very reasonable motivations for allowing the web app
access to additional resources on the UPnP devices in addition to the
control URL. Such information may not be important for the most simplistic
and targeted web apps, but are essential for the more complex or
general-purpose web apps to create a good user experience.

I'm also generally in favor of allowing additional search types instead of
just UPnP service type.

- Cathy.

> From: Jean-Claude Dufourd
> 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
> 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)
> 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
> 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 19:32:38 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:32:49 UTC