RE: [discovery-api] Consolidated comments and questions

> -----Original Message-----
> From: ext Norifumi Kikkawa [mailto:Norifumi.Kikkawa@jp.sony.com]
> Sent: Wednesday, February 06, 2013 4:05 AM
> To: Rich Tibbett
> Cc: public-device-apis@w3.org
> Subject: Re: [discovery-api] Consolidated comments and questions
>
> Hi, please see comments below.
>
> On Tue, 5 Feb 2013 23:36:15 +0900
> Rich Tibbett <richt@opera.com> wrote:
>
> > Cathy.Chan@nokia.com wrote:
>
> > > 5. Allow cross-domain access to additional UPnP device resources in
> > > addition to control URL? From Naoyuki Sato [11], [13]:
> > > The access white-list should be expanded to include additional UPnP
> > > resources such as device description page, service description page,
> > > which allows the web app to examine the actions and other details
> > > supported by a service, and device icons, which allow the web app to
> > > show the device icon to improve user experience.
> >
> > That could be a good addition. We could add .icon to the
> > NetworkService interface for example.
> >
> > However, that would be a UPnP specific attribute. There is no easily
> > addressable icon equivalent in mDNS AFAIK. If it only works half the
> > time it's probably not worth adding.
>
> I'd like to allow more access than icon.
>
> Likewise mDNS case, NSD should provide only SSDP functionality.
> SSDP is a way to find device description. Why not just provide the device
> description to Web app? (What's the difference with the mDNS case?)

+1. The icon is just an example of what info in the device description might 
be useful to the web app. Another useful one is the service description file 
(SCPDURL). There is no need to create individual attributes for each of those 
items. However, such URLs listed in the device description file should be 
whitelisted for the web app to access.

>
> Regarding cross-domain access, I have a concern on prohibiting access other
> than that to the port used in the controlUrl.
> IMO, one of the big goal of NSD is to intract with existing UPnP products
> without modifying them. These products do use various communication
> addition to SOAP. For example, DLNA uses HTTP Streaming and it doesn't
> mandate the tcp port for streaming must be the same as that for SOAP.


To make matters worse, a DLNA media server can also list content that is 
hosted on third-party content providers, in which case it would be impossible 
to grant cross-domain access. I don't think this is a problem that NSD would 
be able to solve (nor is it its job to solve).

> Under user permission, any access should be allowed to the permitted
> device in the local network, I think.

The problem here is that this would open up the device way more than 
necessary/expected by the user. This *might* be fine for a standalone UPnP 
device, but absolutely not for e.g. a software media server running on a PC. 
Granting the web app access to the software media server MUST NOT open it up 
to telnet or ftp  or any other access to the same PC!

- Cathy.

>
> Thanks,
> Kikkawa
>