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

On 28/11/12 20:14 , Cathy.Chan@nokia.com wrote:
>
> 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.]]
>
JCD: Thank you.
But then, section 6 and 6.1 are out of sync with step 2.*, since there 
is no deviceID anywhere else in the spec.
deviceId also needs to be added in 7.1 somewhere, if only to be said to 
be null in the mDNS case.


> 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.
>
JCD: I completely agree. That would have been my next point.
Your argument on id answers my claim about the ability to distinguish, 
but then if the user needs to choose, then something including the 
device friendly name would be relevant. But then the fingerprinting 
argument comes back.
Best regards
JC
>
> 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-device-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


-- 
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