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

Hi Youenn and Cathy,

Cathy described what I want to say. I would add the two issues if searching UPnP device is not supported by NSD at all.

(1) Multiple popup dialog per UPnP service type.
Searching both A and B of UPnP service types of X UPnP device will cause two popup dialog for user agreement by the promise of getNetworkService() method. Practically, most UPnP application would like to control a whole function of UPnP device. For example, controlling volume and playback requires to control both UPnP Rendering control and UPnP AV Transport services, two pop-up dialogs per UPnP service type would confuse consumers even if a web application unifies the two UPnP services in a UPnP device and show the list of UPnP devices for user selection.

(2) Access control should be per UPnP device.
If a user agent implements access control of discovered services, the services should be listed per UPnP device with Friendly Name to support UPnP/DLNA products in the market. Because a consumer does not know about UPnP service types, e.g. UPnP Content Service, and consumers can recognize only UPnP/DLNA device types, e.g. MediaServer. One of reasons is that a device vendor would describe in the user operation manual what UPnP/DLNA device types are supported in the product. The other reason is that a device vendor usually provide a way to change the UPnP FriendyName per UPnP device types. In this sense, searching UPnP device type is necessary to support UPnP/DLNA products in the market.

Thank you.

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








> -----Original Message-----
> From: Cathy.Chan@nokia.com [mailto:Cathy.Chan@nokia.com]
> Sent: Friday, October 11, 2013 3:06 AM
> To: Youenn.Fablet@crf.canon.fr; Igarashi, Tatsuya
> Cc: public-device-apis@w3.org; giuseppep@opera.com; richt@opera.com
> Subject: [discovery] DAP-ISSUE-131 Support UPnP device discovery by Device
> Type? (was RE: [discovery] Adding CORS to NSD API - proposal and issues)
> 
> I'll answer some of these questions as some of them were my idea. Igarashi-san,
> please feel free to jump in as well.
> 
> > From: ext FABLET Youenn [mailto:Youenn.Fablet@crf.canon.fr]
> > Sent: Thursday, October 10, 2013 8:32 AM
> > To: Igarashi, Tatsuya
> > Cc: Device APIs Working Group; Giuseppe Pascale; Rich Tibbett
> > Subject: RE: [discovery] Adding CORS to NSD API - proposal and issues
> >
> > Hi,
> >
> > Your proposal sounds interesting.
> > One thing that I like with it would be to remove the need for web apps
> to parse the config data fields.
> > Since it is already done by the NSD implementation, it would be best if
> done once in usual cases.
> >
> This is a compromise done to keep the "device" object as similar to the
> "service" object as possible, as there were concerns that adding device
> search introduces way too much complexity to justify it. Specifically, if
> the "device" object were to contain parsed information about each of the
> services it contains, as well as embedded devices (and their services, and
> possibly further embedded devices, and so on), we would be looking at a
> complete overhaul on the object model. See my analysis at
> http://www.w3.org/2009/dap/track/issues/131.

> 
> > Adding a deviceId field for UPnP NetworkService objects makes sense to
> me.
> > This field would be a convenient way to group NetworkService objects by
> devices.
> > I was expecting this field to be set to the UDN element value.
> > What is the rationale behind the current choice?
> >
> The deviceId was introduced in the spec (not by this proposal) to group all
> services, embedded devices (and their services) that belong to the same
> *root* device to facilitate removing everything in one go if a root device
> is to go offline. Since embedded devices have their own UDNs, using the UDN
> as the deviceId would cause the embedded devices (and their services) to
> be "disconnected" from the root device.
> 
> > As of UPnP NetworkService name field, would it make sense to directly use
> the friendly name of the UPnP device?
> > Currently, it is set to the cryptic serviceId element value which may not
> be of great use by web apps.
> > Providing a user friendly name would be more consistent with MDNS
> NetworkService name fields as well.
> >
> This issue has been raised separately on the main body of the spec. See
> http://www.w3.org/2009/dap/track/issues/148. It would be better to address
> it in that context.
> 
> > I also understood from the proposal that a NetworkService would be added
> to represent each device itself in addition to the related services.
> > Is my understanding correct? If so, what is the expected benefit?
> >
> Your understanding is correct. And this is the crux of this proposal. Let's
> say there is a device X with services A and B. With the current spec, the
> UA would store an object for A and an object for B, each with their respective
> service types. A web page would invoke the getNetworkService method with
> the respective UPnP service type as an argument to find each of these services.
> (To find both services, it would need to invoke the getNetworkServices method
> with both service types in the argument.) This proposal adds another object
> for X, with its device type stored. This enables a web page to invoke the
> getNetworkService method with a UPnP device type as an argument instead,
> and the existing algorithm for processing that call would locate the object
> for X and (upon user permission) pass it on to the web page. Upon parsing
> the config information, the web page would have information on both services
> to interact with them.
> 
> - Cathy.
> 
> > Regards,
> >                 Youenn
> >
> >> From: Igarashi, Tatsuya [mailto:Tatsuya.Igarashi@jp.sony.com]
> >> Sent: lundi 7 octobre 2013 13:07
> >> To: FABLET Youenn; Giuseppe Pascale; Rich Tibbett
> >> Cc: Device APIs Working Group
> >> Subject: RE: [discovery] Adding CORS to NSD API - proposal and issues
> >>
> >> Hi Tibett and Youenn,
> >>
> >> I would like repeat what Giuseppe said, "It has been pointed out before
> that "device" in UPnP terminology doesn't mean one physical device ".
> >> But it is absolutely tangential. I would suggest to discuss it as the
> DAP-ISSUE-131.  In addition, I would ask both of you to make your comment
> on our proposal as below.
> >>
> >>
> http://lists.w3.org/Archives/Public/public-device-apis/2013Sep/0025.h

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

Received on Friday, 11 October 2013 14:08:58 UTC