Mercurial > pidgin
annotate doc/PROTOCOL @ 1301:e973ef7a8a87
[gaim-migrate @ 1311]
The IRC plugin works again (when joining channels).
Thanks for breaking it for me, bro :-D
committer: Tailor Script <tailor@pidgin.im>
author | Rob Flynn <gaim@robflynn.com> |
---|---|
date | Tue, 19 Dec 2000 01:29:13 +0000 |
parents | 01be71085964 |
children |
rev | line source |
---|---|
1 | 1 # Copyright (c) 1998-9 America Online, Inc. All Rights Reserved. |
2 # | |
3 # This program is free software; you can redistribute it and/or | |
4 # modify it under the terms of the GNU General Public License | |
5 # as published by the Free Software Foundation; either version 2 | |
6 # of the License, or (at your option) any later version. | |
7 # | |
8 # This program is distributed in the hope that it will be useful, | |
9 # but WITHOUT ANY WARRANTY; without even the implied warranty of | |
10 # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the | |
11 # GNU General Public License for more details. | |
12 # | |
13 # You should have received a copy of the GNU General Public License | |
14 # along with this program; if not, write to the Free Software | |
15 # Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. | |
16 | |
17 # Note from Jim Duchek, gaim maintainer -- this may not be the latest | |
18 # version of this document, I provide it as a service. Download a copy | |
19 # of TiK (http://www.aim.aol.com/tik/) for the latest version of this | |
20 # doc. | |
21 | |
141 | 22 # Note from Eric Warmenhoven, random guy -- this appears to be the last |
23 # published version of the protocol, and AOL has stopped hosting the TiK | |
143
01be71085964
[gaim-migrate @ 153]
Eric Warmenhoven <eric@warmenhoven.org>
parents:
141
diff
changeset
|
24 # program. TiK is still being maintained and is hosted on sourceforge.net; |
01be71085964
[gaim-migrate @ 153]
Eric Warmenhoven <eric@warmenhoven.org>
parents:
141
diff
changeset
|
25 # this appears to be the same version of the protocol they're using. |
141 | 26 |
1 | 27 Version: TOC1.0 |
28 | |
29 This document describes the protocol between TOC and TOC clients. | |
30 The protocol is built on TCP. Framing is done by SFLAP, | |
31 described at the bottom of this document. Inside each | |
32 SFLAP frame is a TOC command. | |
33 | |
34 The TOC protocol is ASCII based, and special attention | |
35 must be placed argument separation. The separator and | |
36 the rules of separation are different for messages inbound | |
37 to TOC and outbound to the client. The rules of separation | |
38 are described in sections below. | |
39 | |
40 The TOC server is built mainly to service the TIC and TiK clients. Since | |
41 the TIC client is a Java applet, and downloadable, TOC will NOT support | |
42 multiple TOC protocol versions at the same time. Therefore, TiK | |
43 users will be forced to upgrade if the protocol version changes. | |
44 TOC sends down the protocol version it expects the client | |
45 to speak and understand. Note, the protocol version is a string. | |
46 | |
47 Important Notes | |
48 =============== | |
49 * TOC will drop the connection if a command exceeds the maximum | |
50 length, which is currently 2048 bytes. So the client needs to | |
51 spend special attention to im, chat, and config message lengths. | |
52 There is an 8k length maximum from TOC to the client. | |
53 | |
54 * No commands should be sent to TOC (besides toc_signon) before | |
55 a SIGN_ON is received. If you do send a command before SIGN_ON | |
56 the command will be ignored, and in some case the connection | |
57 will be dropped. | |
58 | |
59 * Initial permit/deny items should be sent after receiving SIGN_ON | |
60 but before sending toc_init_done, otherwise the user will flash | |
61 on peoples buddylist who the user has denied. You will probably | |
62 want to send the toc_add_buddies at this time also. | |
63 | |
64 * After TOC sends the PAUSE message to a client, all messages sent | |
65 to TOC will be ignored, and in some cases the connection will | |
66 be dropped. Another SIGN_ON message will be sent to the client | |
67 when it is online again. The buddy list and permit/deny items must | |
68 be sent again, followed by the toc_init_done. In most cases the | |
69 SIGN_ON message will be sent between 1-2 seconds after the | |
70 PAUSE message. Therefore a client could choose to ignore the | |
71 PAUSE message and hope nothing bad happens. | |
72 | |
73 | |
74 Client -> TOC | |
75 ============== | |
76 The commands and the arguments are usually separated by whitespaces. Arguments | |
77 with whitespace characters should be enclosed in quotes. Dollar signs, | |
78 curly brackets, square brackets, parentheses, quotes, and backslashes | |
79 must all be backslashed whether in quotes or not. It is usually | |
80 a good idea just to use quotes no matter what. All user names from clients | |
81 to TOC should be normalized (spaces removed and lowercased), and therefore | |
82 are the one exception to the always use quotes rule. | |
83 | |
84 When sending commands to the server you will not get a response | |
85 back confirming that the command format was correct or not! However | |
86 in some cases if the command format was incorrect the connection | |
87 will be dropped. | |
88 | |
89 | |
90 RoastingString="Tic/Toc" | |
91 | |
92 toc_signon <authorizer host> <authorizer port> <User Name> <Password> | |
93 <language> <version> | |
94 The password needs to be roasted with the Roasting String if | |
95 coming over a FLAP connection, CP connections don't use | |
96 roasted passwords. The language specified will be used | |
97 when generating web pages, such as the get info pages. | |
98 Currently the only supported language is "english". | |
99 If the language sent isn't found, the default "english" | |
100 language will be used. The version string will be used | |
101 for the client identity, and must be less then 50 | |
102 characters. | |
103 | |
104 Passwords are roasted when sent to the host. This is done so they | |
105 aren't sent in "clear text" over the wire, although they are still | |
106 trivial to decode. Roasting is performed by first xoring each byte | |
107 in the password with the equivalent modulo byte in the roasting | |
108 string. The result is then converted to ascii hex, and prepended | |
109 with "0x". So for example the password "password" roasts to | |
110 "0x2408105c23001130" | |
111 | |
112 toc_init_done | |
113 Tells TOC that we are ready to go online. TOC clients should first | |
114 send TOC the buddy list and any permit/deny lists. However toc_init_done | |
115 must be called within 30 seconds after toc_signon, or the connection | |
116 will be dropped. Remember, it can't be called until after the SIGN_ON | |
117 message is received. Calling this before or multiple times after a | |
118 SIGN_ON will cause the connection to be dropped. | |
119 | |
120 toc_send_im <Destination User> <Message> [auto] | |
121 Send a message to a remote user. Remember to quote and encode the | |
122 message. If the optional string "auto" is the last argument, then the | |
123 auto response flag will be turned on for the im. | |
124 | |
125 toc_add_buddy <Buddy User 1> [<Buddy User2> [<Buddy User 3> [...]]] | |
126 Add buddies to your buddy list. This does not change your | |
127 saved config. | |
128 | |
129 toc_remove_buddy <Buddy User 1> [<Buddy User2> [<Buddy User 3> [...]]] | |
130 Remove buddies from your buddy list. This does not change your | |
131 saved config. | |
132 | |
133 toc_set_config <Config Info> | |
134 Set the config information for this user. The config information | |
135 is line oriented with the first character being the item type, | |
136 followed by a space, with the rest of the line being the item | |
137 value. Only letters, numbers, and spaces should be used. Remember | |
138 you will have to enclose the entire config in quotes. | |
139 | |
140 Item Types: | |
141 g - Buddy Group (All Buddies until the next g or the end of config | |
142 are in this group.) | |
143 b - A Buddy | |
144 p - Person on permit list | |
145 d - Person on deny list | |
146 m - Permit/Deny Mode. Possible values are | |
147 1 - Permit All | |
148 2 - Deny All | |
149 3 - Permit Some | |
150 4 - Deny Some | |
151 | |
152 toc_evil <User> <norm|anon> | |
153 Evil/Warn someone else. The 2nd argument is either the string | |
154 "norm" for a normal warning, or "anon" for an anonymous | |
155 warning. You can only evil people who have recently sent you | |
156 ims. The higher someones evil level, the slower they can | |
157 send message. | |
158 | |
159 toc_add_permit [ <User 1> [<User 2> [...]]] | |
160 ADD the following people to your permit mode. If | |
161 you are in deny mode it will switch you to permit | |
162 mode first. With no arguments and in deny mode | |
163 this will switch you to permit none. If already | |
164 in permit mode, no arguments does nothing | |
165 and your permit list remains the same. | |
166 | |
141 | 167 toc_add_deny [ <User 1> [<User 2> [...]]] |
1 | 168 ADD the following people to your deny mode. If |
169 you are in permit mode it will switch you to | |
170 deny mode first. With no arguments and in permit | |
171 mode, this will switch you to deny none. If | |
172 already in deny mode, no arguments does nothing | |
173 and your deny list remains unchanged. | |
174 | |
175 toc_chat_join <Exchange> <Chat Room Name> | |
176 Join a chat room in the given exchange. Exchange is | |
177 an integer that represents a group of chat rooms. | |
178 Different exchanges have different properties. For | |
179 example some exchanges might have room replication (ie | |
180 a room never fills up, there are just multiple | |
181 instances.) and some exchanges might have navigational | |
182 information, and some exchanges might have ... Currently | |
183 exchange should always be 4, however this may | |
184 change in the future. You will either | |
185 receive an ERROR if the room couldn't be joined | |
186 or a CHAT_JOIN message. The Chat Room Name | |
187 is case insensitive and consecutive spaces | |
188 are removed. | |
189 | |
190 toc_chat_send <Chat Room ID> <Message> | |
191 Send a message in a chat room using the chat room | |
192 id from CHAT_JOIN. Since reflection is always on in | |
193 TOC, you do not need to add the message to your chat UI, | |
194 since you will get a CHAT_IN with the message. | |
195 Remember to quote and encode the message. | |
196 | |
197 toc_chat_whisper <Chat Room ID> <dst_user> <Message> | |
198 Send a message in a chat room using the chat room | |
199 id from CHAT_JOIN. This message is directed at | |
200 only one person. (Currently you DO need to add this to | |
201 your UI.) Remember to quote and encode the message. | |
202 Chat whispering is different from IMs since it is linked | |
203 to a chat room, and should usually be displayed in the chat | |
204 room UI. | |
205 | |
206 toc_chat_evil <Chat Room ID> <User> <norm|anon> | |
207 Evil/Warn someone else inside a chat room. The 3rd argument is either | |
208 the string "norm" for a normal warning, or "anon" for an anonymous | |
209 warning. Currently chat evil is not turned on in the chat complex. | |
210 | |
211 toc_chat_invite <Chat Room ID> <Invite Msg> <buddy1> [<buddy2> [<buddy3> [...]]] | |
212 Once you are inside a chat room you can invite other people into | |
213 that room. Remember to quote and encode the invite message. | |
214 | |
215 toc_chat_leave <Chat Room ID> | |
216 Leave the chat room. | |
217 | |
218 toc_chat_accept <Chat Room ID> | |
219 Accept a CHAT_INVITE message from TOC. The server will send a | |
220 CHAT_JOIN in response. | |
221 | |
222 toc_get_info <username> | |
223 Gets a user's info a GOTO_URL or ERROR message will be sent back to the | |
224 client. | |
225 | |
226 toc_set_info <info information> | |
227 Set the LOCATE user information. This is basic HTML. | |
228 Remember to encode the info. | |
229 | |
230 toc_set_away [<away message>] | |
231 if the away message is present, then the unavailable | |
232 status flag is set for the user. If the away message | |
233 is not present, then the unavailable status flag is | |
234 unset. The away message is basic HTML, remember to | |
235 encode the information. | |
236 | |
237 toc_get_dir <username> | |
238 Gets a user's dir info a GOTO_URL or ERROR message will be sent back to the | |
239 client. | |
240 | |
241 toc_set_dir <info information> | |
242 Set the DIR user information. This is a colon separated fields as in: | |
243 "first name":"middle name":"last name":"maiden name":"city":"state":"country":"email":"allow web searches" | |
244 Should return a DIR_STATUS msg. Having anything in the "allow web searches" | |
245 field allows people to use web-searches to find your directory info. | |
246 Otherwise, they'd have to use the client. | |
247 | |
248 toc_dir_search <info information> | |
249 Perform a search of the Oscar Directory, using colon separated fields as in: | |
250 "first name":"middle name":"last name":"maiden name":"city":"state":"country":"email" | |
251 Returns either a GOTO_URL or ERROR msg. | |
252 | |
253 toc_set_idle <idle secs> | |
254 Set idle information. If <idle secs> is 0 then the user isn't idle at all. | |
255 If <idle secs> is greater then 0 then the user has already been idle | |
256 for <idle secs> number of seconds. The server will automatically | |
257 keep incrementing this number, so do not repeatedly call with new | |
258 idle times. | |
259 | |
141 | 260 toc_set_caps [ <Capability 1> [<Capability 2> [...]]] |
261 Set my capabilities. All capabilities that we support need to | |
262 be sent at the same time. Capabilities are represented by | |
263 UUIDs. | |
264 | |
265 toc_rvous_propose - Not Implemented Yet | |
266 | |
267 toc_rvous_accept <nick> <cookie> <service> <tlvlist> | |
268 Accept a rendezvous proposal from the user <nick>. | |
269 <cookie> is the cookie from the RVOUS_PROPOSE | |
270 message. <service> is the UUID the proposal was | |
271 for. <tlvlist> contains a list of tlv tags followed by | |
272 base64 encoded values. | |
273 | |
274 toc_rvous_cancel <nick> <cookie> <service> <tlvlist> | |
275 Cancel a rendezvous proposal from the user <nick>. | |
276 <cookie> is the cookie from the RVOUS_PROPOSE | |
277 message. <service> is the UUID the proposal was | |
278 for. <tlvlist> contains a list of tlv tags followed by | |
279 base64 encoded values. | |
280 | |
281 toc_format_nickname <new_format> | |
282 Reformat a user's nickname. An ADMIN_NICK_STATUS or ERROR message will | |
283 be sent back to the client. | |
284 | |
285 toc_change_passwd <existing_passwd new_passwd> | |
286 Change a user's password. An ADMIN_PASSWD_STATUS or ERROR message will | |
287 be sent back to the client. | |
288 | |
1 | 289 |
290 TOC -> Client | |
291 ============== | |
292 All user names from TOC to client are NOT normalized, and are | |
293 sent as they should be displayed. String are NOT encoded, instead | |
294 we use colons as separators. So that you can have colons inside | |
295 of messages, everything after the colon before :<Message> should | |
296 be considered part of the message (ie don't just "split" on colons, | |
297 instead split with a max number of results.) | |
298 | |
299 | |
300 SIGN_ON:<Client Version Supported> | |
301 This is sent after a successful toc_signon command is sent to TOC. | |
302 If the command was unsuccessful either the FLAP connection will | |
303 be dropped or you will receive a ERROR message. | |
304 | |
305 CONFIG:<config> | |
306 A user's config. Config can be empty in which case the host was not able to | |
307 retrieve it, or a config didn't exist for the user. See toc_set_config | |
308 above for the format. | |
309 | |
310 NICK:<Nickname> | |
311 Tells you your correct nickname (ie how it should be capitalized and | |
312 spacing) | |
313 | |
314 IM_IN:<Source User>:<Auto Response T/F?>:<Message> | |
315 Receive an IM from some one. Everything after the third colon is | |
316 the incoming message, including other colons. | |
317 | |
318 UPDATE_BUDDY:<Buddy User>:<Online? T/F>:<Evil Amount>:<Signon Time>:<IdleTime>:<UC> | |
319 This one command handles arrival/depart/updates. Evil Amount is | |
320 a percentage, Signon Time is UNIX epoc, idle time is in minutes, UC (User Class) | |
321 is a two/three character string. | |
322 uc[0]: | |
323 ' ' - Ignore | |
324 'A' - On AOL | |
325 uc[1] | |
326 ' ' - Ignore | |
327 'A' - Oscar Admin | |
328 'U' - Oscar Unconfirmed | |
329 'O' - Oscar Normal | |
330 uc[2] | |
331 '\0' - Ignore | |
332 ' ' - Ignore | |
333 'U' - The user has set their unavailable flag. | |
334 | |
335 | |
336 | |
337 ERROR:<Error Code>:Var args | |
338 * General Errors * | |
339 901 - $1 not currently available | |
340 902 - Warning of $1 not currently available | |
341 903 - A message has been dropped, you are exceeding | |
342 the server speed limit | |
141 | 343 |
344 * Admin Errors * | |
345 911 - Error validating input | |
346 912 - Invalid account | |
347 913 - Error encountered while processing request | |
348 914 - Service unavailable | |
349 | |
1 | 350 * Chat Errors * |
351 950 - Chat in $1 is unavailable. | |
352 | |
353 * IM & Info Errors * | |
354 960 - You are sending message too fast to $1 | |
355 961 - You missed an im from $1 because it was too big. | |
356 962 - You missed an im from $1 because it was sent too fast. | |
357 | |
358 * Dir Errors * | |
359 970 - Failure | |
360 971 - Too many matches | |
361 972 - Need more qualifiers | |
362 973 - Dir service temporarily unavailable | |
363 974 - Email lookup restricted | |
364 975 - Keyword Ignored | |
365 976 - No Keywords | |
366 977 - Language not supported | |
367 978 - Country not supported | |
368 979 - Failure unknown $1 | |
369 | |
370 * Auth errors * | |
371 980 - Incorrect nickname or password. | |
372 981 - The service is temporarily unavailable. | |
373 982 - Your warning level is currently too high to sign on. | |
374 983 - You have been connecting and | |
375 disconnecting too frequently. Wait 10 minutes and try again. | |
376 If you continue to try, you will need to wait even longer. | |
377 989 - An unknown signon error has occurred $1 | |
378 | |
379 | |
380 EVILED:<new evil>:<name of eviler, blank if anonymous> | |
381 The user was just eviled. | |
382 | |
383 CHAT_JOIN:<Chat Room Id>:<Chat Room Name> | |
384 We were able to join this chat room. The Chat Room Id is | |
385 internal to TOC. | |
386 | |
387 CHAT_IN:<Chat Room Id>:<Source User>:<Whisper? T/F>:<Message> | |
388 A chat message was sent in a chat room. | |
389 | |
390 CHAT_UPDATE_BUDDY:<Chat Room Id>:<Inside? T/F>:<User 1>:<User 2>... | |
391 This one command handles arrival/departs from a chat room. The | |
392 very first message of this type for each chat room contains the | |
393 users already in the room. | |
394 | |
395 CHAT_INVITE:<Chat Room Name>:<Chat Room Id>:<Invite Sender>:<Message> | |
396 We are being invited to a chat room. | |
397 | |
398 CHAT_LEFT:<Chat Room Id> | |
399 Tells tic connection to chat room has been dropped | |
400 | |
401 GOTO_URL:<Window Name>:<Url> | |
402 Goto a URL. Window Name is the suggested internal name of the window | |
403 to use. (Java supports this.) | |
404 | |
141 | 405 DIR_STATUS:<Return Code>:<Optional args> |
406 <Return Code> is always 0 for success status. | |
407 | |
408 ADMIN_NICK_STATUS:<Return Code>:<Optional args> | |
409 <Return Code> is always 0 for success status. | |
410 | |
411 ADMIN_PASSWD_STATUS:<Return Code>:<Optional args> | |
412 <Return Code> is always 0 for success status. | |
1 | 413 |
414 | |
415 PAUSE | |
416 Tells TIC to pause so we can do migration | |
417 | |
141 | 418 RVOUS_PROPOSE:<user>:<uuid>:<cookie>:<seq>:<rip>:<pip>:<vip>:<port> |
419 [:tlv tag1:tlv value1[:tlv tag2:tlv value2[:...]]] | |
420 Another user has proposed that we rendezvous with them to | |
421 perform the service specified by <uuid>. They want us | |
422 to connect to them, we have their rendezvous ip, their | |
423 proposer_ip, and their verified_ip. The tlv values are | |
424 base64 encoded. | |
425 | |
1 | 426 Typical Signon Process |
427 ====================== | |
428 Except for the section marked optional this is an sequential | |
429 process. Each line MUST occur before the following line. | |
430 | |
431 * Client connects to TOC | |
432 * Client sends "FLAPON\r\n\r\n" | |
433 * TOC sends Client FLAP SIGNON | |
434 * Client sends TOC FLAP SIGNON | |
435 * Client sends TOC "toc_signon" message | |
436 * if login fails TOC drops client's connection | |
437 else TOC sends client SIGN_ON reply | |
438 * if Client doesn't support version it drops the connection | |
439 | |
440 [BEGIN OPTIONAL] | |
441 * TOC sends Client CONFIG | |
442 * Client sends TOC permit/deny stuff | |
443 * Client sends TOC toc_add_buddy message | |
444 [END OPTIONAL] | |
445 | |
446 * Client sends TOC toc_init_done message | |
447 | |
448 | |
449 SFLAP Documentation | |
450 =================== | |
451 SFLAP is pretty much a FLAP connection except the DATA frame payload is a null | |
452 terminated string when traveling from client to host, it is NOT null | |
453 terminated when traveling from host to client. The FLAP Header is binary | |
454 data, and is in network byte order. The data portion is at offset 6, after the | |
455 header. The sequence number is sequential in each direction. So | |
456 packets from the server to client have one sequence number, while | |
457 the packets from the client to server have an independent | |
458 increasing number. | |
459 | |
460 FLAP Header (6 bytes) | |
461 ----------- | |
462 Offset Size Type | |
463 0 1 ASTERISK (literal ASCII '*') | |
464 1 1 Frame Type | |
465 2 2 Sequence Number | |
466 4 2 Data Length | |
467 | |
468 | |
469 Valid Frame Type Values | |
470 ----------------------- | |
471 1 SIGNON | |
472 2 DATA | |
473 3 ERROR (Not used by TOC) | |
474 4 SIGNOFF (Not used by TOC) | |
475 5 KEEP_ALIVE | |
476 | |
477 | |
478 TOC SIGNON FRAME TYPE | |
479 --------------------- | |
480 Sequence Number contains the initial sequence number used in each direction. | |
481 Data Length contains the payload length, with the payload described | |
482 below. The payload area is NOT null terminated. | |
483 | |
484 Host To Client: | |
485 4 byte FLAP version (1) | |
486 | |
487 Client To Host: | |
488 4 byte FLAP version (1) | |
489 2 byte TLV Tag (1) | |
490 2 byte Normalized User Name Length | |
491 N byte Normalized User Name (NOT null terminated) | |
492 | |
493 | |
494 TOC DATA FRAME TYPE | |
495 ------------------- | |
496 Sequence Number contains the next sequence number. | |
497 Data Length is the length of the payload, including the null termination | |
498 from client to host. | |
499 |