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.html


Thank you.

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




From: FABLET Youenn [mailto:Youenn.Fablet@crf.canon.fr]
Sent: Monday, October 07, 2013 5:13 PM
To: Giuseppe Pascale; Rich Tibbett
Cc: Device APIs Working Group
Subject: RE: [discovery] Adding CORS to NSD API - proposal and issues

Searching by service type seems appropriate from a web app point of view.
As Rich said, a web app may just need ContentDirectory service access (slideshow) while another may need access to all ContentDirectory, ConnectionManager and AVTransport services (streaming).
It makes sense to keep it that way.

Granting access at a device level seems more comprehensive from a user point of view.
It is also probably more consistent with UPnP design.
But at the end of the day, this is a browser UX decision (power users may still prefer a pick-service-by-service UX).
I am not sure why the NSD API should actually define constraints here.

Enabling partial exposure of a device has also some benefits.
The web app can parse the UPnP device description to request user specific actions like activate a given missing service or grant a given service.
If that helps the web app job, the order of the services within the NetworkServices array could be specified.

Regards,
                youenn


From: Giuseppe Pascale [mailto:giuseppep@opera.com]
Sent: lundi 7 octobre 2013 09:22
To: Rich Tibbett
Cc: Device APIs Working Group
Subject: Re: [discovery] Adding CORS to NSD API - proposal and issues

On Mon, Oct 7, 2013 at 2:45 AM, Rich Tibbett <richt@opera.com<mailto:richt@opera.com>> wrote:
>
> It has been pointed out before that "device" in UPnP terminology doesn't
> mean one physical device. Actually a "device" in UPnP is somewhat closer to
> our definition of "service", e.g. a "Media Server" in UPnP is a device, and
> includes the following services: "ConnectionManager", "ContentDirectory",
> "AVTransport", "ScheduledRecording".
[...]

My position on this is that a web page can request the four services
above in a single call to getNetworkServices, assuming they intend to
interact with all four services. Otherwise, we the API supports access
minimisation, where a web page could request just "ContentDirectory"
and "ScheduledRecording" to fulfil its use cases.

So say device type X is made of services A,B and C:

if I make a search and only get A and B, should I assume that C is not present or not CORS enabled or what?
Also, if all I want is to interact with device types X why should I ask for all services A,B,C and then filter out which one belong to device types X? Since these services are designed to work together, it may only make sense to expose them togheter (or not expose them at all)


At the UX level, the user would be authorizing one 'device' and all
requested services belonging to that device would be shared.

>
> I think a web app will be interested in talking to a "Media Server" and NOT
> to a subset of functionalities of a Media Server services (functions).  I
> think this goes back to the old discussion about UPnP services VS UPnP
> devices: does it make sense to expose single UPnP services rather than UPnP
> devices? I don't remember if we concluded on that, maybe we should do it
> before we change the spec.
I like the concept of grouping device services together but sharing
those sub-components could be done on a need-to-know basis as per the
current spec.


exposing/enabling just a pieace of some devices may not make sense. Having to fliter-out unwanted services (because I only want services A that are part of device type X) also doesn't make sense. I think we need to change the spec on this.


>
> Going back to the original issue, my comment above is not that relevant
> anymore if we go for the "alternative" proposal (as I also suggest). It's
> still important to define though what to do with UPnP devices: if only some
> services support CORS (i.e. the tentative preflight requests on their
> control URL is successful) what should the UA do? Should it be exposed to a
> web application or not? Should we even allow search for single UPnP
> services, or only for devices?
Well these are additional issues we will then need to discuss and
resolve. Right now we minimize access only to the services requested
from a web page and no more.

I think some people see changing from service access to
grouped-service (aka 'device') access as a trivial change. It really
is not.


but may be needed for the way UPnP is designed. I think other people have axpressed this concern/desire. Is there someone else that think the spec should stay as is instead?

/g