W3C home > Mailing lists > Public > public-device-apis@w3.org > November 2012

RE: [discovery-api] what to put in service name

From: <Cathy.Chan@nokia.com>
Date: Wed, 28 Nov 2012 19:14:55 +0000
To: <jean-claude.dufourd@telecom-paristech.fr>, <public-device-apis@w3.org>
Message-ID: <A46437648ECB3D4F852B077AFF9099F51C8D69A2@008-AM1MPN1-063.mgdnok.nokia.com>
The NetworkService.id attribute has already been updated to be a combination
of the device UDN (which is universally unique) and the serviceId and is
therefore universally unique.

 

See step 2.2 in the "processing a UPnP Device Description File" portion of
Section 7.2:

[[Set network service record's id property to the concatenated string value
of the first occurrence of the <UDN> element in the device descriptor file
with the advertised service's <serviceId> sub-element.]]

 

The NetworkService.name attribute is supposed to be a "human-readable title
for the service". Currently, for UPnP, it's defined to be the serviceId,
which doesn't fit the intended purpose at all. I would suggest using the
device's friendlyName in this attribute if it's intended to be a user-facing
property.

 

Regards, Cathy.

 

 

From: ext Jean-Claude Dufourd
[mailto:jean-claude.dufourd@telecom-paristech.fr] 
Sent: Tuesday, November 27, 2012 12:54 PM
To: public-device-apis@w3.org
Subject: Re: [discovery-api] what to put in service name

 

Hi Rich,

Do you not see that your recommandation makes it impossible to distinguish
between the same service offered by multiple devices ?
As far as I know, there is no obligation to have a different serviceID for
two services of the same type on two different devices.
Worse: I have started the Intel network light twice on my PC, and both
instances of the switchPower service are called *.001. This one may be a
bug, but I am not sure.
If you want to hide the device name, create a hash or something like that,
but either the id or the name attribute of your service object HAVE to be
constructed as different for two or more services of the same type running
on different devices. Otherwise, there is no way to distinguish them.
Best regards
JC

On 23/11/12 16:10 , Rich Tibbett wrote:

Hi Jean-Claude, 

Jean-Claude Dufourd wrote: 



I am working on a platform that will have one same service running on 
all devices. 
When discovering that service with the NSD API, the applications gets an 
array of NetworkService objects and want to discriminate between all of 
these. 
Because this is on top of UPnP, and UPnP only has serviceID and 
serviceType, in my implementation of the NSD API, I wondered what to put 
in the service "name". 
Now, I believe that the service "name" should contain the name of the 
device, so that the application can discriminate between all the 
services in the array above. 


This is the purpose of the NetworkService.id attribute. 




Or should I rely on looking into the hostname part of the "url" 
attribute (I would find this ugly) ? 
Any hint, Rich ? What is your implementation doing ? 
Should the spec be more specific about what is the "name" of the 
NetworkService object ? 


The specification currently says to assign the serviceId from the UPnP
Device Descriptor File's service entry as the name attribute [1]. This is
the same as we are currently doing in our prototype implementation [2]. 

There's a privacy issue here to exposing anything else in the .name
attribute. There are a few other areas that we need to tighten up here wrt
privacy based on feedback we've received so far. I hope to provide an update
on this soon. 

Thanks, 

Rich 

[1]
http://www.w3.org/TR/2012/WD-discovery-api-20121004/#dfn-processing-a-upnp-d
evice-description-file

[2]
http://dev.opera.com/articles/view/network-service-discovery-api-support-in-
opera/








-- 
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 Wednesday, 28 November 2012 19:15:36 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 28 November 2012 19:15:37 GMT