Open Bug 914579 Opened 11 years ago Updated 2 years ago

Add Network Service Discovery API support

Categories

(Core :: Networking, enhancement, P5)

Product:
Core
Component:
Networking
Type:
enhancement

Tracking

()

Status:
UNCONFIRMED

People

(Reporter: andre.fiedler, Unassigned)

References

(
URL
)

Details

(Keywords: feature, Whiteboard: [necko-would-take])

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:26.0) Gecko/20100101 Firefox/26.0 (Beta/Release) Build ID: 20130907030204 Steps to reproduce: Add support for http://www.w3.org/TR/discovery-api/ so we can call navigator.getNetworkServices('urn:schemas-sony-com:service:ScalarWebAPI:1', gotServices, onError); This will affect app development on Firefox OS. For example Sony's PlayMemories app needs to know if a Sony service is available in the current network (connected to camera via wifi). Maybe this can be polyfilled using WebRTC, don't know if this will work. Actual results: not implemented Expected results: callback call with the service response ;)
URL: http://www.w3.org/TR/discovery-api/
Keywords: feature
OS: Mac OS X → All
Hardware: x86 → All
Asking feedback here from Travis to get some initial thoughts and the right stakeholders.
Flags: needinfo?(tchoma)
This can be used to get information about local devices like second screens (TV's), media devices (like Chromecast or XBMC services), remote controlled (wifi) cameras (like Sony's NEX system) aso. Some example service types: urn:schemas-upnp-org:service:AVTransport:1 urn:schemas-upnp-org:service:ConnectionManager:1 urn:schemas-upnp-org:service:ContentDirectory:1 urn:schemas-upnp-org:service:RenderingControl:1 urn:schemas-sony-com:service:IRCC:1 urn:schemas-sony-com:service:ScalarWebAPI:1 urn:dial-multiscreen-org:service:dial:1 urn:microsoft.com:service:X_MS_MediaReceiverRegistrar:1
Network Service Discovery API support in Opera http://dev.opera.com/articles/view/network-service-discovery-api-support-in-opera/
Seems that bug 173804 from way back is basically asking for the same thing, although calling it Zeroconf (the standard name) or Bonjour/Rendezvous (Apple proprietary terms).
Jonas, are you aware of any prior work in this area?
Flags: needinfo?(tchoma) → needinfo?(jonas)
Not really. I know the DAP group has discussed this, but I haven't been part of those discussions.
Flags: needinfo?(jonas)
It looks like the w3c draft is http://www.w3.org/TR/discovery-api/
FWIW, I proposed this to Google as an alternative to their proposed second screen apis. They pointed me to their rejected (mostly for security questions) Intent to implement at: https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/HT0KZKuTLxM
There's a update to the w3c draft here: https://dvcs.w3.org/hg/dap/raw-file/tip/discovery-api/Overview.html
I would recommend just implementing TCPSocket and UDPSocket APIs and then building polyfills on top of those. At least until someone can show that the spec provides a meaningfully different security model. As far as I can tell, the spec currently allows sending arbitrary messages to an endpoint without the UA being able to guarantee anything to the user security-wise about what effects those messages have.
The W3C DAP WG published an updated working draft of Network Service Discovery today. This draft includes use of CORs, updates related to garbage collection issues and updated security and privacy consideration sections. I suspect this will help with regards to security - feedback would be welcome see http://www.w3.org/TR/2014/WD-discovery-api-20140220/ (the correct diff link is http://services.w3.org/htmldiff?doc1=http%3A%2F%2Fwww.w3.org%2FTR%2F2013%2FWD-discovery-api-20130924%2F&doc2=http%3A%2F%2Fwww.w3.org%2FTR%2F2014%2FWD-discovery-api-20140220%2F I hope this is helpful regards, Frederick Frederick Hirsch Change log is applicable since 29 March 2013), i.e. Update working version to latest respec build Fix minor respec link bugs and other minor editorials [discovery-api] Re-write CORS-related parts of the spec following subsequent feedback on http://lists.w3.org/Archives/Public/public-device-apis/2013Oct/0049.html Add CORS as the primary network service opt-in mechanism for the NSD API specification Fix [DAP-ISSUE-147]: Reference 'Requirements for Home Networking Scenarios' in Introduction Fix [DAP-ISSUE-134]: Rename NetworkServices and NetworkService events Replace numeric error codes with string-based error types and fold the NavigatorNetworkServiceError interface in to DOMError (therefore, removing NavigatorNetworkServiceError from spec) Fix [DAP-ISSUE-136]: Issues related to garbage collection Fix [DAP-ISSUE-135]: Add security and privacy considerations section [Network Service Discovery] Fix minor typo in NSD API spec examples Change getNetworkServices API + associated algorithms to use DOM Promises
For TV project, we need this API for integrating UPnP/DLNA functionality into Firefox OS. With this API supported, Gaia app can easily control/display the remote content from other DLNA devices by using plug.play.js [1]. @jonas, how could we move forward on supporting this API? Should I initiate a discussion on mailing list as well? [1] https://github.com/richtr/plug.play.js/
Flags: needinfo?(jonas)
(In reply to Shih-Chiang Chien [:schien] (UTC+8) from comment #12) > For TV project, we need this API for integrating UPnP/DLNA functionality > into Firefox OS. With this API supported, Gaia app can easily > control/display the remote content from other DLNA devices by using > plug.play.js [1]. > > @jonas, how could we move forward on supporting this API? Should I initiate > a discussion on mailing list as well? > > [1] https://github.com/richtr/plug.play.js/ Jonas proposed to implement support for udp sockets and build network discovery on top of that. From previous painful experience, that seems better to me than adding a upnp/dnla stack in gecko.
By @fabrice's recommendation, we'll need UDPSocket API from bug 745283 and build SSDP on top of it in bug 751172, then polyfill Network Service Discovery API in this bug.
Depends on: 751172
Android already has a SSDP implementation at: http://mxr.mozilla.org/mozilla-central/source/mobile/android/modules/SimpleServiceDiscovery.jsm but I don't know that we really want to implement this spec. From what I've hard, its mostly worthless in its current form, since there are no devices that support CORs that exist (and AFAIK none are in the pipes either).
The API as it was drafted last I read it was no more secure than the TCPSocket and system-xhr APIs. Couldn't we simply use those APIs instead?
Flags: needinfo?(jonas)
Also, this bug is about creating a native implementation of the W3C Discover API. Creating a polyfill in a JS-library on top of TCPSocket/UDPSocket would be a separate bug.
No longer depends on: 751172
And yeah, I should clarify comment 16 a bit. Last I looked at the spec the API was so insecure that we couldn't expose it to untrusted web pages. I.e. it effectively had the same security model as TCPSocket/systemXHR/UDPSocket. So we might as well create a library on top of those APIs. Since then I hear that they've made some changes to the API to make it more secure. However the result of those changes is that the API doesn't work with any existing hardware, and so is presumably useless for our purposes.
Intent to implement Network Service Discovery API at Blink dev list: https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/HT0KZKuTLxM
Hi @Jonas and @Wesley, thanks for pointing out the CORs problem in the draft of Network Service Discovery API. Incompatible with existing hardware is a critical issue for implementing DLNA features. I'll create a separate bug for the DLNA support for TV project and we'll work on the TCPSocket/systemXHR/UDPSocket approach.
Note that please refer to bug 751172 for implementing SSDP on WebSocket approach.
Whiteboard: [necko-would-take]
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: -- → P5
Type: defect → enhancement
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.