The world of transports to date is a little mysterious and can sometimes be confusing. When you get right down to it though, it's pretty simple, assuming you already understand a little bit about how XMPP works. One thing that is important to know is that the terms transport and gateway are interchangeable. Some folk will mix and match them depending on which sounds right in a sentence, some are adamant about it being one or the other. In the case of the IM Gateway plugin, I chose to use gateway for the "entire plugin" and transport for each individual service. I probably just made it even more confusing in the process. Also, we typically refer to AIM, MSN, etc as "legacy services". I believe this spawned from a general hope that some magical day XMPP will be -the- method for chatting and the older ones will be obsolete. Who knows. I use the term for consistency.

How do you find what transports are available?

Nowadays, and almost without question, transports are located by performing Service Discovery on an XMPP server. Transports will typically show up in the items list, with a 'gateway' identity. If the transport supports registration, it will indicate that it supports jabber:iq:register. Support of jabber:iq:gateway typically refers to the ability to send a username string to the service and have it return a full valid jid for the username in question. For example, lets say my MSN email address is ninja@foo.bar. You can't have @ in the username part of a jid.. in other words you can't have ninja@foo.bar@msn.jabber.server. The jabber:iq:gateway service will turn that into something like ninja%foo.bar@msn.jabber.server. Then it will handle knowing that % means @ on it's end. It's kinda clever. Some transports support groupchat or MUC as well so you can enter legacy chatrooms from your XMPP account.

Assuming you can contact it and you are not restricted from doing so, there is nothing preventing you from registering with a transport on a different server than your own. Services like this are provided all over the world where folk from lots of different XMPP servers will register with their publicly available transports. Typically this is accomplished by registering the jid of the transport (msn.jabber.server) in DNS so that others can look it up. Don't be fooled however, if you want to hide your transport from the rest of the world, just not registering it in DNS does not mean someone can't register with it. All that is typically required is a way for their server to look up your transport hostname. That can be done via their own DNS or local hosts file or whatever. If you care, it's important to realize this so that you can take whatever precautions you need.

How do I register with a transport once I find it?

This is typically handled via In-Band Registration or by an administrator who sets up your registration for you. It's a fairly simply process where you request a registration "Form", the server sends it back (or tells you go away), you fill it out and return it, and 'lo, you are registered. Once this occurs, typically the transport will subscribe to your presence just like any regular user would. You are expected to accept this. The transport will then be able to see when you are online, change statuses, or log off.

How does the transport know when I'm logged in or not?

Just like any regular user, a transport subscribes to your presence so it can see when you log in, out, change status, etc. If it sees you go to an "away" state, it tries to reflect that on the legacy service. Typically the transport will also be in your roster and will reflect your status on the legacy service in it's own state. So if you go into, for example "free for chat".. you would see your XMPP status change to free for chat, then lets say you are registered with AIM, ICQ, MSN, Yahoo, and IRC. AIM does not support free for chat, so it would consider that a form of available and illustrate that by keeping it's icon/presence in your roster as available. ICQ does know what free for chat is, so it would reflect that for real and let you know it "took" by sending the proper presence packet back to your XMPP client. Same goes for the others. This gives you a visual que as to what your real status on the legacy network is.

What about if I am set to invisible in my XMPP client?

Yeah... that would be a problem that has yet to be resolved. If you go invisible in your XMPP client, well, then you are invisible to the transports as well. So you are effectively sending an unavailable presence packet to the transport and so it logs you off. You CAN log into your XMPP account, go invisible, and -then- send a directed available presence to the transport, but you still aren't going to be invisible on the actual transport. Long story short, there's really no way to carry invisibility over to the legacy network currently.

How does a transport sync up my contact list with the legacy network?

In a very painful way. The transport has to send a subscription packet to your client for every contact so they end up in your contact list. Because the transports have no control over your roster, they can not do anything particularly smooth to ease this transition. Once you have gone through this the first time, you do not have to do it again. There was a proposal called "roster subsync" that involved tagging the subscription packets with a flag that indicated "hey, I'm syncing a roster here, try to be nice and let your user choose to accept all". The proposal was written in a way that hurt nothing if it was not implemented by the client, and was easy to implement. That said... it was rejected. Instead, there is an official JEP called Roster Item Exchange to take care of this issue. Unfortunately, it is sort of a pain to implement. The transport has to check ahead of time what the user's client supports, and dramatically change it's behavior accordingly. If the JEP is not supported, then we send typical subscription packets individually. If it is supported, we have to collect all of the roster items into one big ball and send them as a single group. I am not aware of any clients that actually support this either, so it's been kind of a lost cause. There were murmurs of a way to allow the transports "trusted control" over the user's roster, but I've never seen anything official.