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