[Standards] Using .well-known/ to supplement XEP-0156

Hund, Johannes johannes.hund at siemens.com
Wed Jul 3 10:16:06 UTC 2013


Hello Peter,

I agree that extending this basic layer with application-specific DCPs can be senseful in an IOT context, but I would start with the basic layer.
I think the discovery via UPNP and information exchange that is uptil now defined via DNS TXT can act as starting point and minimum viable system.

It was also the idea I had in mind to provide an lean UPNP DCP describing an XMPP client and  another one for the server, which can be used in conjunction with UPNP discovery to mainly provide the information needed to establish an XMPP connection. 

For discovering supported the XEPs, I am thinking of a way to keep close to the approach that UPNP AV does for negotiating AV codecs and transports, where a service can be queried for a list of supported formats (roughly comparable to HTTP-Accept headers)
Another (non-exclusive) option might be to offer a UPNP-based Service to access disco#info.

I think it's a very interesting topic and am actually interested in contributing to such a proposal.

Best regards,
Johannes


-----Ursprüngliche Nachricht-----
Von: Peter Waher [mailto:Peter.Waher at clayster.com] 
Gesendet: Dienstag, 2. Juli 2013 17:53
An: XMPP Standards
Cc: Hund, Johannes
Betreff: RE: [Standards] Using .well-known/ to supplement XEP-0156

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:johannes.hund at siemens.com]
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: standards-bounces at xmpp.org [mailto:standards-bounces at xmpp.org] 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:johannes.hund at siemens.com]
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: standards-bounces at xmpp.org [mailto:standards-bounces at xmpp.org] 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:yusuke.doi at toshiba.co.jp]
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







More information about the Standards mailing list