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

+1

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



From: Giuseppe Pascale [mailto:giuseppep@opera.com]
Sent: Saturday, October 26, 2013 4:00 PM
To: Rich Tibbett
Cc: Cathy.Chan@nokia.com; Igarashi, Tatsuya; FABLET Youenn; Device APIs Working Group
Subject: Re: [discovery] DAP-ISSUE-131 Support UPnP device discovery by Device Type? (was RE: [discovery] Adding CORS to NSD API - proposal and issues)

I don't understand why we should complicate things when at least with UPnP you already have a concept of device, so you could (as I proposed in some other email, that I think didn't get a reply) do something much simpler: a search by device could simply return the list of services associated to that type of device.

Can you expand on why my proposal would be complex/would not work while adding this kind of query mechanism is easier to support?

/g

On Wed, Oct 23, 2013 at 4:56 PM, Rich Tibbett <richt@opera.com<mailto:richt@opera.com>> wrote:
On Wed, Oct 16, 2013 at 8:56 AM,  <Cathy.Chan@nokia.com<mailto:Cathy.Chan@nokia.com>> wrote:
>> From: ext Rich Tibbett [mailto:richt@opera.com<mailto:richt@opera.com>]
>>
>> On Wed, Oct 16, 2013 at 1:41 AM, Giuseppe Pascale
>> <giuseppep@opera.com<mailto:giuseppep@opera.com>> wrote:
>> > On Tue, Oct 15, 2013 at 7:02 AM, Igarashi, Tatsuya
>> > <Tatsuya.Igarashi@jp.sony.com<mailto:Tatsuya.Igarashi@jp.sony.com>> wrote:
>> >>
>> >> Hi Giuseppe,
>> >>
>> >>
>> >> On Wed, Oct 16, 2013 at 1:41 AM, Giuseppe Pascale
>> <giuseppep@opera.com<mailto: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.
>>
>> 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.
>>
>> Perhaps we could discuss a specific use case or scenario where a pattern of
>> calling getNetworkServices twice as above would be more useful than calling
>> getNetworkServices once against a list of service types that are well-known
>> to the requesting web page and thus are presumably handleable by that web
>> page should they be returned from that call?
>>
> The pattern of calling getNetworkServices twice would typically be useful in cases where a service type is common to multiple device types, and the web app is only interested in using it in the context of a specific device type and not others. (Giuseppe also pointed this use case out in [1].)
>
> I can give a concrete example.
Thank you Cathy. I have been requesting a good practical example of
the exact problem since this issue was raised.

>
> The definition of the UPnP MediaServer device type consists of a mandatory ContentDirectory service and an optional ConnectionManager service. The definition of the UPnP MediaRenderer device type consists of the mandatory AVTransport and RenderingControl services, and an optional ConnectionManager service.
>
> Let's say a user has a MediaServer device that implements both the ContentDirectory and ConnectionManager services, and a MediaRenderer device that implements all three services - AVTransport, RenderingControl and ConnectionManager services. He starts a web app that would discover locally connected MediaRenderer devices and stream content to it/them.
>
> If the web app can only do searches by UPnP service types, it would start by searching for the AVTransport and RenderingControl service types. The UA would ask the user to grant the web app access to the MediaRenderer device (where internally only the AVTransport and RenderingControl services are in scope of the permission request). After the user says yes, the web app would receive the two NetworkService objects corresponding to the AVTransport and RenderingControl services. Upon inspecting the config attribute of either NetworkService object, it would find out that the device also implements the ConnectionManager service. In order to take advantage of that service, the web app would have to initiate another search, this time for the AVTransport, RenderingControl and ConnectionManager service types*, in order to get the user's permission to use the all three services of the device. The UA would ask the user again to grant the web app access to the MediaRenderer device (where this time all three services are in scope). This duplicate prompt could be confusing for the user.
>
> * Slightly off-topic: it's unclear to me whether the second search should be only for ConnectionManager service or all three services. The spec says that
> [[There is no implied persistence to networked service sharing provided to a web page. It MUST NOT be possible to access a networked service previously granted to a web page without user authorization in all of the following cases:
>
>     If the current script is reloaded at any point in the same or different window.
>     if the current script reinvokes the getNetworkServices() method at any point in its execution.
>     If the user navigates forward or back in their history to reload the current page.
>     If a script is running in a different origin.]]
> To me, that means that the second invocation needs to include all three services. Either way, the second search would result in the UA asking the user again to grant the web app access to the MediaRenderer device.
If this prose is not clear then it needs to be cleaned up. The
intention with this is that services should not be exposed to users
unless those particular services are authorized by the user for the
current origin within the current browsing context.

