Richard, > > Jabber is the only software > > that I have heard of that breaks pieces out this way. > > Not really, if you use the example of SMTP you cant run two > entirely different email services on the same domain.
Just because a lot of server developers think of MUC and standard c2s as two different components doesn't mean that users do. In fact, it's exactly the opposite. Here's an example from the email world -- a few organizations setup pop.example.com and smtp.example.com so that they have more flexibility about where different parts of email traffic go. However, the vast, vast majority of companies will just install a single email server at one domain that does both sending and receiving of email. That's because users and admins think of "email" as a unified service for sending and receiving messages. It's the same thing for services like MUC. Admins want to setup an "IM system" and shouldn't have to care about all the different services and the required DNS entries. > Sure but once you come to officially deploying after you have > stabilised it whats the problem with getting the DNS entries > setup? Yea if you are in a large company you might have to go > through some effort getting them setup, but those processes > will have been defined for a reason, if you are in a company > you have to control updates to the DNS you cant just let > anyone change stuff willy nilly, you would have anarchy. So, let's say you have the choice between two IM systems. One you can double click an exe, wait 5 minutes and then it all "just works". The other IM system has 5 different sub-components. You'll have to fill out paperwork for each one because they require a new subdomain and new subdomains are handled by the IT department at your org and will take two weeks to setup. Which IM system do you go with? :) For you, a subdomain is "no problem", but this is honestly not the situation at a lot of orgs. > But its not, the services are on their own domains, but that > is one solution to this problem, simply implement the server > so that everything appears on the same domain name, you are > more likely to get overlaps of JID username parts when all > users and conference rooms etc are all running from the same > domain name, but its an entirely workable solution, e.g. Yep, you've pointed out exactly why subdomains are required. Quite simply, this is a design flaw of the XMPP protocol. There's really nothing to do about it except try to come up with decent ways to make people's lives easier. I think your suggestion about DNS SRV entries may be a good one as well. Here's another idea -- when two servers connect, they could send disco to one another. That should allow them to discover exactly which subdomains (services) each server controls (for the services in disco) and then intelligently re-use existing s2s connections. This doesn't account for when MUC is the first thing connected to, but would be another incremental improvement. I still haven't heard a lot input about why the logic we've implemented in Jive Messenger is a bad thing other than "it's not normal". The only argument so far is that if you are on "blah.foo.com", your server goes down, and there's an evil server on "foo.com" that wants to transparently take your IM traffic then you'd be in trouble. This is a logically true argument, but I think the enhanced ease of use of outweighs this practically non-existant security concern. Regards, Matt
