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