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