OSCAR Protocol: Section 7: Messeging

AIM/Oscar Protocol Specification: Section 7: Messeging

7.0 Messeging

So now we get to the purpose of this whole thing: messaging. Instant messages are strings of ASCII codes that get sent in very-near-real-time between users of the Basic OSCAR Service (BOS). At no time does one client directly locate another client, or even know the location of any other client. All messages are sent to the message server, which then relays them to their destination client(s).

The text of a message is usually in the form of an HTML-like encoding that AOL calls "text/x-aol-rtf" (MIME format notation). For all intents and purposes, it's a subset of HTML. But, just like with HTML, you don't have to use HTML to be HTML. Sending straight ASCII text works just fine as well. The AOL-sourced AIM clients always use HTML even if you don't type or use any. They will usually append at least the <HTML>, <BODY>, and <FONT> tags (and their appropriate closing tags) even if you didn't intend to use any. The server does not touch the message at all.

Sending and receiving instant messages (from now on called IMs), is really quite simple. There are some things that can make it go funny, though. I don't have all those things documented yet.

7.1 Sending IMs

Below is the command structure for the "Send IM" command. I have found, that depending on which message server you end up with, you may have problems when using the command structure defined below. I can't explain this behavior, but it has happened a couple of times before. Just logging out and then back in again (usually getting another server) lets you send messages just fine. Also, changing some of the fields of this command can still get it through the server, but the distant-end client will fail (actually, I've found several combinations that crash the AIM Java client quite messily). Just use with care.

Fig 7.1.1 Send IM Command (Family 0x02)

Position	Length	Data
1	Word	0x0004
3	Word	0x0006
5	Word	0x0000
7	DWord	Request ID
11	DWord	Unknown Purpose (leave as 0x00s)
15	Word	0x0001
17	Byte	Destination SN Length
18	ASCII String	Destination SN (unterminated)
19	Word	0x0002
21	Word	Message Length + 0x0D
23	Byte	0x05
24	Word	0x0100
26	Word	0x0101
28	Word	0x0101
30	Word	Message Length + 0x04
32	Word	0x0000
34	Word	0x0000
35	ASCII String	Message (unterminated)

7.1.1 Errors Dealing with "Send IM" Command

7.2 Receiving IMs

Receiving IMs is gernerally quite simple. The same member information that comes in the "oncoming buddy" command (see figure 5.1.1) is sent here, in the same format and same order. And because of that, the space between the SN and the start of the message will be variable depending on the class of the source SN.

Fig 7.2.1 Incoming IM Command (Family 0x02)

Position	Length	Data
1	Word	0x0004
3	Word	0x0007
5	Word	0x0000
7	QWord+DWord	Unknown Gibberish
19	Word	0x0001
21	Byte	SN Length
23	ASCII String	Source Screen Name
24*	Word	Warning Level of Sender
26*	Word	Class Part One
28	Word	0x0001
30	Word	0x0002
32*	Word	Class Part Two
34	Word	0x0003
36	Word	0x0004
38*	DWord	Member Since date
40	Word	0x0003
42	Word	0x0004
44*	DWord	On Since date
48+	Word	0x0004
50+	Word	0x0002
52+*	Word	Idle Time
54	Word	0x0002
56	Word	Message length + 0x0D
58	7 bytes	0x5101111
65	Word	Message Length + 0x04
67	DWord	0x0000
71	ASCII String	Message (unterminated)
* Not present for commands from AOL members
+ See notes in section 5.1 on these fields (they're the same)

7.2.1 Errors Associated with Receiving IMs

Adam Fritzler

Last modified: Fri Jul 24 14:16:56 MST 1998