ViewVC Help
View File | Revision Log | Show Annotations | View Changeset | Root Listing
root/svn/ircd-hybrid/doc/technical/rfc1459.txt
Revision: 32
Committed: Sun Oct 2 20:41:23 2005 UTC (18 years, 5 months ago) by knight
Content type: text/plain
File size: 129083 byte(s)
Log Message:
- svn:keywords

File Contents

# Content
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

Properties

Name Value
svn:eol-style native
svn:keywords Revision