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

Jean-Claude Dufourd wrote: 
>
>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. 

Not really. Section 6 and 6.1 only define NetworkService.id to be "a unique
identifier for the service. The same service provided at different times or
on different objects must have the same id value." How that unique
identifier is composed depends on the underlying discovery mechanism. In the
case of UPnP, it is defined to be the concatenation of the UDN and the
serviceId. In the case of mDNS, it's defined to be simply the full PTR
Service Instance Name. The deviceID is not (and does not need to be) exposed
to the client at all.

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

The friendly name, along with everything else, is only exposed *after* the
user gives consent to use the discovered device. That shouldn't create a
fingerprinting issue IMO.

- Cathy.

>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-d
evice-description-file
>>>>
>>>>[2]
http://dev.opera.com/articles/view/network-service-discovery-api-support-in-
opera/