Every protocol begins with a single step...

Before connections are made to any of the BOS or special-purpose servers, you must first be authorized by the Authorization Server (login.oscar.aol.com). This will return a cookie that automatically authorizes you to connect to any of the BOS or special-purpose (eg, Advertisement, Chat, etc) servers. This streamlines the login process quite a bit.

The normal steps taken to create an average AIM session are as follows:

1. Connect to Authorizer and retrieve Cookie.
2. Connect to the Authorizer-recommended BOS server and initiate BOS service
3. (Optional) Connect to Advertisements server and retrieve first block of ads (repeat at regular interval)
4. (Optional) Connect to any other non-BOS services that may be available (AFAIK, none at this point)

The last three steps may actually be done in any order (and for the third and fourth step, probably not at all). But, authorization must always come first.

OSCAR has a sense of the "single-login" concept. You login once and get a "cookie" that automatically authorizes you to use any of the OSCAR-associated services, just by sending them your cookie.

The first step of the process is connecting to the Authorizer. This currently resides at the DNS address login.oscar.aol.com. It also appears that you may connect to any port and get the same response. (The AIM clients use 5190, James uses 443, I've used 21 (telnet) before as well.)

After the connection, the client must send the "Authorization Request" command. The server also sends a 4b+FLAP command to the client after each new connection, called the "Connection Acknowledge" command. This may be accepted and processed before or after the inital command from the client (for use it dispatch routines, this can be used as a sign that the inital login should be sent). The response to this ("Authorization Response") contains the cookie to be used for the BOS and other connections. But, if the the Authorization Request fails, you'll get back any one of the several "Authorization Errors". After you've gotten your cookie, it's safe to disconnect yourself from the Authorizer.

The next step is usually to connect to and initiate service with the BOS. The address of the BOS you should connect to is listed in the Authorization Response. The first step for this connection is to send the BOS-Signon command to the server. But, for the purposes of dispatching, it may be best to wait to send this command until the Connection Acknowledge command is recieved from the server immediatly after the connection opens, although this is optional and can be processed afterwards.

Normal BOS signon looks something like this...

1. Server sends Connection Acknowledge
2. Client sends BOS SignOn command.
3. Server sends BOS Host-Ready.
4. Client sends Rate Information Request.
5. Server sends Rate Information Response.
6. Client sends Rate Information Acknowledge.
7. Client requests (in no particular order):
   • Set Privacy Flags
   • Request Our User Information
   • Request New Service
   • Optional: Request BOS Rights
   • Optional: Request Buddy List Rights
   • Optional: Request Locate Rights
   • Optional: Request ICBM Parameter Information
8. Server sends all the information requested (again, in no particular order):
   • Our User Information Response
   • BOS Rights Response
   • Buddy List Rights Response
   • Locate Rights Response
   • ICBM Parameter Information Response
   • New Service Redirect
9. (Aparently Optional) Client sends a SNAC of family 0x0009, subtype 0x0004, data {0x0000, 0x001f}.
10. (Aparently Optional) Client sends a SNAC of family 0x0009, subtype 0x0007, no data.
11. Client sends up buddy list using the Add Buddy to Buddy List command.
12. Client sends up user's profile using the Set User Information command.
13. Client sends the Set Initial ICBM Parameter command.
14. Client sends the Client Ready command.

At that point, you can either quit and begin processing live events, or you may use the information provided in the New Service Redirect command to connect to the Advertisments or other server.

Logging off of AIM is about the simplest thing you can do. The abrupt way to do it is just closing the connection to the main message server. That will normally do it. Sometimes, though, the AIM client sends a small command to the server before it closes, but expects no response. I've found the best way is just to close it forget about it.

This "logout command" is just a FLAP without a Data Field, and the Data Field Length set to 0x0000.