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

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

From: <Cathy.Chan@nokia.com>
Date: Tue, 3 Sep 2013 20:49:57 +0000
To: <Tatsuya.Igarashi@jp.sony.com>, <public-device-apis@w3.org>
Message-ID: <A46437648ECB3D4F852B077AFF9099F5292C846B@008-AM1MPN2-082.mgdnok.nokia.com>
>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.

On both aspects, we also need to consider how permissions are handled. The UPnP device is the logical entity that both the web app and the user should interface with, and permission should be granted on the UPnP device level. In other words, the user should be asked whether he wants to play media on a certain device (permission on the MediaRenderer device), and not asked separately whether he wants to be able to stream media on that device (permission on the AVTransport service) and whether he wants to control volume/brightness/contrast/etc on that device (permission on the RenderingControl service). More importantly, for the web app, it needs to be allowed to use the device as a whole, or not at all. If permission is only granted on some but not all services, the web app might not be able to function properly.

- Cathy.

>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
Received on Tuesday, 3 September 2013 21:07:59 UTC

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