Although not really very useful, several nuggets of information can be obtained about other AIM and AOL users through the OSCAR BOS.

The lifetime of the information AIM BOS can provide you with is extremely limited. Basically, you can only access a user's information while they are online. The AIM servers do not store any information about users if they are not logged onto the service. Please be aware of this.

Information that is very simple to gather includes:

• Member Class
• Warning Level
• Idle Time
• Time of Signon
• Date when Member began their AOL/AIM account

These five things can be obtained simply by adding that screen name to your buddy list and waiting until they come online. The "oncoming buddy" command documented above provides the transport for this information. If you want information about a user and don't want to add them to your buddy list, please see the next subsection.

There's a specific command that the client issues to the server in order to request all available information about a user. This is the "Request Member Information" command and is documented in the following table. This is fairly self-explanatory command.

After the client sends that, the server sends back either the "User Information Response" command, or the "Invalid User Information Request". The latter almost always means that the user you requested information for is not logged on.

* Note that you can request one of two things here (as far as we know right now) -- 0x0001 will return the users profile, and 0x0003 will return the users away message (if any). What you actually get in both cases is either the 0x0001 and 0x0002 TLVs (that are set when you send up your profile/away message) or the 0x0003 and 0x0004 TLVs. Check the 0x0002/0x0004 SNAC for more information on this.

** Something else to note: it appears that requesting a datum of 0x0005 will not return the users capability block. I've also attempted to send up a TLV with type 0x0007 to the server during the login process, but requesting it back through this mechanism didn't yield any results, although AIM took the 0x0007 TLV ok.

This table has been moved to here.

Request IDs: You must pick a request ID to send up in the reqest so that you can identify the response to the request later. Normally, the request response will not contain any of the information from the origial request and therefore will be useless if you don't know what it's in response to! They're kind of like sequence numbers, but they're not as strict. Reqest IDs are always 32-bit DWords.

The OSCAR BOS (basic services) allows a few rudimentrary methods of locating other AIM and AOL users.

A "find SN by email address" request is facilitated by the "Request Screen Name by Address" command in next table.

Please notice the lack of a length byte/word prefixed to the email address. It's kind of strange for this derivation in behavior, but AOL can do what they want.

The server's response to that is the "Search by Address Response" command, explaned in the next table. Please note that there may be several screen names per email address.

And if no screen names are found, we get the "Search by Address Response Fail" command below.

It would appear that AIM no longer has the feature of being able to find by name. That now takes you to the address: http://www.aol.com/netfind/whitepages.html. I sure thought it used to do this....