Re: [discovery] Adding CORS to NSD API - proposal and issues

On Mon, Oct 7, 2013 at 2:45 AM, Rich Tibbett <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