There's a few "features" that just don't fall under a larger category.
9.1 Inviting a Friend to Join AIM
Well, AIM has this really stupid feature to automatically send an invitation to a "friend" to join AIM. You just give it an email address and a short message, and it's sends it for you.
Fig 9.1.1 Invite a Friend Command
|15||Word||EMail Address Length|
|17||ASCII String||EMail Address (unterminated)|
|22||ASCII String||Message (unterminated)|
In response, the server sends a "Invitation Successful" command to the client.
Fig 9.1.2 Invitation Successful
9.2 Changing Your Password
This looks a little complicated. You have to open a connection back to the authorizer again, and then negotiate the whole process there. It's a total of 15 or so commands. Maybe later.
9.3 The "user info" block
Since this fits into quite a few different areas of AIM, it's current
home is here in the miscellaneous section.
Basically, many times throughout the life of your AIM session you'll
have to pass around and parse this user info block, which consists
of a few basic elements that represent an online user and his/her
status. This shows up in ICBMs, online buddy notifications, search
responses, and more. If you see "user info" referenced
anywhere throughout this protocol, this is what that means.
Fig 9.3.1 "User Info" Block
||User's warning level
||Number of TLVs to follow
Where TLVs can be of the following types:
||Session length (AIM)
||Session length (AOL)
||Member since (time_t)
||Online since (time_t)
||Capability block *
* See here for a description of the capability block.