RE: [discovery-api] Consolidated comments and questions

> From: ext Jean-Claude Dufourd
[mailto:jean-claude.dufourd@telecom-paristech.fr] 
> Sent: Wednesday, February 06, 2013 10:31 AM
> To: Rich Tibbett
> Cc: public-device-apis@w3.org
> Subject: Re: [discovery-api] Consolidated comments and questions
>
> Le 6/2/13 15:44 , Rich Tibbett a écrit :
> 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. 

It matters because it is meant to be presented to the user as part of the
user experience. As a user, I would much rather see that I'm streaming from
"Living Room Media Server" than from
"urn:schemas-upnp-org:service:ContentDirectory:1", which means absolutely
nothing to me. As I've repeated a few times already, the .name attribute is
meant to be a humanly readable value. The serviceId value clearly does not
quality as one. A web app author who understands the non-uniqueness
limitation of the attribute is free to further combine that attribute with
other information (such as the serviceType as JCD did) to present a
reasonably useful name to the user. But that should be done by the web app
author, not the UA, IMO.

>
> The only keyed information we require is on the NetworkService.id
attribute which requires that the id be unique for each service being
shared. 
> JCD:Maybe my proposal is not good enough, but the current name=serviceId
for UPnP does not work in practice.
> First serviceId may well be the same on different devices, so you get
identical "name" fields if multiple devices expose the same service.
> Then, if you want the user to be able to choose with just the name
information, then the name has to contain both the device friendly name and
some information about the service, > so why not serviceType (or a relevant
part thereof)... 

> Best regards
> JC







Best regards 
JC 



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