RE: DAP-ISSUE-130: Enable variety of protocols (e.g. UPnP, Bonour) with protocol independent developer code [Network Service Discovery]

> -----Original Message-----
> From: ext Device APIs Working Group Issue Tracker
> [mailto:sysbot+tracker@w3.org]
> Sent: Tuesday, July 09, 2013 1:20 PM
> To: public-device-apis@w3.org
> Subject: DAP-ISSUE-130: Enable variety of protocols (e.g. UPnP, Bonour) with
> protocol independent developer code [Network Service Discovery]
> 
> DAP-ISSUE-130: Enable variety of protocols (e.g. UPnP, Bonour) with protocol
> independent developer code [Network Service Discovery]
> 
> http://www.w3.org/2009/dap/track/issues/130
> 
> Raised by: Jean-Claude Dufourd
> On product: Network Service Discovery
> 
> Dear all,
> 
> As I told you before, I have an implementation of NSD for UPnP and Bonjour,
> with extensions for exposing a service and communicating between webapp
> and service.
> Note: In Bonjour, exposing a service means providing a JSON service
> description (à la SDCP), and sending messages means exchanging JSON
> messages over plain text sockets.
> By doing this, I have exactly the same level of functionality in UPnP and
> Bonjour. And thus, my first service developer's first strong request was
> "please get rid of anything protocol specific".
> He wanted to specify a service type (whether in a search or in an advertizing
> request) in a way that can be transparently implemented in UPnP or Bonjour,
> depending on what is implemented. This assumes that some
> implementations will have UPnP and Bonjour, and others will have only one
> of the two, and he wants the same webapp to simply address all cases.
> 
> I tried to implement this by specifying only the main COMMONFRAGMENT of
> a service type.
> In UPnP, a service type is
> "upnp:urn:DOMAIN:service:COMMONFRAGMENT:1"
> (note: I chose my project name for DOMAIN) In Bonjour, a service type is
> "zeroconf:_COMMONFRAGMENT._tcp.local."
> 
> I first attempted to implement the search for COMMONFRAGMENT on top
> of my NSD implementation.
> It was not possible. I had to modify/extend the NSD implementation.
> 
> By doing this, I do not remove the difference of NSD response between
> UPnP and Bonjour, but the author's code can then be made protocol-
> independent.
> And I think that is a "good thing".
> 
> So I propose to allow, as first argument of getNetworkServices, a plain string
> that is neither starting with "upnp:" nor "zeroconf:", in which case, the
> service type matching would not be done as exact string comparison, but by
> testing the inclusion of the first argument value in the service type of
> discovered services.

At the high level, this looks like a reasonable and useful change. I'm trying to figure out how it would be specified or work in practice. 
If a UA monitors the network for device announcements, then it would be fairly straightforward. All the UA needs to do, as you said, is to test the inclusion of the requested type in the service part of the discovered services. But what if a UA does not monitor the network for device announcements, and only issues a search for the requested service type(s) when getNetworkServices is invoked? What UPnP search target would the UA use to search for services on the network? Specifically, what domain should it use when constructing the search target? And if we go ahead with adding device type support [DAP-ISSUE-131], should the UA use a device or service search target, or both? Furthermore, if we are to allow the web author to use just a partial string as the requested type (e.g. "print" to find all print-related services), how would the UA construct the search target (noting that "wild-card" is not supported in UPnP search targets)? While one can always issue an "ssdp:all" search target to look for everything and do the filtering upon receiving the responses, such an approach is highly inefficient and generates way more network traffic than necessary.

> If the absence of a prefix is a problem to anyone, using a prefix of
> "fragment:" would also work.
> 

May I suggest "any:" - "look for the xxx service using any discovery mechanism", in the same manner that the upnp/zeroconf prefixes mean "look for the xxx service using upnp/zeroconf discovery mechanism".

[DAP-ISSUE-131] http://www.w3.org/2009/dap/track/issues/131

Regards, Cathy.

> What do you think ?
> Best regards
> JC
> 
>