Re: DAP Request: Feedback on Applicability and implementation plans for Network Service Discovery

On 25avr. 19:24, Clift, Graham wrote:
>
> >>However, it makes some use cases impossible, when a choice among 
> multiple identical services is required without friendly names.
>
> The application doesn't need to identify the service or the device 
> since it is relying on the UA to present these options to the user, 
> whether it be by its friendly name or by some other unique identifier 
> that the underlying discovery protocol supports. Simply put, when the 
> app wants to render the name of a device or service the UA will 
> translate the abstracted id into the relevant field and render it as 
> seems fit for the technology. Similarly when the user selects a device 
> or service the app knows nothing private about what was displayed on 
> the screen that caused the user to select that device or service. It 
> is up to the app to ask the UA to apply filter criteria to ensure only 
> relevant devices or services are made available to the user for this 
> particular use case. The filter criteria could be by device, by 
> service or by content type. I could imagine not just photos or video 
> but whole web pages being rendered in iframes where the base URL does 
> not need to be known to the application since it is always abstracted 
> by the UA.
>
JCD: I am not sure I understand what you are suggesting: is it something 
like the following ?
When the app needs to display the friendly name for the user to choose, 
it asks the UA to do so in its place.
That means the UA needs to do many things for the app, for example all 
GUI with sensitive info.
I do not think that is as easy to define as you think it is.

And using a unique identifier is fine for machines, but I never 
recognize the UUID for my iphone.

