]>
Commit | Line | Data |
---|---|---|
212380e3 | 1 | |
2 | ||
3 | ||
4 | ||
5 | ||
6 | ||
7 | Network Working Group J. Oikarinen | |
8 | Request for Comments: 1459 D. Reed | |
9 | May 1993 | |
10 | ||
11 | ||
12 | Internet Relay Chat Protocol | |
13 | ||
14 | Status of This Memo | |
15 | ||
16 | This memo defines an Experimental Protocol for the Internet | |
17 | community. Discussion and suggestions for improvement are requested. | |
18 | Please refer to the current edition of the "IAB Official Protocol | |
19 | Standards" for the standardization state and status of this protocol. | |
20 | Distribution of this memo is unlimited. | |
21 | ||
22 | Abstract | |
23 | ||
24 | The IRC protocol was developed over the last 4 years since it was | |
25 | first implemented as a means for users on a BBS to chat amongst | |
26 | themselves. Now it supports a world-wide network of servers and | |
27 | clients, and is stringing to cope with growth. Over the past 2 years, | |
28 | the average number of users connected to the main IRC network has | |
29 | grown by a factor of 10. | |
30 | ||
31 | The IRC protocol is a text-based protocol, with the simplest client | |
32 | being any socket program capable of connecting to the server. | |
33 | ||
34 | Table of Contents | |
35 | ||
36 | 1. INTRODUCTION ............................................... 4 | |
37 | 1.1 Servers ................................................ 4 | |
38 | 1.2 Clients ................................................ 5 | |
39 | 1.2.1 Operators .......................................... 5 | |
40 | 1.3 Channels ................................................ 5 | |
41 | 1.3.1 Channel Operators .................................... 6 | |
42 | 2. THE IRC SPECIFICATION ....................................... 7 | |
43 | 2.1 Overview ................................................ 7 | |
44 | 2.2 Character codes ......................................... 7 | |
45 | 2.3 Messages ................................................ 7 | |
46 | 2.3.1 Message format in 'pseudo' BNF .................... 8 | |
47 | 2.4 Numeric replies ......................................... 10 | |
48 | 3. IRC Concepts ................................................ 10 | |
49 | 3.1 One-to-one communication ................................ 10 | |
50 | 3.2 One-to-many ............................................. 11 | |
51 | 3.2.1 To a list .......................................... 11 | |
52 | 3.2.2 To a group (channel) ............................... 11 | |
53 | 3.2.3 To a host/server mask .............................. 12 | |
54 | 3.3 One to all .............................................. 12 | |
55 | ||
56 | ||
57 | ||
58 | Oikarinen & Reed [Page 1] | |
59 | \f | |
60 | RFC 1459 Internet Relay Chat Protocol May 1993 | |
61 | ||
62 | ||
63 | 3.3.1 Client to Client ................................... 12 | |
64 | 3.3.2 Clients to Server .................................. 12 | |
65 | 3.3.3 Server to Server ................................... 12 | |
66 | 4. MESSAGE DETAILS ............................................. 13 | |
67 | 4.1 Connection Registration ................................. 13 | |
68 | 4.1.1 Password message ................................... 14 | |
69 | 4.1.2 Nickname message ................................... 14 | |
70 | 4.1.3 User message ....................................... 15 | |
71 | 4.1.4 Server message ..................................... 16 | |
72 | 4.1.5 Operator message ................................... 17 | |
73 | 4.1.6 Quit message ....................................... 17 | |
74 | 4.1.7 Server Quit message ................................ 18 | |
75 | 4.2 Channel operations ...................................... 19 | |
76 | 4.2.1 Join message ....................................... 19 | |
77 | 4.2.2 Part message ....................................... 20 | |
78 | 4.2.3 Mode message ....................................... 21 | |
79 | 4.2.3.1 Channel modes ................................. 21 | |
80 | 4.2.3.2 User modes .................................... 22 | |
81 | 4.2.4 Topic message ...................................... 23 | |
82 | 4.2.5 Names message ...................................... 24 | |
83 | 4.2.6 List message ....................................... 24 | |
84 | 4.2.7 Invite message ..................................... 25 | |
85 | 4.2.8 Kick message ....................................... 25 | |
86 | 4.3 Server queries and commands ............................. 26 | |
87 | 4.3.1 Version message .................................... 26 | |
88 | 4.3.2 Stats message ...................................... 27 | |
89 | 4.3.3 Links message ...................................... 28 | |
90 | 4.3.4 Time message ....................................... 29 | |
91 | 4.3.5 Connect message .................................... 29 | |
92 | 4.3.6 Trace message ...................................... 30 | |
93 | 4.3.7 Admin message ...................................... 31 | |
94 | 4.3.8 Info message ....................................... 31 | |
95 | 4.4 Sending messages ........................................ 32 | |
96 | 4.4.1 Private messages ................................... 32 | |
97 | 4.4.2 Notice messages .................................... 33 | |
98 | 4.5 User-based queries ...................................... 33 | |
99 | 4.5.1 Who query .......................................... 33 | |
100 | 4.5.2 Whois query ........................................ 34 | |
101 | 4.5.3 Whowas message ..................................... 35 | |
102 | 4.6 Miscellaneous messages .................................. 35 | |
103 | 4.6.1 Kill message ....................................... 36 | |
104 | 4.6.2 Ping message ....................................... 37 | |
105 | 4.6.3 Pong message ....................................... 37 | |
106 | 4.6.4 Error message ...................................... 38 | |
107 | 5. OPTIONAL MESSAGES ........................................... 38 | |
108 | 5.1 Away message ............................................ 38 | |
109 | 5.2 Rehash command .......................................... 39 | |
110 | 5.3 Restart command ......................................... 39 | |
111 | ||
112 | ||
113 | ||
114 | Oikarinen & Reed [Page 2] | |
115 | \f | |
116 | RFC 1459 Internet Relay Chat Protocol May 1993 | |
117 | ||
118 | ||
119 | 5.4 Summon message .......................................... 40 | |
120 | 5.5 Users message ........................................... 40 | |
121 | 5.6 Operwall command ........................................ 41 | |
122 | 5.7 Userhost message ........................................ 42 | |
123 | 5.8 Ison message ............................................ 42 | |
124 | 6. REPLIES ..................................................... 43 | |
125 | 6.1 Error Replies ........................................... 43 | |
126 | 6.2 Command responses ....................................... 48 | |
127 | 6.3 Reserved numerics ....................................... 56 | |
128 | 7. Client and server authentication ............................ 56 | |
129 | 8. Current Implementations Details ............................. 56 | |
130 | 8.1 Network protocol: TCP ................................... 57 | |
131 | 8.1.1 Support of Unix sockets ............................ 57 | |
132 | 8.2 Command Parsing ......................................... 57 | |
133 | 8.3 Message delivery ........................................ 57 | |
134 | 8.4 Connection 'Liveness' ................................... 58 | |
135 | 8.5 Establishing a server-client connection ................. 58 | |
136 | 8.6 Establishing a server-server connection ................. 58 | |
137 | 8.6.1 State information exchange when connecting ......... 59 | |
138 | 8.7 Terminating server-client connections ................... 59 | |
139 | 8.8 Terminating server-server connections ................... 59 | |
140 | 8.9 Tracking nickname changes ............................... 60 | |
141 | 8.10 Flood control of clients ............................... 60 | |
142 | 8.11 Non-blocking lookups ................................... 61 | |
143 | 8.11.1 Hostname (DNS) lookups ............................ 61 | |
144 | 8.11.2 Username (Ident) lookups .......................... 61 | |
145 | 8.12 Configuration file ..................................... 61 | |
146 | 8.12.1 Allowing clients to connect ....................... 62 | |
147 | 8.12.2 Operators ......................................... 62 | |
148 | 8.12.3 Allowing servers to connect ....................... 62 | |
149 | 8.12.4 Administrivia ..................................... 63 | |
150 | 8.13 Channel membership ..................................... 63 | |
151 | 9. Current problems ............................................ 63 | |
152 | 9.1 Scalability ............................................. 63 | |
153 | 9.2 Labels .................................................. 63 | |
154 | 9.2.1 Nicknames .......................................... 63 | |
155 | 9.2.2 Channels ........................................... 64 | |
156 | 9.2.3 Servers ............................................ 64 | |
157 | 9.3 Algorithms .............................................. 64 | |
158 | 10. Support and availability ................................... 64 | |
159 | 11. Security Considerations .................................... 65 | |
160 | 12. Authors' Addresses ......................................... 65 | |
161 | ||
162 | ||
163 | ||
164 | ||
165 | ||
166 | ||
167 | ||
168 | ||
169 | ||
170 | Oikarinen & Reed [Page 3] | |
171 | \f | |
172 | RFC 1459 Internet Relay Chat Protocol May 1993 | |
173 | ||
174 | ||
175 | 1. INTRODUCTION | |
176 | ||
177 | The IRC (Internet Relay Chat) protocol has been designed over a | |
178 | number of years for use with text based conferencing. This document | |
179 | describes the current IRC protocol. | |
180 | ||
181 | The IRC protocol has been developed on systems using the TCP/IP | |
182 | network protocol, although there is no requirement that this remain | |
183 | the only sphere in which it operates. | |
184 | ||
185 | IRC itself is a teleconferencing system, which (through the use of | |
186 | the client-server model) is well-suited to running on many machines | |
187 | in a distributed fashion. A typical setup involves a single process | |
188 | (the server) forming a central point for clients (or other servers) | |
189 | to connect to, performing the required message delivery/multiplexing | |
190 | and other functions. | |
191 | ||
192 | 1.1 Servers | |
193 | ||
194 | The server forms the backbone of IRC, providing a point to which | |
195 | clients may connect to to talk to each other, and a point for other | |
196 | servers to connect to, forming an IRC network. The only network | |
197 | configuration allowed for IRC servers is that of a spanning tree [see | |
198 | Fig. 1] where each server acts as a central node for the rest of the | |
199 | net it sees. | |
200 | ||
201 | ||
202 | [ Server 15 ] [ Server 13 ] [ Server 14] | |
203 | / \ / | |
204 | / \ / | |
205 | [ Server 11 ] ------ [ Server 1 ] [ Server 12] | |
206 | / \ / | |
207 | / \ / | |
208 | [ Server 2 ] [ Server 3 ] | |
209 | / \ \ | |
210 | / \ \ | |
211 | [ Server 4 ] [ Server 5 ] [ Server 6 ] | |
212 | / | \ / | |
213 | / | \ / | |
214 | / | \____ / | |
215 | / | \ / | |
216 | [ Server 7 ] [ Server 8 ] [ Server 9 ] [ Server 10 ] | |
217 | ||
218 | : | |
219 | [ etc. ] | |
220 | : | |
221 | ||
222 | [ Fig. 1. Format of IRC server network ] | |
223 | ||
224 | ||
225 | ||
226 | Oikarinen & Reed [Page 4] | |
227 | \f | |
228 | RFC 1459 Internet Relay Chat Protocol May 1993 | |
229 | ||
230 | ||
231 | 1.2 Clients | |
232 | ||
233 | A client is anything connecting to a server that is not another | |
234 | server. Each client is distinguished from other clients by a unique | |
235 | nickname having a maximum length of nine (9) characters. See the | |
236 | protocol grammar rules for what may and may not be used in a | |
237 | nickname. In addition to the nickname, all servers must have the | |
238 | following information about all clients: the real name of the host | |
239 | that the client is running on, the username of the client on that | |
240 | host, and the server to which the client is connected. | |
241 | ||
242 | 1.2.1 Operators | |
243 | ||
244 | To allow a reasonable amount of order to be kept within the IRC | |
245 | network, a special class of clients (operators) is allowed to perform | |
246 | general maintenance functions on the network. Although the powers | |
247 | granted to an operator can be considered as 'dangerous', they are | |
248 | nonetheless required. Operators should be able to perform basic | |
249 | network tasks such as disconnecting and reconnecting servers as | |
250 | needed to prevent long-term use of bad network routing. In | |
251 | recognition of this need, the protocol discussed herein provides for | |
252 | operators only to be able to perform such functions. See sections | |
253 | 4.1.7 (SQUIT) and 4.3.5 (CONNECT). | |
254 | ||
255 | A more controversial power of operators is the ability to remove a | |
256 | user from the connected network by 'force', i.e. operators are able | |
257 | to close the connection between any client and server. The | |
258 | justification for this is delicate since its abuse is both | |
259 | destructive and annoying. For further details on this type of | |
260 | action, see section 4.6.1 (KILL). | |
261 | ||
262 | 1.3 Channels | |
263 | ||
264 | A channel is a named group of one or more clients which will all | |
265 | receive messages addressed to that channel. The channel is created | |
266 | implicitly when the first client joins it, and the channel ceases to | |
267 | exist when the last client leaves it. While channel exists, any | |
268 | client can reference the channel using the name of the channel. | |
269 | ||
270 | Channels names are strings (beginning with a '&' or '#' character) of | |
271 | length up to 200 characters. Apart from the the requirement that the | |
272 | first character being either '&' or '#'; the only restriction on a | |
273 | channel name is that it may not contain any spaces (' '), a control G | |
274 | (^G or ASCII 7), or a comma (',' which is used as a list item | |
275 | separator by the protocol). | |
276 | ||
277 | There are two types of channels allowed by this protocol. One is a | |
278 | distributed channel which is known to all the servers that are | |
279 | ||
280 | ||
281 | ||
282 | Oikarinen & Reed [Page 5] | |
283 | \f | |
284 | RFC 1459 Internet Relay Chat Protocol May 1993 | |
285 | ||
286 | ||
287 | connected to the network. These channels are marked by the first | |
288 | character being a only clients on the server where it exists may join | |
289 | it. These are distinguished by a leading '&' character. On top of | |
290 | these two types, there are the various channel modes available to | |
291 | alter the characteristics of individual channels. See section 4.2.3 | |
292 | (MODE command) for more details on this. | |
293 | ||
294 | To create a new channel or become part of an existing channel, a user | |
295 | is required to JOIN the channel. If the channel doesn't exist prior | |
296 | to joining, the channel is created and the creating user becomes a | |
297 | channel operator. If the channel already exists, whether or not your | |
298 | request to JOIN that channel is honoured depends on the current modes | |
299 | of the channel. For example, if the channel is invite-only, (+i), | |
300 | then you may only join if invited. As part of the protocol, a user | |
301 | may be a part of several channels at once, but a limit of ten (10) | |
302 | channels is recommended as being ample for both experienced and | |
303 | novice users. See section 8.13 for more information on this. | |
304 | ||
305 | If the IRC network becomes disjoint because of a split between two | |
306 | servers, the channel on each side is only composed of those clients | |
307 | which are connected to servers on the respective sides of the split, | |
308 | possibly ceasing to exist on one side of the split. When the split | |
309 | is healed, the connecting servers announce to each other who they | |
310 | think is in each channel and the mode of that channel. If the | |
311 | channel exists on both sides, the JOINs and MODEs are interpreted in | |
312 | an inclusive manner so that both sides of the new connection will | |
313 | agree about which clients are in the channel and what modes the | |
314 | channel has. | |
315 | ||
316 | 1.3.1 Channel Operators | |
317 | ||
318 | The channel operator (also referred to as a "chop" or "chanop") on a | |
319 | given channel is considered to 'own' that channel. In recognition of | |
320 | this status, channel operators are endowed with certain powers which | |
321 | enable them to keep control and some sort of sanity in their channel. | |
322 | As an owner of a channel, a channel operator is not required to have | |
323 | reasons for their actions, although if their actions are generally | |
324 | antisocial or otherwise abusive, it might be reasonable to ask an IRC | |
325 | operator to intervene, or for the usersjust leave and go elsewhere | |
326 | and form their own channel. | |
327 | ||
328 | The commands which may only be used by channel operators are: | |
329 | ||
330 | KICK - Eject a client from the channel | |
331 | MODE - Change the channel's mode | |
332 | INVITE - Invite a client to an invite-only channel (mode +i) | |
333 | TOPIC - Change the channel topic in a mode +t channel | |
334 | ||
335 | ||
336 | ||
337 | ||
338 | Oikarinen & Reed [Page 6] | |
339 | \f | |
340 | RFC 1459 Internet Relay Chat Protocol May 1993 | |
341 | ||
342 | ||
343 | A channel operator is identified by the '@' symbol next to their | |
344 | nickname whenever it is associated with a channel (ie replies to the | |
345 | NAMES, WHO and WHOIS commands). | |
346 | ||
347 | 2. The IRC Specification | |
348 | ||
349 | 2.1 Overview | |
350 | ||
351 | The protocol as described herein is for use both with server to | |
352 | server and client to server connections. There are, however, more | |
353 | restrictions on client connections (which are considered to be | |
354 | untrustworthy) than on server connections. | |
355 | ||
356 | 2.2 Character codes | |
357 | ||
358 | No specific character set is specified. The protocol is based on a a | |
359 | set of codes which are composed of eight (8) bits, making up an | |
360 | octet. Each message may be composed of any number of these octets; | |
361 | however, some octet values are used for control codes which act as | |
362 | message delimiters. | |
363 | ||
364 | Regardless of being an 8-bit protocol, the delimiters and keywords | |
365 | are such that protocol is mostly usable from USASCII terminal and a | |
366 | telnet connection. | |
367 | ||
368 | Because of IRC's scandanavian origin, the characters {}| are | |
369 | considered to be the lower case equivalents of the characters []\, | |
370 | respectively. This is a critical issue when determining the | |
371 | equivalence of two nicknames. | |
372 | ||
373 | 2.3 Messages | |
374 | ||
375 | Servers and clients send eachother messages which may or may not | |
376 | generate a reply. If the message contains a valid command, as | |
377 | described in later sections, the client should expect a reply as | |
378 | specified but it is not advised to wait forever for the reply; client | |
379 | to server and server to server communication is essentially | |
380 | asynchronous in nature. | |
381 | ||
382 | Each IRC message may consist of up to three main parts: the prefix | |
383 | (optional), the command, and the command parameters (of which there | |
384 | may be up to 15). The prefix, command, and all parameters are | |
385 | separated by one (or more) ASCII space character(s) (0x20). | |
386 | ||
387 | The presence of a prefix is indicated with a single leading ASCII | |
388 | colon character (':', 0x3b), which must be the first character of the | |
389 | message itself. There must be no gap (whitespace) between the colon | |
390 | and the prefix. The prefix is used by servers to indicate the true | |
391 | ||
392 | ||
393 | ||
394 | Oikarinen & Reed [Page 7] | |
395 | \f | |
396 | RFC 1459 Internet Relay Chat Protocol May 1993 | |
397 | ||
398 | ||
399 | origin of the message. If the prefix is missing from the message, it | |
400 | is assumed to have originated from the connection from which it was | |
401 | received. Clients should not use prefix when sending a message from | |
402 | themselves; if they use a prefix, the only valid prefix is the | |
403 | registered nickname associated with the client. If the source | |
404 | identified by the prefix cannot be found from the server's internal | |
405 | database, or if the source is registered from a different link than | |
406 | from which the message arrived, the server must ignore the message | |
407 | silently. | |
408 | ||
409 | The command must either be a valid IRC command or a three (3) digit | |
410 | number represented in ASCII text. | |
411 | ||
412 | IRC messages are always lines of characters terminated with a CR-LF | |
413 | (Carriage Return - Line Feed) pair, and these messages shall not | |
414 | exceed 512 characters in length, counting all characters including | |
415 | the trailing CR-LF. Thus, there are 510 characters maximum allowed | |
416 | for the command and its parameters. There is no provision for | |
417 | continuation message lines. See section 7 for more details about | |
418 | current implementations. | |
419 | ||
420 | 2.3.1 Message format in 'pseudo' BNF | |
421 | ||
422 | The protocol messages must be extracted from the contiguous stream of | |
423 | octets. The current solution is to designate two characters, CR and | |
424 | LF, as message separators. Empty messages are silently ignored, | |
425 | which permits use of the sequence CR-LF between messages | |
426 | without extra problems. | |
427 | ||
428 | The extracted message is parsed into the components <prefix>, | |
429 | <command> and list of parameters matched either by <middle> or | |
430 | <trailing> components. | |
431 | ||
432 | The BNF representation for this is: | |
433 | ||
434 | ||
435 | <message> ::= [':' <prefix> <SPACE> ] <command> <params> <crlf> | |
436 | <prefix> ::= <servername> | <nick> [ '!' <user> ] [ '@' <host> ] | |
437 | <command> ::= <letter> { <letter> } | <number> <number> <number> | |
438 | <SPACE> ::= ' ' { ' ' } | |
439 | <params> ::= <SPACE> [ ':' <trailing> | <middle> <params> ] | |
440 | ||
441 | <middle> ::= <Any *non-empty* sequence of octets not including SPACE | |
442 | or NUL or CR or LF, the first of which may not be ':'> | |
443 | <trailing> ::= <Any, possibly *empty*, sequence of octets not including | |
444 | NUL or CR or LF> | |
445 | ||
446 | <crlf> ::= CR LF | |
447 | ||
448 | ||
449 | ||
450 | Oikarinen & Reed [Page 8] | |
451 | \f | |
452 | RFC 1459 Internet Relay Chat Protocol May 1993 | |
453 | ||
454 | ||
455 | NOTES: | |
456 | ||
457 | 1) <SPACE> is consists only of SPACE character(s) (0x20). | |
458 | Specially notice that TABULATION, and all other control | |
459 | characters are considered NON-WHITE-SPACE. | |
460 | ||
461 | 2) After extracting the parameter list, all parameters are equal, | |
462 | whether matched by <middle> or <trailing>. <Trailing> is just | |
463 | a syntactic trick to allow SPACE within parameter. | |
464 | ||
465 | 3) The fact that CR and LF cannot appear in parameter strings is | |
466 | just artifact of the message framing. This might change later. | |
467 | ||
468 | 4) The NUL character is not special in message framing, and | |
469 | basically could end up inside a parameter, but as it would | |
470 | cause extra complexities in normal C string handling. Therefore | |
471 | NUL is not allowed within messages. | |
472 | ||
473 | 5) The last parameter may be an empty string. | |
474 | ||
475 | 6) Use of the extended prefix (['!' <user> ] ['@' <host> ]) must | |
476 | not be used in server to server communications and is only | |
477 | intended for server to client messages in order to provide | |
478 | clients with more useful information about who a message is | |
479 | from without the need for additional queries. | |
480 | ||
481 | Most protocol messages specify additional semantics and syntax for | |
482 | the extracted parameter strings dictated by their position in the | |
483 | list. For example, many server commands will assume that the first | |
484 | parameter after the command is the list of targets, which can be | |
485 | described with: | |
486 | ||
487 | <target> ::= <to> [ "," <target> ] | |
488 | <to> ::= <channel> | <user> '@' <servername> | <nick> | <mask> | |
489 | <channel> ::= ('#' | '&') <chstring> | |
490 | <servername> ::= <host> | |
491 | <host> ::= see RFC 952 [DNS:4] for details on allowed hostnames | |
492 | <nick> ::= <letter> { <letter> | <number> | <special> } | |
493 | <mask> ::= ('#' | '$') <chstring> | |
494 | <chstring> ::= <any 8bit code except SPACE, BELL, NUL, CR, LF and | |
495 | comma (',')> | |
496 | ||
497 | Other parameter syntaxes are: | |
498 | ||
499 | <user> ::= <nonwhite> { <nonwhite> } | |
500 | <letter> ::= 'a' ... 'z' | 'A' ... 'Z' | |
501 | <number> ::= '0' ... '9' | |
502 | <special> ::= '-' | '[' | ']' | '\' | '`' | '^' | '{' | '}' | |
503 | ||
504 | ||
505 | ||
506 | Oikarinen & Reed [Page 9] | |
507 | \f | |
508 | RFC 1459 Internet Relay Chat Protocol May 1993 | |
509 | ||
510 | ||
511 | <nonwhite> ::= <any 8bit code except SPACE (0x20), NUL (0x0), CR | |
512 | (0xd), and LF (0xa)> | |
513 | ||
514 | 2.4 Numeric replies | |
515 | ||
516 | Most of the messages sent to the server generate a reply of some | |
517 | sort. The most common reply is the numeric reply, used for both | |
518 | errors and normal replies. The numeric reply must be sent as one | |
519 | message consisting of the sender prefix, the three digit numeric, and | |
520 | the target of the reply. A numeric reply is not allowed to originate | |
521 | from a client; any such messages received by a server are silently | |
522 | dropped. In all other respects, a numeric reply is just like a normal | |
523 | message, except that the keyword is made up of 3 numeric digits | |
524 | rather than a string of letters. A list of different replies is | |
525 | supplied in section 6. | |
526 | ||
527 | 3. IRC Concepts. | |
528 | ||
529 | This section is devoted to describing the actual concepts behind the | |
530 | organization of the IRC protocol and how the current | |
531 | implementations deliver different classes of messages. | |
532 | ||
533 | ||
534 | ||
535 | 1--\ | |
536 | A D---4 | |
537 | 2--/ \ / | |
538 | B----C | |
539 | / \ | |
540 | 3 E | |
541 | ||
542 | Servers: A, B, C, D, E Clients: 1, 2, 3, 4 | |
543 | ||
544 | [ Fig. 2. Sample small IRC network ] | |
545 | ||
546 | 3.1 One-to-one communication | |
547 | ||
548 | Communication on a one-to-one basis is usually only performed by | |
549 | clients, since most server-server traffic is not a result of servers | |
550 | talking only to each other. To provide a secure means for clients to | |
551 | talk to each other, it is required that all servers be able to send a | |
552 | message in exactly one direction along the spanning tree in order to | |
553 | reach any client. The path of a message being delivered is the | |
554 | shortest path between any two points on the spanning tree. | |
555 | ||
556 | The following examples all refer to Figure 2 above. | |
557 | ||
558 | ||
559 | ||
560 | ||
561 | ||
562 | Oikarinen & Reed [Page 10] | |
563 | \f | |
564 | RFC 1459 Internet Relay Chat Protocol May 1993 | |
565 | ||
566 | ||
567 | Example 1: | |
568 | A message between clients 1 and 2 is only seen by server A, which | |
569 | sends it straight to client 2. | |
570 | ||
571 | Example 2: | |
572 | A message between clients 1 and 3 is seen by servers A & B, and | |
573 | client 3. No other clients or servers are allowed see the message. | |
574 | ||
575 | Example 3: | |
576 | A message between clients 2 and 4 is seen by servers A, B, C & D | |
577 | and client 4 only. | |
578 | ||
579 | 3.2 One-to-many | |
580 | ||
581 | The main goal of IRC is to provide a forum which allows easy and | |
582 | efficient conferencing (one to many conversations). IRC offers | |
583 | several means to achieve this, each serving its own purpose. | |
584 | ||
585 | 3.2.1 To a list | |
586 | ||
587 | The least efficient style of one-to-many conversation is through | |
588 | clients talking to a 'list' of users. How this is done is almost | |
589 | self explanatory: the client gives a list of destinations to which | |
590 | the message is to be delivered and the server breaks it up and | |
591 | dispatches a separate copy of the message to each given destination. | |
592 | This isn't as efficient as using a group since the destination list | |
593 | is broken up and the dispatch sent without checking to make sure | |
594 | duplicates aren't sent down each path. | |
595 | ||
596 | 3.2.2 To a group (channel) | |
597 | ||
598 | In IRC the channel has a role equivalent to that of the multicast | |
599 | group; their existence is dynamic (coming and going as people join | |
600 | and leave channels) and the actual conversation carried out on a | |
601 | channel is only sent to servers which are supporting users on a given | |
602 | channel. If there are multiple users on a server in the same | |
603 | channel, the message text is sent only once to that server and then | |
604 | sent to each client on the channel. This action is then repeated for | |
605 | each client-server combination until the original message has fanned | |
606 | out and reached each member of the channel. | |
607 | ||
608 | The following examples all refer to Figure 2. | |
609 | ||
610 | Example 4: | |
611 | Any channel with 1 client in it. Messages to the channel go to the | |
612 | server and then nowhere else. | |
613 | ||
614 | ||
615 | ||
616 | ||
617 | ||
618 | Oikarinen & Reed [Page 11] | |
619 | \f | |
620 | RFC 1459 Internet Relay Chat Protocol May 1993 | |
621 | ||
622 | ||
623 | Example 5: | |
624 | 2 clients in a channel. All messages traverse a path as if they | |
625 | were private messages between the two clients outside a channel. | |
626 | ||
627 | Example 6: | |
628 | Clients 1, 2 and 3 in a channel. All messages to the channel are | |
629 | sent to all clients and only those servers which must be traversed | |
630 | by the message if it were a private message to a single client. If | |
631 | client 1 sends a message, it goes back to client 2 and then via | |
632 | server B to client 3. | |
633 | ||
634 | 3.2.3 To a host/server mask | |
635 | ||
636 | To provide IRC operators with some mechanism to send messages to a | |
637 | large body of related users, host and server mask messages are | |
638 | provided. These messages are sent to users whose host or server | |
639 | information match that of the mask. The messages are only sent to | |
640 | locations where users are, in a fashion similar to that of channels. | |
641 | ||
642 | 3.3 One-to-all | |
643 | ||
644 | The one-to-all type of message is better described as a broadcast | |
645 | message, sent to all clients or servers or both. On a large network | |
646 | of users and servers, a single message can result in a lot of traffic | |
647 | being sent over the network in an effort to reach all of the desired | |
648 | destinations. | |
649 | ||
650 | For some messages, there is no option but to broadcast it to all | |
651 | servers so that the state information held by each server is | |
652 | reasonably consistent between servers. | |
653 | ||
654 | 3.3.1 Client-to-Client | |
655 | ||
656 | There is no class of message which, from a single message, results in | |
657 | a message being sent to every other client. | |
658 | ||
659 | 3.3.2 Client-to-Server | |
660 | ||
661 | Most of the commands which result in a change of state information | |
662 | (such as channel membership, channel mode, user status, etc) must be | |
663 | sent to all servers by default, and this distribution may not be | |
664 | changed by the client. | |
665 | ||
666 | 3.3.3 Server-to-Server. | |
667 | ||
668 | While most messages between servers are distributed to all 'other' | |
669 | servers, this is only required for any message that affects either a | |
670 | user, channel or server. Since these are the basic items found in | |
671 | ||
672 | ||
673 | ||
674 | Oikarinen & Reed [Page 12] | |
675 | \f | |
676 | RFC 1459 Internet Relay Chat Protocol May 1993 | |
677 | ||
678 | ||
679 | IRC, nearly all messages originating from a server are broadcast to | |
680 | all other connected servers. | |
681 | ||
682 | 4. Message details | |
683 | ||
684 | On the following pages are descriptions of each message recognized by | |
685 | the IRC server and client. All commands described in this section | |
686 | must be implemented by any server for this protocol. | |
687 | ||
688 | Where the reply ERR_NOSUCHSERVER is listed, it means that the | |
689 | <server> parameter could not be found. The server must not send any | |
690 | other replies after this for that command. | |
691 | ||
692 | The server to which a client is connected is required to parse the | |
693 | complete message, returning any appropriate errors. If the server | |
694 | encounters a fatal error while parsing a message, an error must be | |
695 | sent back to the client and the parsing terminated. A fatal error | |
696 | may be considered to be incorrect command, a destination which is | |
697 | otherwise unknown to the server (server, nick or channel names fit | |
698 | this category), not enough parameters or incorrect privileges. | |
699 | ||
700 | If a full set of parameters is presented, then each must be checked | |
701 | for validity and appropriate responses sent back to the client. In | |
702 | the case of messages which use parameter lists using the comma as an | |
703 | item separator, a reply must be sent for each item. | |
704 | ||
705 | In the examples below, some messages appear using the full format: | |
706 | ||
707 | :Name COMMAND parameter list | |
708 | ||
709 | Such examples represent a message from "Name" in transit between | |
710 | servers, where it is essential to include the name of the original | |
711 | sender of the message so remote servers may send back a reply along | |
712 | the correct path. | |
713 | ||
714 | 4.1 Connection Registration | |
715 | ||
716 | The commands described here are used to register a connection with an | |
717 | IRC server as either a user or a server as well as correctly | |
718 | disconnect. | |
719 | ||
720 | A "PASS" command is not required for either client or server | |
721 | connection to be registered, but it must precede the server message | |
722 | or the latter of the NICK/USER combination. It is strongly | |
723 | recommended that all server connections have a password in order to | |
724 | give some level of security to the actual connections. The | |
725 | recommended order for a client to register is as follows: | |
726 | ||
727 | ||
728 | ||
729 | ||
730 | Oikarinen & Reed [Page 13] | |
731 | \f | |
732 | RFC 1459 Internet Relay Chat Protocol May 1993 | |
733 | ||
734 | ||
735 | 1. Pass message | |
736 | 2. Nick message | |
737 | 3. User message | |
738 | ||
739 | 4.1.1 Password message | |
740 | ||
741 | ||
742 | Command: PASS | |
743 | Parameters: <password> | |
744 | ||
745 | The PASS command is used to set a 'connection password'. The | |
746 | password can and must be set before any attempt to register the | |
747 | connection is made. Currently this requires that clients send a PASS | |
748 | command before sending the NICK/USER combination and servers *must* | |
749 | send a PASS command before any SERVER command. The password supplied | |
750 | must match the one contained in the C/N lines (for servers) or I | |
751 | lines (for clients). It is possible to send multiple PASS commands | |
752 | before registering but only the last one sent is used for | |
753 | verification and it may not be changed once registered. Numeric | |
754 | Replies: | |
755 | ||
756 | ERR_NEEDMOREPARAMS ERR_ALREADYREGISTRED | |
757 | ||
758 | Example: | |
759 | ||
760 | PASS secretpasswordhere | |
761 | ||
762 | 4.1.2 Nick message | |
763 | ||
764 | Command: NICK | |
765 | Parameters: <nickname> [ <hopcount> ] | |
766 | ||
767 | NICK message is used to give user a nickname or change the previous | |
768 | one. The <hopcount> parameter is only used by servers to indicate | |
769 | how far away a nick is from its home server. A local connection has | |
770 | a hopcount of 0. If supplied by a client, it must be ignored. | |
771 | ||
772 | If a NICK message arrives at a server which already knows about an | |
773 | identical nickname for another client, a nickname collision occurs. | |
774 | As a result of a nickname collision, all instances of the nickname | |
775 | are removed from the server's database, and a KILL command is issued | |
776 | to remove the nickname from all other server's database. If the NICK | |
777 | message causing the collision was a nickname change, then the | |
778 | original (old) nick must be removed as well. | |
779 | ||
780 | If the server recieves an identical NICK from a client which is | |
781 | directly connected, it may issue an ERR_NICKCOLLISION to the local | |
782 | client, drop the NICK command, and not generate any kills. | |
783 | ||
784 | ||
785 | ||
786 | Oikarinen & Reed [Page 14] | |
787 | \f | |
788 | RFC 1459 Internet Relay Chat Protocol May 1993 | |
789 | ||
790 | ||
791 | Numeric Replies: | |
792 | ||
793 | ERR_NONICKNAMEGIVEN ERR_ERRONEUSNICKNAME | |
794 | ERR_NICKNAMEINUSE ERR_NICKCOLLISION | |
795 | ||
796 | Example: | |
797 | ||
798 | NICK Wiz ; Introducing new nick "Wiz". | |
799 | ||
800 | :WiZ NICK Kilroy ; WiZ changed his nickname to Kilroy. | |
801 | ||
802 | 4.1.3 User message | |
803 | ||
804 | Command: USER | |
805 | Parameters: <username> <hostname> <servername> <realname> | |
806 | ||
807 | The USER message is used at the beginning of connection to specify | |
808 | the username, hostname, servername and realname of s new user. It is | |
809 | also used in communication between servers to indicate new user | |
810 | arriving on IRC, since only after both USER and NICK have been | |
811 | received from a client does a user become registered. | |
812 | ||
813 | Between servers USER must to be prefixed with client's NICKname. | |
814 | Note that hostname and servername are normally ignored by the IRC | |
815 | server when the USER command comes from a directly connected client | |
816 | (for security reasons), but they are used in server to server | |
817 | communication. This means that a NICK must always be sent to a | |
818 | remote server when a new user is being introduced to the rest of the | |
819 | network before the accompanying USER is sent. | |
820 | ||
821 | It must be noted that realname parameter must be the last parameter, | |
822 | because it may contain space characters and must be prefixed with a | |
823 | colon (':') to make sure this is recognised as such. | |
824 | ||
825 | Since it is easy for a client to lie about its username by relying | |
826 | solely on the USER message, the use of an "Identity Server" is | |
827 | recommended. If the host which a user connects from has such a | |
828 | server enabled the username is set to that as in the reply from the | |
829 | "Identity Server". | |
830 | ||
831 | Numeric Replies: | |
832 | ||
833 | ERR_NEEDMOREPARAMS ERR_ALREADYREGISTRED | |
834 | ||
835 | Examples: | |
836 | ||
837 | ||
838 | USER guest tolmoon tolsun :Ronnie Reagan | |
839 | ||
840 | ||
841 | ||
842 | Oikarinen & Reed [Page 15] | |
843 | \f | |
844 | RFC 1459 Internet Relay Chat Protocol May 1993 | |
845 | ||
846 | ||
847 | ; User registering themselves with a | |
848 | username of "guest" and real name | |
849 | "Ronnie Reagan". | |
850 | ||
851 | ||
852 | :testnick USER guest tolmoon tolsun :Ronnie Reagan | |
853 | ; message between servers with the | |
854 | nickname for which the USER command | |
855 | belongs to | |
856 | ||
857 | 4.1.4 Server message | |
858 | ||
859 | Command: SERVER | |
860 | Parameters: <servername> <hopcount> <info> | |
861 | ||
862 | The server message is used to tell a server that the other end of a | |
863 | new connection is a server. This message is also used to pass server | |
864 | data over whole net. When a new server is connected to net, | |
865 | information about it be broadcast to the whole network. <hopcount> | |
866 | is used to give all servers some internal information on how far away | |
867 | all servers are. With a full server list, it would be possible to | |
868 | construct a map of the entire server tree, but hostmasks prevent this | |
869 | from being done. | |
870 | ||
871 | The SERVER message must only be accepted from either (a) a connection | |
872 | which is yet to be registered and is attempting to register as a | |
873 | server, or (b) an existing connection to another server, in which | |
874 | case the SERVER message is introducing a new server behind that | |
875 | server. | |
876 | ||
877 | Most errors that occur with the receipt of a SERVER command result in | |
878 | the connection being terminated by the destination host (target | |
879 | SERVER). Error replies are usually sent using the "ERROR" command | |
880 | rather than the numeric since the ERROR command has several useful | |
881 | properties which make it useful here. | |
882 | ||
883 | If a SERVER message is parsed and attempts to introduce a server | |
884 | which is already known to the receiving server, the connection from | |
885 | which that message must be closed (following the correct procedures), | |
886 | since a duplicate route to a server has formed and the acyclic nature | |
887 | of the IRC tree broken. | |
888 | ||
889 | Numeric Replies: | |
890 | ||
891 | ERR_ALREADYREGISTRED | |
892 | ||
893 | Example: | |
894 | ||
895 | ||
896 | ||
897 | ||
898 | Oikarinen & Reed [Page 16] | |
899 | \f | |
900 | RFC 1459 Internet Relay Chat Protocol May 1993 | |
901 | ||
902 | ||
903 | SERVER test.oulu.fi 1 :[tolsun.oulu.fi] Experimental server | |
904 | ; New server test.oulu.fi introducing | |
905 | itself and attempting to register. The | |
906 | name in []'s is the hostname for the | |
907 | host running test.oulu.fi. | |
908 | ||
909 | ||
910 | :tolsun.oulu.fi SERVER csd.bu.edu 5 :BU Central Server | |
911 | ; Server tolsun.oulu.fi is our uplink | |
912 | for csd.bu.edu which is 5 hops away. | |
913 | ||
914 | 4.1.5 Oper | |
915 | ||
916 | Command: OPER | |
917 | Parameters: <user> <password> | |
918 | ||
919 | OPER message is used by a normal user to obtain operator privileges. | |
920 | The combination of <user> and <password> are required to gain | |
921 | Operator privileges. | |
922 | ||
923 | If the client sending the OPER command supplies the correct password | |
924 | for the given user, the server then informs the rest of the network | |
925 | of the new operator by issuing a "MODE +o" for the clients nickname. | |
926 | ||
927 | The OPER message is client-server only. | |
928 | ||
929 | Numeric Replies: | |
930 | ||
931 | ERR_NEEDMOREPARAMS RPL_YOUREOPER | |
932 | ERR_NOOPERHOST ERR_PASSWDMISMATCH | |
933 | ||
934 | Example: | |
935 | ||
936 | OPER foo bar ; Attempt to register as an operator | |
937 | using a username of "foo" and "bar" as | |
938 | the password. | |
939 | ||
940 | 4.1.6 Quit | |
941 | ||
942 | Command: QUIT | |
943 | Parameters: [<Quit message>] | |
944 | ||
945 | A client session is ended with a quit message. The server must close | |
946 | the connection to a client which sends a QUIT message. If a "Quit | |
947 | Message" is given, this will be sent instead of the default message, | |
948 | the nickname. | |
949 | ||
950 | When netsplits (disconnecting of two servers) occur, the quit message | |
951 | ||
952 | ||
953 | ||
954 | Oikarinen & Reed [Page 17] | |
955 | \f | |
956 | RFC 1459 Internet Relay Chat Protocol May 1993 | |
957 | ||
958 | ||
959 | is composed of the names of two servers involved, separated by a | |
960 | space. The first name is that of the server which is still connected | |
961 | and the second name is that of the server that has become | |
962 | disconnected. | |
963 | ||
964 | If, for some other reason, a client connection is closed without the | |
965 | client issuing a QUIT command (e.g. client dies and EOF occurs | |
966 | on socket), the server is required to fill in the quit message with | |
967 | some sort of message reflecting the nature of the event which | |
968 | caused it to happen. | |
969 | ||
970 | Numeric Replies: | |
971 | ||
972 | None. | |
973 | ||
974 | Examples: | |
975 | ||
976 | QUIT :Gone to have lunch ; Preferred message format. | |
977 | ||
978 | 4.1.7 Server quit message | |
979 | ||
980 | Command: SQUIT | |
981 | Parameters: <server> <comment> | |
982 | ||
983 | The SQUIT message is needed to tell about quitting or dead servers. | |
984 | If a server wishes to break the connection to another server it must | |
985 | send a SQUIT message to the other server, using the the name of the | |
986 | other server as the server parameter, which then closes its | |
987 | connection to the quitting server. | |
988 | ||
989 | This command is also available operators to help keep a network of | |
990 | IRC servers connected in an orderly fashion. Operators may also | |
991 | issue an SQUIT message for a remote server connection. In this case, | |
992 | the SQUIT must be parsed by each server inbetween the operator and | |
993 | the remote server, updating the view of the network held by each | |
994 | server as explained below. | |
995 | ||
996 | The <comment> should be supplied by all operators who execute a SQUIT | |
997 | for a remote server (that is not connected to the server they are | |
998 | currently on) so that other operators are aware for the reason of | |
999 | this action. The <comment> is also filled in by servers which may | |
1000 | place an error or similar message here. | |
1001 | ||
1002 | Both of the servers which are on either side of the connection being | |
1003 | closed are required to to send out a SQUIT message (to all its other | |
1004 | server connections) for all other servers which are considered to be | |
1005 | behind that link. | |
1006 | ||
1007 | ||
1008 | ||
1009 | ||
1010 | Oikarinen & Reed [Page 18] | |
1011 | \f | |
1012 | RFC 1459 Internet Relay Chat Protocol May 1993 | |
1013 | ||
1014 | ||
1015 | Similarly, a QUIT message must be sent to the other connected servers | |
1016 | rest of the network on behalf of all clients behind that link. In | |
1017 | addition to this, all channel members of a channel which lost a | |
1018 | member due to the split must be sent a QUIT message. | |
1019 | ||
1020 | If a server connection is terminated prematurely (e.g. the server on | |
1021 | the other end of the link died), the server which detects | |
1022 | this disconnection is required to inform the rest of the network | |
1023 | that the connection has closed and fill in the comment field | |
1024 | with something appropriate. | |
1025 | ||
1026 | Numeric replies: | |
1027 | ||
1028 | ERR_NOPRIVILEGES ERR_NOSUCHSERVER | |
1029 | ||
1030 | Example: | |
1031 | ||
1032 | SQUIT tolsun.oulu.fi :Bad Link ? ; the server link tolson.oulu.fi has | |
1033 | been terminated because of "Bad Link". | |
1034 | ||
1035 | :Trillian SQUIT cm22.eng.umd.edu :Server out of control | |
1036 | ; message from Trillian to disconnect | |
1037 | "cm22.eng.umd.edu" from the net | |
1038 | because "Server out of control". | |
1039 | ||
1040 | 4.2 Channel operations | |
1041 | ||
1042 | This group of messages is concerned with manipulating channels, their | |
1043 | properties (channel modes), and their contents (typically clients). | |
1044 | In implementing these, a number of race conditions are inevitable | |
1045 | when clients at opposing ends of a network send commands which will | |
1046 | ultimately clash. It is also required that servers keep a nickname | |
1047 | history to ensure that wherever a <nick> parameter is given, the | |
1048 | server check its history in case it has recently been changed. | |
1049 | ||
1050 | 4.2.1 Join message | |
1051 | ||
1052 | Command: JOIN | |
1053 | Parameters: <channel>{,<channel>} [<key>{,<key>}] | |
1054 | ||
1055 | The JOIN command is used by client to start listening a specific | |
1056 | channel. Whether or not a client is allowed to join a channel is | |
1057 | checked only by the server the client is connected to; all other | |
1058 | servers automatically add the user to the channel when it is received | |
1059 | from other servers. The conditions which affect this are as follows: | |
1060 | ||
1061 | 1. the user must be invited if the channel is invite-only; | |
1062 | ||
1063 | ||
1064 | ||
1065 | ||
1066 | Oikarinen & Reed [Page 19] | |
1067 | \f | |
1068 | RFC 1459 Internet Relay Chat Protocol May 1993 | |
1069 | ||
1070 | ||
1071 | 2. the user's nick/username/hostname must not match any | |
1072 | active bans; | |
1073 | ||
1074 | 3. the correct key (password) must be given if it is set. | |
1075 | ||
1076 | These are discussed in more detail under the MODE command (see | |
1077 | section 4.2.3 for more details). | |
1078 | ||
1079 | Once a user has joined a channel, they receive notice about all | |
1080 | commands their server receives which affect the channel. This | |
1081 | includes MODE, KICK, PART, QUIT and of course PRIVMSG/NOTICE. The | |
1082 | JOIN command needs to be broadcast to all servers so that each server | |
1083 | knows where to find the users who are on the channel. This allows | |
1084 | optimal delivery of PRIVMSG/NOTICE messages to the channel. | |
1085 | ||
1086 | If a JOIN is successful, the user is then sent the channel's topic | |
1087 | (using RPL_TOPIC) and the list of users who are on the channel (using | |
1088 | RPL_NAMREPLY), which must include the user joining. | |
1089 | ||
1090 | Numeric Replies: | |
1091 | ||
1092 | ERR_NEEDMOREPARAMS ERR_BANNEDFROMCHAN | |
1093 | ERR_INVITEONLYCHAN ERR_BADCHANNELKEY | |
1094 | ERR_CHANNELISFULL ERR_BADCHANMASK | |
1095 | ERR_NOSUCHCHANNEL ERR_TOOMANYCHANNELS | |
1096 | RPL_TOPIC | |
1097 | ||
1098 | Examples: | |
1099 | ||
1100 | JOIN #foobar ; join channel #foobar. | |
1101 | ||
1102 | JOIN &foo fubar ; join channel &foo using key "fubar". | |
1103 | ||
1104 | JOIN #foo,&bar fubar ; join channel #foo using key "fubar" | |
1105 | and &bar using no key. | |
1106 | ||
1107 | JOIN #foo,#bar fubar,foobar ; join channel #foo using key "fubar". | |
1108 | and channel #bar using key "foobar". | |
1109 | ||
1110 | JOIN #foo,#bar ; join channels #foo and #bar. | |
1111 | ||
1112 | :WiZ JOIN #Twilight_zone ; JOIN message from WiZ | |
1113 | ||
1114 | 4.2.2 Part message | |
1115 | ||
1116 | Command: PART | |
1117 | Parameters: <channel>{,<channel>} | |
1118 | ||
1119 | ||
1120 | ||
1121 | ||
1122 | Oikarinen & Reed [Page 20] | |
1123 | \f | |
1124 | RFC 1459 Internet Relay Chat Protocol May 1993 | |
1125 | ||
1126 | ||
1127 | The PART message causes the client sending the message to be removed | |
1128 | from the list of active users for all given channels listed in the | |
1129 | parameter string. | |
1130 | ||
1131 | Numeric Replies: | |
1132 | ||
1133 | ERR_NEEDMOREPARAMS ERR_NOSUCHCHANNEL | |
1134 | ERR_NOTONCHANNEL | |
1135 | ||
1136 | Examples: | |
1137 | ||
1138 | PART #twilight_zone ; leave channel "#twilight_zone" | |
1139 | ||
1140 | PART #oz-ops,&group5 ; leave both channels "&group5" and | |
1141 | "#oz-ops". | |
1142 | ||
1143 | 4.2.3 Mode message | |
1144 | ||
1145 | Command: MODE | |
1146 | ||
1147 | The MODE command is a dual-purpose command in IRC. It allows both | |
1148 | usernames and channels to have their mode changed. The rationale for | |
1149 | this choice is that one day nicknames will be obsolete and the | |
1150 | equivalent property will be the channel. | |
1151 | ||
1152 | When parsing MODE messages, it is recommended that the entire message | |
1153 | be parsed first and then the changes which resulted then passed on. | |
1154 | ||
1155 | 4.2.3.1 Channel modes | |
1156 | ||
1157 | Parameters: <channel> {[+|-]|o|p|s|i|t|n|b|v} [<limit>] [<user>] | |
1158 | [<ban mask>] | |
1159 | ||
1160 | The MODE command is provided so that channel operators may change the | |
1161 | characteristics of `their' channel. It is also required that servers | |
1162 | be able to change channel modes so that channel operators may be | |
1163 | created. | |
1164 | ||
1165 | The various modes available for channels are as follows: | |
1166 | ||
1167 | o - give/take channel operator privileges; | |
1168 | p - private channel flag; | |
1169 | s - secret channel flag; | |
1170 | i - invite-only channel flag; | |
1171 | t - topic settable by channel operator only flag; | |
1172 | n - no messages to channel from clients on the outside; | |
1173 | m - moderated channel; | |
1174 | l - set the user limit to channel; | |
1175 | ||
1176 | ||
1177 | ||
1178 | Oikarinen & Reed [Page 21] | |
1179 | \f | |
1180 | RFC 1459 Internet Relay Chat Protocol May 1993 | |
1181 | ||
1182 | ||
1183 | b - set a ban mask to keep users out; | |
1184 | v - give/take the ability to speak on a moderated channel; | |
1185 | k - set a channel key (password). | |
1186 | ||
1187 | When using the 'o' and 'b' options, a restriction on a total of three | |
1188 | per mode command has been imposed. That is, any combination of 'o' | |
1189 | and | |
1190 | ||
1191 | 4.2.3.2 User modes | |
1192 | ||
1193 | Parameters: <nickname> {[+|-]|i|w|s|o} | |
1194 | ||
1195 | The user MODEs are typically changes which affect either how the | |
1196 | client is seen by others or what 'extra' messages the client is sent. | |
1197 | A user MODE command may only be accepted if both the sender of the | |
1198 | message and the nickname given as a parameter are both the same. | |
1199 | ||
1200 | The available modes are as follows: | |
1201 | ||
1202 | i - marks a users as invisible; | |
1203 | s - marks a user for receipt of server notices; | |
1204 | w - user receives wallops; | |
1205 | o - operator flag. | |
1206 | ||
1207 | Additional modes may be available later on. | |
1208 | ||
1209 | If a user attempts to make themselves an operator using the "+o" | |
1210 | flag, the attempt should be ignored. There is no restriction, | |
1211 | however, on anyone `deopping' themselves (using "-o"). Numeric | |
1212 | Replies: | |
1213 | ||
1214 | ERR_NEEDMOREPARAMS RPL_CHANNELMODEIS | |
1215 | ERR_CHANOPRIVSNEEDED ERR_NOSUCHNICK | |
1216 | ERR_NOTONCHANNEL ERR_KEYSET | |
1217 | RPL_BANLIST RPL_ENDOFBANLIST | |
1218 | ERR_UNKNOWNMODE ERR_NOSUCHCHANNEL | |
1219 | ||
1220 | ERR_USERSDONTMATCH RPL_UMODEIS | |
1221 | ERR_UMODEUNKNOWNFLAG | |
1222 | ||
1223 | Examples: | |
1224 | ||
1225 | Use of Channel Modes: | |
1226 | ||
1227 | MODE #Finnish +im ; Makes #Finnish channel moderated and | |
1228 | 'invite-only'. | |
1229 | ||
1230 | MODE #Finnish +o Kilroy ; Gives 'chanop' privileges to Kilroy on | |
1231 | ||
1232 | ||
1233 | ||
1234 | Oikarinen & Reed [Page 22] | |
1235 | \f | |
1236 | RFC 1459 Internet Relay Chat Protocol May 1993 | |
1237 | ||
1238 | ||
1239 | channel #Finnish. | |
1240 | ||
1241 | MODE #Finnish +v Wiz ; Allow WiZ to speak on #Finnish. | |
1242 | ||
1243 | MODE #Fins -s ; Removes 'secret' flag from channel | |
1244 | #Fins. | |
1245 | ||
1246 | MODE #42 +k oulu ; Set the channel key to "oulu". | |
1247 | ||
1248 | MODE #eu-opers +l 10 ; Set the limit for the number of users | |
1249 | on channel to 10. | |
1250 | ||
1251 | MODE &oulu +b ; list ban masks set for channel. | |
1252 | ||
1253 | MODE &oulu +b *!*@* ; prevent all users from joining. | |
1254 | ||
1255 | MODE &oulu +b *!*@*.edu ; prevent any user from a hostname | |
1256 | matching *.edu from joining. | |
1257 | ||
1258 | Use of user Modes: | |
1259 | ||
1260 | :MODE WiZ -w ; turns reception of WALLOPS messages | |
1261 | off for WiZ. | |
1262 | ||
1263 | :Angel MODE Angel +i ; Message from Angel to make themselves | |
1264 | invisible. | |
1265 | ||
1266 | MODE WiZ -o ; WiZ 'deopping' (removing operator | |
1267 | status). The plain reverse of this | |
1268 | command ("MODE WiZ +o") must not be | |
1269 | allowed from users since would bypass | |
1270 | the OPER command. | |
1271 | ||
1272 | 4.2.4 Topic message | |
1273 | ||
1274 | Command: TOPIC | |
1275 | Parameters: <channel> [<topic>] | |
1276 | ||
1277 | The TOPIC message is used to change or view the topic of a channel. | |
1278 | The topic for channel <channel> is returned if there is no <topic> | |
1279 | given. If the <topic> parameter is present, the topic for that | |
1280 | channel will be changed, if the channel modes permit this action. | |
1281 | ||
1282 | Numeric Replies: | |
1283 | ||
1284 | ERR_NEEDMOREPARAMS ERR_NOTONCHANNEL | |
1285 | RPL_NOTOPIC RPL_TOPIC | |
1286 | ERR_CHANOPRIVSNEEDED | |
1287 | ||
1288 | ||
1289 | ||
1290 | Oikarinen & Reed [Page 23] | |
1291 | \f | |
1292 | RFC 1459 Internet Relay Chat Protocol May 1993 | |
1293 | ||
1294 | ||
1295 | Examples: | |
1296 | ||
1297 | :Wiz TOPIC #test :New topic ;User Wiz setting the topic. | |
1298 | ||
1299 | TOPIC #test :another topic ;set the topic on #test to "another | |
1300 | topic". | |
1301 | ||
1302 | TOPIC #test ; check the topic for #test. | |
1303 | ||
1304 | 4.2.5 Names message | |
1305 | ||
1306 | Command: NAMES | |
1307 | Parameters: [<channel>{,<channel>}] | |
1308 | ||
1309 | By using the NAMES command, a user can list all nicknames that are | |
1310 | visible to them on any channel that they can see. Channel names | |
1311 | which they can see are those which aren't private (+p) or secret (+s) | |
1312 | or those which they are actually on. The <channel> parameter | |
1313 | specifies which channel(s) to return information about if valid. | |
1314 | There is no error reply for bad channel names. | |
1315 | ||
1316 | If no <channel> parameter is given, a list of all channels and their | |
1317 | occupants is returned. At the end of this list, a list of users who | |
1318 | are visible but either not on any channel or not on a visible channel | |
1319 | are listed as being on `channel' "*". | |
1320 | ||
1321 | Numerics: | |
1322 | ||
1323 | RPL_NAMREPLY RPL_ENDOFNAMES | |
1324 | ||
1325 | Examples: | |
1326 | ||
1327 | NAMES #twilight_zone,#42 ; list visible users on #twilight_zone | |
1328 | and #42 if the channels are visible to | |
1329 | you. | |
1330 | ||
1331 | NAMES ; list all visible channels and users | |
1332 | ||
1333 | 4.2.6 List message | |
1334 | ||
1335 | Command: LIST | |
1336 | Parameters: [<channel>{,<channel>} [<server>]] | |
1337 | ||
1338 | The list message is used to list channels and their topics. If the | |
1339 | <channel> parameter is used, only the status of that channel | |
1340 | is displayed. Private channels are listed (without their | |
1341 | topics) as channel "Prv" unless the client generating the query is | |
1342 | actually on that channel. Likewise, secret channels are not listed | |
1343 | ||
1344 | ||
1345 | ||
1346 | Oikarinen & Reed [Page 24] | |
1347 | \f | |
1348 | RFC 1459 Internet Relay Chat Protocol May 1993 | |
1349 | ||
1350 | ||
1351 | at all unless the client is a member of the channel in question. | |
1352 | ||
1353 | Numeric Replies: | |
1354 | ||
1355 | ERR_NOSUCHSERVER RPL_LISTSTART | |
1356 | RPL_LIST RPL_LISTEND | |
1357 | ||
1358 | Examples: | |
1359 | ||
1360 | LIST ; List all channels. | |
1361 | ||
1362 | LIST #twilight_zone,#42 ; List channels #twilight_zone and #42 | |
1363 | ||
1364 | 4.2.7 Invite message | |
1365 | ||
1366 | Command: INVITE | |
1367 | Parameters: <nickname> <channel> | |
1368 | ||
1369 | The INVITE message is used to invite users to a channel. The | |
1370 | parameter <nickname> is the nickname of the person to be invited to | |
1371 | the target channel <channel>. There is no requirement that the | |
1372 | channel the target user is being invited to must exist or be a valid | |
1373 | channel. To invite a user to a channel which is invite only (MODE | |
1374 | +i), the client sending the invite must be recognised as being a | |
1375 | channel operator on the given channel. | |
1376 | ||
1377 | Numeric Replies: | |
1378 | ||
1379 | ERR_NEEDMOREPARAMS ERR_NOSUCHNICK | |
1380 | ERR_NOTONCHANNEL ERR_USERONCHANNEL | |
1381 | ERR_CHANOPRIVSNEEDED | |
1382 | RPL_INVITING RPL_AWAY | |
1383 | ||
1384 | Examples: | |
1385 | ||
1386 | :Angel INVITE Wiz #Dust ; User Angel inviting WiZ to channel | |
1387 | #Dust | |
1388 | ||
1389 | INVITE Wiz #Twilight_Zone ; Command to invite WiZ to | |
1390 | #Twilight_zone | |
1391 | ||
1392 | 4.2.8 Kick command | |
1393 | ||
1394 | Command: KICK | |
1395 | Parameters: <channel> <user> [<comment>] | |
1396 | ||
1397 | The KICK command can be used to forcibly remove a user from a | |
1398 | channel. It 'kicks them out' of the channel (forced PART). | |
1399 | ||
1400 | ||
1401 | ||
1402 | Oikarinen & Reed [Page 25] | |
1403 | \f | |
1404 | RFC 1459 Internet Relay Chat Protocol May 1993 | |
1405 | ||
1406 | ||
1407 | Only a channel operator may kick another user out of a channel. | |
1408 | Each server that receives a KICK message checks that it is valid | |
1409 | (ie the sender is actually a channel operator) before removing | |
1410 | the victim from the channel. | |
1411 | ||
1412 | Numeric Replies: | |
1413 | ||
1414 | ERR_NEEDMOREPARAMS ERR_NOSUCHCHANNEL | |
1415 | ERR_BADCHANMASK ERR_CHANOPRIVSNEEDED | |
1416 | ERR_NOTONCHANNEL | |
1417 | ||
1418 | Examples: | |
1419 | ||
1420 | KICK &Melbourne Matthew ; Kick Matthew from &Melbourne | |
1421 | ||
1422 | KICK #Finnish John :Speaking English | |
1423 | ; Kick John from #Finnish using | |
1424 | "Speaking English" as the reason | |
1425 | (comment). | |
1426 | ||
1427 | :WiZ KICK #Finnish John ; KICK message from WiZ to remove John | |
1428 | from channel #Finnish | |
1429 | ||
1430 | NOTE: | |
1431 | It is possible to extend the KICK command parameters to the | |
1432 | following: | |
1433 | ||
1434 | <channel>{,<channel>} <user>{,<user>} [<comment>] | |
1435 | ||
1436 | 4.3 Server queries and commands | |
1437 | ||
1438 | The server query group of commands has been designed to return | |
1439 | information about any server which is connected to the network. All | |
1440 | servers connected must respond to these queries and respond | |
1441 | correctly. Any invalid response (or lack thereof) must be considered | |
1442 | a sign of a broken server and it must be disconnected/disabled as | |
1443 | soon as possible until the situation is remedied. | |
1444 | ||
1445 | In these queries, where a parameter appears as "<server>", it will | |
1446 | usually mean it can be a nickname or a server or a wildcard name of | |
1447 | some sort. For each parameter, however, only one query and set of | |
1448 | replies is to be generated. | |
1449 | ||
1450 | 4.3.1 Version message | |
1451 | ||
1452 | Command: VERSION | |
1453 | Parameters: [<server>] | |
1454 | ||
1455 | ||
1456 | ||
1457 | ||
1458 | Oikarinen & Reed [Page 26] | |
1459 | \f | |
1460 | RFC 1459 Internet Relay Chat Protocol May 1993 | |
1461 | ||
1462 | ||
1463 | The VERSION message is used to query the version of the server | |
1464 | program. An optional parameter <server> is used to query the version | |
1465 | of the server program which a client is not directly connected to. | |
1466 | ||
1467 | Numeric Replies: | |
1468 | ||
1469 | ERR_NOSUCHSERVER RPL_VERSION | |
1470 | ||
1471 | Examples: | |
1472 | ||
1473 | :Wiz VERSION *.se ; message from Wiz to check the version | |
1474 | of a server matching "*.se" | |
1475 | ||
1476 | VERSION tolsun.oulu.fi ; check the version of server | |
1477 | "tolsun.oulu.fi". | |
1478 | ||
1479 | 4.3.2 Stats message | |
1480 | ||
1481 | Command: STATS | |
1482 | Parameters: [<query> [<server>]] | |
1483 | ||
1484 | The stats message is used to query statistics of certain server. If | |
1485 | <server> parameter is omitted, only the end of stats reply is sent | |
1486 | back. The implementation of this command is highly dependent on the | |
1487 | server which replies, although the server must be able to supply | |
1488 | information as described by the queries below (or similar). | |
1489 | ||
1490 | A query may be given by any single letter which is only checked by | |
1491 | the destination server (if given as the <server> parameter) and is | |
1492 | otherwise passed on by intermediate servers, ignored and unaltered. | |
1493 | The following queries are those found in the current IRC | |
1494 | implementation and provide a large portion of the setup information | |
1495 | for that server. Although these may not be supported in the same way | |
1496 | by other versions, all servers should be able to supply a valid reply | |
1497 | to a STATS query which is consistent with the reply formats currently | |
1498 | used and the purpose of the query. | |
1499 | ||
1500 | The currently supported queries are: | |
1501 | ||
1502 | c - returns a list of servers which the server may connect | |
1503 | to or allow connections from; | |
1504 | h - returns a list of servers which are either forced to be | |
1505 | treated as leaves or allowed to act as hubs; | |
1506 | i - returns a list of hosts which the server allows a client | |
1507 | to connect from; | |
1508 | k - returns a list of banned username/hostname combinations | |
1509 | for that server; | |
1510 | l - returns a list of the server's connections, showing how | |
1511 | ||
1512 | ||
1513 | ||
1514 | Oikarinen & Reed [Page 27] | |
1515 | \f | |
1516 | RFC 1459 Internet Relay Chat Protocol May 1993 | |
1517 | ||
1518 | ||
1519 | long each connection has been established and the traffic | |
1520 | over that connection in bytes and messages for each | |
1521 | direction; | |
1522 | m - returns a list of commands supported by the server and | |
1523 | the usage count for each if the usage count is non zero; | |
1524 | o - returns a list of hosts from which normal clients may | |
1525 | become operators; | |
1526 | y - show Y (Class) lines from server's configuration file; | |
1527 | u - returns a string showing how long the server has been up. | |
1528 | ||
1529 | Numeric Replies: | |
1530 | ||
1531 | ERR_NOSUCHSERVER | |
1532 | RPL_STATSCLINE RPL_STATSNLINE | |
1533 | RPL_STATSILINE RPL_STATSKLINE | |
1534 | RPL_STATSQLINE RPL_STATSLLINE | |
1535 | RPL_STATSLINKINFO RPL_STATSUPTIME | |
1536 | RPL_STATSCOMMANDS RPL_STATSOLINE | |
1537 | RPL_STATSHLINE RPL_ENDOFSTATS | |
1538 | ||
1539 | Examples: | |
1540 | ||
1541 | STATS m ; check the command usage for the server | |
1542 | you are connected to | |
1543 | ||
1544 | :Wiz STATS c eff.org ; request by WiZ for C/N line | |
1545 | information from server eff.org | |
1546 | ||
1547 | 4.3.3 Links message | |
1548 | ||
1549 | Command: LINKS | |
1550 | Parameters: [[<remote server>] <server mask>] | |
1551 | ||
1552 | With LINKS, a user can list all servers which are known by the server | |
1553 | answering the query. The returned list of servers must match the | |
1554 | mask, or if no mask is given, the full list is returned. | |
1555 | ||
1556 | If <remote server> is given in addition to <server mask>, the LINKS | |
1557 | command is forwarded to the first server found that matches that name | |
1558 | (if any), and that server is then required to answer the query. | |
1559 | ||
1560 | Numeric Replies: | |
1561 | ||
1562 | ERR_NOSUCHSERVER | |
1563 | RPL_LINKS RPL_ENDOFLINKS | |
1564 | ||
1565 | Examples: | |
1566 | ||
1567 | ||
1568 | ||
1569 | ||
1570 | Oikarinen & Reed [Page 28] | |
1571 | \f | |
1572 | RFC 1459 Internet Relay Chat Protocol May 1993 | |
1573 | ||
1574 | ||
1575 | LINKS *.au ; list all servers which have a name | |
1576 | that matches *.au; | |
1577 | ||
1578 | :WiZ LINKS *.bu.edu *.edu ; LINKS message from WiZ to the first | |
1579 | server matching *.edu for a list of | |
1580 | servers matching *.bu.edu. | |
1581 | ||
1582 | 4.3.4 Time message | |
1583 | ||
1584 | Command: TIME | |
1585 | Parameters: [<server>] | |
1586 | ||
1587 | The time message is used to query local time from the specified | |
1588 | server. If the server parameter is not given, the server handling the | |
1589 | command must reply to the query. | |
1590 | ||
1591 | Numeric Replies: | |
1592 | ||
1593 | ERR_NOSUCHSERVER RPL_TIME | |
1594 | ||
1595 | Examples: | |
1596 | ||
1597 | TIME tolsun.oulu.fi ; check the time on the server | |
1598 | "tolson.oulu.fi" | |
1599 | ||
1600 | Angel TIME *.au ; user angel checking the time on a | |
1601 | server matching "*.au" | |
1602 | ||
1603 | 4.3.5 Connect message | |
1604 | ||
1605 | Command: CONNECT | |
1606 | Parameters: <target server> [<port> [<remote server>]] | |
1607 | ||
1608 | The CONNECT command can be used to force a server to try to establish | |
1609 | a new connection to another server immediately. CONNECT is a | |
1610 | privileged command and is to be available only to IRC Operators. If | |
1611 | a remote server is given then the CONNECT attempt is made by that | |
1612 | server to <target server> and <port>. | |
1613 | ||
1614 | Numeric Replies: | |
1615 | ||
1616 | ERR_NOSUCHSERVER ERR_NOPRIVILEGES | |
1617 | ERR_NEEDMOREPARAMS | |
1618 | ||
1619 | Examples: | |
1620 | ||
1621 | CONNECT tolsun.oulu.fi ; Attempt to connect a server to | |
1622 | tolsun.oulu.fi | |
1623 | ||
1624 | ||
1625 | ||
1626 | Oikarinen & Reed [Page 29] | |
1627 | \f | |
1628 | RFC 1459 Internet Relay Chat Protocol May 1993 | |
1629 | ||
1630 | ||
1631 | :WiZ CONNECT eff.org 6667 csd.bu.edu | |
1632 | ; CONNECT attempt by WiZ to get servers | |
1633 | eff.org and csd.bu.edu connected on port | |
1634 | 6667. | |
1635 | ||
1636 | 4.3.6 Trace message | |
1637 | ||
1638 | Command: TRACE | |
1639 | Parameters: [<server>] | |
1640 | ||
1641 | TRACE command is used to find the route to specific server. Each | |
1642 | server that processes this message must tell the sender about it by | |
1643 | sending a reply indicating it is a pass-through link, forming a chain | |
1644 | of replies similar to that gained from using "traceroute". After | |
1645 | sending this reply back, it must then send the TRACE message to the | |
1646 | next server until given server is reached. If the <server> parameter | |
1647 | is omitted, it is recommended that TRACE command send a message to | |
1648 | the sender telling which servers the current server has direct | |
1649 | connection to. | |
1650 | ||
1651 | If the destination given by "<server>" is an actual server, then the | |
1652 | destination server is required to report all servers and users which | |
1653 | are connected to it, although only operators are permitted to see | |
1654 | users present. If the destination given by <server> is a nickname, | |
1655 | they only a reply for that nickname is given. | |
1656 | ||
1657 | Numeric Replies: | |
1658 | ||
1659 | ERR_NOSUCHSERVER | |
1660 | ||
1661 | If the TRACE message is destined for another server, all intermediate | |
1662 | servers must return a RPL_TRACELINK reply to indicate that the TRACE | |
1663 | passed through it and where its going next. | |
1664 | ||
1665 | RPL_TRACELINK | |
1666 | A TRACE reply may be composed of any number of the following numeric | |
1667 | replies. | |
1668 | ||
1669 | RPL_TRACECONNECTING RPL_TRACEHANDSHAKE | |
1670 | RPL_TRACEUNKNOWN RPL_TRACEOPERATOR | |
1671 | RPL_TRACEUSER RPL_TRACESERVER | |
1672 | RPL_TRACESERVICE RPL_TRACENEWTYPE | |
1673 | RPL_TRACECLASS | |
1674 | ||
1675 | Examples: | |
1676 | ||
1677 | TRACE *.oulu.fi ; TRACE to a server matching *.oulu.fi | |
1678 | ||
1679 | ||
1680 | ||
1681 | ||
1682 | Oikarinen & Reed [Page 30] | |
1683 | \f | |
1684 | RFC 1459 Internet Relay Chat Protocol May 1993 | |
1685 | ||
1686 | ||
1687 | :WiZ TRACE AngelDust ; TRACE issued by WiZ to nick AngelDust | |
1688 | ||
1689 | 4.3.7 Admin command | |
1690 | ||
1691 | Command: ADMIN | |
1692 | Parameters: [<server>] | |
1693 | ||
1694 | The admin message is used to find the name of the administrator of | |
1695 | the given server, or current server if <server> parameter is omitted. | |
1696 | Each server must have the ability to forward ADMIN messages to other | |
1697 | servers. | |
1698 | ||
1699 | Numeric Replies: | |
1700 | ||
1701 | ERR_NOSUCHSERVER | |
1702 | RPL_ADMINME RPL_ADMINLOC1 | |
1703 | RPL_ADMINLOC2 RPL_ADMINEMAIL | |
1704 | ||
1705 | Examples: | |
1706 | ||
1707 | ADMIN tolsun.oulu.fi ; request an ADMIN reply from | |
1708 | tolsun.oulu.fi | |
1709 | ||
1710 | :WiZ ADMIN *.edu ; ADMIN request from WiZ for first | |
1711 | server found to match *.edu. | |
1712 | ||
1713 | 4.3.8 Info command | |
1714 | ||
1715 | Command: INFO | |
1716 | Parameters: [<server>] | |
1717 | ||
1718 | The INFO command is required to return information which describes | |
1719 | the server: its version, when it was compiled, the patchlevel, when | |
1720 | it was started, and any other miscellaneous information which may be | |
1721 | considered to be relevant. | |
1722 | ||
1723 | Numeric Replies: | |
1724 | ||
1725 | ERR_NOSUCHSERVER | |
1726 | RPL_INFO RPL_ENDOFINFO | |
1727 | ||
1728 | Examples: | |
1729 | ||
1730 | INFO csd.bu.edu ; request an INFO reply from | |
1731 | csd.bu.edu | |
1732 | ||
1733 | :Avalon INFO *.fi ; INFO request from Avalon for first | |
1734 | server found to match *.fi. | |
1735 | ||
1736 | ||
1737 | ||
1738 | Oikarinen & Reed [Page 31] | |
1739 | \f | |
1740 | RFC 1459 Internet Relay Chat Protocol May 1993 | |
1741 | ||
1742 | ||
1743 | INFO Angel ; request info from the server that | |
1744 | Angel is connected to. | |
1745 | ||
1746 | 4.4 Sending messages | |
1747 | ||
1748 | The main purpose of the IRC protocol is to provide a base for clients | |
1749 | to communicate with each other. PRIVMSG and NOTICE are the only | |
1750 | messages available which actually perform delivery of a text message | |
1751 | from one client to another - the rest just make it possible and try | |
1752 | to ensure it happens in a reliable and structured manner. | |
1753 | ||
1754 | 4.4.1 Private messages | |
1755 | ||
1756 | Command: PRIVMSG | |
1757 | Parameters: <receiver>{,<receiver>} <text to be sent> | |
1758 | ||
1759 | PRIVMSG is used to send private messages between users. <receiver> | |
1760 | is the nickname of the receiver of the message. <receiver> can also | |
1761 | be a list of names or channels separated with commas. | |
1762 | ||
1763 | The <receiver> parameter may also me a host mask (#mask) or server | |
1764 | mask ($mask). In both cases the server will only send the PRIVMSG | |
1765 | to those who have a server or host matching the mask. The mask must | |
1766 | have at least 1 (one) "." in it and no wildcards following the | |
1767 | last ".". This requirement exists to prevent people sending messages | |
1768 | to "#*" or "$*", which would broadcast to all users; from | |
1769 | experience, this is abused more than used responsibly and properly. | |
1770 | Wildcards are the '*' and '?' characters. This extension to | |
1771 | the PRIVMSG command is only available to Operators. | |
1772 | ||
1773 | Numeric Replies: | |
1774 | ||
1775 | ERR_NORECIPIENT ERR_NOTEXTTOSEND | |
1776 | ERR_CANNOTSENDTOCHAN ERR_NOTOPLEVEL | |
1777 | ERR_WILDTOPLEVEL ERR_TOOMANYTARGETS | |
1778 | ERR_NOSUCHNICK | |
1779 | RPL_AWAY | |
1780 | ||
1781 | Examples: | |
1782 | ||
1783 | :Angel PRIVMSG Wiz :Hello are you receiving this message ? | |
1784 | ; Message from Angel to Wiz. | |
1785 | ||
1786 | PRIVMSG Angel :yes I'm receiving it !receiving it !'u>(768u+1n) .br ; | |
1787 | Message to Angel. | |
1788 | ||
1789 | PRIVMSG jto@tolsun.oulu.fi :Hello ! | |
1790 | ; Message to a client on server | |
1791 | ||
1792 | ||
1793 | ||
1794 | Oikarinen & Reed [Page 32] | |
1795 | \f | |
1796 | RFC 1459 Internet Relay Chat Protocol May 1993 | |
1797 | ||
1798 | ||
1799 | tolsun.oulu.fi with username of "jto". | |
1800 | ||
1801 | PRIVMSG $*.fi :Server tolsun.oulu.fi rebooting. | |
1802 | ; Message to everyone on a server which | |
1803 | has a name matching *.fi. | |
1804 | ||
1805 | PRIVMSG #*.edu :NSFNet is undergoing work, expect interruptions | |
1806 | ; Message to all users who come from a | |
1807 | host which has a name matching *.edu. | |
1808 | ||
1809 | 4.4.2 Notice | |
1810 | ||
1811 | Command: NOTICE | |
1812 | Parameters: <nickname> <text> | |
1813 | ||
1814 | The NOTICE message is used similarly to PRIVMSG. The difference | |
1815 | between NOTICE and PRIVMSG is that automatic replies must never be | |
1816 | sent in response to a NOTICE message. This rule applies to servers | |
1817 | too - they must not send any error reply back to the client on | |
1818 | receipt of a notice. The object of this rule is to avoid loops | |
1819 | between a client automatically sending something in response to | |
1820 | something it received. This is typically used by automatons (clients | |
1821 | with either an AI or other interactive program controlling their | |
1822 | actions) which are always seen to be replying lest they end up in a | |
1823 | loop with another automaton. | |
1824 | ||
1825 | See PRIVMSG for more details on replies and examples. | |
1826 | ||
1827 | 4.5 User based queries | |
1828 | ||
1829 | User queries are a group of commands which are primarily concerned | |
1830 | with finding details on a particular user or group users. When using | |
1831 | wildcards with any of these commands, if they match, they will only | |
1832 | return information on users who are 'visible' to you. The visibility | |
1833 | of a user is determined as a combination of the user's mode and the | |
1834 | common set of channels you are both on. | |
1835 | ||
1836 | 4.5.1 Who query | |
1837 | ||
1838 | Command: WHO | |
1839 | Parameters: [<name> [<o>]] | |
1840 | ||
1841 | The WHO message is used by a client to generate a query which returns | |
1842 | a list of information which 'matches' the <name> parameter given by | |
1843 | the client. In the absence of the <name> parameter, all visible | |
1844 | (users who aren't invisible (user mode +i) and who don't have a | |
1845 | common channel with the requesting client) are listed. The same | |
1846 | result can be achieved by using a <name> of "0" or any wildcard which | |
1847 | ||
1848 | ||
1849 | ||
1850 | Oikarinen & Reed [Page 33] | |
1851 | \f | |
1852 | RFC 1459 Internet Relay Chat Protocol May 1993 | |
1853 | ||
1854 | ||
1855 | will end up matching every entry possible. | |
1856 | ||
1857 | The <name> passed to WHO is matched against users' host, server, real | |
1858 | name and nickname if the channel <name> cannot be found. | |
1859 | ||
1860 | If the "o" parameter is passed only operators are returned according | |
1861 | to the name mask supplied. | |
1862 | ||
1863 | Numeric Replies: | |
1864 | ||
1865 | ERR_NOSUCHSERVER | |
1866 | RPL_WHOREPLY RPL_ENDOFWHO | |
1867 | ||
1868 | Examples: | |
1869 | ||
1870 | WHO *.fi ; List all users who match against | |
1871 | "*.fi". | |
1872 | ||
1873 | WHO jto* o ; List all users with a match against | |
1874 | "jto*" if they are an operator. | |
1875 | ||
1876 | 4.5.2 Whois query | |
1877 | ||
1878 | Command: WHOIS | |
1879 | Parameters: [<server>] <nickmask>[,<nickmask>[,...]] | |
1880 | ||
1881 | This message is used to query information about particular user. The | |
1882 | server will answer this message with several numeric messages | |
1883 | indicating different statuses of each user which matches the nickmask | |
1884 | (if you are entitled to see them). If no wildcard is present in the | |
1885 | <nickmask>, any information about that nick which you are allowed to | |
1886 | see is presented. A comma (',') separated list of nicknames may be | |
1887 | given. | |
1888 | ||
1889 | The latter version sends the query to a specific server. It is | |
1890 | useful if you want to know how long the user in question has been | |
1891 | idle as only local server (ie. the server the user is directly | |
1892 | connected to) knows that information, while everything else is | |
1893 | globally known. | |
1894 | ||
1895 | Numeric Replies: | |
1896 | ||
1897 | ERR_NOSUCHSERVER ERR_NONICKNAMEGIVEN | |
1898 | RPL_WHOISUSER RPL_WHOISCHANNELS | |
1899 | RPL_WHOISCHANNELS RPL_WHOISSERVER | |
1900 | RPL_AWAY RPL_WHOISOPERATOR | |
1901 | RPL_WHOISIDLE ERR_NOSUCHNICK | |
1902 | RPL_ENDOFWHOIS | |
1903 | ||
1904 | ||
1905 | ||
1906 | Oikarinen & Reed [Page 34] | |
1907 | \f | |
1908 | RFC 1459 Internet Relay Chat Protocol May 1993 | |
1909 | ||
1910 | ||
1911 | Examples: | |
1912 | ||
1913 | WHOIS wiz ; return available user information | |
1914 | about nick WiZ | |
1915 | ||
1916 | WHOIS eff.org trillian ; ask server eff.org for user | |
1917 | information about trillian | |
1918 | ||
1919 | 4.5.3 Whowas | |
1920 | ||
1921 | Command: WHOWAS | |
1922 | Parameters: <nickname> [<count> [<server>]] | |
1923 | ||
1924 | Whowas asks for information about a nickname which no longer exists. | |
1925 | This may either be due to a nickname change or the user leaving IRC. | |
1926 | In response to this query, the server searches through its nickname | |
1927 | history, looking for any nicks which are lexically the same (no wild | |
1928 | card matching here). The history is searched backward, returning the | |
1929 | most recent entry first. If there are multiple entries, up to | |
1930 | <count> replies will be returned (or all of them if no <count> | |
1931 | parameter is given). If a non-positive number is passed as being | |
1932 | <count>, then a full search is done. | |
1933 | ||
1934 | Numeric Replies: | |
1935 | ||
1936 | ERR_NONICKNAMEGIVEN ERR_WASNOSUCHNICK | |
1937 | RPL_WHOWASUSER RPL_WHOISSERVER | |
1938 | RPL_ENDOFWHOWAS | |
1939 | ||
1940 | Examples: | |
1941 | ||
1942 | WHOWAS Wiz ; return all information in the nick | |
1943 | history about nick "WiZ"; | |
1944 | ||
1945 | WHOWAS Mermaid 9 ; return at most, the 9 most recent | |
1946 | entries in the nick history for | |
1947 | "Mermaid"; | |
1948 | ||
1949 | WHOWAS Trillian 1 *.edu ; return the most recent history for | |
1950 | "Trillian" from the first server found | |
1951 | to match "*.edu". | |
1952 | ||
1953 | 4.6 Miscellaneous messages | |
1954 | ||
1955 | Messages in this category do not fit into any of the above categories | |
1956 | but are nonetheless still a part of and required by the protocol. | |
1957 | ||
1958 | ||
1959 | ||
1960 | ||
1961 | ||
1962 | Oikarinen & Reed [Page 35] | |
1963 | \f | |
1964 | RFC 1459 Internet Relay Chat Protocol May 1993 | |
1965 | ||
1966 | ||
1967 | 4.6.1 Kill message | |
1968 | ||
1969 | Command: KILL | |
1970 | Parameters: <nickname> <comment> | |
1971 | ||
1972 | The KILL message is used to cause a client-server connection to be | |
1973 | closed by the server which has the actual connection. KILL is used | |
1974 | by servers when they encounter a duplicate entry in the list of valid | |
1975 | nicknames and is used to remove both entries. It is also available | |
1976 | to operators. | |
1977 | ||
1978 | Clients which have automatic reconnect algorithms effectively make | |
1979 | this command useless since the disconnection is only brief. It does | |
1980 | however break the flow of data and can be used to stop large amounts | |
1981 | of being abused, any user may elect to receive KILL messages | |
1982 | generated for others to keep an 'eye' on would be trouble spots. | |
1983 | ||
1984 | In an arena where nicknames are required to be globally unique at all | |
1985 | times, KILL messages are sent whenever 'duplicates' are detected | |
1986 | (that is an attempt to register two users with the same nickname) in | |
1987 | the hope that both of them will disappear and only 1 reappear. | |
1988 | ||
1989 | The comment given must reflect the actual reason for the KILL. For | |
1990 | server-generated KILLs it usually is made up of details concerning | |
1991 | the origins of the two conflicting nicknames. For users it is left | |
1992 | up to them to provide an adequate reason to satisfy others who see | |
1993 | it. To prevent/discourage fake KILLs from being generated to hide | |
1994 | the identify of the KILLer, the comment also shows a 'kill-path' | |
1995 | which is updated by each server it passes through, each prepending | |
1996 | its name to the path. | |
1997 | ||
1998 | Numeric Replies: | |
1999 | ||
2000 | ERR_NOPRIVILEGES ERR_NEEDMOREPARAMS | |
2001 | ERR_NOSUCHNICK ERR_CANTKILLSERVER | |
2002 | ||
2003 | ||
2004 | KILL David (csd.bu.edu <- tolsun.oulu.fi) | |
2005 | ; Nickname collision between csd.bu.edu | |
2006 | and tolson.oulu.fi | |
2007 | ||
2008 | ||
2009 | NOTE: | |
2010 | It is recommended that only Operators be allowed to kill other users | |
2011 | with KILL message. In an ideal world not even operators would need | |
2012 | to do this and it would be left to servers to deal with. | |
2013 | ||
2014 | ||
2015 | ||
2016 | ||
2017 | ||
2018 | Oikarinen & Reed [Page 36] | |
2019 | \f | |
2020 | RFC 1459 Internet Relay Chat Protocol May 1993 | |
2021 | ||
2022 | ||
2023 | 4.6.2 Ping message | |
2024 | ||
2025 | Command: PING | |
2026 | Parameters: <server1> [<server2>] | |
2027 | ||
2028 | The PING message is used to test the presence of an active client at | |
2029 | the other end of the connection. A PING message is sent at regular | |
2030 | intervals if no other activity detected coming from a connection. If | |
2031 | a connection fails to respond to a PING command within a set amount | |
2032 | of time, that connection is closed. | |
2033 | ||
2034 | Any client which receives a PING message must respond to <server1> | |
2035 | (server which sent the PING message out) as quickly as possible with | |
2036 | an appropriate PONG message to indicate it is still there and alive. | |
2037 | Servers should not respond to PING commands but rely on PINGs from | |
2038 | the other end of the connection to indicate the connection is alive. | |
2039 | If the <server2> parameter is specified, the PING message gets | |
2040 | forwarded there. | |
2041 | ||
2042 | Numeric Replies: | |
2043 | ||
2044 | ERR_NOORIGIN ERR_NOSUCHSERVER | |
2045 | ||
2046 | Examples: | |
2047 | ||
2048 | PING tolsun.oulu.fi ; server sending a PING message to | |
2049 | another server to indicate it is still | |
2050 | alive. | |
2051 | ||
2052 | PING WiZ ; PING message being sent to nick WiZ | |
2053 | ||
2054 | 4.6.3 Pong message | |
2055 | ||
2056 | Command: PONG | |
2057 | Parameters: <daemon> [<daemon2>] | |
2058 | ||
2059 | PONG message is a reply to ping message. If parameter <daemon2> is | |
2060 | given this message must be forwarded to given daemon. The <daemon> | |
2061 | parameter is the name of the daemon who has responded to PING message | |
2062 | and generated this message. | |
2063 | ||
2064 | Numeric Replies: | |
2065 | ||
2066 | ERR_NOORIGIN ERR_NOSUCHSERVER | |
2067 | ||
2068 | Examples: | |
2069 | ||
2070 | PONG csd.bu.edu tolsun.oulu.fi ; PONG message from csd.bu.edu to | |
2071 | ||
2072 | ||
2073 | ||
2074 | Oikarinen & Reed [Page 37] | |
2075 | \f | |
2076 | RFC 1459 Internet Relay Chat Protocol May 1993 | |
2077 | ||
2078 | ||
2079 | tolsun.oulu.fi | |
2080 | ||
2081 | 4.6.4 Error | |
2082 | ||
2083 | Command: ERROR | |
2084 | Parameters: <error message> | |
2085 | ||
2086 | The ERROR command is for use by servers when reporting a serious or | |
2087 | fatal error to its operators. It may also be sent from one server to | |
2088 | another but must not be accepted from any normal unknown clients. | |
2089 | ||
2090 | An ERROR message is for use for reporting errors which occur with a | |
2091 | server-to-server link only. An ERROR message is sent to the server | |
2092 | at the other end (which sends it to all of its connected operators) | |
2093 | and to all operators currently connected. It is not to be passed | |
2094 | onto any other servers by a server if it is received from a server. | |
2095 | ||
2096 | When a server sends a received ERROR message to its operators, the | |
2097 | message should be encapsulated inside a NOTICE message, indicating | |
2098 | that the client was not responsible for the error. | |
2099 | ||
2100 | Numerics: | |
2101 | ||
2102 | None. | |
2103 | ||
2104 | Examples: | |
2105 | ||
2106 | ERROR :Server *.fi already exists; ERROR message to the other server | |
2107 | which caused this error. | |
2108 | ||
2109 | NOTICE WiZ :ERROR from csd.bu.edu -- Server *.fi already exists | |
2110 | ; Same ERROR message as above but sent | |
2111 | to user WiZ on the other server. | |
2112 | ||
2113 | 5. OPTIONALS | |
2114 | ||
2115 | This section describes OPTIONAL messages. They are not required in a | |
2116 | working server implementation of the protocol described herein. In | |
2117 | the absence of the option, an error reply message must be generated | |
2118 | or an unknown command error. If the message is destined for another | |
2119 | server to answer then it must be passed on (elementary parsing | |
2120 | required) The allocated numerics for this are listed with the | |
2121 | messages below. | |
2122 | ||
2123 | 5.1 Away | |
2124 | ||
2125 | Command: AWAY | |
2126 | Parameters: [message] | |
2127 | ||
2128 | ||
2129 | ||
2130 | Oikarinen & Reed [Page 38] | |
2131 | \f | |
2132 | RFC 1459 Internet Relay Chat Protocol May 1993 | |
2133 | ||
2134 | ||
2135 | With the AWAY message, clients can set an automatic reply string for | |
2136 | any PRIVMSG commands directed at them (not to a channel they are on). | |
2137 | The automatic reply is sent by the server to client sending the | |
2138 | PRIVMSG command. The only replying server is the one to which the | |
2139 | sending client is connected to. | |
2140 | ||
2141 | The AWAY message is used either with one parameter (to set an AWAY | |
2142 | message) or with no parameters (to remove the AWAY message). | |
2143 | ||
2144 | Numeric Replies: | |
2145 | ||
2146 | RPL_UNAWAY RPL_NOWAWAY | |
2147 | ||
2148 | Examples: | |
2149 | ||
2150 | AWAY :Gone to lunch. Back in 5 ; set away message to "Gone to lunch. | |
2151 | Back in 5". | |
2152 | ||
2153 | :WiZ AWAY ; unmark WiZ as being away. | |
2154 | ||
2155 | ||
2156 | 5.2 Rehash message | |
2157 | ||
2158 | Command: REHASH | |
2159 | Parameters: None | |
2160 | ||
2161 | The rehash message can be used by the operator to force the server to | |
2162 | re-read and process its configuration file. | |
2163 | ||
2164 | Numeric Replies: | |
2165 | ||
2166 | RPL_REHASHING ERR_NOPRIVILEGES | |
2167 | ||
2168 | Examples: | |
2169 | ||
2170 | REHASH ; message from client with operator | |
2171 | status to server asking it to reread its | |
2172 | configuration file. | |
2173 | ||
2174 | 5.3 Restart message | |
2175 | ||
2176 | Command: RESTART | |
2177 | Parameters: None | |
2178 | ||
2179 | The restart message can only be used by an operator to force a server | |
2180 | restart itself. This message is optional since it may be viewed as a | |
2181 | risk to allow arbitrary people to connect to a server as an operator | |
2182 | and execute this command, causing (at least) a disruption to service. | |
2183 | ||
2184 | ||
2185 | ||
2186 | Oikarinen & Reed [Page 39] | |
2187 | \f | |
2188 | RFC 1459 Internet Relay Chat Protocol May 1993 | |
2189 | ||
2190 | ||
2191 | The RESTART command must always be fully processed by the server to | |
2192 | which the sending client is connected and not be passed onto other | |
2193 | connected servers. | |
2194 | ||
2195 | Numeric Replies: | |
2196 | ||
2197 | ERR_NOPRIVILEGES | |
2198 | ||
2199 | Examples: | |
2200 | ||
2201 | RESTART ; no parameters required. | |
2202 | ||
2203 | 5.4 Summon message | |
2204 | ||
2205 | Command: SUMMON | |
2206 | Parameters: <user> [<server>] | |
2207 | ||
2208 | The SUMMON command can be used to give users who are on a host | |
2209 | running an IRC server a message asking them to please join IRC. This | |
2210 | message is only sent if the target server (a) has SUMMON enabled, (b) | |
2211 | the user is logged in and (c) the server process can write to the | |
2212 | user's tty (or similar). | |
2213 | ||
2214 | If no <server> parameter is given it tries to summon <user> from the | |
2215 | server the client is connected to is assumed as the target. | |
2216 | ||
2217 | If summon is not enabled in a server, it must return the | |
2218 | ERR_SUMMONDISABLED numeric and pass the summon message onwards. | |
2219 | ||
2220 | Numeric Replies: | |
2221 | ||
2222 | ERR_NORECIPIENT ERR_FILEERROR | |
2223 | ERR_NOLOGIN ERR_NOSUCHSERVER | |
2224 | RPL_SUMMONING | |
2225 | ||
2226 | Examples: | |
2227 | ||
2228 | SUMMON jto ; summon user jto on the server's host | |
2229 | ||
2230 | SUMMON jto tolsun.oulu.fi ; summon user jto on the host which a | |
2231 | server named "tolsun.oulu.fi" is | |
2232 | running. | |
2233 | ||
2234 | ||
2235 | 5.5 Users | |
2236 | ||
2237 | Command: USERS | |
2238 | Parameters: [<server>] | |
2239 | ||
2240 | ||
2241 | ||
2242 | Oikarinen & Reed [Page 40] | |
2243 | \f | |
2244 | RFC 1459 Internet Relay Chat Protocol May 1993 | |
2245 | ||
2246 | ||
2247 | The USERS command returns a list of users logged into the server in a | |
2248 | similar format to who(1), rusers(1) and finger(1). Some people | |
2249 | may disable this command on their server for security related | |
2250 | reasons. If disabled, the correct numeric must be returned to | |
2251 | indicate this. | |
2252 | ||
2253 | Numeric Replies: | |
2254 | ||
2255 | ERR_NOSUCHSERVER ERR_FILEERROR | |
2256 | RPL_USERSSTART RPL_USERS | |
2257 | RPL_NOUSERS RPL_ENDOFUSERS | |
2258 | ERR_USERSDISABLED | |
2259 | ||
2260 | Disabled Reply: | |
2261 | ||
2262 | ERR_USERSDISABLED | |
2263 | ||
2264 | Examples: | |
2265 | ||
2266 | USERS eff.org ; request a list of users logged in on | |
2267 | server eff.org | |
2268 | ||
2269 | :John USERS tolsun.oulu.fi ; request from John for a list of users | |
2270 | logged in on server tolsun.oulu.fi | |
2271 | ||
2272 | 5.6 Operwall message | |
2273 | ||
2274 | Command: WALLOPS | |
2275 | Parameters: Text to be sent to all operators currently online | |
2276 | ||
2277 | Sends a message to all operators currently online. After | |
2278 | implementing WALLOPS as a user command it was found that it was | |
2279 | often and commonly abused as a means of sending a message to a lot | |
2280 | of people (much similar to WALL). Due to this it is recommended | |
2281 | that the current implementation of WALLOPS be used as an | |
2282 | example by allowing and recognising only servers as the senders of | |
2283 | WALLOPS. | |
2284 | ||
2285 | Numeric Replies: | |
2286 | ||
2287 | ERR_NEEDMOREPARAMS | |
2288 | ||
2289 | Examples: | |
2290 | ||
2291 | :csd.bu.edu WALLOPS :Connect '*.uiuc.edu 6667' from Joshua; WALLOPS | |
2292 | message from csd.bu.edu announcing a | |
2293 | CONNECT message it received and acted | |
2294 | upon from Joshua. | |
2295 | ||
2296 | ||
2297 | ||
2298 | Oikarinen & Reed [Page 41] | |
2299 | \f | |
2300 | RFC 1459 Internet Relay Chat Protocol May 1993 | |
2301 | ||
2302 | ||
2303 | 5.7 Userhost message | |
2304 | ||
2305 | Command: USERHOST | |
2306 | Parameters: <nickname>{<space><nickname>} | |
2307 | ||
2308 | The USERHOST command takes a list of up to 5 nicknames, each | |
2309 | separated by a space character and returns a list of information | |
2310 | about each nickname that it found. The returned list has each reply | |
2311 | separated by a space. | |
2312 | ||
2313 | Numeric Replies: | |
2314 | ||
2315 | RPL_USERHOST ERR_NEEDMOREPARAMS | |
2316 | ||
2317 | Examples: | |
2318 | ||
2319 | USERHOST Wiz Michael Marty p ;USERHOST request for information on | |
2320 | nicks "Wiz", "Michael", "Marty" and "p" | |
2321 | ||
2322 | 5.8 Ison message | |
2323 | ||
2324 | Command: ISON | |
2325 | Parameters: <nickname>{<space><nickname>} | |
2326 | ||
2327 | The ISON command was implemented to provide a quick and efficient | |
2328 | means to get a response about whether a given nickname was currently | |
2329 | on IRC. ISON only takes one (1) parameter: a space-separated list of | |
2330 | nicks. For each nickname in the list that is present, the server | |
2331 | adds that to its reply string. Thus the reply string may return | |
2332 | empty (none of the given nicks are present), an exact copy of the | |
2333 | parameter string (all of them present) or as any other subset of the | |
2334 | set of nicks given in the parameter. The only limit on the number | |
2335 | of nicks that may be checked is that the combined length must not be | |
2336 | too large as to cause the server to chop it off so it fits in 512 | |
2337 | characters. | |
2338 | ||
2339 | ISON is only be processed by the server local to the client sending | |
2340 | the command and thus not passed onto other servers for further | |
2341 | processing. | |
2342 | ||
2343 | Numeric Replies: | |
2344 | ||
2345 | RPL_ISON ERR_NEEDMOREPARAMS | |
2346 | ||
2347 | Examples: | |
2348 | ||
2349 | ISON phone trillian WiZ jarlek Avalon Angel Monstah | |
2350 | ; Sample ISON request for 7 nicks. | |
2351 | ||
2352 | ||
2353 | ||
2354 | Oikarinen & Reed [Page 42] | |
2355 | \f | |
2356 | RFC 1459 Internet Relay Chat Protocol May 1993 | |
2357 | ||
2358 | ||
2359 | 6. REPLIES | |
2360 | ||
2361 | The following is a list of numeric replies which are generated in | |
2362 | response to the commands given above. Each numeric is given with its | |
2363 | number, name and reply string. | |
2364 | ||
2365 | 6.1 Error Replies. | |
2366 | ||
2367 | 401 ERR_NOSUCHNICK | |
2368 | "<nickname> :No such nick/channel" | |
2369 | ||
2370 | - Used to indicate the nickname parameter supplied to a | |
2371 | command is currently unused. | |
2372 | ||
2373 | 402 ERR_NOSUCHSERVER | |
2374 | "<server name> :No such server" | |
2375 | ||
2376 | - Used to indicate the server name given currently | |
2377 | doesn't exist. | |
2378 | ||
2379 | 403 ERR_NOSUCHCHANNEL | |
2380 | "<channel name> :No such channel" | |
2381 | ||
2382 | - Used to indicate the given channel name is invalid. | |
2383 | ||
2384 | 404 ERR_CANNOTSENDTOCHAN | |
2385 | "<channel name> :Cannot send to channel" | |
2386 | ||
2387 | - Sent to a user who is either (a) not on a channel | |
2388 | which is mode +n or (b) not a chanop (or mode +v) on | |
2389 | a channel which has mode +m set and is trying to send | |
2390 | a PRIVMSG message to that channel. | |
2391 | ||
2392 | 405 ERR_TOOMANYCHANNELS | |
2393 | "<channel name> :You have joined too many \ | |
2394 | channels" | |
2395 | - Sent to a user when they have joined the maximum | |
2396 | number of allowed channels and they try to join | |
2397 | another channel. | |
2398 | ||
2399 | 406 ERR_WASNOSUCHNICK | |
2400 | "<nickname> :There was no such nickname" | |
2401 | ||
2402 | - Returned by WHOWAS to indicate there is no history | |
2403 | information for that nickname. | |
2404 | ||
2405 | 407 ERR_TOOMANYTARGETS | |
2406 | "<target> :Duplicate recipients. No message \ | |
2407 | ||
2408 | ||
2409 | ||
2410 | Oikarinen & Reed [Page 43] | |
2411 | \f | |
2412 | RFC 1459 Internet Relay Chat Protocol May 1993 | |
2413 | ||
2414 | ||
2415 | delivered" | |
2416 | ||
2417 | - Returned to a client which is attempting to send a | |
2418 | PRIVMSG/NOTICE using the user@host destination format | |
2419 | and for a user@host which has several occurrences. | |
2420 | ||
2421 | 409 ERR_NOORIGIN | |
2422 | ":No origin specified" | |
2423 | ||
2424 | - PING or PONG message missing the originator parameter | |
2425 | which is required since these commands must work | |
2426 | without valid prefixes. | |
2427 | ||
2428 | 411 ERR_NORECIPIENT | |
2429 | ":No recipient given (<command>)" | |
2430 | 412 ERR_NOTEXTTOSEND | |
2431 | ":No text to send" | |
2432 | 413 ERR_NOTOPLEVEL | |
2433 | "<mask> :No toplevel domain specified" | |
2434 | 414 ERR_WILDTOPLEVEL | |
2435 | "<mask> :Wildcard in toplevel domain" | |
2436 | ||
2437 | - 412 - 414 are returned by PRIVMSG to indicate that | |
2438 | the message wasn't delivered for some reason. | |
2439 | ERR_NOTOPLEVEL and ERR_WILDTOPLEVEL are errors that | |
2440 | are returned when an invalid use of | |
2441 | "PRIVMSG $<server>" or "PRIVMSG #<host>" is attempted. | |
2442 | ||
2443 | 421 ERR_UNKNOWNCOMMAND | |
2444 | "<command> :Unknown command" | |
2445 | ||
2446 | - Returned to a registered client to indicate that the | |
2447 | command sent is unknown by the server. | |
2448 | ||
2449 | 422 ERR_NOMOTD | |
2450 | ":MOTD File is missing" | |
2451 | ||
2452 | - Server's MOTD file could not be opened by the server. | |
2453 | ||
2454 | 423 ERR_NOADMININFO | |
2455 | "<server> :No administrative info available" | |
2456 | ||
2457 | - Returned by a server in response to an ADMIN message | |
2458 | when there is an error in finding the appropriate | |
2459 | information. | |
2460 | ||
2461 | 424 ERR_FILEERROR | |
2462 | ":File error doing <file op> on <file>" | |
2463 | ||
2464 | ||
2465 | ||
2466 | Oikarinen & Reed [Page 44] | |
2467 | \f | |
2468 | RFC 1459 Internet Relay Chat Protocol May 1993 | |
2469 | ||
2470 | ||
2471 | - Generic error message used to report a failed file | |
2472 | operation during the processing of a message. | |
2473 | ||
2474 | 431 ERR_NONICKNAMEGIVEN | |
2475 | ":No nickname given" | |
2476 | ||
2477 | - Returned when a nickname parameter expected for a | |
2478 | command and isn't found. | |
2479 | ||
2480 | 432 ERR_ERRONEUSNICKNAME | |
2481 | "<nick> :Erroneus nickname" | |
2482 | ||
2483 | - Returned after receiving a NICK message which contains | |
2484 | characters which do not fall in the defined set. See | |
2485 | section x.x.x for details on valid nicknames. | |
2486 | ||
2487 | 433 ERR_NICKNAMEINUSE | |
2488 | "<nick> :Nickname is already in use" | |
2489 | ||
2490 | - Returned when a NICK message is processed that results | |
2491 | in an attempt to change to a currently existing | |
2492 | nickname. | |
2493 | ||
2494 | 436 ERR_NICKCOLLISION | |
2495 | "<nick> :Nickname collision KILL" | |
2496 | ||
2497 | - Returned by a server to a client when it detects a | |
2498 | nickname collision (registered of a NICK that | |
2499 | already exists by another server). | |
2500 | ||
2501 | 441 ERR_USERNOTINCHANNEL | |
2502 | "<nick> <channel> :They aren't on that channel" | |
2503 | ||
2504 | - Returned by the server to indicate that the target | |
2505 | user of the command is not on the given channel. | |
2506 | ||
2507 | 442 ERR_NOTONCHANNEL | |
2508 | "<channel> :You're not on that channel" | |
2509 | ||
2510 | - Returned by the server whenever a client tries to | |
2511 | perform a channel effecting command for which the | |
2512 | client isn't a member. | |
2513 | ||
2514 | 443 ERR_USERONCHANNEL | |
2515 | "<user> <channel> :is already on channel" | |
2516 | ||
2517 | - Returned when a client tries to invite a user to a | |
2518 | channel they are already on. | |
2519 | ||
2520 | ||
2521 | ||
2522 | Oikarinen & Reed [Page 45] | |
2523 | \f | |
2524 | RFC 1459 Internet Relay Chat Protocol May 1993 | |
2525 | ||
2526 | ||
2527 | 444 ERR_NOLOGIN | |
2528 | "<user> :User not logged in" | |
2529 | ||
2530 | - Returned by the summon after a SUMMON command for a | |
2531 | user was unable to be performed since they were not | |
2532 | logged in. | |
2533 | ||
2534 | 445 ERR_SUMMONDISABLED | |
2535 | ":SUMMON has been disabled" | |
2536 | ||
2537 | - Returned as a response to the SUMMON command. Must be | |
2538 | returned by any server which does not implement it. | |
2539 | ||
2540 | 446 ERR_USERSDISABLED | |
2541 | ":USERS has been disabled" | |
2542 | ||
2543 | - Returned as a response to the USERS command. Must be | |
2544 | returned by any server which does not implement it. | |
2545 | ||
2546 | 451 ERR_NOTREGISTERED | |
2547 | ":You have not registered" | |
2548 | ||
2549 | - Returned by the server to indicate that the client | |
2550 | must be registered before the server will allow it | |
2551 | to be parsed in detail. | |
2552 | ||
2553 | 461 ERR_NEEDMOREPARAMS | |
2554 | "<command> :Not enough parameters" | |
2555 | ||
2556 | - Returned by the server by numerous commands to | |
2557 | indicate to the client that it didn't supply enough | |
2558 | parameters. | |
2559 | ||
2560 | 462 ERR_ALREADYREGISTRED | |
2561 | ":You may not reregister" | |
2562 | ||
2563 | - Returned by the server to any link which tries to | |
2564 | change part of the registered details (such as | |
2565 | password or user details from second USER message). | |
2566 | ||
2567 | ||
2568 | 463 ERR_NOPERMFORHOST | |
2569 | ":Your host isn't among the privileged" | |
2570 | ||
2571 | - Returned to a client which attempts to register with | |
2572 | a server which does not been setup to allow | |
2573 | connections from the host the attempted connection | |
2574 | is tried. | |
2575 | ||
2576 | ||
2577 | ||
2578 | Oikarinen & Reed [Page 46] | |
2579 | \f | |
2580 | RFC 1459 Internet Relay Chat Protocol May 1993 | |
2581 | ||
2582 | ||
2583 | 464 ERR_PASSWDMISMATCH | |
2584 | ":Password incorrect" | |
2585 | ||
2586 | - Returned to indicate a failed attempt at registering | |
2587 | a connection for which a password was required and | |
2588 | was either not given or incorrect. | |
2589 | ||
2590 | 465 ERR_YOUREBANNEDCREEP | |
2591 | ":You are banned from this server" | |
2592 | ||
2593 | - Returned after an attempt to connect and register | |
2594 | yourself with a server which has been setup to | |
2595 | explicitly deny connections to you. | |
2596 | ||
2597 | 467 ERR_KEYSET | |
2598 | "<channel> :Channel key already set" | |
2599 | 471 ERR_CHANNELISFULL | |
2600 | "<channel> :Cannot join channel (+l)" | |
2601 | 472 ERR_UNKNOWNMODE | |
2602 | "<char> :is unknown mode char to me" | |
2603 | 473 ERR_INVITEONLYCHAN | |
2604 | "<channel> :Cannot join channel (+i)" | |
2605 | 474 ERR_BANNEDFROMCHAN | |
2606 | "<channel> :Cannot join channel (+b)" | |
2607 | 475 ERR_BADCHANNELKEY | |
2608 | "<channel> :Cannot join channel (+k)" | |
2609 | 481 ERR_NOPRIVILEGES | |
2610 | ":Permission Denied- You're not an IRC operator" | |
2611 | ||
2612 | - Any command requiring operator privileges to operate | |
2613 | must return this error to indicate the attempt was | |
2614 | unsuccessful. | |
2615 | ||
2616 | 482 ERR_CHANOPRIVSNEEDED | |
2617 | "<channel> :You're not channel operator" | |
2618 | ||
2619 | - Any command requiring 'chanop' privileges (such as | |
2620 | MODE messages) must return this error if the client | |
2621 | making the attempt is not a chanop on the specified | |
2622 | channel. | |
2623 | ||
2624 | 483 ERR_CANTKILLSERVER | |
2625 | ":You cant kill a server!" | |
2626 | ||
2627 | - Any attempts to use the KILL command on a server | |
2628 | are to be refused and this error returned directly | |
2629 | to the client. | |
2630 | ||
2631 | ||
2632 | ||
2633 | ||
2634 | Oikarinen & Reed [Page 47] | |
2635 | \f | |
2636 | RFC 1459 Internet Relay Chat Protocol May 1993 | |
2637 | ||
2638 | ||
2639 | 491 ERR_NOOPERHOST | |
2640 | ":No O-lines for your host" | |
2641 | ||
2642 | - If a client sends an OPER message and the server has | |
2643 | not been configured to allow connections from the | |
2644 | client's host as an operator, this error must be | |
2645 | returned. | |
2646 | ||
2647 | 501 ERR_UMODEUNKNOWNFLAG | |
2648 | ":Unknown MODE flag" | |
2649 | ||
2650 | - Returned by the server to indicate that a MODE | |
2651 | message was sent with a nickname parameter and that | |
2652 | the a mode flag sent was not recognized. | |
2653 | ||
2654 | 502 ERR_USERSDONTMATCH | |
2655 | ":Cant change mode for other users" | |
2656 | ||
2657 | - Error sent to any user trying to view or change the | |
2658 | user mode for a user other than themselves. | |
2659 | ||
2660 | 6.2 Command responses. | |
2661 | ||
2662 | 300 RPL_NONE | |
2663 | Dummy reply number. Not used. | |
2664 | ||
2665 | 302 RPL_USERHOST | |
2666 | ":[<reply>{<space><reply>}]" | |
2667 | ||
2668 | - Reply format used by USERHOST to list replies to | |
2669 | the query list. The reply string is composed as | |
2670 | follows: | |
2671 | ||
2672 | <reply> ::= <nick>['*'] '=' <'+'|'-'><hostname> | |
2673 | ||
2674 | The '*' indicates whether the client has registered | |
2675 | as an Operator. The '-' or '+' characters represent | |
2676 | whether the client has set an AWAY message or not | |
2677 | respectively. | |
2678 | ||
2679 | 303 RPL_ISON | |
2680 | ":[<nick> {<space><nick>}]" | |
2681 | ||
2682 | - Reply format used by ISON to list replies to the | |
2683 | query list. | |
2684 | ||
2685 | 301 RPL_AWAY | |
2686 | "<nick> :<away message>" | |
2687 | ||
2688 | ||
2689 | ||
2690 | Oikarinen & Reed [Page 48] | |
2691 | \f | |
2692 | RFC 1459 Internet Relay Chat Protocol May 1993 | |
2693 | ||
2694 | ||
2695 | 305 RPL_UNAWAY | |
2696 | ":You are no longer marked as being away" | |
2697 | 306 RPL_NOWAWAY | |
2698 | ":You have been marked as being away" | |
2699 | ||
2700 | - These replies are used with the AWAY command (if | |
2701 | allowed). RPL_AWAY is sent to any client sending a | |
2702 | PRIVMSG to a client which is away. RPL_AWAY is only | |
2703 | sent by the server to which the client is connected. | |
2704 | Replies RPL_UNAWAY and RPL_NOWAWAY are sent when the | |
2705 | client removes and sets an AWAY message. | |
2706 | ||
2707 | 311 RPL_WHOISUSER | |
2708 | "<nick> <user> <host> * :<real name>" | |
2709 | 312 RPL_WHOISSERVER | |
2710 | "<nick> <server> :<server info>" | |
2711 | 313 RPL_WHOISOPERATOR | |
2712 | "<nick> :is an IRC operator" | |
2713 | 317 RPL_WHOISIDLE | |
2714 | "<nick> <integer> :seconds idle" | |
2715 | 318 RPL_ENDOFWHOIS | |
2716 | "<nick> :End of /WHOIS list" | |
2717 | 319 RPL_WHOISCHANNELS | |
2718 | "<nick> :{[@|+]<channel><space>}" | |
2719 | ||
2720 | - Replies 311 - 313, 317 - 319 are all replies | |
2721 | generated in response to a WHOIS message. Given that | |
2722 | there are enough parameters present, the answering | |
2723 | server must either formulate a reply out of the above | |
2724 | numerics (if the query nick is found) or return an | |
2725 | error reply. The '*' in RPL_WHOISUSER is there as | |
2726 | the literal character and not as a wild card. For | |
2727 | each reply set, only RPL_WHOISCHANNELS may appear | |
2728 | more than once (for long lists of channel names). | |
2729 | The '@' and '+' characters next to the channel name | |
2730 | indicate whether a client is a channel operator or | |
2731 | has been granted permission to speak on a moderated | |
2732 | channel. The RPL_ENDOFWHOIS reply is used to mark | |
2733 | the end of processing a WHOIS message. | |
2734 | ||
2735 | 314 RPL_WHOWASUSER | |
2736 | "<nick> <user> <host> * :<real name>" | |
2737 | 369 RPL_ENDOFWHOWAS | |
2738 | "<nick> :End of WHOWAS" | |
2739 | ||
2740 | - When replying to a WHOWAS message, a server must use | |
2741 | the replies RPL_WHOWASUSER, RPL_WHOISSERVER or | |
2742 | ERR_WASNOSUCHNICK for each nickname in the presented | |
2743 | ||
2744 | ||
2745 | ||
2746 | Oikarinen & Reed [Page 49] | |
2747 | \f | |
2748 | RFC 1459 Internet Relay Chat Protocol May 1993 | |
2749 | ||
2750 | ||
2751 | list. At the end of all reply batches, there must | |
2752 | be RPL_ENDOFWHOWAS (even if there was only one reply | |
2753 | and it was an error). | |
2754 | ||
2755 | 321 RPL_LISTSTART | |
2756 | "Channel :Users Name" | |
2757 | 322 RPL_LIST | |
2758 | "<channel> <# visible> :<topic>" | |
2759 | 323 RPL_LISTEND | |
2760 | ":End of /LIST" | |
2761 | ||
2762 | - Replies RPL_LISTSTART, RPL_LIST, RPL_LISTEND mark | |
2763 | the start, actual replies with data and end of the | |
2764 | server's response to a LIST command. If there are | |
2765 | no channels available to return, only the start | |
2766 | and end reply must be sent. | |
2767 | ||
2768 | 324 RPL_CHANNELMODEIS | |
2769 | "<channel> <mode> <mode params>" | |
2770 | ||
2771 | 331 RPL_NOTOPIC | |
2772 | "<channel> :No topic is set" | |
2773 | 332 RPL_TOPIC | |
2774 | "<channel> :<topic>" | |
2775 | ||
2776 | - When sending a TOPIC message to determine the | |
2777 | channel topic, one of two replies is sent. If | |
2778 | the topic is set, RPL_TOPIC is sent back else | |
2779 | RPL_NOTOPIC. | |
2780 | ||
2781 | 341 RPL_INVITING | |
2782 | "<channel> <nick>" | |
2783 | ||
2784 | - Returned by the server to indicate that the | |
2785 | attempted INVITE message was successful and is | |
2786 | being passed onto the end client. | |
2787 | ||
2788 | 342 RPL_SUMMONING | |
2789 | "<user> :Summoning user to IRC" | |
2790 | ||
2791 | - Returned by a server answering a SUMMON message to | |
2792 | indicate that it is summoning that user. | |
2793 | ||
2794 | 351 RPL_VERSION | |
2795 | "<version>.<debuglevel> <server> :<comments>" | |
2796 | ||
2797 | - Reply by the server showing its version details. | |
2798 | The <version> is the version of the software being | |
2799 | ||
2800 | ||
2801 | ||
2802 | Oikarinen & Reed [Page 50] | |
2803 | \f | |
2804 | RFC 1459 Internet Relay Chat Protocol May 1993 | |
2805 | ||
2806 | ||
2807 | used (including any patchlevel revisions) and the | |
2808 | <debuglevel> is used to indicate if the server is | |
2809 | running in "debug mode". | |
2810 | ||
2811 | The "comments" field may contain any comments about | |
2812 | the version or further version details. | |
2813 | ||
2814 | 352 RPL_WHOREPLY | |
2815 | "<channel> <user> <host> <server> <nick> \ | |
2816 | <H|G>[*][@|+] :<hopcount> <real name>" | |
2817 | 315 RPL_ENDOFWHO | |
2818 | "<name> :End of /WHO list" | |
2819 | ||
2820 | - The RPL_WHOREPLY and RPL_ENDOFWHO pair are used | |
2821 | to answer a WHO message. The RPL_WHOREPLY is only | |
2822 | sent if there is an appropriate match to the WHO | |
2823 | query. If there is a list of parameters supplied | |
2824 | with a WHO message, a RPL_ENDOFWHO must be sent | |
2825 | after processing each list item with <name> being | |
2826 | the item. | |
2827 | ||
2828 | 353 RPL_NAMREPLY | |
2829 | "<channel> :[[@|+]<nick> [[@|+]<nick> [...]]]" | |
2830 | 366 RPL_ENDOFNAMES | |
2831 | "<channel> :End of /NAMES list" | |
2832 | ||
2833 | - To reply to a NAMES message, a reply pair consisting | |
2834 | of RPL_NAMREPLY and RPL_ENDOFNAMES is sent by the | |
2835 | server back to the client. If there is no channel | |
2836 | found as in the query, then only RPL_ENDOFNAMES is | |
2837 | returned. The exception to this is when a NAMES | |
2838 | message is sent with no parameters and all visible | |
2839 | channels and contents are sent back in a series of | |
2840 | RPL_NAMEREPLY messages with a RPL_ENDOFNAMES to mark | |
2841 | the end. | |
2842 | ||
2843 | 364 RPL_LINKS | |
2844 | "<mask> <server> :<hopcount> <server info>" | |
2845 | 365 RPL_ENDOFLINKS | |
2846 | "<mask> :End of /LINKS list" | |
2847 | ||
2848 | - In replying to the LINKS message, a server must send | |
2849 | replies back using the RPL_LINKS numeric and mark the | |
2850 | end of the list using an RPL_ENDOFLINKS reply. | |
2851 | ||
2852 | 367 RPL_BANLIST | |
2853 | "<channel> <banid>" | |
2854 | 368 RPL_ENDOFBANLIST | |
2855 | ||
2856 | ||
2857 | ||
2858 | Oikarinen & Reed [Page 51] | |
2859 | \f | |
2860 | RFC 1459 Internet Relay Chat Protocol May 1993 | |
2861 | ||
2862 | ||
2863 | "<channel> :End of channel ban list" | |
2864 | ||
2865 | - When listing the active 'bans' for a given channel, | |
2866 | a server is required to send the list back using the | |
2867 | RPL_BANLIST and RPL_ENDOFBANLIST messages. A separate | |
2868 | RPL_BANLIST is sent for each active banid. After the | |
2869 | banids have been listed (or if none present) a | |
2870 | RPL_ENDOFBANLIST must be sent. | |
2871 | ||
2872 | 371 RPL_INFO | |
2873 | ":<string>" | |
2874 | 374 RPL_ENDOFINFO | |
2875 | ":End of /INFO list" | |
2876 | ||
2877 | - A server responding to an INFO message is required to | |
2878 | send all its 'info' in a series of RPL_INFO messages | |
2879 | with a RPL_ENDOFINFO reply to indicate the end of the | |
2880 | replies. | |
2881 | ||
2882 | 375 RPL_MOTDSTART | |
2883 | ":- <server> Message of the day - " | |
2884 | 372 RPL_MOTD | |
2885 | ":- <text>" | |
2886 | 376 RPL_ENDOFMOTD | |
2887 | ":End of /MOTD command" | |
2888 | ||
2889 | - When responding to the MOTD message and the MOTD file | |
2890 | is found, the file is displayed line by line, with | |
2891 | each line no longer than 80 characters, using | |
2892 | RPL_MOTD format replies. These should be surrounded | |
2893 | by a RPL_MOTDSTART (before the RPL_MOTDs) and an | |
2894 | RPL_ENDOFMOTD (after). | |
2895 | ||
2896 | 381 RPL_YOUREOPER | |
2897 | ":You are now an IRC operator" | |
2898 | ||
2899 | - RPL_YOUREOPER is sent back to a client which has | |
2900 | just successfully issued an OPER message and gained | |
2901 | operator status. | |
2902 | ||
2903 | 382 RPL_REHASHING | |
2904 | "<config file> :Rehashing" | |
2905 | ||
2906 | - If the REHASH option is used and an operator sends | |
2907 | a REHASH message, an RPL_REHASHING is sent back to | |
2908 | the operator. | |
2909 | ||
2910 | 391 RPL_TIME | |
2911 | ||
2912 | ||
2913 | ||
2914 | Oikarinen & Reed [Page 52] | |
2915 | \f | |
2916 | RFC 1459 Internet Relay Chat Protocol May 1993 | |
2917 | ||
2918 | ||
2919 | "<server> :<string showing server's local time>" | |
2920 | ||
2921 | - When replying to the TIME message, a server must send | |
2922 | the reply using the RPL_TIME format above. The string | |
2923 | showing the time need only contain the correct day and | |
2924 | time there. There is no further requirement for the | |
2925 | time string. | |
2926 | ||
2927 | 392 RPL_USERSSTART | |
2928 | ":UserID Terminal Host" | |
2929 | 393 RPL_USERS | |
2930 | ":%-8s %-9s %-8s" | |
2931 | 394 RPL_ENDOFUSERS | |
2932 | ":End of users" | |
2933 | 395 RPL_NOUSERS | |
2934 | ":Nobody logged in" | |
2935 | ||
2936 | - If the USERS message is handled by a server, the | |
2937 | replies RPL_USERSTART, RPL_USERS, RPL_ENDOFUSERS and | |
2938 | RPL_NOUSERS are used. RPL_USERSSTART must be sent | |
2939 | first, following by either a sequence of RPL_USERS | |
2940 | or a single RPL_NOUSER. Following this is | |
2941 | RPL_ENDOFUSERS. | |
2942 | ||
2943 | 200 RPL_TRACELINK | |
2944 | "Link <version & debug level> <destination> \ | |
2945 | <next server>" | |
2946 | 201 RPL_TRACECONNECTING | |
2947 | "Try. <class> <server>" | |
2948 | 202 RPL_TRACEHANDSHAKE | |
2949 | "H.S. <class> <server>" | |
2950 | 203 RPL_TRACEUNKNOWN | |
2951 | "???? <class> [<client IP address in dot form>]" | |
2952 | 204 RPL_TRACEOPERATOR | |
2953 | "Oper <class> <nick>" | |
2954 | 205 RPL_TRACEUSER | |
2955 | "User <class> <nick>" | |
2956 | 206 RPL_TRACESERVER | |
2957 | "Serv <class> <int>S <int>C <server> \ | |
2958 | <nick!user|*!*>@<host|server>" | |
2959 | 208 RPL_TRACENEWTYPE | |
2960 | "<newtype> 0 <client name>" | |
2961 | 261 RPL_TRACELOG | |
2962 | "File <logfile> <debug level>" | |
2963 | ||
2964 | - The RPL_TRACE* are all returned by the server in | |
2965 | response to the TRACE message. How many are | |
2966 | returned is dependent on the the TRACE message and | |
2967 | ||
2968 | ||
2969 | ||
2970 | Oikarinen & Reed [Page 53] | |
2971 | \f | |
2972 | RFC 1459 Internet Relay Chat Protocol May 1993 | |
2973 | ||
2974 | ||
2975 | whether it was sent by an operator or not. There | |
2976 | is no predefined order for which occurs first. | |
2977 | Replies RPL_TRACEUNKNOWN, RPL_TRACECONNECTING and | |
2978 | RPL_TRACEHANDSHAKE are all used for connections | |
2979 | which have not been fully established and are either | |
2980 | unknown, still attempting to connect or in the | |
2981 | process of completing the 'server handshake'. | |
2982 | RPL_TRACELINK is sent by any server which handles | |
2983 | a TRACE message and has to pass it on to another | |
2984 | server. The list of RPL_TRACELINKs sent in | |
2985 | response to a TRACE command traversing the IRC | |
2986 | network should reflect the actual connectivity of | |
2987 | the servers themselves along that path. | |
2988 | RPL_TRACENEWTYPE is to be used for any connection | |
2989 | which does not fit in the other categories but is | |
2990 | being displayed anyway. | |
2991 | ||
2992 | 211 RPL_STATSLINKINFO | |
2993 | "<linkname> <sendq> <sent messages> \ | |
2994 | <sent bytes> <received messages> \ | |
2995 | <received bytes> <time open>" | |
2996 | 212 RPL_STATSCOMMANDS | |
2997 | "<command> <count>" | |
2998 | 213 RPL_STATSCLINE | |
2999 | "C <host> * <name> <port> <class>" | |
3000 | 214 RPL_STATSNLINE | |
3001 | "N <host> * <name> <port> <class>" | |
3002 | 215 RPL_STATSILINE | |
3003 | "I <host> * <host> <port> <class>" | |
3004 | 216 RPL_STATSKLINE | |
3005 | "K <host> * <username> <port> <class>" | |
3006 | 218 RPL_STATSYLINE | |
3007 | "Y <class> <ping frequency> <connect \ | |
3008 | frequency> <max sendq>" | |
3009 | 219 RPL_ENDOFSTATS | |
3010 | "<stats letter> :End of /STATS report" | |
3011 | 241 RPL_STATSLLINE | |
3012 | "L <hostmask> * <servername> <maxdepth>" | |
3013 | 242 RPL_STATSUPTIME | |
3014 | ":Server Up %d days %d:%02d:%02d" | |
3015 | 243 RPL_STATSOLINE | |
3016 | "O <hostmask> * <name>" | |
3017 | 244 RPL_STATSHLINE | |
3018 | "H <hostmask> * <servername>" | |
3019 | ||
3020 | 221 RPL_UMODEIS | |
3021 | "<user mode string>" | |
3022 | ||
3023 | ||
3024 | ||
3025 | ||
3026 | Oikarinen & Reed [Page 54] | |
3027 | \f | |
3028 | RFC 1459 Internet Relay Chat Protocol May 1993 | |
3029 | ||
3030 | ||
3031 | - To answer a query about a client's own mode, | |
3032 | RPL_UMODEIS is sent back. | |
3033 | ||
3034 | 251 RPL_LUSERCLIENT | |
3035 | ":There are <integer> users and <integer> \ | |
3036 | invisible on <integer> servers" | |
3037 | 252 RPL_LUSEROP | |
3038 | "<integer> :operator(s) online" | |
3039 | 253 RPL_LUSERUNKNOWN | |
3040 | "<integer> :unknown connection(s)" | |
3041 | 254 RPL_LUSERCHANNELS | |
3042 | "<integer> :channels formed" | |
3043 | 255 RPL_LUSERME | |
3044 | ":I have <integer> clients and <integer> \ | |
3045 | servers" | |
3046 | ||
3047 | - In processing an LUSERS message, the server | |
3048 | sends a set of replies from RPL_LUSERCLIENT, | |
3049 | RPL_LUSEROP, RPL_USERUNKNOWN, | |
3050 | RPL_LUSERCHANNELS and RPL_LUSERME. When | |
3051 | replying, a server must send back | |
3052 | RPL_LUSERCLIENT and RPL_LUSERME. The other | |
3053 | replies are only sent back if a non-zero count | |
3054 | is found for them. | |
3055 | ||
3056 | 256 RPL_ADMINME | |
3057 | "<server> :Administrative info" | |
3058 | 257 RPL_ADMINLOC1 | |
3059 | ":<admin info>" | |
3060 | 258 RPL_ADMINLOC2 | |
3061 | ":<admin info>" | |
3062 | 259 RPL_ADMINEMAIL | |
3063 | ":<admin info>" | |
3064 | ||
3065 | - When replying to an ADMIN message, a server | |
3066 | is expected to use replies RLP_ADMINME | |
3067 | through to RPL_ADMINEMAIL and provide a text | |
3068 | message with each. For RPL_ADMINLOC1 a | |
3069 | description of what city, state and country | |
3070 | the server is in is expected, followed by | |
3071 | details of the university and department | |
3072 | (RPL_ADMINLOC2) and finally the administrative | |
3073 | contact for the server (an email address here | |
3074 | is required) in RPL_ADMINEMAIL. | |
3075 | ||
3076 | ||
3077 | ||
3078 | ||
3079 | ||
3080 | ||
3081 | ||
3082 | Oikarinen & Reed [Page 55] | |
3083 | \f | |
3084 | RFC 1459 Internet Relay Chat Protocol May 1993 | |
3085 | ||
3086 | ||
3087 | 6.3 Reserved numerics. | |
3088 | ||
3089 | These numerics are not described above since they fall into one of | |
3090 | the following categories: | |
3091 | ||
3092 | 1. no longer in use; | |
3093 | ||
3094 | 2. reserved for future planned use; | |
3095 | ||
3096 | 3. in current use but are part of a non-generic 'feature' of | |
3097 | the current IRC server. | |
3098 | ||
3099 | 209 RPL_TRACECLASS 217 RPL_STATSQLINE | |
3100 | 231 RPL_SERVICEINFO 232 RPL_ENDOFSERVICES | |
3101 | 233 RPL_SERVICE 234 RPL_SERVLIST | |
3102 | 235 RPL_SERVLISTEND | |
3103 | 316 RPL_WHOISCHANOP 361 RPL_KILLDONE | |
3104 | 362 RPL_CLOSING 363 RPL_CLOSEEND | |
3105 | 373 RPL_INFOSTART 384 RPL_MYPORTIS | |
3106 | 466 ERR_YOUWILLBEBANNED 476 ERR_BADCHANMASK | |
3107 | 492 ERR_NOSERVICEHOST | |
3108 | ||
3109 | 7. Client and server authentication | |
3110 | ||
3111 | Clients and servers are both subject to the same level of | |
3112 | authentication. For both, an IP number to hostname lookup (and | |
3113 | reverse check on this) is performed for all connections made to the | |
3114 | server. Both connections are then subject to a password check (if | |
3115 | there is a password set for that connection). These checks are | |
3116 | possible on all connections although the password check is only | |
3117 | commonly used with servers. | |
3118 | ||
3119 | An additional check that is becoming of more and more common is that | |
3120 | of the username responsible for making the connection. Finding the | |
3121 | username of the other end of the connection typically involves | |
3122 | connecting to an authentication server such as IDENT as described in | |
3123 | RFC 1413. | |
3124 | ||
3125 | Given that without passwords it is not easy to reliably determine who | |
3126 | is on the other end of a network connection, use of passwords is | |
3127 | strongly recommended on inter-server connections in addition to any | |
3128 | other measures such as using an ident server. | |
3129 | ||
3130 | 8. Current implementations | |
3131 | ||
3132 | The only current implementation of this protocol is the IRC server, | |
3133 | version 2.8. Earlier versions may implement some or all of the | |
3134 | commands described by this document with NOTICE messages replacing | |
3135 | ||
3136 | ||
3137 | ||
3138 | Oikarinen & Reed [Page 56] | |
3139 | \f | |
3140 | RFC 1459 Internet Relay Chat Protocol May 1993 | |
3141 | ||
3142 | ||
3143 | many of the numeric replies. Unfortunately, due to backward | |
3144 | compatibility requirements, the implementation of some parts of this | |
3145 | document varies with what is laid out. On notable difference is: | |
3146 | ||
3147 | * recognition that any LF or CR anywhere in a message marks the | |
3148 | end of that message (instead of requiring CR-LF); | |
3149 | ||
3150 | The rest of this section deals with issues that are mostly of | |
3151 | importance to those who wish to implement a server but some parts | |
3152 | also apply directly to clients as well. | |
3153 | ||
3154 | 8.1 Network protocol: TCP - why it is best used here. | |
3155 | ||
3156 | IRC has been implemented on top of TCP since TCP supplies a reliable | |
3157 | network protocol which is well suited to this scale of conferencing. | |
3158 | The use of multicast IP is an alternative, but it is not widely | |
3159 | available or supported at the present time. | |
3160 | ||
3161 | 8.1.1 Support of Unix sockets | |
3162 | ||
3163 | Given that Unix domain sockets allow listen/connect operations, the | |
3164 | current implementation can be configured to listen and accept both | |
3165 | client and server connections on a Unix domain socket. These are | |
3166 | recognized as sockets where the hostname starts with a '/'. | |
3167 | ||
3168 | When providing any information about the connections on a Unix domain | |
3169 | socket, the server is required to supplant the actual hostname in | |
3170 | place of the pathname unless the actual socket name is being asked | |
3171 | for. | |
3172 | ||
3173 | 8.2 Command Parsing | |
3174 | ||
3175 | To provide useful 'non-buffered' network IO for clients and servers, | |
3176 | each connection is given its own private 'input buffer' in which the | |
3177 | results of the most recent read and parsing are kept. A buffer size | |
3178 | of 512 bytes is used so as to hold 1 full message, although, this | |
3179 | will usually hold several commands. The private buffer is parsed | |
3180 | after every read operation for valid messages. When dealing with | |
3181 | multiple messages from one client in the buffer, care should be taken | |
3182 | in case one happens to cause the client to be 'removed'. | |
3183 | ||
3184 | 8.3 Message delivery | |
3185 | ||
3186 | It is common to find network links saturated or hosts to which you | |
3187 | are sending data unable to send data. Although Unix typically | |
3188 | handles this through the TCP window and internal buffers, the server | |
3189 | often has large amounts of data to send (especially when a new | |
3190 | server-server link forms) and the small buffers provided in the | |
3191 | ||
3192 | ||
3193 | ||
3194 | Oikarinen & Reed [Page 57] | |
3195 | \f | |
3196 | RFC 1459 Internet Relay Chat Protocol May 1993 | |
3197 | ||
3198 | ||
3199 | kernel are not enough for the outgoing queue. To alleviate this | |
3200 | problem, a "send queue" is used as a FIFO queue for data to be sent. | |
3201 | A typical "send queue" may grow to 200 Kbytes on a large IRC network | |
3202 | with a slow network connection when a new server connects. | |
3203 | ||
3204 | When polling its connections, a server will first read and parse all | |
3205 | incoming data, queuing any data to be sent out. When all available | |
3206 | input is processed, the queued data is sent. This reduces the number | |
3207 | of write() system calls and helps TCP make bigger packets. | |
3208 | ||
3209 | 8.4 Connection 'Liveness' | |
3210 | ||
3211 | To detect when a connection has died or become unresponsive, the | |
3212 | server must ping each of its connections that it doesn't get a | |
3213 | response from in a given amount of time. | |
3214 | ||
3215 | If a connection doesn't respond in time, its connection is closed | |
3216 | using the appropriate procedures. A connection is also dropped if | |
3217 | its sendq grows beyond the maximum allowed, because it is better to | |
3218 | close a slow connection than have a server process block. | |
3219 | ||
3220 | 8.5 Establishing a server to client connection | |
3221 | ||
3222 | Upon connecting to an IRC server, a client is sent the MOTD (if | |
3223 | present) as well as the current user/server count (as per the LUSER | |
3224 | command). The server is also required to give an unambiguous message | |
3225 | to the client which states its name and version as well as any other | |
3226 | introductory messages which may be deemed appropriate. | |
3227 | ||
3228 | After dealing with this, the server must then send out the new user's | |
3229 | nickname and other information as supplied by itself (USER command) | |
3230 | and as the server could discover (from DNS/authentication servers). | |
3231 | The server must send this information out with NICK first followed by | |
3232 | USER. | |
3233 | ||
3234 | 8.6 Establishing a server-server connection. | |
3235 | ||
3236 | The process of establishing of a server-to-server connection is | |
3237 | fraught with danger since there are many possible areas where | |
3238 | problems can occur - the least of which are race conditions. | |
3239 | ||
3240 | After a server has received a connection following by a PASS/SERVER | |
3241 | pair which were recognised as being valid, the server should then | |
3242 | reply with its own PASS/SERVER information for that connection as | |
3243 | well as all of the other state information it knows about as | |
3244 | described below. | |
3245 | ||
3246 | When the initiating server receives a PASS/SERVER pair, it too then | |
3247 | ||
3248 | ||
3249 | ||
3250 | Oikarinen & Reed [Page 58] | |
3251 | \f | |
3252 | RFC 1459 Internet Relay Chat Protocol May 1993 | |
3253 | ||
3254 | ||
3255 | checks that the server responding is authenticated properly before | |
3256 | accepting the connection to be that server. | |
3257 | ||
3258 | 8.6.1 Server exchange of state information when connecting | |
3259 | ||
3260 | The order of state information being exchanged between servers is | |
3261 | essential. The required order is as follows: | |
3262 | ||
3263 | * all known other servers; | |
3264 | ||
3265 | * all known user information; | |
3266 | ||
3267 | * all known channel information. | |
3268 | ||
3269 | Information regarding servers is sent via extra SERVER messages, user | |
3270 | information with NICK/USER/MODE/JOIN messages and channels with MODE | |
3271 | messages. | |
3272 | ||
3273 | NOTE: channel topics are *NOT* exchanged here because the TOPIC | |
3274 | command overwrites any old topic information, so at best, the two | |
3275 | sides of the connection would exchange topics. | |
3276 | ||
3277 | By passing the state information about servers first, any collisions | |
3278 | with servers that already exist occur before nickname collisions due | |
3279 | to a second server introducing a particular nickname. Due to the IRC | |
3280 | network only being able to exist as an acyclic graph, it may be | |
3281 | possible that the network has already reconnected in another | |
3282 | location, the place where the collision occurs indicating where the | |
3283 | net needs to split. | |
3284 | ||
3285 | 8.7 Terminating server-client connections | |
3286 | ||
3287 | When a client connection closes, a QUIT message is generated on | |
3288 | behalf of the client by the server to which the client connected. No | |
3289 | other message is to be generated or used. | |
3290 | ||
3291 | 8.8 Terminating server-server connections | |
3292 | ||
3293 | If a server-server connection is closed, either via a remotely | |
3294 | generated SQUIT or 'natural' causes, the rest of the connected IRC | |
3295 | network must have its information updated with by the server which | |
3296 | detected the closure. The server then sends a list of SQUITs (one | |
3297 | for each server behind that connection) and a list of QUITs (again, | |
3298 | one for each client behind that connection). | |
3299 | ||
3300 | ||
3301 | ||
3302 | ||
3303 | ||
3304 | ||
3305 | ||
3306 | Oikarinen & Reed [Page 59] | |
3307 | \f | |
3308 | RFC 1459 Internet Relay Chat Protocol May 1993 | |
3309 | ||
3310 | ||
3311 | 8.9 Tracking nickname changes | |
3312 | ||
3313 | All IRC servers are required to keep a history of recent nickname | |
3314 | changes. This is required to allow the server to have a chance of | |
3315 | keeping in touch of things when nick-change race conditions occur | |
3316 | with commands which manipulate them. Commands which must trace nick | |
3317 | changes are: | |
3318 | ||
3319 | * KILL (the nick being killed) | |
3320 | ||
3321 | * MODE (+/- o,v) | |
3322 | ||
3323 | * KICK (the nick being kicked) | |
3324 | ||
3325 | No other commands are to have nick changes checked for. | |
3326 | ||
3327 | In the above cases, the server is required to first check for the | |
3328 | existence of the nickname, then check its history to see who that | |
3329 | nick currently belongs to (if anyone!). This reduces the chances of | |
3330 | race conditions but they can still occur with the server ending up | |
3331 | affecting the wrong client. When performing a change trace for an | |
3332 | above command it is recommended that a time range be given and | |
3333 | entries which are too old ignored. | |
3334 | ||
3335 | For a reasonable history, a server should be able to keep previous | |
3336 | nickname for every client it knows about if they all decided to | |
3337 | change. This size is limited by other factors (such as memory, etc). | |
3338 | ||
3339 | 8.10 Flood control of clients | |
3340 | ||
3341 | With a large network of interconnected IRC servers, it is quite easy | |
3342 | for any single client attached to the network to supply a continuous | |
3343 | stream of messages that result in not only flooding the network, but | |
3344 | also degrading the level of service provided to others. Rather than | |
3345 | require every 'victim' to be provide their own protection, flood | |
3346 | protection was written into the server and is applied to all clients | |
3347 | except services. The current algorithm is as follows: | |
3348 | ||
3349 | * check to see if client's `message timer' is less than | |
3350 | current time (set to be equal if it is); | |
3351 | ||
3352 | * read any data present from the client; | |
3353 | ||
3354 | * while the timer is less than ten seconds ahead of the current | |
3355 | time, parse any present messages and penalize the client by | |
3356 | 2 seconds for each message; | |
3357 | ||
3358 | which in essence means that the client may send 1 message every 2 | |
3359 | ||
3360 | ||
3361 | ||
3362 | Oikarinen & Reed [Page 60] | |
3363 | \f | |
3364 | RFC 1459 Internet Relay Chat Protocol May 1993 | |
3365 | ||
3366 | ||
3367 | seconds without being adversely affected. | |
3368 | ||
3369 | 8.11 Non-blocking lookups | |
3370 | ||
3371 | In a real-time environment, it is essential that a server process do | |
3372 | as little waiting as possible so that all the clients are serviced | |
3373 | fairly. Obviously this requires non-blocking IO on all network | |
3374 | read/write operations. For normal server connections, this was not | |
3375 | difficult, but there are other support operations that may cause the | |
3376 | server to block (such as disk reads). Where possible, such activity | |
3377 | should be performed with a short timeout. | |
3378 | ||
3379 | 8.11.1 Hostname (DNS) lookups | |
3380 | ||
3381 | Using the standard resolver libraries from Berkeley and others has | |
3382 | meant large delays in some cases where replies have timed out. To | |
3383 | avoid this, a separate set of DNS routines were written which were | |
3384 | setup for non-blocking IO operations and then polled from within the | |
3385 | main server IO loop. | |
3386 | ||
3387 | 8.11.2 Username (Ident) lookups | |
3388 | ||
3389 | Although there are numerous ident libraries for use and inclusion | |
3390 | into other programs, these caused problems since they operated in a | |
3391 | synchronous manner and resulted in frequent delays. Again the | |
3392 | solution was to write a set of routines which would cooperate with | |
3393 | the rest of the server and work using non-blocking IO. | |
3394 | ||
3395 | 8.12 Configuration File | |
3396 | ||
3397 | To provide a flexible way of setting up and running the server, it is | |
3398 | recommended that a configuration file be used which contains | |
3399 | instructions to the server on the following: | |
3400 | ||
3401 | * which hosts to accept client connections from; | |
3402 | ||
3403 | * which hosts to allow to connect as servers; | |
3404 | ||
3405 | * which hosts to connect to (both actively and | |
3406 | passively); | |
3407 | ||
3408 | * information about where the server is (university, | |
3409 | city/state, company are examples of this); | |
3410 | ||
3411 | * who is responsible for the server and an email address | |
3412 | at which they can be contacted; | |
3413 | ||
3414 | * hostnames and passwords for clients which wish to be given | |
3415 | ||
3416 | ||
3417 | ||
3418 | Oikarinen & Reed [Page 61] | |
3419 | \f | |
3420 | RFC 1459 Internet Relay Chat Protocol May 1993 | |
3421 | ||
3422 | ||
3423 | access to restricted operator commands. | |
3424 | ||
3425 | In specifying hostnames, both domain names and use of the 'dot' | |
3426 | notation (127.0.0.1) should both be accepted. It must be possible to | |
3427 | specify the password to be used/accepted for all outgoing and | |
3428 | incoming connections (although the only outgoing connections are | |
3429 | those to other servers). | |
3430 | ||
3431 | The above list is the minimum requirement for any server which wishes | |
3432 | to make a connection with another server. Other items which may be | |
3433 | of use are: | |
3434 | ||
3435 | * specifying which servers other server may introduce; | |
3436 | ||
3437 | * how deep a server branch is allowed to become; | |
3438 | ||
3439 | * hours during which clients may connect. | |
3440 | ||
3441 | 8.12.1 Allowing clients to connect | |
3442 | ||
3443 | A server should use some sort of 'access control list' (either in the | |
3444 | configuration file or elsewhere) that is read at startup and used to | |
3445 | decide what hosts clients may use to connect to it. | |
3446 | ||
3447 | Both 'deny' and 'allow' should be implemented to provide the required | |
3448 | flexibility for host access control. | |
3449 | ||
3450 | 8.12.2 Operators | |
3451 | ||
3452 | The granting of operator privileges to a disruptive person can have | |
3453 | dire consequences for the well-being of the IRC net in general due to | |
3454 | the powers given to them. Thus, the acquisition of such powers | |
3455 | should not be very easy. The current setup requires two 'passwords' | |
3456 | to be used although one of them is usually easy guessed. Storage of | |
3457 | oper passwords in configuration files is preferable to hard coding | |
3458 | them in and should be stored in a crypted format (ie using crypt(3) | |
3459 | from Unix) to prevent easy theft. | |
3460 | ||
3461 | 8.12.3 Allowing servers to connect | |
3462 | ||
3463 | The interconnection of server is not a trivial matter: a bad | |
3464 | connection can have a large impact on the usefulness of IRC. Thus, | |
3465 | each server should have a list of servers to which it may connect and | |
3466 | which servers may connect to it. Under no circumstances should a | |
3467 | server allow an arbitrary host to connect as a server. In addition | |
3468 | to which servers may and may not connect, the configuration file | |
3469 | should also store the password and other characteristics of that | |
3470 | link. | |
3471 | ||
3472 | ||
3473 | ||
3474 | Oikarinen & Reed [Page 62] | |
3475 | \f | |
3476 | RFC 1459 Internet Relay Chat Protocol May 1993 | |
3477 | ||
3478 | ||
3479 | 8.12.4 Administrivia | |
3480 | ||
3481 | To provide accurate and valid replies to the ADMIN command (see | |
3482 | section 4.3.7), the server should find the relevant details in the | |
3483 | configuration. | |
3484 | ||
3485 | 8.13 Channel membership | |
3486 | ||
3487 | The current server allows any registered local user to join upto 10 | |
3488 | different channels. There is no limit imposed on non-local users so | |
3489 | that the server remains (reasonably) consistant with all others on a | |
3490 | channel membership basis | |
3491 | ||
3492 | 9. Current problems | |
3493 | ||
3494 | There are a number of recognized problems with this protocol, all of | |
3495 | which hope to be solved sometime in the near future during its | |
3496 | rewrite. Currently, work is underway to find working solutions to | |
3497 | these problems. | |
3498 | ||
3499 | 9.1 Scalability | |
3500 | ||
3501 | It is widely recognized that this protocol does not scale | |
3502 | sufficiently well when used in a large arena. The main problem comes | |
3503 | from the requirement that all servers know about all other servers | |
3504 | and users and that information regarding them be updated as soon as | |
3505 | it changes. It is also desirable to keep the number of servers low | |
3506 | so that the path length between any two points is kept minimal and | |
3507 | the spanning tree as strongly branched as possible. | |
3508 | ||
3509 | 9.2 Labels | |
3510 | ||
3511 | The current IRC protocol has 3 types of labels: the nickname, the | |
3512 | channel name and the server name. Each of the three types has its | |
3513 | own domain and no duplicates are allowed inside that domain. | |
3514 | Currently, it is possible for users to pick the label for any of the | |
3515 | three, resulting in collisions. It is widely recognized that this | |
3516 | needs reworking, with a plan for unique names for channels and nicks | |
3517 | that don't collide being desirable as well as a solution allowing a | |
3518 | cyclic tree. | |
3519 | ||
3520 | 9.2.1 Nicknames | |
3521 | ||
3522 | The idea of the nickname on IRC is very convenient for users to use | |
3523 | when talking to each other outside of a channel, but there is only a | |
3524 | finite nickname space and being what they are, its not uncommon for | |
3525 | several people to want to use the same nick. If a nickname is chosen | |
3526 | by two people using this protocol, either one will not succeed or | |
3527 | ||
3528 | ||
3529 | ||
3530 | Oikarinen & Reed [Page 63] | |
3531 | \f | |
3532 | RFC 1459 Internet Relay Chat Protocol May 1993 | |
3533 | ||
3534 | ||
3535 | both will removed by use of KILL (4.6.1). | |
3536 | ||
3537 | 9.2.2 Channels | |
3538 | ||
3539 | The current channel layout requires that all servers know about all | |
3540 | channels, their inhabitants and properties. Besides not scaling | |
3541 | well, the issue of privacy is also a concern. A collision of | |
3542 | channels is treated as an inclusive event (both people who create the | |
3543 | new channel are considered to be members of it) rather than an | |
3544 | exclusive one such as used to solve nickname collisions. | |
3545 | ||
3546 | 9.2.3 Servers | |
3547 | ||
3548 | Although the number of servers is usually small relative to the | |
3549 | number of users and channels, they two currently required to be known | |
3550 | globally, either each one separately or hidden behind a mask. | |
3551 | ||
3552 | 9.3 Algorithms | |
3553 | ||
3554 | In some places within the server code, it has not been possible to | |
3555 | avoid N^2 algorithms such as checking the channel list of a set | |
3556 | of clients. | |
3557 | ||
3558 | In current server versions, there are no database consistency checks, | |
3559 | each server assumes that a neighbouring server is correct. This | |
3560 | opens the door to large problems if a connecting server is buggy or | |
3561 | otherwise tries to introduce contradictions to the existing net. | |
3562 | ||
3563 | Currently, because of the lack of unique internal and global labels, | |
3564 | there are a multitude of race conditions that exist. These race | |
3565 | conditions generally arise from the problem of it taking time for | |
3566 | messages to traverse and effect the IRC network. Even by changing to | |
3567 | unique labels, there are problems with channel-related commands being | |
3568 | disrupted. | |
3569 | ||
3570 | 10. Current support and availability | |
3571 | ||
3572 | Mailing lists for IRC related discussion: | |
3573 | Future protocol: ircd-three-request@eff.org | |
3574 | General discussion: operlist-request@eff.org | |
3575 | ||
3576 | Software implemenations | |
3577 | cs.bu.edu:/irc | |
3578 | nic.funet.fi:/pub/irc | |
3579 | coombs.anu.edu.au:/pub/irc | |
3580 | ||
3581 | Newsgroup: alt.irc | |
3582 | ||
3583 | ||
3584 | ||
3585 | ||
3586 | Oikarinen & Reed [Page 64] | |
3587 | \f | |
3588 | RFC 1459 Internet Relay Chat Protocol May 1993 | |
3589 | ||
3590 | ||
3591 | Security Considerations | |
3592 | ||
3593 | Security issues are discussed in sections 4.1, 4.1.1, 4.1.3, 5.5, and | |
3594 | 7. | |
3595 | ||
3596 | 12. Authors' Addresses | |
3597 | ||
3598 | Jarkko Oikarinen | |
3599 | Tuirantie 17 as 9 | |
3600 | 90500 OULU | |
3601 | FINLAND | |
3602 | ||
3603 | Email: jto@tolsun.oulu.fi | |
3604 | ||
3605 | ||
3606 | Darren Reed | |
3607 | 4 Pateman Street | |
3608 | Watsonia, Victoria 3087 | |
3609 | Australia | |
3610 | ||
3611 | Email: avalon@coombs.anu.edu.au | |
3612 | ||
3613 | ||
3614 | ||
3615 | ||
3616 | ||
3617 | ||
3618 | ||
3619 | ||
3620 | ||
3621 | ||
3622 | ||
3623 | ||
3624 | ||
3625 | ||
3626 | ||
3627 | ||
3628 | ||
3629 | ||
3630 | ||
3631 | ||
3632 | ||
3633 | ||
3634 | ||
3635 | ||
3636 | ||
3637 | ||
3638 | ||
3639 | ||
3640 | ||
3641 | ||
3642 | Oikarinen & Reed [Page 65] | |
3643 | \f |