OSCAR sequences

1.    Login sequence  2.   Retrieving offline messages sequences    3.   Retrieving user information sequence    4.   Client migration sequence  5.   New uin registration sequence    6.   Delete user account (unregister) sequence    7.   Send user warning sequence    8.   Change user_info sequence    9.   AIM change account info sequence    10.   Client verification sequence    11.   ICQ search user(s) sequences    12.   ICQ SSI authorization sequence    13.   Service request sequence  14.   Upload/download server-stored buddy icons (SSBI) sequences

Retrieving offline messages sequence        ICQ IM service has ability to save messages were sent to you when you was offline. ICQ client can request these saved messages (called offline messages) after login sequence. After receiving offline messages client should ask server to delete them or it will receive them in next request. If there is no offline messages server sends only SNAC(15,03)/0042 (without SNAC(15,03)/0041)  Retrieving offline messages   >>   SNAC(15,02)/003C   Client sends offline messages request   <<   SNAC(15,03)/0041   Server sends message #1   <<   ...   ...   <<   SNAC(15,03)/0041   Server sends message #N   <<   SNAC(15,03)/0042   Server sends end-of-offline messages snac   >>   SNAC(15,02)/003E   Client ask server to delete offline messages

Retrieving user information sequence        ICQ IM service user information is structured and has many fields. These fields divided into several sections: basic info, work info, more info, about info, extended email info, interests info, affilations info). There are 3 info requests client can send to get full or short user information:  Retrieving self full information   >>   SNAC(15,02)/07D0/04B2   Client ask server for self full information   <<   SNAC(15,03)/07DA/00C8   Server sends basic user information   <<   SNAC(15,03)/07DA/00DC   Server sends more user information   <<   SNAC(15,03)/07DA/00EB   Server sends extended email user information   <<   SNAC(15,03)/07DA/010E   Server sends homepage category user information   <<   SNAC(15,03)/07DA/00D2   Server sends work user information   <<   SNAC(15,03)/07DA/00E6   Server sends user about information   <<   SNAC(15,03)/07DA/00F0   Server sends user interests information   <<   SNAC(15,03)/07DA/00FA   Server sends user affilations information  Retrieving full user information (for another user)   >>   SNAC(15,02)/07D0/04D0   Client ask server for full user information   <<   SNAC(15,03)/07DA/00C8   Server sends basic user information   <<   SNAC(15,03)/07DA/00DC   Server sends more user information   <<   SNAC(15,03)/07DA/00EB   Server sends extended email user information   <<   SNAC(15,03)/07DA/010E   Server sends homepage category user information   <<   SNAC(15,03)/07DA/00D2   Server sends work user information   <<   SNAC(15,03)/07DA/00E6   Server sends user about information   <<   SNAC(15,03)/07DA/00F0   Server sends user interests information   <<   SNAC(15,03)/07DA/00FA   Server sends user affilations information  Retrieving short user information   >>   SNAC(15,02)/07D0/04BA   Client ask server for short user information   <<   SNAC(15,03)/07DA/0104   Server sends short user information

Migration sequence        Migration sequence used to redirect client to new BOS server during current BOS shutdown. Server can migrate whole connection or only several services. Migration always initiated by server. Server can abort migration sequence via SNAC(01,0D) - server resume command.  Migration sequence   <<   SNAC(01,0B)   Server sends pause. Client should stop send snacs   >>   SNAC(01,0C)   Client ack pause command   <<   SNAC(01,12)   Server sends migration (cookie/BOS address)   <>   disconnect   Client disconnects from BOS (only full migration)   <>   login (stage II)   Client start normal login sequence from stage II

New uin registration sequence        ICQ IM service supports automatic user registration. So client can obtain new account in real time. To perform new uin registration client should provide only password and random request id. Server also can reply via SNAC(17,01) if it can't create new user account.  New uin registration   <>   connect   Client connects to authorizer server   >>   SNAC(17,04)   Client sends registration request   <<   SNAC(17,05)   Server sends new uin (registration reply)   <>   disconnect   Client disconnects from authorizer

