6.0 Gathering Member Information
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.
6.1 Gathering the Basics
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.
6.2 Getting a Personal Profile
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.
Fig 6.2.1 Request Member Information Command
||Requested Information *
|14||ASCII String||Screen Name (not terminated)|
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.
Fig 6.2.2 User Information Response Command
This table has been moved to here.
Fig 6.2.3 Invald User Information Request Command
|5||DWord||ID of the Request that failed|
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.
6.3 Finding People
The OSCAR BOS (basic services) allows a few rudimentrary methods of locating other AIM and AOL users.
6.3.1 Finding by EMail Address
A "find SN by email address" request is facilitated by the "Request Screen Name by Address" command in next table.
Fig 22.214.171.124 Request Screen Name by Address
|11||ASCII String||Email Address (unterminated)|
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.
Fig 126.96.36.199 Search by Address Response
|15*||ASCII String||SN (unterminated)|
|* Field repeats for every listed screen name.|
And if no screen names are found, we get the "Search by Address Response Fail" command below.
Fig 188.8.131.52 Search by Address Fail
6.3.2 Finding by Name
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....