> >>Interesting solution but not exactly standard, and will only > >>work between servers that are running Jive Messenger, > > > > True. However, the nice thing about the logic is that normal DNS is > > tried first. We also recommend that users setup DNS for max > > compatibility. Even so, the extra logic means that if normal DNS isn't > > or can't be setup, the service will still work if the other server is > > JM. So far, we don't see a reason that this couldn't be added as an > > implementation recommendation attached to the RFC's. > > This really sounds like a bad idea to me. This implies that in the case of > user > error, for example a user who tries to connect to a service such as > conference.uct.ac.za, a JM server will try to resolve and connect to > uct.ac.za > and then ac.za ? Just moving up the tree isn't a reasonable assumption.
It seems like a reasonable, but obviously not 100% accurate, assumption to me. Most installations run at least a conference server along with their main server. With our server implementation you get conferencing, pubsub, JEP-0065 Proxy, and a user directory installed and running by default, all on the same host. If you want those to be available to the outside world you have to setup quite a few DNS entries. As Matt mentioned, it is often very difficult, or impossible, for administrators to get DNS entries put in for all of the possible sub domains -- even the root one. > > Instead of 1 NXDOMAIN dns lookup result, you have either 3 failed lookups, > or > perhaps worse, 2 failed connection attempts to resolvable addresses which > have > no jabber servers running there, or perhaps completely unrelated servers > (in > which case the failure gets even messier). That doesn't seem so horrible to me. Personally, I'd rather have a more simplified setup to increase adoption of cross domain XMPP/Jabber. > > This is bad engineering i.t.o. creating undesirable impact on the broader > Internet. What is the undesirable impact? Sure, there are a few more DNS lookups and potentially more connections and some stream errors. That doesn't seem like much of an impact. I don't see the harm in connecting to hosts that do not provide service to the domain you need. This is flushed out rather quickly in the S2S process. -JD