Delete user ICQ account sequence        This sequence used to unregister ICQ account. Use this carefully - this request completely removes your uin from server. You should provide password for this uin because it is required during unregistration.  Unregistration sequence   >>   SNAC(15,02)/07D0/04C4   Client sends delete account request   <<   SNAC(15,03)/07DA/00B4   Server sends account deleted ack   <>   disconnect   Client disconnects from BOS server

Send user warning sequence        This sequence used to send warning to AIM user that bother you. User that have too high warning level disconnects from server and can't connect for some time. You can send normal and anonymous warning. Normal warning increase user warning level by 15%, anonymous warning increase warn level by 3%.  Send warning sequence   >>   SNAC(04,08)   Client sends warning to user   <<   SNAC(04,09)   Server ack (new user warn level & warn level diff)

Change user info sequence        ICQ service user information is structured and has many fields. These fields divided into several sections: basic info, work info, more info, about info, extended email info, interests info, affilations info, password, permissions) and you can save info by sections. Here is the sequences to change user information:  Change basic info sequence   >>   SNAC(15,02)/07D0/03EA   Client send new basic info to server   <<   SNAC(15,03)/07DA/0064   Server report saving info result  Change work info sequence   >>   SNAC(15,02)/07D0/03F3   Client send new work info to server   <<   SNAC(15,03)/07DA/006E   Server report saving info result  Change more info sequence   >>   SNAC(15,02)/07D0/03FD   Client send new more info to server   <<   SNAC(15,03)/07DA/0078   Server report saving info result  Change notes info sequence   >>   SNAC(15,02)/07D0/0406   Client send new notes info to server   <<   SNAC(15,03)/07DA/0082   Server report saving info result  Change extended email info sequence   >>   SNAC(15,02)/07D0/040B   Client send new extended email info to server   <<   SNAC(15,03)/07DA/0087   Server report saving info result  Change interests info sequence   >>   SNAC(15,02)/07D0/0410   Client send new interests info to server   <<   SNAC(15,03)/07DA/008C   Server report saving info result  Change affilations info sequence   >>   SNAC(15,02)/07D0/041A   Client send new affilations info to server   <<   SNAC(15,03)/07DA/0096   Server report saving info result  Change user permissions sequence   >>   SNAC(15,02)/07D0/0424   Client send new user permissions to server   <<   SNAC(15,03)/07DA/00A0   Server report saving info result  Change user password sequence   >>   SNAC(15,02)/07D0/042E   Client send new password to server   <<   SNAC(15,03)/07DA/00AA   Server report saving info result  Change homepage category/description sequence   >>   SNAC(15,02)/07D0/0442   Client send homepage category to server   <<   SNAC(15,03)/07DA/00BE   Server report saving info result      Modern ICQ client use another way to update user information. They send single unified request packet which contain tlv chain with data fields client want to change. Here is the sequence:  Change user permissions sequence   >>   SNAC(15,02)/07D0/0C3A   Client send to server data it want to change   <<   SNAC(15,03)/07DA/0C3F   Server report saving info result

AIM change account info sequence        This sequence used to change AIM service account info (screenname formatting, email, password). Server should ack account change request by SNAC(07,02)  Change account info sequence   >>   SNAC(07,04)   Client sends new account info to server   <<   SNAC(07,05)   Server sends account change result

Client verification sequence        This request used by AOL AIM server to recognize clone clients. The request contains eight bytes. The first four are an offset, the second four are a length.      When the client receives the request, it adds it to the current ds (0x00400000) and dereferences it, copying the data into a buffer which it then runs directly through the MD5 hasher. The 16 byte output of the hash is then sent back to the server.  Client verification   <<   SNAC(01,1F)   Server ack client for verification reply   >>   SNAC(01,20)   Client sends verification reply

Main | Basic | Login | Snaclist | Sequences | Misc | Changes | Credits | Terms