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

Re: [discovery-api] Consolidated comments and questions

From: Rich Tibbett <richt@opera.com>
Date: Wed, 06 Feb 2013 15:44:52 +0100
Message-ID: <51126C64.1050801@opera.com>
To: Jean-Claude Dufourd <jean-claude.dufourd@telecom-paristech.fr>
CC: public-device-apis@w3.org
Jean-Claude Dufourd wrote:
> Le 5/2/13 15:36 , Rich Tibbett a écrit :
>> 3. Use UPnP friendly name as NetworkService.name? From Cathy [8]:
>>> [[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 is concerned about fingerprinting [9]. Cathy thinks as long as the
>>> information is provided after user consent, it should be ok [10].
>>
>> The UPnP Friendly Name is only provided at the device-level, not at
>> the individual services level. As such it doesn't seem it would make
>> sense to use that for service naming (10 different services from the
>> same device would each have the same names which is misleading IMO).
>>
>> It would be great if there were something equivalent to 'friendly
>> name' in the service description file (obtainable via the Service's
>> SCPDURL element). Alas, there is no such thing.
> JCD: In my in-progress implementation, I had to concatenate "device
> friendly name" for human readability with "serviceType" for unique
> identification of the service.
> The result is long, but otherwise, the system is simply not usable.

Yes. Bear in mind though that the NeworkService.name attribute does not 
have any requirements to be unique though so it shouldn't matter so much 
exactly what is returned here.

The only keyed information we require is on the NetworkService.id 
attribute which requires that the id be unique for each service being 
shared.

> Best regards
> JC
>
Received on Wednesday, 6 February 2013 14:45:23 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:53:58 UTC