Re: [discovery-api] Consolidated comments and questions

Hi Rich, thank you for your reply.

Please see my comments below.

On Wed, 6 Feb 2013 23:42:59 +0900
Rich Tibbett <> wrote:

> Norifumi Kikkawa wrote:
> > Hello all,
> >
> > Thank you for the fine list, Cathy,
> > and thank you for the comments to each one, Rich.
> >
> > Please see my comments below.
> >
> > On Tue, 5 Feb 2013 23:36:15 +0900
> > Rich Tibbett<>  wrote:
> >
> >> wrote:
> >
> >>> 4. Allow device type search (and more generally, other UPnP search
> >>> strings)?
> >>>>  From Naoyuki Sato [11], [13] and Cathy [14]:
> >>> It is typically more common for UPnP controller applications to search
> >>> for
> >>> device types than service types, as controllers tend to expose a
> >>> device list
> >>> for the user to select from.
> >> The abstraction introduced by this specification is at the
> >> service-level. At no point would a user agent know what device types to
> >> search for since that is not a parameter that can be provided via the
> >> getNetworkServices() method.
> >>
> >> I have updated the specification so implementations can search for
> >> 'ssdp:all', 'upnp:rootdevice' or a valid service type token in their
> >> UPnP Search. I don't know how we could know to search for a specific
> >> device type in this specification. That would be a severe limitation on
> >> user choice in selecting services that match those requested by the page
> >> and favors the big players to promote and exclude existing and new
> >> devices from being discovered via this API.
> >>
> >> The specification is deliberately device-neutral and service orientated.
> >
> > I want to use deviceType search with NSD.
> >
> > Please see Igarashi-san's post [1] explaing "deviceType in UPnP" is a
> > service in the sense of generic term such as "MediaServer" or
> > "MediaRenderer" feature rather than type of physical device form such
> > as "PC" "TV" etc.
> >
> > For example, A physical device such as a PC can serve both MediaServer
> > deviceType and MediaRenderer deviceType features.
> > A MediaServer deviceType is defined to provide media library service.,
> >
> > I agree with you that the NSD has to provide a mechanim for web
> > application to find network services regardless which physical device
> > holds the services in the network. Therefore, for this purpose,
> > I believe the NSD should use UPnP deviceType.
> > Note that typically user is not aware of serviceType (a control
> > point software does care).
> Every device type has one or more service types attached to it. We are 
> actually suggesting we skip the step of asking for something 
> unnecessarily abstract - a device type with X services - and instead ask 
> for specific services of that device via service types.
> i.e. If a device type is defined to be the combination of a MediaServer 
> and MediaRenderer then if you request those MediaServer and 
> MediaRenderer services in a single call to getNetworkServices the user 
> can select from a list of the _devices_ that match any or all of the 
> service types provided in the opt-in dialog (since we plan to show 
> devices in the opt-in dialog to users rather than service types at that 
> level). If a device supports e.g. both a MediaServer and MediaRenderer 
> then both services will be provided to the web page by the user 
> selecting that single device at the prompt.

A MediaServer is a deviceType defined to have ContentDirectory 
serviceType (CDS), ConnectionManager serviceType (CMS) 
and optional AVTransport serviceType (AVT). However,
the combination of CDS, CMS and optional AVT doesn't have to be 
a MediaServer deviceType. These serviceTypes may be used to 
other purpose by definition of UPnP Architecture. 

To find a logical entity to serve media library, a user/WebApp 
wants to find a MediaServer, not a combination of CDS and CMS. 
Therefore providing a deviceType seems reasonable and not 
uncessarily abstract to me.

I doubt that it is useful to provide a phisical device level pop-up
(if you mean physical device in "we plan to show devices in the opt-in
dialog to users") because UPnP doesn't provide a physical level metadata. 
UPnP defines lots of things per rootdevice, e.g. friendlyName,
icon, presentationPage, etc. deviceType is one of them.
I think UPnP device concept is important for developpers, but this is
logical concept and does not mean a physical device.
Per rootdevice pop-up wil be used instead and it's OK IMO.

> navigator.getNetworkServices([
>    'urn:schemas-upnp-org:device:MediaServer:1',
>    'urn:schemas-upnp-org:device:MediaServer:2',
>    'urn:schemas-upnp-org:device:MediaServer:3',
>    'urn:schemas-upnp-org:device:MediaRenderer:1',
>    'urn:schemas-upnp-org:device:MediaRenderer:2',
>    'urn:schemas-upnp-org:device:MediaRenderer:3'
> ], function(networkServices) {});
> Selecting a device that supports both MediaServer:2 and MediaRenderer:1 
> from the call above will result in the NetworkServices object returned 
> in the successCallback containing 2 NetworkService objects attached to 
> the same device.

I'm little bit confused here. I don't want a way to find physical
devices which support more than one specified deviceTypes. 
I'd like to see a way to find UPnP rootdevices which support
a single specified deviceType.

In your example above, the API realizes deviceType-level search
which I actually hope though your comments seem negative
about it?

Regarding version number, UPnP defines a device shall respond 
backward compatible query. For example, a device supporting
MediaServer:2 will respond to a query to MediaServer:1.

Likewise, I propose the NSD API uses same scheme.
If WebApp wants to find MediaServer:1 capable device,

, function(networkServices) {});

should be sufficient. WebApp shouldn't have to specify 
MediaServer:2,3, or unknown future versions and
all of them should be returned.


> There's room for improvement in binding those services together in the 
> resulting NetworkServices object (i.e. indicating that they belong to 
> the same device) but I don't think device type search up-front adds 
> anything to what we can't already do within the current definition of 
> getNetworkServices.

> - Rich
> >
> > [1]

 Norifumi Kikkawa <>
  Sec.1  Dept. No.2
  Cloud Technology Development Div.
  COR&D Sony Corporation
 (TEL) +81 50 3750 3953 

Received on Thursday, 7 February 2013 04:39:30 UTC