RE: DAP-ISSUE-130 (was: Draft Minutes 21 August 2013 teleconference)

>From: ext Jean-Claude Dufourd [mailto:jean-claude.dufourd@telecom-paristech.fr] 
>Sent: Thursday, August 29, 2013 8:01 AM
>To: public-device-apis@w3.org
>Subject: Re: DAP-ISSUE-130 (was: Draft Minutes 21 August 2013 teleconference)
>
>Le 28/8/13 22:38 , Cathy.Chan@nokia.com a écrit :
>>>>> <richt> ISSUE-130:
>>>>>
>>>> http://lists.w3.org/Archives/Public/public-device-apis/2013Aug/att-000
>>>> 2/minutes-2013-07-24.html#item05
>>>>
>>>>>
>>>>> <trackbot> Notes added to ISSUE-130 Enable variety of protocols (e.g.
>>>>> UPnP, Bonour) with protocol independent developer code.
>>>>>
>>>>> richt: sent mail to list, introduces more problems to do this,
>>>>> especially since no commonality among the various protocols
>>>>>
>>>> JCD: I think you are missing the point: this proposal allows searching
>>>> for a fragment of the service type, which means something like wildcards.
>>>> If you request "fragment", it is like allowing a request for
>>>> "*fragment*" (or maybe just "fragment*" if your fragment starts with a
>>>> protocol prefix) Currently, you just cannot do this.
>>>> Which means you cannot implement a service manager web app, which
>>>> would explore the home network, and understand which higher level
>>>> services the web app can offer the user.
>>>> E.g. if the web app sees a phone and a TV on the network, it will
>>>> propose to start another web app which organizes the display of new
>>>> pictures from the phone on the TV.
>> OK. I think I now understand the use case you have in mind. I agree it's an interesting one that the current API may or may not readily supports.
>>
>>>> As there are many possible services, requesting specific discoveries
>>>> to see of each service is currently runnable or not will be impractical.
>> Why is that? Wouldn't the service manager still know what specific service types the various web apps are capable of handling? The list might be long, but it wouldn't be infinite, would it? For instance, the service manager would know that a certain web app is able to use "urn:schemas-upnp-org:service:printbasic:1" and another web app is able to use "urn:vendorX-com:service:print:1". While it can perform a "fragment" search for "print", it would have no use of a local service that runs "urn:vendorZ-com:service:printpicture:1". In that case, why not search for "urn: schemas-upnp-org:service:printbasic:1" and "urn:vendorX-com:service:print:1" to begin with?
>JCD: With a static, but long, list of possible tasks, I see 
>impracticality in two places:
>- for the author, web app script code that is much longer and more complex
>- for the user, many responses to allow discovery requests required 
>instead of just one
>
>In my scenario, the author codes one async request for discovery of 
>anything, the user needs to authorize a request to discover anything by 
>this task manager web app, says yes once and for all, then the web app 
>receives a list of discovered services and the author then synchronously 
>matches the discovered services with the requirements of possible tasks 
>to deduce the list of runnable tasks, etc...
>
Are you saying that the user grants blanket permission to the task manager (and *implicitly* all the individual web apps that perform specific tasks) to access ANY AND ALL networked services it finds on the network? That is a very dangerous proposition. Many users would not even know what services exist on the network and would have no idea what they're exposing themselves to. One notable example is the UPnP IGD device - it's in many home routers, most users are not aware of them, and it can perform powerful functions (and mischiefs). I take the security considerations of this spec to mean that the user must (at least once) grant each web app express permission to use each discovered service, and would be very concerned if such blanket permissions are allowed.

