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

Hi, 

I agree with Cathy about the permission consideration. The access permission should be granted in UPnP device level, since CE devices generally provide users with a way to change UPnP Friendly name per UPnP device levels. The following is an example to change the [Renderer Name] of the TV.

http://docs.esupport.sony.com/imanual/NA/EN/hx850/c_nwset_detail.html

In the real world, searching by UPnP device type is more important than searching by UPnP service type. 

PS. I could attend the today's teleconference after the web and tv IG's one, about at 10:00am ESD. I am afraid of missing this discussion. if any question or a different opinion, please send it to this reflector.

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



> -----Original Message-----
> From: Cathy.Chan@nokia.com [mailto:Cathy.Chan@nokia.com]
> Sent: Wednesday, September 04, 2013 5:50 AM
> To: Igarashi, Tatsuya; public-device-apis@w3.org
> Subject: RE: 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.
> >
> 
> 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.ht
> m
> >l [3]
> >http://lists.w3.org/Archives/Public/public-device-apis/2013Jan/0010.ht
> m
> >l [4]
> >http://lists.w3.org/Archives/Public/public-device-apis/2013Feb/0012.ht
> m
> >l [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 23:49:58 UTC