That is significantly harder. Consider a graph (as in, graph data structure) of IM users. Communicating between an AIM and an XMPP user is a single line, and even though the two nodes are on different services it's not that hard to make work. Almost by definition, both services have very similar semantics for what an IM is, and stuff like presence converged a while ago enough for interop.

Now, consider a conference. Let's say AIM_A and AIM_B wish to conference with XMPP_X and XMPP_Y. Now there's six entities; the four users I just mentioned, and the conference rooms that are supposed to be reflections of each other. Conference rooms actually have complicated protocols for creating and managing them, fundamentally. Hooking them up to each other is very non-trivial. What does it even mean at the protocol level for XMPP_X to try to kick AIM_A out of the conference? You need a lot of infrastructure to make this work, almost none of which exists because it requires both conferences to cooperate, or a lot of implementation by one side or the other to be able to directly connect to an entirely foreign network on a foreign protocol. None of which the proprietary networks are likely to do.

Without cooperation on both sides this is basically impossible.

Right, that makes sense, thank you for the explanation. I guess interopertability between the two services implied to me they could speak eachothers' protocols in entirety (at least ideally), so i pictured gtalk talking to the aim chat room via its protocol. Oh well.

BTW this has implications for google apps users since there are no usable persistent chat rooms in gtalk. Well i guess any users, but for businesses chat rooms are more useful than for casual users I think.