Hello Johannes Well, you could start by creating one interface for an XMPP Server and one interface for an XMPP client. That interface could have methods returning basic information, perhaps something similar to what is being published through other methods.
However, for automation purposes I believe we also need an interface returning supported features (discovery), and perhaps also interfaces for important XEPs. For IoT I was thinking of creating interfaces for the Concentrators XEP (0326), sensor data XEP (0323) control XEP (0325) in a first effort (also the soon to be proposed Interoperability XEP), since these are important for automation. The interoperability effort in itself would implicitly include a myriad of interfaces (or loose-coupled contracts) for use within IoT. Are you interested in writing a proposal together for this purpose? Sincerely, Peter Waher -----Original Message----- From: Hund, Johannes [mailto:[email protected]] Sent: den 28 juni 2013 10:35 To: XMPP Standards Subject: Re: [Standards] Using .well-known/ to supplement XEP-0156 Hello Peter, after a brief research, I agree that UPNP might be an interesting option for XEP-0174 or peer-to-peer XMPP as well as XEP-0156. Basically, a DCP for XMPP server and client would need to be specified, right? As I understood it, maybe the informations provided by the TXT record in XEP-0174 would be a good starting point for the informations. Control points could cover things like create user and connection. UPNP seems more browsable and more versatile to me compared to mDNS and DNS-SD. Best regards, Johannes -----Ursprüngliche Nachricht----- Von: [email protected] [mailto:[email protected]] Im Auftrag von Peter Waher Gesendet: Donnerstag, 23. Mai 2013 05:45 An: XMPP Standards Betreff: Re: [Standards] Using .well-known/ to supplement XEP-0156 Hello Johannes. The thought has crossed my mind. It has been nagging me as a good thing to do, but I haven't come to the point yet to try it out. But, the reasons to use UPnP, instead of, or in parallel with DNS, include the following: * UPnP is server-less. Works using multi-cast and single-cast UDP in the local network. (Controlling TTL and enabling IGMP in routers, can take you further out in the network.) * UPnP allows you to send spontaneous notifications of existence, and also request notifications from devices when you need them. * UPnP has well defined interfaces, including class definitions, with data and methods that can be called. * UPnP is used in home environments. * UPnP, as part of DLNA is also used in home entertainment systems. With the move towards IoT, especially using IP-TV, and similar approaches, UPnP is a natural way to publish presence of devices with well-defined interfaces that can be used by IP-TV applications running on the set-top-box. Many set-top-boxes already have a natural API for DLNA (and therefore UPnP). I think It would be worth-while to define one or more UPnP interfaces for XMPP-capable devices. Needless to say, I'm happy to join an effort to create such interfaces and related XEP(s). Sincerely, Peter Waher -----Original Message----- From: Hund, Johannes [mailto:[email protected]] Sent: den 21 maj 2013 07:30 To: XMPP Standards Subject: Re: [Standards] Using .well-known/ to supplement XEP-0156 Hello Peter, would you see UPNP/SSDP discovery also orthogonal to XEP-0174, which uses MDNS/DNS-SD a.k.a. zeroconf/Bonjour to discover xmpp clients? In that case for serverless p2p-Messaging. I understood that UPNP basically does the same thing zeroconf does in terms of discovery, but on a more application-layer-focused approach. Or would it make sense to offer UPNP as an alternative discovery method in XEP-0174? I know the OP was about XEP-0156, but I think both XEPs are related in terms of out-of-band discovery methods. Is my assumption right Both use DNS flavors, but could also be solved by UPNP? Best regards, Johannes -----Ursprüngliche Nachricht----- Von: [email protected] [mailto:[email protected]] Im Auftrag von Peter Waher Gesendet: Montag, 20. Mai 2013 19:16 An: XMPP Standards Betreff: Re: [Standards] Using .well-known/ to supplement XEP-0156 Hello Yusuke. Work for implementing support for UPnP (and so DLNA) into browsers has been done in many places. It's one of the use cases in IP-TV applications, to be able to connect to home entertainment equipment and Home Automation devices through the set-top-box, which normally runs a browser. Support for UPnP in browsers has not been standardized (yet, anybody interested to create a proposal?). What people have done is creating plugins, particular for a given browser, being a STB-browser, Smart TV, or a more common browser supporting plugins, like Firefox or Opera. These plugins then publish a JavaScript API that allows the web applications to access UPnP (& DLNA) devices. Some links: http://html5.cablelabs.com/upnp/html5-upnp-integration.html http://dev.opera.com/articles/view/network-service-discovery-api-support-in-opera/ http://upnp.org/sdcps-and-certification/resources/sdks/ I personally like UPnP & DLNA. It would be a great way to find XMPP-based devices, particularly IoT devices, in your vicinity, and be able to interact with them. Sincerely, Peter Waher -----Original Message----- From: Yusuke DOI [mailto:[email protected]] Sent: den 19 maj 2013 22:09 To: XMPP Standards Cc: Peter Waher Subject: Re: [Standards] Using .well-known/ to supplement XEP-0156 Peter, (2013-05-19 03:13), Peter Waher wrote: > What about the UPnP method? Using SSDP? Creating some well defined > UPnP Device interface for XMPP Servers & XMPP Clients, perhaps > exposing the features of each device at the same time? Saves time as > you don't have to do service discovery on each device. UPnP is not for browsers and I think this is not what Lance needs. Regards, Yusuke
