> 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.
Sorry but that is a bit of an erroneous comparison, in the cases where orgs setup pop.example.com smtp.example.com etc they are not providing extra email addresses of [EMAIL PROTECTED] and [EMAIL PROTECTED] they are just pointing to the same server that is providing emails for [EMAIL PROTECTED], in the case of XMPP where you have a MUC component connected to a host XMPP server the MUC component in current implementations has its own domain separate from any other domains the server hosts.
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.
If you want to run a MUC service on its own domain then you have to setup the DNS entries, if you dont want to have to setup those entries then follow my suggestion and run all your XMPP services on the same domain rather than separate ones, other than the possible overlaps it should be fine (although they can be solved by just using something like prefixing).
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".
What IM system would this be?, I find it hard to believe any IM system is going to be externally connectable without some kind of DNS entries being setup.
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.
Then follow the suggestion of implementing all the server component under a single domain if thats what they want, rather than individual sub domains, simple and doesnt require any non standard hacks, as it has been said if there are any problems with this approach its better to perfect the single domain approach than perpetuate a "hack" that has some potential security implications.
Yep, you've pointed out exactly why subdomains are required. Quite simply, this is a design flaw of the XMPP protocol.
Not really, its just the recommended way to set it up (avoids any namespace overlaps, i.e. a room overlapping a user with the same name), as far as I can see it you should be able to run a conference server under the same domain as c2s, you should easily be able to run stuff like pubsub under it too.
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.
Its not non existant at all, at the very least it provides a way for an attacker to compromise your entire XMPP setup by highjacking a single point of your DNS setup, at worse they can compromise an organisation unrelated to your own and highjack your traffic, thats hardly a non-existant security concern, IMO we shouldnt be working to introduce any security concerns wether they are serious or not anyway, if anything we should do everything we can do to make it more secure, not less.
But anyway I doubt you will change your view on this subject, I just hope you will provide your users with a way to turn off this "feature" just incase they arnt happy with the security concerns it introduces.
Richard