The contentious point may be 'If the current script reinvokes the
getNetworkServices() method at any point in its execution'. That
shouldn't mean previously authorized services for the current page
should be lost to the web page when subsequent calls are made to the
API. In your example you shouldn't have to call all 3 services in the
second call since two of those services were already authorized and
shared in the first call.

But multiple calls to getNetworkServices() is clearly not an ideal
strategy if users need to opt-in to share services on each request
(i.e. it interrupts a user's workflow twice instead of once). We
should explore a way to fulfil this use case in a single call to the
API...

>
> While the web app could have started the search with all three service types, it would not be desirable either. Such a search would result in the UA prompting the user to grant the web app access to both the MediaRenderer device (to use all three services) and the MediaServer device (to use the ConnectionManager service). The user might question why the web app would try to access his MediaServer (and for many users, access to the MediaServer means access to their media library) and might call foul play on the web app.
>
> This issue would not have occurred if the web app was able to issue a search by device type. By searching for the MediaRenderer device type, the UA would prompt the user once to grant the web app access to the MediaRenderer device (to use all of its services), and the web app would receive information of all services to perform its function.
>
> This is a long-winded way to say, once again, that searching by device type has its uses and should not be dismissed so quickly.
In light of the motivating use case being presented here I can agree
with this sentiment.

The current specification provides no guarantee that all service types
requested will be from the same device and in the example provided (in
the second request you detail above) both the MediaRenderer and
MediaServer will match on the ConnectionManager service type when
really you wanted only want the ConnectionManager service belonging to
the same device as has been previously shared.

I understood the original intention of this use case to be as follows:
"I want a device (or plurality of devices) that MUST support service
type A + B and MAY support service type C." There is no way to do that
currently in our spec and doing that over multiple calls to
getNetworkServices() is tricky.

But actually, in light of this use case what we actually need is a
selection of services belonging to one 'device' (be that a top-level
device or sub-device). So I want to explore grouping here as a means
to fulfil this use case.

My app must have services A + B and optionally C to function at all.
Here is the syntax we could introduce to accomplish this:

getNetworkServices(['a; b; c', 'a; b']);

this means devices are matched and presented to the user if services
they provide match to the following provided rule:

(a AND b AND c) OR (a AND b)

This meets the needs of the provided use case without needing to
expose top-level UPnP devices directly. This means:

a.) we don't need to expose services belonging to devices that have
not been requested from the web page. i.e. the data sharing
minimization currently provided by the spec remains in place.
b.) two devices implementing a subset of identical services can be
considered equivalent regardless of their associated device type. i.e.
If a web page needs a device that supports both A and B then any
device that meets that criteria can be shared with the web page
equally.

There are a number of other examples we could then use here:

getNetworkServices(['a;b;c', 'd' ]) == (a AND b AND c) OR d
getNetworkServices(['a', 'b', 'c']) == a OR b OR c

With the introduction of AND grouping logic (semi-colon separation
within requested service type tokens) to compliment the already
existing OR logic (provided when supplying an array of services in the
spec) it seems we can cover the provided use case, maintain suitable
data sharing minimization to web pages and do all that in a single
call to getNetworkServices() instead of having to track devices across
multiple API calls.

We could also add this to the spec without too many changes since we
get to keep the services-first sharing concept intact. This is
important because it is the normalisation point we use in the spec
across all network service discovery protocols.

Best regards,

Rich

>
> [1] http://lists.w3.org/Archives/Public/public-device-apis/2013Oct/0097.html

>