>With the current spec, the author needs to go through the list of 
>possible tasks, and make an async request for discovery for each 
>possible task to determine if it is runnable. The user needs to 
>authorize one request for discovery per possible task. Impractical are 
>the number of async discovery requests in the web app and the number of 
>authorization requests to the user upon execution.
>
>>
>> Or do you envision that the service manager would dynamically broker the discovered services to web apps without knowing what service types they support ahead of time?
>JCD: The task manager needs to know which service is required by which 
>task regardless of whether the list of possible tasks is static or 
>dynamic, I think.
>
>
>>
>>>>   From a perspective of reducing the security related interactions with
>>>> the user, it is better that the service manager web app is given once
>>>> the full authority to discover everything on the network (which
>>>> requires wildcards or fragment search) rather than have as many
>>>> requests for discovery as there are services to be tested for their ability to
>>> run.
>> The service manager can easily lump all services to be tested into a single discovery request rather than issuing one request per each service. That would result in a single user interaction point for permission.
>JCD: Oh! Are you seriously suggesting a getNetworkServices call with 
>say, a hundred or more service types ?
>Again, this is placing a ridiculous constraint onto the web app author, 
>rather than implementing a straightforward extension of the current spec.
>And when I say "straightforward extension", I have implemented it and 
>been using it for months: it is less than 50 additional lines of code, 
>and would work with any of the UPnP and mDNS libraries I have looked at.
>
It's not about the number of lines of code. It's whether the usage makes sense and whether it introduces undue complexity. You still haven't convinced me that searching for wildcarded service type is better than searching for individual exact service types when you have specific apps that work with specific types (be that a handful of them or hundreds of them). Why go out and ask for *print* when you know you can only handle printA and printB and [insert any number of additional specific service types you can handle here], and will be discarding everything from printC to printZ to printXYZ to RANDOMprintServiceByRandomVendor?

>>
>> Additionally, as I stated in my earlier comment [1], it would be tricky for the UA to issue a search request for wildcard service types.
>>
>> [1] http://lists.w3.org/Archives/Public/public-device-apis/2013Jul/0025.html
>JCD: Actually, I did not understand why you made that point.
>
>Quoting you: "But what if a UA does not monitor the network for device 
>announcements, and only issues a search for the requested service 
>type(s) when getNetworkServices is invoked? What UPnP search target 
>would the UA use to search for services on the network? Specifically, 
>what domain should it use when constructing the search target?"
>
>Is there a practical situation where a UPnP-enabled UA does not monitor 
>the network for device announcements ?
>I do not see one. I would think such a UA to be incomplete, and yes, it 
>would not be able to respond to such request.
>
The UA that I would build would wait until the first invocation of the getNetworkServices()start monitoring the network for device announcements (and issue a search for the requested service types). Why would I want my UA to waste resources on all the discovery business if I don't know when (or if ever!) the user would use it?

>In other words, my proposed change would imply that the UA monitors the 
>network for device announcements.
>In which sense could it be a problem ?
>
The current spec leaves it up to the UA to decide whether and when it monitors the network for device announcements. It also clearly specifies how the UA would initiate service discovery on the network when it needs to (i.e. what UPnP search target to use).
[[The user agent must also send an ST header with this HTTP request equal to the String value of ssdp:all or upnp:rootdevice or a single valid service type token beginning with the String value upnp:. If a single valid service type token beginning with the String value upnp: is to be used, the user agent MUST strip the leading String upnp: before using this value in this HTTP request.]] - Section 8.2.
For completeness, your proposal would have to address that aspect, i.e. give the UA specific instructions on how to initiate service discovery when presented with wildcarded service types.

- Cathy.

>Best regards
>JC
>-- 
>Télécom ParisTech <http://www.telecom-paristech.fr> 	*Jean-Claude 
>DUFOURD <http://jcdufourd.wp.mines-telecom.fr>*
>Directeur d'études
>Tél. : +33 1 45 81 77 33 	37-39 rue Dareau
>75014 Paris, France
>
>Site web <http://www.telecom-paristech.fr>Twitter 
><https://twitter.com/TelecomPTech>Facebook 
><https://www.facebook.com/TelecomParisTech>Google+ 
><https://plus.google.com/111525064771175271294>Blog 
><http://jcdufourd.wp.mines-telecom.fr>

Received on Thursday, 29 August 2013 19:35:41 UTC