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

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

From: Rich Tibbett <richt@opera.com>
Date: Fri, 23 Nov 2012 16:10:26 +0100
Message-ID: <50AF91E2.3080001@opera.com>
To: Jean-Claude Dufourd <jean-claude.dufourd@telecom-paristech.fr>
CC: public-device-apis@w3.org
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/
Received on Friday, 23 November 2012 15:10:59 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:32:46 UTC