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

comments inline

regards, Frederick

Frederick Hirsch

On Oct 15, 2013, at 12:46 PM, ext Rich Tibbett wrote:

> On Wed, Oct 16, 2013 at 1:41 AM, Giuseppe Pascale <> wrote:
>> On Tue, Oct 15, 2013 at 7:02 AM, Igarashi, Tatsuya
>> <> wrote:
>>> Hi Giuseppe,
>>> On Wed, Oct 16, 2013 at 1:41 AM, Giuseppe Pascale <> 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.

This also goes against the privacy principle of minimization - the web page should not inventory all the services but only access what it needs by asking for what it needs.

> 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?
>>> BTW, the about description “the user is promoted to select discovered
>>> network services…” would not be correct. I think it should be “the user is
>>> prompted to allow providing network service information discovered on local
>>> network”, because UA does not support service selection.
>> My understanding was that this is not required but I agree this text seems
>> to suggest otherwise. Rich?
> I can try to clean up this sentence. Of course it is worth pointing
> out here that most of the UI/UX is quite deliberately left out of the
> scope of this spec.
> I would suggest both of the interpretations of user prompting made
> above could be potentially valid but such UX decisions fall to
> implementers. We shouldn't need to say much more than this in this
> specification.
> - Rich

Received on Thursday, 17 October 2013 15:16:50 UTC