RE: [discovery] DAP-ISSUE-131 Support UPnP device discovery by Device Type? (was RE: [discovery] Adding CORS to NSD API - proposal and issues)

Comments inline,

> -----Original Message-----
> From: Frederick.Hirsch@nokia.com [mailto:Frederick.Hirsch@nokia.com]
> Sent: Friday, October 18, 2013 12:12 AM
> To: richt@opera.com
> Cc: Frederick.Hirsch@nokia.com; giuseppep@opera.com; Igarashi, Tatsuya;
> Cathy.Chan@nokia.com; Youenn.Fablet@crf.canon.fr;
> public-device-apis@w3.org
> Subject: Re: [discovery] DAP-ISSUE-131 Support UPnP device discovery by
> Device Type? (was RE: [discovery] Adding CORS to NSD API - proposal and issues)
> 
> comments inline
> 
> regards, Frederick
> 
> Frederick Hirsch
> Nokia
> 
> 
> 
> On Oct 15, 2013, at 12:46 PM, ext Rich Tibbett wrote:
> 
> > On Wed, Oct 16, 2013 at 1:41 AM, Giuseppe Pascale <giuseppep@opera.com>
> wrote:
> >> On Tue, Oct 15, 2013 at 7:02 AM, Igarashi, Tatsuya
> >> <Tatsuya.Igarashi@jp.sony.com> wrote:
> >>>
> >>> Hi Giuseppe,
> >>>
> >>>
> >>> On Wed, Oct 16, 2013 at 1:41 AM, Giuseppe Pascale <giuseppep@opera.com>
> wrote:
> >>>>
> >>>> I don't think this is the case, as how permission is asked is not
> >>>> mandated by the spec and the UA may request only once per device,
> >>>> regardless of the number of service searches you do (maybe by
> >>>> showing which services will be
> >>>> exposed)
> >>>>
> >>>
> >>> In the case that a web application specifies multiple types to the
> >>> getNetworkService method, do you mean how many dialogs pop-up is
> >>> implementation dependent ?
> >>>
> >>>
> >>>
> >>> promise = window . navigator . getNetworkServices ( type )
> >>>
> >>> Immediately returns a new Promise object and then the user is
> >>> prompted to select discovered network services that have advertised
> >>> support for the requested service type(s).
> >>>
> >>> In my understanding that UA must prompt per getNetworkServices
> >>> method. And I  assumed the case that a web application searches UPnP
> >>> Service B after searching UPnP Service A which is founded in the
> >>> Device Description of UPnP Device X. This case causes two popup
> >>> dialogs by the two getNetworkServices() methods. I do not think that
> >>> all web application must know what UPnP services are supported by
> >>> UPnP device in advance of getting UPnP device description.
> >>>
> >
> > While this type of API usage is technically possible it would be a
> > less than ideal pattern for web developers to use.
> >
> > Why? When we share a service with a web page that has not demonstrated
> > any prior awareness or interest in that service's corresponding type
> > then there is a good possibility that the web page does not know or
> > does not need to know how to interact with it if/when it received a
> > service object of that type.

(I could not follow this email thread, but I reply as follow, assuming the above is the answer from Richt)

It may be ideal pattern for web developer, However, it is not ideal pattern for UPnP/DLNA developers who want to develop a web application.

>From the perspective of UPnP architecture[1], What a UPnP control application is primary interesting is UPnP Device, not individual UPnP service. After discovering UPnP device and retrieving UPnP device description, then the application controls iUPnP services according to the theory operation described in each Device Control Protocol specs [2]. This is the ideal and also practical pattern for most UPnP/DLNA application developers. 

We do not insist that NSD should not support searching by UPnP service type, but we just propose that NSD should support searching by UPnP device type for UPnP/DLNA products in the market.

[1] http://upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v1.0.pdf
[2] http://upnp.org/sdcps-and-certification/standards/sdcps/

> >
> > Calling getNetworkServices twice as you propose above - initially to
> > determine the services running on a device and then calling it again
> > with a list of all service types discovered from the first call -
> > introduces this exact problem. The argument is "I don't know exactly
> > what services I want or will receive but I just want them all for the
> > sake of having them all". This does not fulfil the key requirements of
> > this API: being able to interact with all services returned to a web
> > page.
> >
> 
> This also goes against the privacy principle of minimization - the web page
> should not inventory all the services but only access what it needs by asking
> for what it needs.
> 

I agree on the privacy principle of minimization. In addition, we know the minimization is trade-off with usability. For controlling UPnP/DLNA devices, it would be beneficial for users to support searching UPnP device, even though it makes leaking information of UPnP services to user-granted web page. I described the rationale below;

(1) Only "Friendly Name" of UPnP device is user-recognizable information. Privacy/Security control should be per UPnP device.
(2) It is  complicated for users if privacy/security control and user agreement of get NetworkServiceDiscovery is done per individual UPnP service. In addition, such user scenario is confusing for consumers since they do not know UPnP services at all. Note that consumers could know what UPnP/DLNA devices are supported in a CE products by users-manual and/or DLNA certificated information of product, e.g. MediaServer, MediaRenderer.
(3) As described above, a web application which controls UPnP device generally want to get a whole of UPnP device description to control the UPnP device. In this sense, the issue (2) is not negligible since it would really happen in the market. We should address the issue (2) for usability. 

Thank you.

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

Received on Friday, 18 October 2013 09:01:35 UTC