> As to how this would be accepted by browser vendors. Well I think 
> reluctance to add NSD in its current form might have been more about 
> privacy/security than anything else. This proposal would remove that 
> obstacle. Also, this approach could be left abstract enough that it 
> can be applied easily to any technology including Bonjour, 
> Dial/ChromeCast, UPnP, ZeroConf without having to reference them. It 
> is then left to browser manufacturers to help innovate around the 
> technology and the use cases and this would be an attractive reason 
> for supporting IMHO.
>
> Regards
>
> Graham
>
> *From:*Jean-Claude Dufourd 
> [mailto:jean-claude.dufourd@telecom-paristech.fr]
> *Sent:* Friday, April 25, 2014 1:29 AM
> *To:* Clift, Graham; Vickers, Mark; Daniel Davis
> *Cc:* public-web-and-tv; frederick.hirsch@nokia.com; 
> public-device-apis@w3.org; Dominique Hazaël-Massieux; Rich Tibbett; 
> Amol Bhagwat
> *Subject:* Re: DAP Request: Feedback on Applicability and 
> implementation plans for Network Service Discovery
>
> This idea goes in the direction of what I have been advocating for 
> some time (have the UA do more than the current NSD and hide details).
> So I like it very much :)
> However, it makes some use cases impossible, when a choice among 
> multiple identical services is required without friendly names.
>
> Some friends are meeting after a weekend together, they took a lot of 
> photos with their mobiles, and they are sending pictures to a large 
> screen using WebScreens for common viewing.
> One person likes the current photo very much, asks for it:
> - either the person who wants the photo needs to choose from as many 
> photostreams as there are mobiles in the room
> - or the person owning the picture needs to choose from as many 
> receivers as there are mobiles in the room.
> If the group is large, this may happen in parallel in multiple sub-groups.
>
> How would you propose to make this use case possible without 
> indications about the ID of the device behind a service ?
>
> On another level entirely, NSD is a proposal from browser vendors. 
> UPnP messaging is not included because browser vendors refuse to 
> implement the complete UPnP stack, reportedly because of 
> interoperability issues.
> In a way, browser vendors want to do the minimum.
> How do you intend to motivate them to step up and implement this extra 
> abstraction of yours, when they are already hesitating to implement 
> minimal NSD ?
> Best regards
> JC
>
> Le 25/4/14 02:52 , Clift, Graham a écrit :
>
>     I would go along with Mark's idea but maybe take a few steps further.
>
>       
>
>     It would be very interesting to see a proposal for NSD that provided the richness that a CORS enabled NSD solution offers but without the dependency on CORS or without any dependency on the users faith in privacy/security of an application when it accesses the LAN.
>
>       
>
>     One way I see (and maybe there is something already in the space) is to abstract away all the device/content discovery in the UA such that the application never knows anything about what is on the LAN but has an abstract reference to it that only the UA understands how to translate and that the UA can present to the user for selection when instructed to by the application, the result of the selection then being sent to the application again as an abstract reference. The application can only know that there is some device there that can play a piece of content, or that there is some kind of content out there that meets a search criteria that it itself can play. However it never sees device names, friendly names,  content names and so on. When playing content the url is even abstracted such that only the UA can translate (underneath the video element for example) into a real location for the content.
>
>       
>
>     Done this way I don't see why there would be concerns over CORS or privacy/fingerprinting.
>
>       
>
>     Regards
>
>       
>
>     Graham
>
>       
>
>     -----Original Message-----
>
>     From: Vickers, Mark [mailto:Mark_Vickers@cable.comcast.com]
>
>     Sent: Thursday, April 24, 2014 4:38 PM
>
>     To: Daniel Davis
>
>     Cc: public-web-and-tv;frederick.hirsch@nokia.com  <mailto:frederick.hirsch@nokia.com>;public-device-apis@w3.org  <mailto:public-device-apis@w3.org>; Dominique Hazaël-Massieux; Rich Tibbett; Amol Bhagwat
>
>     Subject: Re: DAP Request: Feedback on Applicability and implementation plans for Network Service Discovery
>
>       
>
>     +Amol
>
>       
>
>         * Are device manufacturers willing to support CORS in order to enable NSD support?
>
>       
>
>     A key thing would be to work with organizations that define home networking protocols (UPnP, DLNA, .) to review the spec and see if they want to add a CORS requirement to their specifications. Giuseppe has initiated those conversations.
>
>       
>
>     Of course, this only gives access to the subset of future devices that add CORS support. It doesn't give access to any existing home network devices.
>
>       
>
>     As I've mentioned before, there is another, universally deployed model that allows full access to any existing LAN devices without a new W3C spec and safely avoids the security issue. Instead of giving external websites access to the LAN (which drives the security requirements), the user agent can provide access to the LAN. Since the device running the user agent is already behind the firewall on the LAN, it can access the LAN services without extra security. The user agent needs to provide a user interface for any specific or general LAN access. Examples of this are:
>
>     1. How every browser prints a web page to a LAN printer 2. How every browser saves website files to a LAN storage device 3. How Safari's Bonjour menu browses LAN devices
>
>       
>
>     This approach could be applied to any given LAN service and implemented by:
>
>     a. Browser vendors (e.g. 1-3 above)
>
>     b. Browser extensions (e.g. GoogleCast extension, which plays video to ChromeCast devices or vGet Chrome Extension, which plays videos to discovered UPnP/DLNA devices) c. External spec groups by mandating user agent behavior (e.g. DLNA CVP-2, which specifies that user agents must implement DLNA protocols to discover and connect to LAN-based video service gateways, which provide the URL for the browser. Since the user agent finds the resources before the browser is started, there was no need to add any LAN access APIs like NSD.)
>
>       
>
>     I still think this a superior model for integrating the LAN into the Web.
>
>       
>
>     Thanks,
>
>     mav
>
>       
>
>     On Apr 16, 2014, at 11:55 PM, Daniel Davis<ddavis@w3.org>  <mailto:ddavis@w3.org>  wrote:
>
>       
>
>         Hello Web and TV IG members,
>
>           
>
>         Unfortunately there wasn't much time to discuss this on yesterday's
>
>         call but we'd still like feedback to Frederick's questions below and
>
>         your thoughts on the Network Service Discovery (NSD) API.
>
>           
>
>         For example:
>
>         * What would be necessary to keep interest in the API going?
>
>         * Are device manufacturers willing to support CORS in order to enable
>
>         NSD support?
>
>         * Are stakeholders willing to work with user agent vendors for
>
>         implementation?
>
>           
>
>         and similar comments.
>
>           
>
>         Thank you in advance,
>
>         Daniel
>
>           
>
>         On 10/04/14 04:58,Frederick.Hirsch@nokia.com  <mailto:Frederick.Hirsch@nokia.com>  wrote:
>
>             Dear Web & TV Interest Group Chairs and members:
>
>               
>
>             The Device APIs working group [1] has produced a "Network Service Discovery" draft [2] in which the Web & TV Interest Group [3] has shown interest [4].
>
>               
>
>             "This specification defines a mechanism for an HTML document to discover and subsequently communicate with HTTP-based services advertised via common discovery protocols within the current network."
>
>               
>
>             This allows a web page to discover and establish communication with services on a local network. The specification takes into account Zeroconf, SSDP and DIAL.  The specification does not define the application communications once the connection is established.
>
>               
>
>             We are concerned that we will not have adequate implementer interest
>
>             in this specification to justify progressing it further [5][6][7], and are thus wondering if the the Web & TV Interest Group, as a "customer" of this work would be willing to work with us on obtaining implementers input and feedback on this specification. Without proper interest from implementers the Device APIs Working Group would have no other option than to stop work on it.
>
>               
>
>             We are seeking feedback from the Web & TV Interest group and implementers to the following questions:
>
>               
>
>             1. Does this specification address use cases and needs of concern to you?
>
>               
>
>             2. In particular, in light of the recent additional requirement of CORS [8] support from local network services, it is likely that this specification would only work with recently updated devices. Do you plan to deploy CORS support in your UPnP/DIAL/Zeroconf based devices?
>
>               
>
>             3. Are you working on implementations of this specification? If so, have you determined whether these implementations are likely to find their way into a well-deployed browser?
>
>               
>
>             5. Can you provide any assistance in determining implementers plans, and possibly work with implementers on providing input and feedback on the future of this specification?
>
>               
>
>             Feedback you give us is important to DAP taking appropriate next
>
>             steps and will be much appreciated. Please send any comment to the
>
>             DAP public list (cc'd) , public-device-apis @ w3.org
>
>               
>
>             Thanks
>
>               
>
>             regards, Frederick
>
>               
>
>             Frederick Hirsch, Nokia, @fjhirsch
>
>             Chair Device APIs Working Group
>
>               
>
>             [1]http://www.w3.org/2009/dap/
>
>               
>
>             [2]http://www.w3.org/TR/2014/WD-discovery-api-20140220/
>
>               
>
>             [3]http://www.w3.org/2011/webtv/
>
>               
>
>             [4]
>
>             http://lists.w3.org/Archives/Public/public-device-apis/2011Jul/att-00
>
>             98/minutes-2011-07-20.html#item07
>
>               
>
>             [5]
>
>             http://lists.w3.org/Archives/Public/public-device-apis/2014Mar/att-00
>
>             24/minutes-2014-03-27.html#item08
>
>               
>
>             [6]
>
>             https://groups.google.com/a/chromium.org/forum/#!searchin/blink-dev/n  <https://groups.google.com/a/chromium.org/forum/#%21searchin/blink-dev/n>
>
>             etwork$20service$20discovery/blink-dev/HT0KZKuTLxM/S3w-SdvjZfUJ
>
>               
>
>             [7]https://bugzilla.mozilla.org/show_bug.cgi?id=914579
>
>               
>
>             [8]http://www.w3.org/TR/cors/
>
>               
>
>             For tracker, this completes ACTION-687
>
>               
>
>           
>
>       
>
>       
>
>       
>
>       
>
>       
>
> -- 
>
> 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>*
>