ISSUES-131: Support UPnP device discovery by Device Type?

Hi,

In terms of the ISSUES-131 [1], we have insisted on supporting UPnP device discovery with several comments [2] [3] [4].
I have read the recent emails and minutes regarding the ISSUES-131. We still insist that NSD should support UPnP discovery for device type. I described the rationale as follows.


(1)   NSD should enable the communication with UPnP devices in its manner.
I certainly support what Cathy said. An application(UPnP Control Point) generally searches UPnP devices at first and then access its UPnP services on it. Please also note that UPnP services may not be independent and the UPnP Control Point have to know a whole of UPnP Device Control Protocol(DCP) to control its UPnP services.
Upon this point, I would like to clarify what is the high priority requirement on NSD. I think it is not just to provide an abstract/generic API about the service discovery protocols, but to provide the service discovery API which enables an web application communicate with networked devices which can be discovered by the service discovery protocols. In other words, it is not just to support SSDP which is a part of UPnP [5], but to enable a web application communicates with a UPnP device control which can be discovered via NSD. To meet this requirement, I insist that NSD should support UPnP device discovery by device type.


(2)   NSD should discover an instance which is recognizable by users.
There is a misleading that UPnP SSDP is used to discovery a physical device. UPnP [5] defines “UPnP device” is “Logical device” and a physical device may support multiple UPnP devices. Also, there is another misleading about the terminology “UPnP service”. UPnP [5] defines “Service” in its own manner, such as that UPnP service is a logical functional unit which is contained in an UPnP device. Please do not confuse just about the terminology “Service”.
To design service discovery APIs, we should consider what is a primary instance to be discovered. My suggestion is to discover a logical instance which has a user-friendly/user-visible name and the primary instance would be an discovery entry point to communicate with a service via it protocols. In the case of UPnP [4], UPnP device has the “FriendlyName” property described in UPnP device description file. In the case of mDNS [6], SRV record has an instance name property which is user-friendly/user-visible . In this sense, I think that UPnP device corresponds to mDNS service instance. It does make sense that the both UPnP device and mDNS service instance are handled equivalently if a web application displays them on the user-visible service list. To realize it, I insist that NSD should support UPnP device discovery by device type.

PS. Please see the Appendix C of [7]: “What you see what you get”. It is a good text to consider what should be discovered by a service discovery. The upnp-service type is the true service identifier of service protocols, but UPnP service type is not visible to users. I think one of the reasons that “UPnP device” was defined as a container of services not to decouple the true service identifier from the name represent to users. In the same way, an instance name of mDNS is also used to recognize a physical device, e.g. it is the "Stuart's Printer".

[1] http://www.w3.org/2009/dap/track/issues/131
[2] http://lists.w3.org/Archives/Public/public-device-apis/2012Nov/0101.html
[3] http://lists.w3.org/Archives/Public/public-device-apis/2013Jan/0010.html
[4] http://lists.w3.org/Archives/Public/public-device-apis/2013Feb/0012.html
[5] http://upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v1.1.pdf
[6] http://tools.ietf.org/html/rfc6762
[7] http://tools.ietf.org/html/rfc6763

Thank you.

-***---***---***---***---***---***---***---***---***--***---***---***-
Tatsuya Igarashi　(Tatsuya.Igarashi@jp.sony.com<mailto:Tatsuya.Igarashi@jp.sony.com>)
Information Technology Development Div, R&D Platform
Sony Corporation