1 Network Working Group J. Oikarinen
2 Request for Comments: 1459 D. Reed
6 Internet Relay Chat Protocol
8 Undernet Specific Annotations and Changes
9 This document exists here in order to attempt to describe the existing
10 protocol that is currently in use on the Undernet IRC Network. Since
11 the original standard was released, many networks have made
12 significant changes and enhancements to the protocol described in the
13 original version of this document. This version of the standard should
14 be updated by the current maintainers of the Undernet server software
15 distribution as changes are made that affect the protocol. Please be
16 aware that some sections may be out of date.
20 This memo defines an Experimental Protocol for the Internet
21 community. Discussion and suggestions for improvement are requested.
22 Please refer to the current edition of the "IAB Official Protocol
23 Standards" for the standardization state and status of this protocol.
24 Distribution of this memo is unlimited.
28 The IRC protocol was developed over the last 4 years since it was
29 first implemented as a means for users on a BBS to chat amongst
30 themselves. Now it supports a world-wide network of servers and
31 clients, and is stringing to cope with growth. Over the past 2 years,
32 the average number of users connected to the main IRC network has
33 grown by a factor of 10.
35 The IRC protocol is a text-based protocol, with the simplest client
36 being any socket program capable of connecting to the server.
40 1. INTRODUCTION ............................................... 4
41 1.1 Servers ................................................ 4
42 1.2 Clients ................................................ 5
43 1.2.1 Operators .......................................... 5
44 1.3 Channels ................................................ 5
45 1.3.1 Channel Operators .................................... 6
46 2. THE IRC SPECIFICATION ....................................... 7
47 2.1 Overview ................................................ 7
48 2.2 Character codes ......................................... 7
49 2.3 Messages ................................................ 7
50 2.3.1 Message format in 'pseudo' BNF .................... 8
51 2.4 Numeric replies ......................................... 10
52 3. IRC Concepts ................................................ 10
53 3.1 One-to-one communication ................................ 10
54 3.2 One-to-many ............................................. 11
55 3.2.1 To a list .......................................... 11
56 3.2.2 To a group (channel) ............................... 11
57 3.2.3 To a host/server mask .............................. 12
58 3.3 One to all .............................................. 12
62 Oikarinen & Reed [Page 1]
64 RFC 1459 Internet Relay Chat Protocol May 1993
67 3.3.1 Client to Client ................................... 12
68 3.3.2 Clients to Server .................................. 12
69 3.3.3 Server to Server ................................... 12
70 4. MESSAGE DETAILS ............................................. 13
71 4.1 Connection Registration ................................. 13
72 4.1.1 Password message ................................... 14
73 4.1.2 Nickname message ................................... 14
74 4.1.3 User message ....................................... 15
75 4.1.4 Server message ..................................... 16
76 4.1.5 Operator message ................................... 17
77 4.1.6 Quit message ....................................... 17
78 4.1.7 Server Quit message ................................ 18
79 4.2 Channel operations ...................................... 19
80 4.2.1 Join message ....................................... 19
81 4.2.2 Part message ....................................... 20
82 4.2.3 Mode message ....................................... 21
83 4.2.3.1 Channel modes ................................. 21
84 4.2.3.2 User modes .................................... 22
85 4.2.4 Topic message ...................................... 23
86 4.2.5 Names message ...................................... 24
87 4.2.6 List message ....................................... 24
88 4.2.7 Invite message ..................................... 25
89 4.2.8 Kick message ....................................... 25
90 4.3 Server queries and commands ............................. 26
91 4.3.1 Version message .................................... 26
92 4.3.2 Stats message ...................................... 27
93 4.3.3 Links message ...................................... 28
94 4.3.4 Time message ....................................... 29
95 4.3.5 Connect message .................................... 29
96 4.3.6 Trace message ...................................... 30
97 4.3.7 Admin message ...................................... 31
98 4.3.8 Info message ....................................... 31
99 4.4 Sending messages ........................................ 32
100 4.4.1 Private messages ................................... 32
101 4.4.2 Notice messages .................................... 33
102 4.5 User-based queries ...................................... 33
103 4.5.1 Who query .......................................... 33
104 4.5.2 Whois query ........................................ 34
105 4.5.3 Whowas message ..................................... 35
106 4.6 Miscellaneous messages .................................. 35
107 4.6.1 Kill message ....................................... 36
108 4.6.2 Ping message ....................................... 37
109 4.6.3 Pong message ....................................... 37
110 4.6.4 Error message ...................................... 38
111 5. OPTIONAL MESSAGES ........................................... 38
112 5.1 Away message ............................................ 38
113 5.2 Rehash command .......................................... 39
114 5.3 Restart command ......................................... 39
118 Oikarinen & Reed [Page 2]
120 RFC 1459 Internet Relay Chat Protocol May 1993
123 5.4 Summon message .......................................... 40
124 5.5 Users message ........................................... 40
125 5.6 Operwall command ........................................ 41
126 5.7 Userhost message ........................................ 42
127 5.8 Ison message ............................................ 42
128 6. REPLIES ..................................................... 43
129 6.1 Error Replies ........................................... 43
130 6.2 Command responses ....................................... 48
131 6.3 Reserved numerics ....................................... 56
132 7. Client and server authentication ............................ 56
133 8. Current Implementations Details ............................. 56
134 8.1 Network protocol: TCP ................................... 57
135 8.1.1 Support of Unix sockets ............................ 57
136 8.2 Command Parsing ......................................... 57
137 8.3 Message delivery ........................................ 57
138 8.4 Connection 'Liveness' ................................... 58
139 8.5 Establishing a server-client connection ................. 58
140 8.6 Establishing a server-server connection ................. 58
141 8.6.1 State information exchange when connecting ......... 59
142 8.7 Terminating server-client connections ................... 59
143 8.8 Terminating server-server connections ................... 59
144 8.9 Tracking nickname changes ............................... 60
145 8.10 Flood control of clients ............................... 60
146 8.11 Non-blocking lookups ................................... 61
147 8.11.1 Hostname (DNS) lookups ............................ 61
148 8.11.2 Username (Ident) lookups .......................... 61
149 8.12 Configuration file ..................................... 61
150 8.12.1 Allowing clients to connect ....................... 62
151 8.12.2 Operators ......................................... 62
152 8.12.3 Allowing servers to connect ....................... 62
153 8.12.4 Administrivia ..................................... 63
154 8.13 Channel membership ..................................... 63
155 9. Current problems ............................................ 63
156 9.1 Scalability ............................................. 63
157 9.2 Labels .................................................. 63
158 9.2.1 Nicknames .......................................... 63
159 9.2.2 Channels ........................................... 64
160 9.2.3 Servers ............................................ 64
161 9.3 Algorithms .............................................. 64
162 10. Support and availability ................................... 64
163 11. Security Considerations .................................... 65
164 12. Authors' Addresses ......................................... 65
174 Oikarinen & Reed [Page 3]
176 RFC 1459 Internet Relay Chat Protocol May 1993
181 The IRC (Internet Relay Chat) protocol has been designed over a
182 number of years for use with text based conferencing. This document
183 describes the current IRC protocol.
185 The IRC protocol has been developed on systems using the TCP/IP
186 network protocol, although there is no requirement that this remain
187 the only sphere in which it operates.
189 IRC itself is a teleconferencing system, which (through the use of
190 the client-server model) is well-suited to running on many machines
191 in a distributed fashion. A typical setup involves a single process
192 (the server) forming a central point for clients (or other servers)
193 to connect to, performing the required message delivery/multiplexing
198 The server forms the backbone of IRC, providing a point to which
199 clients may connect to to talk to each other, and a point for other
200 servers to connect to, forming an IRC network. The only network
201 configuration allowed for IRC servers is that of a spanning tree [see
202 Fig. 1] where each server acts as a central node for the rest of the
206 [ Server 15 ] [ Server 13 ] [ Server 14]
209 [ Server 11 ] ------ [ Server 1 ] [ Server 12]
212 [ Server 2 ] [ Server 3 ]
215 [ Server 4 ] [ Server 5 ] [ Server 6 ]
220 [ Server 7 ] [ Server 8 ] [ Server 9 ] [ Server 10 ]
226 [ Fig. 1. Format of IRC server network ]
230 Oikarinen & Reed [Page 4]
232 RFC 1459 Internet Relay Chat Protocol May 1993
237 A client is anything connecting to a server that is not another
238 server. Each client is distinguished from other clients by a unique
239 nickname having a maximum length of nine (9) characters. See the
240 protocol grammar rules for what may and may not be used in a
241 nickname. In addition to the nickname, all servers must have the
242 following information about all clients: the real name of the host
243 that the client is running on, the username of the client on that
244 host, and the server to which the client is connected.
248 To allow a reasonable amount of order to be kept within the IRC
249 network, a special class of clients (operators) is allowed to perform
250 general maintenance functions on the network. Although the powers
251 granted to an operator can be considered as 'dangerous', they are
252 nonetheless required. Operators should be able to perform basic
253 network tasks such as disconnecting and reconnecting servers as
254 needed to prevent long-term use of bad network routing. In
255 recognition of this need, the protocol discussed herein provides for
256 operators only to be able to perform such functions. See sections
257 4.1.7 (SQUIT) and 4.3.5 (CONNECT).
259 A more controversial power of operators is the ability to remove a
260 user from the connected network by 'force', i.e. operators are able
261 to close the connection between any client and server. The
262 justification for this is delicate since its abuse is both
263 destructive and annoying. For further details on this type of
264 action, see section 4.6.1 (KILL).
268 A channel is a named group of one or more clients which will all
269 receive messages addressed to that channel. The channel is created
270 implicitly when the first client joins it, and the channel ceases to
271 exist when the last client leaves it. While channel exists, any
272 client can reference the channel using the name of the channel.
274 Channels names are strings (beginning with a '&' or '#' character) of
275 length up to 200 characters. Apart from the the requirement that the
276 first character being either '&' or '#'; the only restriction on a
277 channel name is that it may not contain any spaces (' '), a control G
278 (^G or ASCII 7), or a comma (',' which is used as a list item
279 separator by the protocol).
281 There are two types of channels allowed by this protocol. One is a
282 distributed channel which is known to all the servers that are
286 Oikarinen & Reed [Page 5]
288 RFC 1459 Internet Relay Chat Protocol May 1993
291 connected to the network. These channels are marked by the first
292 character being a only clients on the server where it exists may join
293 it. These are distinguished by a leading '&' character. On top of
294 these two types, there are the various channel modes available to
295 alter the characteristics of individual channels. See section 4.2.3
296 (MODE command) for more details on this.
298 To create a new channel or become part of an existing channel, a user
299 is required to JOIN the channel. If the channel doesn't exist prior
300 to joining, the channel is created and the creating user becomes a
301 channel operator. If the channel already exists, whether or not your
302 request to JOIN that channel is honoured depends on the current modes
303 of the channel. For example, if the channel is invite-only, (+i),
304 then you may only join if invited. As part of the protocol, a user
305 may be a part of several channels at once, but a limit of ten (10)
306 channels is recommended as being ample for both experienced and
307 novice users. See section 8.13 for more information on this.
309 If the IRC network becomes disjoint because of a split between two
310 servers, the channel on each side is only composed of those clients
311 which are connected to servers on the respective sides of the split,
312 possibly ceasing to exist on one side of the split. When the split
313 is healed, the connecting servers announce to each other who they
314 think is in each channel and the mode of that channel. If the
315 channel exists on both sides, the JOINs and MODEs are interpreted in
316 an inclusive manner so that both sides of the new connection will
317 agree about which clients are in the channel and what modes the
320 1.3.1 Channel Operators
322 The channel operator (also referred to as a "chop" or "chanop") on a
323 given channel is considered to 'own' that channel. In recognition of
324 this status, channel operators are endowed with certain powers which
325 enable them to keep control and some sort of sanity in their channel.
326 As an owner of a channel, a channel operator is not required to have
327 reasons for their actions, although if their actions are generally
328 antisocial or otherwise abusive, it might be reasonable to ask an IRC
329 operator to intervene, or for the usersjust leave and go elsewhere
330 and form their own channel.
332 The commands which may only be used by channel operators are:
334 KICK - Eject a client from the channel
335 MODE - Change the channel's mode
336 INVITE - Invite a client to an invite-only channel (mode +i)
337 TOPIC - Change the channel topic in a mode +t channel
342 Oikarinen & Reed [Page 6]
344 RFC 1459 Internet Relay Chat Protocol May 1993
347 A channel operator is identified by the '@' symbol next to their
348 nickname whenever it is associated with a channel (ie replies to the
349 NAMES, WHO and WHOIS commands).
351 2. The IRC Specification
355 The protocol as described herein is for use both with server to
356 server and client to server connections. There are, however, more
357 restrictions on client connections (which are considered to be
358 untrustworthy) than on server connections.
362 No specific character set is specified. The protocol is based on a a
363 set of codes which are composed of eight (8) bits, making up an
364 octet. Each message may be composed of any number of these octets;
365 however, some octet values are used for control codes which act as
368 Regardless of being an 8-bit protocol, the delimiters and keywords
369 are such that protocol is mostly usable from USASCII terminal and a
372 Because of IRC's scandanavian origin, the characters {}| are
373 considered to be the lower case equivalents of the characters []\,
374 respectively. This is a critical issue when determining the
375 equivalence of two nicknames.
379 Servers and clients send eachother messages which may or may not
380 generate a reply. If the message contains a valid command, as
381 described in later sections, the client should expect a reply as
382 specified but it is not advised to wait forever for the reply; client
383 to server and server to server communication is essentially
384 asynchronous in nature.
386 Each IRC message may consist of up to three main parts: the prefix
387 (optional), the command, and the command parameters (of which there
388 may be up to 15). The prefix, command, and all parameters are
389 separated by one (or more) ASCII space character(s) (0x20).
391 The presence of a prefix is indicated with a single leading ASCII
392 colon character (':', 0x3b), which must be the first character of the
393 message itself. There must be no gap (whitespace) between the colon
394 and the prefix. The prefix is used by servers to indicate the true
398 Oikarinen & Reed [Page 7]
400 RFC 1459 Internet Relay Chat Protocol May 1993
403 origin of the message. If the prefix is missing from the message, it
404 is assumed to have originated from the connection from which it was
405 received. Clients should not use prefix when sending a message from
406 themselves; if they use a prefix, the only valid prefix is the
407 registered nickname associated with the client. If the source
408 identified by the prefix cannot be found from the server's internal
409 database, or if the source is registered from a different link than
410 from which the message arrived, the server must ignore the message
413 The command must either be a valid IRC command or a three (3) digit
414 number represented in ASCII text.
416 IRC messages are always lines of characters terminated with a CR-LF
417 (Carriage Return - Line Feed) pair, and these messages shall not
418 exceed 512 characters in length, counting all characters including
419 the trailing CR-LF. Thus, there are 510 characters maximum allowed
420 for the command and its parameters. There is no provision for
421 continuation message lines. See section 7 for more details about
422 current implementations.
424 2.3.1 Message format in 'pseudo' BNF
426 The protocol messages must be extracted from the contiguous stream of
427 octets. The current solution is to designate two characters, CR and
428 LF, as message separators. Empty messages are silently ignored,
429 which permits use of the sequence CR-LF between messages
430 without extra problems.
432 The extracted message is parsed into the components <prefix>,
433 <command> and list of parameters matched either by <middle> or
434 <trailing> components.
436 The BNF representation for this is:
439 <server_message> ::= <numeric> <command> <params> <crlf>
440 <message> ::= [':' <prefix> <SPACE> ] <command> <params> <crlf>
441 <prefix> ::= <servername> | <nick> [ '!' <user> ] [ '@' <host> ]
442 <command> ::= <letter> { <letter> } | <number> <number> <number>
443 <SPACE> ::= ' ' { ' ' }
444 <params> ::= <SPACE> [ ':' <trailing> | <middle> <params> ]
445 <numeric> ::= <numeric> { <letter> | <number> | '[' | ']' }
447 <middle> ::= <Any *non-empty* sequence of octets not including SPACE
448 or NUL or CR or LF, the first of which may not be ':'>
449 <trailing> ::= <Any, possibly *empty*, sequence of octets not including
456 Oikarinen & Reed [Page 8]
458 RFC 1459 Internet Relay Chat Protocol May 1993
463 1) <SPACE> is consists only of SPACE character(s) (0x20).
464 Specially notice that TABULATION, and all other control
465 characters are considered NON-WHITE-SPACE.
467 2) After extracting the parameter list, all parameters are equal,
468 whether matched by <middle> or <trailing>. <Trailing> is just
469 a syntactic trick to allow SPACE within parameter.
471 3) The fact that CR and LF cannot appear in parameter strings is
472 just artifact of the message framing. This might change later.
474 4) The NUL character is not special in message framing, and
475 basically could end up inside a parameter, but as it would
476 cause extra complexities in normal C string handling. Therefore
477 NUL is not allowed within messages.
479 5) The last parameter may be an empty string.
481 6) Use of the extended prefix (['!' <user> ] ['@' <host> ]) must
482 not be used in server to server communications and is only
483 intended for server to client messages in order to provide
484 clients with more useful information about who a message is
485 from without the need for additional queries.
487 Most protocol messages specify additional semantics and syntax for
488 the extracted parameter strings dictated by their position in the
489 list. For example, many server commands will assume that the first
490 parameter after the command is the list of targets, which can be
493 <target> ::= <to> [ "," <target> ]
494 <to> ::= <channel> | <user> '@' <servername> | <nick> | <mask>
495 <channel> ::= ('#' | '&' | '+') <chstring>
496 <servername> ::= <host>
497 <host> ::= see RFC 952 [DNS:4] for details on allowed hostnames
498 <nick> ::= <letter> { <letter> | <number> | <special> }
499 <mask> ::= $(<servername> | @<hostname>)
500 <chstring> ::= <any 8bit code except SPACE, BELL, NUL, CR, LF and
503 Other parameter syntaxes are:
505 <user> ::= <nonwhite> { <nonwhite> }
506 <letter> ::= 'a' ... 'z' | 'A' ... 'Z'
507 <number> ::= '0' ... '9'
508 <special> ::= '-' | '[' | ']' | '\' | '`' | '^' | '{' | '}'
512 Oikarinen & Reed [Page 9]
514 RFC 1459 Internet Relay Chat Protocol May 1993
517 <nonwhite> ::= <any 8bit code except SPACE (0x20), NUL (0x0), CR
522 Most of the messages sent to the server generate a reply of some
523 sort. The most common reply is the numeric reply, used for both
524 errors and normal replies. The numeric reply must be sent as one
525 message consisting of the sender prefix, the three digit numeric, and
526 the target of the reply. A numeric reply is not allowed to originate
527 from a client; any such messages received by a server are silently
528 dropped. In all other respects, a numeric reply is just like a normal
529 message, except that the keyword is made up of 3 numeric digits
530 rather than a string of letters. A list of different replies is
531 supplied in section 6.
535 This section is devoted to describing the actual concepts behind the
536 organization of the IRC protocol and how the current
537 implementations deliver different classes of messages.
548 Servers: A, B, C, D, E Clients: 1, 2, 3, 4
550 [ Fig. 2. Sample small IRC network ]
552 3.1 One-to-one communication
554 Communication on a one-to-one basis is usually only performed by
555 clients, since most server-server traffic is not a result of servers
556 talking only to each other. To provide a secure means for clients to
557 talk to each other, it is required that all servers be able to send a
558 message in exactly one direction along the spanning tree in order to
559 reach any client. The path of a message being delivered is the
560 shortest path between any two points on the spanning tree.
562 The following examples all refer to Figure 2 above.
568 Oikarinen & Reed [Page 10]
570 RFC 1459 Internet Relay Chat Protocol May 1993
574 A message between clients 1 and 2 is only seen by server A, which
575 sends it straight to client 2.
578 A message between clients 1 and 3 is seen by servers A & B, and
579 client 3. No other clients or servers are allowed see the message.
582 A message between clients 2 and 4 is seen by servers A, B, C & D
587 The main goal of IRC is to provide a forum which allows easy and
588 efficient conferencing (one to many conversations). IRC offers
589 several means to achieve this, each serving its own purpose.
593 The least efficient style of one-to-many conversation is through
594 clients talking to a 'list' of users. How this is done is almost
595 self explanatory: the client gives a list of destinations to which
596 the message is to be delivered and the server breaks it up and
597 dispatches a separate copy of the message to each given destination.
598 This isn't as efficient as using a group since the destination list
599 is broken up and the dispatch sent without checking to make sure
600 duplicates aren't sent down each path.
602 3.2.2 To a group (channel)
604 In IRC the channel has a role equivalent to that of the multicast
605 group; their existence is dynamic (coming and going as people join
606 and leave channels) and the actual conversation carried out on a
607 channel is only sent to servers which are supporting users on a given
608 channel. If there are multiple users on a server in the same
609 channel, the message text is sent only once to that server and then
610 sent to each client on the channel. This action is then repeated for
611 each client-server combination until the original message has fanned
612 out and reached each member of the channel.
614 The following examples all refer to Figure 2.
617 Any channel with 1 client in it. Messages to the channel go to the
618 server and then nowhere else.
624 Oikarinen & Reed [Page 11]
626 RFC 1459 Internet Relay Chat Protocol May 1993
630 2 clients in a channel. All messages traverse a path as if they
631 were private messages between the two clients outside a channel.
634 Clients 1, 2 and 3 in a channel. All messages to the channel are
635 sent to all clients and only those servers which must be traversed
636 by the message if it were a private message to a single client. If
637 client 1 sends a message, it goes back to client 2 and then via
638 server B to client 3.
640 3.2.3 To a host/server mask
642 To provide IRC operators with some mechanism to send messages to a
643 large body of related users, host and server mask messages are
644 provided. These messages are sent to users whose host or server
645 information match that of the mask. The messages are only sent to
646 locations where users are, in a fashion similar to that of channels.
650 The one-to-all type of message is better described as a broadcast
651 message, sent to all clients or servers or both. On a large network
652 of users and servers, a single message can result in a lot of traffic
653 being sent over the network in an effort to reach all of the desired
656 For some messages, there is no option but to broadcast it to all
657 servers so that the state information held by each server is
658 reasonably consistent between servers.
660 3.3.1 Client-to-Client
662 There is no class of message which, from a single message, results in
663 a message being sent to every other client.
665 3.3.2 Client-to-Server
667 Most of the commands which result in a change of state information
668 (such as channel membership, channel mode, user status, etc) must be
669 sent to all servers by default, and this distribution may not be
670 changed by the client.
672 3.3.3 Server-to-Server.
674 While most messages between servers are distributed to all 'other'
675 servers, this is only required for any message that affects either a
676 user, channel or server. Since these are the basic items found in
680 Oikarinen & Reed [Page 12]
682 RFC 1459 Internet Relay Chat Protocol May 1993
685 IRC, nearly all messages originating from a server are broadcast to
686 all other connected servers.
690 On the following pages are descriptions of each message recognized by
691 the IRC server and client. All commands described in this section
692 must be implemented by any server for this protocol.
694 Where the reply ERR_NOSUCHSERVER is listed, it means that the
695 <server> parameter could not be found. The server must not send any
696 other replies after this for that command.
698 The server to which a client is connected is required to parse the
699 complete message, returning any appropriate errors. If the server
700 encounters a fatal error while parsing a message, an error must be
701 sent back to the client and the parsing terminated. A fatal error
702 may be considered to be incorrect command, a destination which is
703 otherwise unknown to the server (server, nick or channel names fit
704 this category), not enough parameters or incorrect privileges.
706 If a full set of parameters is presented, then each must be checked
707 for validity and appropriate responses sent back to the client. In
708 the case of messages which use parameter lists using the comma as an
709 item separator, a reply must be sent for each item.
711 In the examples below, some messages appear using the full format:
713 :Name COMMAND parameter list
715 Such examples represent a message from "Name" in transit between
716 servers, where it is essential to include the name of the original
717 sender of the message so remote servers may send back a reply along
720 4.1 Connection Registration
722 The commands described here are used to register a connection with an
723 IRC server as either a user or a server as well as correctly
726 A "PASS" command is not required for either client or server
727 connection to be registered, but it must precede the server message
728 or the latter of the NICK/USER combination. It is strongly
729 recommended that all server connections have a password in order to
730 give some level of security to the actual connections. The
731 recommended order for a client to register is as follows:
736 Oikarinen & Reed [Page 13]
738 RFC 1459 Internet Relay Chat Protocol May 1993
745 4.1.1 Password message
749 Parameters: <password>
751 The PASS command is used to set a 'connection password'. The
752 password can and must be set before any attempt to register the
753 connection is made. Currently this requires that clients send a PASS
754 command before sending the NICK/USER combination and servers *must*
755 send a PASS command before any SERVER command. The password supplied
756 must match the one contained in the C/N lines (for servers) or I
757 lines (for clients). It is possible to send multiple PASS commands
758 before registering but only the last one sent is used for
759 verification and it may not be changed once registered. Numeric
762 ERR_NEEDMOREPARAMS ERR_ALREADYREGISTRED
766 PASS secretpasswordhere
771 Parameters: <nickname> [ <hopcount> ]
773 NICK message is used to give user a nickname or change the previous
774 one. The <hopcount> parameter is only used by servers to indicate
775 how far away a nick is from its home server. A local connection has
776 a hopcount of 0. If supplied by a client, it must be ignored.
778 If a NICK message arrives at a server which already knows about an
779 identical nickname for another client, a nickname collision occurs.
780 As a result of a nickname collision, all instances of the nickname
781 are removed from the server's database, and a KILL command is issued
782 to remove the nickname from all other server's database. If the NICK
783 message causing the collision was a nickname change, then the
784 original (old) nick must be removed as well.
786 If the server recieves an identical NICK from a client which is
787 directly connected, it may issue an ERR_NICKCOLLISION to the local
788 client, drop the NICK command, and not generate any kills.
792 Oikarinen & Reed [Page 14]
794 RFC 1459 Internet Relay Chat Protocol May 1993
799 ERR_NONICKNAMEGIVEN ERR_ERRONEUSNICKNAME
800 ERR_NICKNAMEINUSE ERR_NICKCOLLISION
804 NICK Wiz ; Introducing new nick "Wiz".
806 :WiZ NICK Kilroy ; WiZ changed his nickname to Kilroy.
811 Parameters: <username> <usermode> <snomask> <info>
813 The USER message is used at the beginning of connection to specify
814 the username, usermod, snomask and information of a new user. Servers
815 use the NICK command to send all information once USER and NICK have
816 been received from the client. Only after both USER and NICK have been
817 received from a client does a user become registered.
819 Undernet does not send USER between servers, NICK is used to send
820 all information about a user. The usermode parameter allows clients to
821 set their initial user mode (see MODE) upon registration, the snomask
822 parameter allows the user to specify a specific set of server notices
823 they wish to receive. If the usermode and snomasks look like host names
824 they are ignored. If a valid ident response is received from the
825 client's host upon connection, the name returned from the ident server
826 is used and username is ignored.
828 It must be noted that info parameter must be the last parameter,
829 because it may contain space characters and must be prefixed with a
830 colon (':') to make sure this is recognised as such.
832 Since it is easy for a client to lie about its username by relying
833 solely on the USER message, the use of an "Identity Server" is
834 recommended. If the host which a user connects from has such a
835 server enabled the username is set to that as in the reply from the
840 ERR_NEEDMOREPARAMS ERR_ALREADYREGISTRED
845 USER guest tolmoon tolsun :Ronnie Reagan
849 Oikarinen & Reed [Page 15]
851 RFC 1459 Internet Relay Chat Protocol May 1993
854 ; User registering themselves with a
855 username of "guest" and real name
859 :testnick USER guest tolmoon tolsun :Ronnie Reagan
860 ; message between servers with the
861 nickname for which the USER command
867 Parameters: <servername> <hopcount> <info>
869 The server message is used to tell a server that the other end of a
870 new connection is a server. This message is also used to pass server
871 data over whole net. When a new server is connected to net,
872 information about it be broadcast to the whole network. <hopcount>
873 is used to give all servers some internal information on how far away
874 all servers are. With a full server list, it would be possible to
875 construct a map of the entire server tree, but hostmasks prevent this
878 The SERVER message must only be accepted from either (a) a connection
879 which is yet to be registered and is attempting to register as a
880 server, or (b) an existing connection to another server, in which
881 case the SERVER message is introducing a new server behind that
884 Most errors that occur with the receipt of a SERVER command result in
885 the connection being terminated by the destination host (target
886 SERVER). Error replies are usually sent using the "ERROR" command
887 rather than the numeric since the ERROR command has several useful
888 properties which make it useful here.
890 If a SERVER message is parsed and attempts to introduce a server
891 which is already known to the receiving server, the connection from
892 which that message must be closed (following the correct procedures),
893 since a duplicate route to a server has formed and the acyclic nature
894 of the IRC tree broken.
905 Oikarinen & Reed [Page 16]
907 RFC 1459 Internet Relay Chat Protocol May 1993
910 SERVER test.oulu.fi 1 :[tolsun.oulu.fi] Experimental server
911 ; New server test.oulu.fi introducing
912 itself and attempting to register. The
913 name in []'s is the hostname for the
914 host running test.oulu.fi.
917 :tolsun.oulu.fi SERVER csd.bu.edu 5 :BU Central Server
918 ; Server tolsun.oulu.fi is our uplink
919 for csd.bu.edu which is 5 hops away.
924 Parameters: <user> <password>
926 OPER message is used by a normal user to obtain operator privileges.
927 The combination of <user> and <password> are required to gain
930 If the client sending the OPER command supplies the correct password
931 for the given user, the server then informs the rest of the network
932 of the new operator by issuing a "MODE +o" for the clients nickname.
934 The OPER message is client-server only.
938 ERR_NEEDMOREPARAMS RPL_YOUREOPER
939 ERR_NOOPERHOST ERR_PASSWDMISMATCH
943 OPER foo bar ; Attempt to register as an operator
944 using a username of "foo" and "bar" as
950 Parameters: [<Quit message>]
952 A client session is ended with a quit message. The server must close
953 the connection to a client which sends a QUIT message. If a "Quit
954 Message" is given, this will be sent instead of the default message,
957 When netsplits (disconnecting of two servers) occur, the quit message
961 Oikarinen & Reed [Page 17]
963 RFC 1459 Internet Relay Chat Protocol May 1993
966 is composed of the names of two servers involved, separated by a
967 space. The first name is that of the server which is still connected
968 and the second name is that of the server that has become
971 If, for some other reason, a client connection is closed without the
972 client issuing a QUIT command (e.g. client dies and EOF occurs
973 on socket), the server is required to fill in the quit message with
974 some sort of message reflecting the nature of the event which
983 QUIT :Gone to have lunch ; Preferred message format.
985 4.1.7 Server quit message
988 Parameters: <server> <comment>
990 The SQUIT message is needed to tell about quitting or dead servers.
991 If a server wishes to break the connection to another server it must
992 send a SQUIT message to the other server, using the the name of the
993 other server as the server parameter, which then closes its
994 connection to the quitting server.
996 This command is also available operators to help keep a network of
997 IRC servers connected in an orderly fashion. Operators may also
998 issue an SQUIT message for a remote server connection. In this case,
999 the SQUIT must be parsed by each server inbetween the operator and
1000 the remote server, updating the view of the network held by each
1001 server as explained below.
1003 The <comment> should be supplied by all operators who execute a SQUIT
1004 for a remote server (that is not connected to the server they are
1005 currently on) so that other operators are aware for the reason of
1006 this action. The <comment> is also filled in by servers which may
1007 place an error or similar message here.
1009 Both of the servers which are on either side of the connection being
1010 closed are required to to send out a SQUIT message (to all its other
1011 server connections) for all other servers which are considered to be
1017 Oikarinen & Reed [Page 18]
1019 RFC 1459 Internet Relay Chat Protocol May 1993
1022 Similarly, a QUIT message must be sent to the other connected servers
1023 rest of the network on behalf of all clients behind that link. In
1024 addition to this, all channel members of a channel which lost a
1025 member due to the split must be sent a QUIT message.
1027 If a server connection is terminated prematurely (e.g. the server on
1028 the other end of the link died), the server which detects
1029 this disconnection is required to inform the rest of the network
1030 that the connection has closed and fill in the comment field
1031 with something appropriate.
1035 ERR_NOPRIVILEGES ERR_NOSUCHSERVER
1039 SQUIT tolsun.oulu.fi :Bad Link ? ; the server link tolson.oulu.fi has
1040 been terminated because of "Bad Link".
1042 :Trillian SQUIT cm22.eng.umd.edu :Server out of control
1043 ; message from Trillian to disconnect
1044 "cm22.eng.umd.edu" from the net
1045 because "Server out of control".
1047 4.2 Channel operations
1049 This group of messages is concerned with manipulating channels, their
1050 properties (channel modes), and their contents (typically clients).
1051 In implementing these, a number of race conditions are inevitable
1052 when clients at opposing ends of a network send commands which will
1053 ultimately clash. It is also required that servers keep a nickname
1054 history to ensure that wherever a <nick> parameter is given, the
1055 server check its history in case it has recently been changed.
1060 Parameters: <channel>{,<channel>} [<key>{,<key>}]
1062 The JOIN command is used by client to start listening a specific
1063 channel. Whether or not a client is allowed to join a channel is
1064 checked only by the server the client is connected to; all other
1065 servers automatically add the user to the channel when it is received
1066 from other servers. The conditions which affect this are as follows:
1068 1. the user must be invited if the channel is invite-only;
1073 Oikarinen & Reed [Page 19]
1075 RFC 1459 Internet Relay Chat Protocol May 1993
1078 2. the user's nick/username/hostname must not match any
1081 3. the correct key (password) must be given if it is set.
1083 These are discussed in more detail under the MODE command (see
1084 section 4.2.3 for more details).
1086 Once a user has joined a channel, they receive notice about all
1087 commands their server receives which affect the channel. This
1088 includes MODE, KICK, PART, QUIT and of course PRIVMSG/NOTICE. The
1089 JOIN command needs to be broadcast to all servers so that each server
1090 knows where to find the users who are on the channel. This allows
1091 optimal delivery of PRIVMSG/NOTICE messages to the channel.
1093 If a JOIN is successful, the user is then sent the channel's topic
1094 (using RPL_TOPIC) and the list of users who are on the channel (using
1095 RPL_NAMREPLY), which must include the user joining.
1099 ERR_NEEDMOREPARAMS ERR_BANNEDFROMCHAN
1100 ERR_INVITEONLYCHAN ERR_BADCHANNELKEY
1101 ERR_CHANNELISFULL ERR_BADCHANMASK
1102 ERR_NOSUCHCHANNEL ERR_TOOMANYCHANNELS
1107 JOIN #foobar ; join channel #foobar.
1109 JOIN &foo fubar ; join channel &foo using key "fubar".
1111 JOIN #foo,&bar fubar ; join channel #foo using key "fubar"
1112 and &bar using no key.
1114 JOIN #foo,#bar fubar,foobar ; join channel #foo using key "fubar".
1115 and channel #bar using key "foobar".
1117 JOIN #foo,#bar ; join channels #foo and #bar.
1119 :WiZ JOIN #Twilight_zone ; JOIN message from WiZ
1124 Parameters: <channel>{,<channel>}
1129 Oikarinen & Reed [Page 20]
1131 RFC 1459 Internet Relay Chat Protocol May 1993
1134 The PART message causes the client sending the message to be removed
1135 from the list of active users for all given channels listed in the
1140 ERR_NEEDMOREPARAMS ERR_NOSUCHCHANNEL
1145 PART #twilight_zone ; leave channel "#twilight_zone"
1147 PART #oz-ops,&group5 ; leave both channels "&group5" and
1154 The MODE command is a dual-purpose command in IRC. It allows both
1155 usernames and channels to have their mode changed. The rationale for
1156 this choice is that one day nicknames will be obsolete and the
1157 equivalent property will be the channel.
1159 When parsing MODE messages, it is recommended that the entire message
1160 be parsed first and then the changes which resulted then passed on.
1162 4.2.3.1 Channel modes
1164 Parameters: <channel> {[+|-]|o|p|s|i|t|n|b|v} [<limit>] [<user>]
1167 The MODE command is provided so that channel operators may change the
1168 characteristics of `their' channel. It is also required that servers
1169 be able to change channel modes so that channel operators may be
1172 The various modes available for channels are as follows:
1174 o - give/take channel operator privileges;
1175 p - private channel flag;
1176 s - secret channel flag;
1177 i - invite-only channel flag;
1178 t - topic settable by channel operator only flag;
1179 n - no messages to channel from clients on the outside;
1180 m - moderated channel;
1181 l - set the user limit to channel;
1185 Oikarinen & Reed [Page 21]
1187 RFC 1459 Internet Relay Chat Protocol May 1993
1190 b - set a ban mask to keep users out;
1191 v - give/take the ability to speak on a moderated channel;
1192 k - set a channel key (password).
1194 When using the 'o' and 'b' options, a restriction on a total of three
1195 per mode command has been imposed. That is, any combination of 'o'
1200 Parameters: <nickname> {[+|-]|i|w|s|o}
1202 The user MODEs are typically changes which affect either how the
1203 client is seen by others or what 'extra' messages the client is sent.
1204 A user MODE command may only be accepted if both the sender of the
1205 message and the nickname given as a parameter are both the same.
1207 The available modes are as follows:
1209 i - marks a users as invisible;
1210 s - marks a user for receipt of server notices;
1211 w - user receives wallops;
1214 Additional modes may be available later on.
1216 If a user attempts to make themselves an operator using the "+o"
1217 flag, the attempt should be ignored. There is no restriction,
1218 however, on anyone `deopping' themselves (using "-o"). Numeric
1221 ERR_NEEDMOREPARAMS RPL_CHANNELMODEIS
1222 ERR_CHANOPRIVSNEEDED ERR_NOSUCHNICK
1223 ERR_NOTONCHANNEL ERR_KEYSET
1224 RPL_BANLIST RPL_ENDOFBANLIST
1225 ERR_UNKNOWNMODE ERR_NOSUCHCHANNEL
1227 ERR_USERSDONTMATCH RPL_UMODEIS
1228 ERR_UMODEUNKNOWNFLAG
1232 Use of Channel Modes:
1234 MODE #Finnish +im ; Makes #Finnish channel moderated and
1237 MODE #Finnish +o Kilroy ; Gives 'chanop' privileges to Kilroy on
1241 Oikarinen & Reed [Page 22]
1243 RFC 1459 Internet Relay Chat Protocol May 1993
1248 MODE #Finnish +v Wiz ; Allow WiZ to speak on #Finnish.
1250 MODE #Fins -s ; Removes 'secret' flag from channel
1253 MODE #42 +k oulu ; Set the channel key to "oulu".
1255 MODE #eu-opers +l 10 ; Set the limit for the number of users
1258 MODE &oulu +b ; list ban masks set for channel.
1260 MODE &oulu +b *!*@* ; prevent all users from joining.
1262 MODE &oulu +b *!*@*.edu ; prevent any user from a hostname
1263 matching *.edu from joining.
1267 :MODE WiZ -w ; turns reception of WALLOPS messages
1270 :Angel MODE Angel +i ; Message from Angel to make themselves
1273 MODE WiZ -o ; WiZ 'deopping' (removing operator
1274 status). The plain reverse of this
1275 command ("MODE WiZ +o") must not be
1276 allowed from users since would bypass
1282 Parameters: <channel> [<topic>]
1284 The TOPIC message is used to change or view the topic of a channel.
1285 The topic for channel <channel> is returned if there is no <topic>
1286 given. If the <topic> parameter is present, the topic for that
1287 channel will be changed, if the channel modes permit this action.
1288 You may not query a topic from outside a secret channel. Modeless
1289 channels don't have a topic and thus ERR_CHANOPRIVSNEEDED is returned.
1290 A list of channels may be specified comma seperated.
1294 ERR_NEEDMOREPARAMS ERR_NOTONCHANNEL
1295 RPL_NOTOPIC RPL_TOPIC
1296 ERR_CHANOPRIVSNEEDED ERR_NOSUCHCHANNEL
1301 Oikarinen & Reed [Page 23]
1303 RFC 1459 Internet Relay Chat Protocol May 1993
1308 :Wiz TOPIC #test :New topic ;User Wiz setting the topic.
1310 TOPIC #test :another topic ;set the topic on #test to "another
1313 TOPIC #test ; check the topic for #test.
1315 TOPIC #test,#testing ; check the topic on #test and #testing
1317 TOPIC #test,#testing :Topic ; set the topic on #test and #testing
1323 Parameters: [<channel>{,<channel>}]
1325 By using the NAMES command, a user can list all nicknames that are
1326 visible to them on any channel that they can see. Channel names
1327 which they can see are those which aren't private (+p) or secret (+s)
1328 or those which they are actually on. The <channel> parameter
1329 specifies which channel(s) to return information about if valid.
1330 There is no error reply for bad channel names.
1332 If no <channel> parameter is given, a list of all channels and their
1333 occupants is returned. At the end of this list, a list of users who
1334 are visible but either not on any channel or not on a visible channel
1335 are listed as being on `channel' "*".
1339 RPL_NAMREPLY RPL_ENDOFNAMES
1344 NAMES #twilight_zone,#42 ; list visible users on #twilight_zone
1345 and #42 if the channels are visible to
1348 NAMES 0 ; list all visible channels and users
1350 NAMES ; does nothing because of the amount
1351 of users that would do it by accident
1356 Parameters: [<channel>{,<channel>} [<server>]]
1358 The list message is used to list channels and their topics. If the
1359 <channel> parameter is used, only the status of that channel
1360 is displayed. Private channels are listed (without their
1361 topics) as channel "Prv" unless the client generating the query is
1362 actually on that channel. Likewise, secret channels are not listed
1366 Oikarinen & Reed [Page 24]
1368 RFC 1459 Internet Relay Chat Protocol May 1993
1371 at all unless the client is a member of the channel in question.
1375 ERR_NOSUCHSERVER RPL_LISTSTART
1376 RPL_LIST RPL_LISTEND
1380 LIST ; List all channels.
1382 LIST #twilight_zone,#42 ; List channels #twilight_zone and #42
1384 4.2.7 Invite message
1387 Parameters: <nickname> <channel>
1389 The INVITE message is used to invite users to a channel. The
1390 parameter <nickname> is the nickname of the person to be invited to
1391 the target channel <channel>. There is no requirement that the
1392 channel the target user is being invited to must exist or be a valid
1393 channel. To invite a user to a channel which is invite only (MODE
1394 +i), the client sending the invite must be recognised as being a
1395 channel operator on the given channel.
1399 ERR_NEEDMOREPARAMS ERR_NOSUCHNICK
1400 ERR_NOTONCHANNEL ERR_USERONCHANNEL
1401 ERR_CHANOPRIVSNEEDED
1402 RPL_INVITING RPL_AWAY
1406 :Angel INVITE Wiz #Dust ; User Angel inviting WiZ to channel
1409 INVITE Wiz #Twilight_Zone ; Command to invite WiZ to
1415 Parameters: <channel> <user> [<comment>]
1417 The KICK command can be used to forcibly remove a user from a
1418 channel. It 'kicks them out' of the channel (forced PART).
1422 Oikarinen & Reed [Page 25]
1424 RFC 1459 Internet Relay Chat Protocol May 1993
1427 Only a channel operator may kick another user out of a channel.
1428 Each server that receives a KICK message checks that it is valid
1429 (ie the sender is actually a channel operator) before removing
1430 the victim from the channel.
1434 ERR_NEEDMOREPARAMS ERR_NOSUCHCHANNEL
1435 ERR_BADCHANMASK ERR_CHANOPRIVSNEEDED
1440 KICK &Melbourne Matthew ; Kick Matthew from &Melbourne
1442 KICK #Finnish John :Speaking English
1443 ; Kick John from #Finnish using
1444 "Speaking English" as the reason
1447 :WiZ KICK #Finnish John ; KICK message from WiZ to remove John
1448 from channel #Finnish
1451 It is possible to extend the KICK command parameters to the
1454 <channel>{,<channel>} <user>{,<user>} [<comment>]
1456 4.3 Server queries and commands
1458 The server query group of commands has been designed to return
1459 information about any server which is connected to the network. All
1460 servers connected must respond to these queries and respond
1461 correctly. Any invalid response (or lack thereof) must be considered
1462 a sign of a broken server and it must be disconnected/disabled as
1463 soon as possible until the situation is remedied.
1465 In these queries, where a parameter appears as "<server>", it will
1466 usually mean it can be a nickname or a server or a wildcard name of
1467 some sort. For each parameter, however, only one query and set of
1468 replies is to be generated.
1470 4.3.1 Version message
1473 Parameters: [<server>]
1478 Oikarinen & Reed [Page 26]
1480 RFC 1459 Internet Relay Chat Protocol May 1993
1483 The VERSION message is used to query the version of the server
1484 program. An optional parameter <server> is used to query the version
1485 of the server program which a client is not directly connected to.
1489 ERR_NOSUCHSERVER RPL_VERSION
1493 :Wiz VERSION *.se ; message from Wiz to check the version
1494 of a server matching "*.se"
1496 VERSION tolsun.oulu.fi ; check the version of server
1502 Parameters: [<query> [<server>]]
1504 Many stats commands are only available to opers, please document
1505 which ones are available to users and which are available to opers.
1507 The stats message is used to query statistics of certain server. If
1508 <server> parameter is omitted, only the end of stats reply is sent
1509 back. The implementation of this command is highly dependent on the
1510 server which replies, although the server must be able to supply
1511 information as described by the queries below (or similar).
1513 A query may be given by any single letter which is only checked by
1514 the destination server (if given as the <server> parameter) and is
1515 otherwise passed on by intermediate servers, ignored and unaltered.
1516 The following queries are those found in the current IRC
1517 implementation and provide a large portion of the setup information
1518 for that server. Although these may not be supported in the same way
1519 by other versions, all servers should be able to supply a valid reply
1520 to a STATS query which is consistent with the reply formats currently
1521 used and the purpose of the query.
1523 The currently supported queries are:
1525 c - returns a list of servers which the server may connect
1526 to or allow connections from;
1527 h - returns a list of servers which are either forced to be
1528 treated as leaves or allowed to act as hubs;
1529 i - returns a list of hosts which the server allows a client
1531 k - returns a list of banned username/hostname combinations
1533 l - returns a list of the server's connections, showing how
1537 Oikarinen & Reed [Page 27]
1539 RFC 1459 Internet Relay Chat Protocol May 1993
1542 long each connection has been established and the traffic
1543 over that connection in bytes and messages for each
1545 m - returns a list of commands supported by the server and
1546 the usage count for each if the usage count is non zero;
1547 o - returns a list of hosts from which normal clients may
1549 y - show Y (Class) lines from server's configuration file;
1550 u - returns a string showing how long the server has been up.
1555 RPL_STATSCLINE RPL_STATSNLINE
1556 RPL_STATSILINE RPL_STATSKLINE
1557 RPL_STATSQLINE RPL_STATSLLINE
1558 RPL_STATSLINKINFO RPL_STATSUPTIME
1559 RPL_STATSCOMMANDS RPL_STATSOLINE
1560 RPL_STATSHLINE RPL_ENDOFSTATS
1564 STATS m ; check the command usage for the server
1565 you are connected to
1567 :Wiz STATS c eff.org ; request by WiZ for C/N line
1568 information from server eff.org
1573 Parameters: [[<remote server>] <server mask>]
1575 With LINKS, a user can list all servers which are known by the server
1576 answering the query. The returned list of servers must match the
1577 mask, or if no mask is given, the full list is returned.
1579 If <remote server> is given in addition to <server mask>, the LINKS
1580 command is forwarded to the first server found that matches that name
1581 (if any), and that server is then required to answer the query.
1586 RPL_LINKS RPL_ENDOFLINKS
1593 Oikarinen & Reed [Page 28]
1595 RFC 1459 Internet Relay Chat Protocol May 1993
1598 LINKS *.au ; list all servers which have a name
1601 :WiZ LINKS *.bu.edu *.edu ; LINKS message from WiZ to the first
1602 server matching *.edu for a list of
1603 servers matching *.bu.edu.
1608 Parameters: [<server>]
1610 The time message is used to query local time from the specified
1611 server. If the server parameter is not given, the server handling the
1612 command must reply to the query.
1616 ERR_NOSUCHSERVER RPL_TIME
1620 TIME tolsun.oulu.fi ; check the time on the server
1623 Angel TIME *.au ; user angel checking the time on a
1624 server matching "*.au"
1626 4.3.5 Connect message
1629 Parameters: <target server> [<port> [<remote server>]]
1631 The CONNECT command can be used to force a server to try to establish
1632 a new connection to another server immediately. CONNECT is a
1633 privileged command and is to be available only to IRC Operators. If
1634 a remote server is given then the CONNECT attempt is made by that
1635 server to <target server> and <port>. A port of 0 means use the default
1636 port number. Most errors are reported in notice's.
1640 ERR_NOSUCHSERVER ERR_NOPRIVILEGES
1645 CONNECT tolsun.oulu.fi ; Attempt to connect a server to
1650 Oikarinen & Reed [Page 29]
1652 RFC 1459 Internet Relay Chat Protocol May 1993
1655 :WiZ CONNECT eff.org 6667 csd.bu.edu
1656 ; CONNECT attempt by WiZ to get servers
1657 eff.org and csd.bu.edu connected on port
1663 Parameters: [<server>]
1665 TRACE command is used to find the route to specific server. Each
1666 server that processes this message must tell the sender about it by
1667 sending a reply indicating it is a pass-through link, forming a chain
1668 of replies similar to that gained from using "traceroute". After
1669 sending this reply back, it must then send the TRACE message to the
1670 next server until given server is reached. If the <server> parameter
1671 is omitted, it is recommended that TRACE command send a message to
1672 the sender telling which servers the current server has direct
1675 If the destination given by "<server>" is an actual server, then the
1676 destination server is required to report all servers and users which
1677 are connected to it, although only operators are permitted to see
1678 users present. If the destination given by <server> is a nickname,
1679 they only a reply for that nickname is given.
1685 If the TRACE message is destined for another server, all intermediate
1686 servers must return a RPL_TRACELINK reply to indicate that the TRACE
1687 passed through it and where its going next.
1690 A TRACE reply may be composed of any number of the following numeric
1693 RPL_TRACECONNECTING RPL_TRACEHANDSHAKE
1694 RPL_TRACEUNKNOWN RPL_TRACEOPERATOR
1695 RPL_TRACEUSER RPL_TRACESERVER
1696 RPL_TRACESERVICE RPL_TRACENEWTYPE
1701 TRACE *.oulu.fi ; TRACE to a server matching *.oulu.fi
1706 Oikarinen & Reed [Page 30]
1708 RFC 1459 Internet Relay Chat Protocol May 1993
1711 :WiZ TRACE AngelDust ; TRACE issued by WiZ to nick AngelDust
1716 Parameters: [<server>]
1718 The admin message is used to find the name of the administrator of
1719 the given server, or current server if <server> parameter is omitted.
1720 Each server must have the ability to forward ADMIN messages to other
1721 servers. The given server may be a nick, where the server that the
1722 nick is on will be queried.
1727 RPL_ADMINME RPL_ADMINLOC1
1728 RPL_ADMINLOC2 RPL_ADMINEMAIL
1732 ADMIN tolsun.oulu.fi ; request an ADMIN reply from
1735 :WiZ ADMIN *.edu ; ADMIN request from WiZ for first
1736 server found to match *.edu.
1741 Parameters: [<server>]
1743 The INFO command is required to return information which describes
1744 the server: its version, when it was compiled, the patchlevel, when
1745 it was started, and any other miscellaneous information which may be
1746 considered to be relevant.
1751 RPL_INFO RPL_ENDOFINFO
1755 INFO csd.bu.edu ; request an INFO reply from
1758 :Avalon INFO *.fi ; INFO request from Avalon for first
1759 server found to match *.fi.
1763 Oikarinen & Reed [Page 31]
1765 RFC 1459 Internet Relay Chat Protocol May 1993
1768 INFO Angel ; request info from the server that
1769 Angel is connected to.
1771 4.4 Sending messages
1773 The main purpose of the IRC protocol is to provide a base for clients
1774 to communicate with each other. PRIVMSG and NOTICE are the only
1775 messages available which actually perform delivery of a text message
1776 from one client to another - the rest just make it possible and try
1777 to ensure it happens in a reliable and structured manner.
1779 4.4.1 Private messages
1782 Parameters: <receiver>{,<receiver>} <text to be sent>
1784 PRIVMSG is used to send private messages between users. <receiver>
1785 is the nickname of the receiver of the message. <receiver> can also
1786 be a list of names or channels separated with commas.
1788 The <receiver> parameter may also me a host mask ($@mask) or server
1789 mask ($mask). In both cases the server will only send the PRIVMSG
1790 to those who have a server or host matching the mask. The mask must
1791 have at least 1 (one) "." in it and no wildcards following the
1792 last ".". This requirement exists to prevent people sending messages
1793 to "$@*" or "$*", which would broadcast to all users; from
1794 experience, this is abused more than used responsibly and properly.
1795 Wildcards are the '*' and '?' characters. This extension to
1796 the PRIVMSG command is only available to Operators.
1800 ERR_NORECIPIENT ERR_NOTEXTTOSEND
1801 ERR_CANNOTSENDTOCHAN ERR_NOTOPLEVEL
1802 ERR_WILDTOPLEVEL ERR_TOOMANYTARGETS
1808 :Angel PRIVMSG Wiz :Hello are you receiving this message ?
1809 ; Message from Angel to Wiz.
1811 PRIVMSG Angel :yes I'm receiving it !receiving it !'u>(768u+1n) .br ;
1814 PRIVMSG jto@tolsun.oulu.fi :Hello !
1815 ; Message to a client on server
1819 Oikarinen & Reed [Page 32]
1821 RFC 1459 Internet Relay Chat Protocol May 1993
1824 tolsun.oulu.fi with username of "jto".
1826 PRIVMSG $*.fi :Server tolsun.oulu.fi rebooting.
1827 ; Message to everyone on a server which
1828 has a name matching *.fi.
1830 PRIVMSG $@*.edu :NSFNet is undergoing work, expect interruptions
1831 ; Message to all users who come from a
1832 host which has a name matching *.edu.
1837 Parameters: <nickname> <text>
1839 The NOTICE message is used similarly to PRIVMSG. The difference
1840 between NOTICE and PRIVMSG is that automatic replies must never be
1841 sent in response to a NOTICE message. This rule applies to servers
1842 too - they must not send any error reply back to the client on
1843 receipt of a notice. The object of this rule is to avoid loops
1844 between a client automatically sending something in response to
1845 something it received. This is typically used by automatons (clients
1846 with either an AI or other interactive program controlling their
1847 actions) which are always seen to be replying lest they end up in a
1848 loop with another automaton.
1850 See PRIVMSG for more details on replies and examples.
1852 4.5 User based queries
1854 User queries are a group of commands which are primarily concerned
1855 with finding details on a particular user or group users. When using
1856 wildcards with any of these commands, if they match, they will only
1857 return information on users who are 'visible' to you. The visibility
1858 of a user is determined as a combination of the user's mode and the
1859 common set of channels you are both on.
1864 Parameters: [<name> [<o>]]
1866 The WHO message is used by a client to generate a query which returns
1867 a list of information which 'matches' the <name> parameter given by
1868 the client. In the absence of the <name> parameter, all visible
1869 (users who aren't invisible (user mode +i) and who don't have a
1870 common channel with the requesting client) are listed. The same
1871 result can be achieved by using a <name> of "0" or any wildcard which
1875 Oikarinen & Reed [Page 33]
1877 RFC 1459 Internet Relay Chat Protocol May 1993
1880 will end up matching every entry possible.
1882 The <name> passed to WHO is matched against users' host, server, real
1883 name and nickname if the channel <name> cannot be found.
1885 If the "o" parameter is passed only operators are returned according
1886 to the name mask supplied.
1891 RPL_WHOREPLY RPL_ENDOFWHO
1895 WHO *.fi ; List all users who match against
1898 WHO jto* o ; List all users with a match against
1899 "jto*" if they are an operator.
1904 Parameters: [<server>] <nickmask>[,<nickmask>[,...]]
1906 This message is used to query information about particular user. The
1907 server will answer this message with several numeric messages
1908 indicating different statuses of each user which matches the nickmask
1909 (if you are entitled to see them). If no wildcard is present in the
1910 <nickmask>, any information about that nick which you are allowed to
1911 see is presented. A comma (',') separated list of nicknames may be
1914 The latter version sends the query to a specific server. It is
1915 useful if you want to know how long the user in question has been
1916 idle as only local server (ie. the server the user is directly
1917 connected to) knows that information, while everything else is
1922 ERR_NOSUCHSERVER ERR_NONICKNAMEGIVEN
1923 RPL_WHOISUSER RPL_WHOISCHANNELS
1924 RPL_WHOISCHANNELS RPL_WHOISSERVER
1925 RPL_AWAY RPL_WHOISOPERATOR
1926 RPL_WHOISIDLE ERR_NOSUCHNICK
1931 Oikarinen & Reed [Page 34]
1933 RFC 1459 Internet Relay Chat Protocol May 1993
1938 WHOIS wiz ; return available user information
1941 WHOIS eff.org trillian ; ask server eff.org for user
1942 information about trillian
1947 Parameters: <nickname> [<count> [<server>]]
1949 Whowas asks for information about a nickname which no longer exists.
1950 This may either be due to a nickname change or the user leaving IRC.
1951 In response to this query, the server searches through its nickname
1952 history, looking for any nicks which are lexically the same (no wild
1953 card matching here). The history is searched backward, returning the
1954 most recent entry first. If there are multiple entries, up to
1955 <count> replies will be returned (or all of them if no <count>
1956 parameter is given). If a non-positive number is passed as being
1957 <count>, then a full search is done.
1961 ERR_NONICKNAMEGIVEN ERR_WASNOSUCHNICK
1962 RPL_WHOWASUSER RPL_WHOISSERVER
1967 WHOWAS Wiz ; return all information in the nick
1968 history about nick "WiZ";
1970 WHOWAS Mermaid 9 ; return at most, the 9 most recent
1971 entries in the nick history for
1974 WHOWAS Trillian 1 *.edu ; return the most recent history for
1975 "Trillian" from the first server found
1978 4.6 Miscellaneous messages
1980 Messages in this category do not fit into any of the above categories
1981 but are nonetheless still a part of and required by the protocol.
1987 Oikarinen & Reed [Page 35]
1989 RFC 1459 Internet Relay Chat Protocol May 1993
1995 Parameters: <nickname> <comment>
1997 The KILL message is used to cause a client-server connection to be
1998 closed by the server which has the actual connection. KILL is used
1999 by servers when they encounter a duplicate entry in the list of valid
2000 nicknames and is used to remove both entries. It is also available
2003 Clients which have automatic reconnect algorithms effectively make
2004 this command useless since the disconnection is only brief. It does
2005 however break the flow of data and can be used to stop large amounts
2006 of being abused, any user may elect to receive KILL messages
2007 generated for others to keep an 'eye' on would be trouble spots.
2009 In an arena where nicknames are required to be globally unique at all
2010 times, KILL messages are sent whenever 'duplicates' are detected
2011 (that is an attempt to register two users with the same nickname) in
2012 the hope that both of them will disappear and only 1 reappear.
2014 The comment given must reflect the actual reason for the KILL. For
2015 server-generated KILLs it usually is made up of details concerning
2016 the origins of the two conflicting nicknames. For users it is left
2017 up to them to provide an adequate reason to satisfy others who see
2018 it. To prevent/discourage fake KILLs from being generated to hide
2019 the identify of the KILLer, the comment also shows a 'kill-path'
2020 which is updated by each server it passes through, each prepending
2021 its name to the path.
2025 ERR_NOPRIVILEGES ERR_NEEDMOREPARAMS
2026 ERR_NOSUCHNICK ERR_CANTKILLSERVER
2029 KILL David (csd.bu.edu <- tolsun.oulu.fi)
2030 ; Nickname collision between csd.bu.edu
2035 It is recommended that only Operators be allowed to kill other users
2036 with KILL message. In an ideal world not even operators would need
2037 to do this and it would be left to servers to deal with.
2043 Oikarinen & Reed [Page 36]
2045 RFC 1459 Internet Relay Chat Protocol May 1993
2051 Parameters: <server1> [<server2>]
2053 The PING message is used to test the presence of an active client at
2054 the other end of the connection. A PING message is sent at regular
2055 intervals if no other activity detected coming from a connection. If
2056 a connection fails to respond to a PING command within a set amount
2057 of time, that connection is closed.
2059 Any client which receives a PING message must respond to <server1>
2060 (server which sent the PING message out) as quickly as possible with
2061 an appropriate PONG message to indicate it is still there and alive.
2062 Servers should not respond to PING commands but rely on PINGs from
2063 the other end of the connection to indicate the connection is alive.
2064 If the <server2> parameter is specified, the PING message gets
2069 ERR_NOORIGIN ERR_NOSUCHSERVER
2073 PING tolsun.oulu.fi ; server sending a PING message to
2074 another server to indicate it is still
2077 PING WiZ ; PING message being sent to nick WiZ
2082 Parameters: <daemon> [<daemon2>]
2084 PONG message is a reply to ping message. If parameter <daemon2> is
2085 given this message must be forwarded to given daemon. The <daemon>
2086 parameter is the name of the daemon who has responded to PING message
2087 and generated this message.
2091 ERR_NOORIGIN ERR_NOSUCHSERVER
2095 PONG csd.bu.edu tolsun.oulu.fi ; PONG message from csd.bu.edu to
2099 Oikarinen & Reed [Page 37]
2101 RFC 1459 Internet Relay Chat Protocol May 1993
2109 Parameters: <error message>
2111 The ERROR command is for use by servers when reporting a serious or
2112 fatal error to its operators. It may also be sent from one server to
2113 another but must not be accepted from any normal unknown clients.
2115 An ERROR message is for use for reporting errors which occur with a
2116 server-to-server link only. An ERROR message is sent to the server
2117 at the other end (which sends it to all of its connected operators)
2118 and to all operators currently connected. It is not to be passed
2119 onto any other servers by a server if it is received from a server.
2121 When a server sends a received ERROR message to its operators, the
2122 message should be encapsulated inside a NOTICE message, indicating
2123 that the client was not responsible for the error.
2131 ERROR :Server *.fi already exists; ERROR message to the other server
2132 which caused this error.
2134 NOTICE WiZ :ERROR from csd.bu.edu -- Server *.fi already exists
2135 ; Same ERROR message as above but sent
2136 to user WiZ on the other server.
2140 This section describes OPTIONAL messages. They are not required in a
2141 working server implementation of the protocol described herein. In
2142 the absence of the option, an error reply message must be generated
2143 or an unknown command error. If the message is destined for another
2144 server to answer then it must be passed on (elementary parsing
2145 required) The allocated numerics for this are listed with the
2151 Parameters: [message]
2155 Oikarinen & Reed [Page 38]
2157 RFC 1459 Internet Relay Chat Protocol May 1993
2160 With the AWAY message, clients can set an automatic reply string for
2161 any PRIVMSG commands directed at them (not to a channel they are on).
2162 The automatic reply is sent by the server to client sending the
2163 PRIVMSG command. The only replying server is the one to which the
2164 sending client is connected to.
2166 The AWAY message is used either with one parameter (to set an AWAY
2167 message) or with no parameters (to remove the AWAY message).
2171 RPL_UNAWAY RPL_NOWAWAY
2175 AWAY :Gone to lunch. Back in 5 ; set away message to "Gone to lunch.
2178 :WiZ AWAY ; unmark WiZ as being away.
2186 The rehash message can be used by the operator to force the server to
2187 re-read and process its configuration file.
2191 RPL_REHASHING ERR_NOPRIVILEGES
2195 REHASH ; message from client with operator
2196 status to server asking it to reread its
2204 The restart message can only be used by an operator to force a server
2205 restart itself. This message is optional since it may be viewed as a
2206 risk to allow arbitrary people to connect to a server as an operator
2207 and execute this command, causing (at least) a disruption to service.
2211 Oikarinen & Reed [Page 39]
2213 RFC 1459 Internet Relay Chat Protocol May 1993
2216 The RESTART command must always be fully processed by the server to
2217 which the sending client is connected and not be passed onto other
2226 RESTART ; no parameters required.
2233 Parameters: [<server>]
2237 Oikarinen & Reed [Page 40]
2239 RFC 1459 Internet Relay Chat Protocol May 1993
2242 The USERS command returns a list of users logged into the server in a
2243 similar format to who(1), rusers(1) and finger(1). Some people
2244 may disable this command on their server for security related
2245 reasons. If disabled, the correct numeric must be returned to
2250 ERR_NOSUCHSERVER ERR_FILEERROR
2251 RPL_USERSSTART RPL_USERS
2252 RPL_NOUSERS RPL_ENDOFUSERS
2261 USERS eff.org ; request a list of users logged in on
2264 :John USERS tolsun.oulu.fi ; request from John for a list of users
2265 logged in on server tolsun.oulu.fi
2267 5.6 Operwall message
2270 Parameters: Text to be sent to all operators currently online
2272 Sends a message to all operators currently online. After
2273 implementing WALLOPS as a user command it was found that it was
2274 often and commonly abused as a means of sending a message to a lot
2275 of people (much similar to WALL). Due to this it is recommended
2276 that the current implementation of WALLOPS be used as an
2277 example by allowing and recognising only servers as the senders of
2286 :csd.bu.edu WALLOPS :Connect '*.uiuc.edu 6667' from Joshua; WALLOPS
2287 message from csd.bu.edu announcing a
2288 CONNECT message it received and acted
2293 Oikarinen & Reed [Page 41]
2295 RFC 1459 Internet Relay Chat Protocol May 1993
2298 5.7 Userhost message
2301 Parameters: <nickname>{<space><nickname>}
2303 The USERHOST command takes a list of up to 5 nicknames, each
2304 separated by a space character and returns a list of information
2305 about each nickname that it found. The returned list has each reply
2306 separated by a space.
2310 RPL_USERHOST ERR_NEEDMOREPARAMS
2314 USERHOST Wiz Michael Marty p ;USERHOST request for information on
2315 nicks "Wiz", "Michael", "Marty" and "p"
2317 5.7.1 Userip message
2320 Parameters: <nickname>{<space><nickname>}
2322 The USERHOST command takes a list of up to 5 nicknames, each
2323 separated by a space character and returns a list of information
2324 about each nickname that it found. The returned list has each reply
2325 separated by a space.
2329 RPL_USERIP ERR_NEEDMOREPARAMS
2333 USERIP Wiz Michael Marty p ;USERIP request for information on
2334 nicks "Wiz", "Michael", "Marty" and "p"
2339 Parameters: <nickname>{<space><nickname>}
2341 The ISON command was implemented to provide a quick and efficient
2342 means to get a response about whether a given nickname was currently
2343 on IRC. ISON only takes one (1) parameter: a space-separated list of
2344 nicks. For each nickname in the list that is present, the server
2345 adds that to its reply string. Thus the reply string may return
2346 empty (none of the given nicks are present), an exact copy of the
2347 parameter string (all of them present) or as any other subset of the
2348 set of nicks given in the parameter. The only limit on the number
2349 of nicks that may be checked is that the combined length must not be
2350 too large as to cause the server to chop it off so it fits in 512
2353 ISON is only be processed by the server local to the client sending
2354 the command and thus not passed onto other servers for further
2359 RPL_ISON ERR_NEEDMOREPARAMS
2363 ISON phone trillian WiZ jarlek Avalon Angel Monstah
2364 ; Sample ISON request for 7 nicks.
2368 Oikarinen & Reed [Page 42]
2370 RFC 1459 Internet Relay Chat Protocol May 1993
2375 The following is a list of numeric replies which are generated in
2376 response to the commands given above. Each numeric is given with its
2377 number, name and reply string.
2382 "<nickname> :No such nick/channel"
2384 - Used to indicate the nickname parameter supplied to a
2385 command is currently unused.
2387 402 ERR_NOSUCHSERVER
2388 "<server name> :No such server"
2390 - Used to indicate the server name given currently
2393 403 ERR_NOSUCHCHANNEL
2394 "<channel name> :No such channel"
2396 - Used to indicate the given channel name is invalid.
2398 404 ERR_CANNOTSENDTOCHAN
2399 "<channel name> :Cannot send to channel"
2401 - Sent to a user who is either (a) not on a channel
2402 which is mode +n or (b) not a chanop (or mode +v) on
2403 a channel which has mode +m set and is trying to send
2404 a PRIVMSG message to that channel.
2406 405 ERR_TOOMANYCHANNELS
2407 "<channel name> :You have joined too many \
2409 - Sent to a user when they have joined the maximum
2410 number of allowed channels and they try to join
2413 406 ERR_WASNOSUCHNICK
2414 "<nickname> :There was no such nickname"
2416 - Returned by WHOWAS to indicate there is no history
2417 information for that nickname.
2419 407 ERR_TOOMANYTARGETS
2420 "<target> :Duplicate recipients. No message \
2424 Oikarinen & Reed [Page 43]
2426 RFC 1459 Internet Relay Chat Protocol May 1993
2431 - Returned to a client which is attempting to send a
2432 PRIVMSG/NOTICE using the user@host destination format
2433 and for a user@host which has several occurrences.
2436 ":No origin specified"
2438 - PING or PONG message missing the originator parameter
2439 which is required since these commands must work
2440 without valid prefixes.
2443 ":No recipient given (<command>)"
2444 412 ERR_NOTEXTTOSEND
2447 "<mask> :No toplevel domain specified"
2448 414 ERR_WILDTOPLEVEL
2449 "<mask> :Wildcard in toplevel domain"
2451 - 412 - 414 are returned by PRIVMSG to indicate that
2452 the message wasn't delivered for some reason.
2453 ERR_NOTOPLEVEL and ERR_WILDTOPLEVEL are errors that
2454 are returned when an invalid use of
2455 "PRIVMSG $<server>" or "PRIVMSG #<host>" is attempted.
2457 421 ERR_UNKNOWNCOMMAND
2458 "<command> :Unknown command"
2460 - Returned to a registered client to indicate that the
2461 command sent is unknown by the server.
2464 ":MOTD File is missing"
2466 - Server's MOTD file could not be opened by the server.
2469 "<server> :No administrative info available"
2471 - Returned by a server in response to an ADMIN message
2472 when there is an error in finding the appropriate
2476 ":File error doing <file op> on <file>"
2480 Oikarinen & Reed [Page 44]
2482 RFC 1459 Internet Relay Chat Protocol May 1993
2485 - Generic error message used to report a failed file
2486 operation during the processing of a message.
2488 431 ERR_NONICKNAMEGIVEN
2489 ":No nickname given"
2491 - Returned when a nickname parameter expected for a
2492 command and isn't found.
2494 432 ERR_ERRONEUSNICKNAME
2495 "<nick> :Erroneus nickname"
2497 - Returned after receiving a NICK message which contains
2498 characters which do not fall in the defined set. See
2499 section x.x.x for details on valid nicknames.
2501 433 ERR_NICKNAMEINUSE
2502 "<nick> :Nickname is already in use"
2504 - Returned when a NICK message is processed that results
2505 in an attempt to change to a currently existing
2508 436 ERR_NICKCOLLISION
2509 "<nick> :Nickname collision KILL"
2511 - Returned by a server to a client when it detects a
2512 nickname collision (registered of a NICK that
2513 already exists by another server).
2515 441 ERR_USERNOTINCHANNEL
2516 "<nick> <channel> :They aren't on that channel"
2518 - Returned by the server to indicate that the target
2519 user of the command is not on the given channel.
2521 442 ERR_NOTONCHANNEL
2522 "<channel> :You're not on that channel"
2524 - Returned by the server whenever a client tries to
2525 perform a channel effecting command for which the
2526 client isn't a member.
2528 443 ERR_USERONCHANNEL
2529 "<user> <channel> :is already on channel"
2531 - Returned when a client tries to invite a user to a
2532 channel they are already on.
2536 Oikarinen & Reed [Page 45]
2538 RFC 1459 Internet Relay Chat Protocol May 1993
2542 "<user> :User not logged in"
2544 - Returned by the summon after a SUMMON command for a
2545 user was unable to be performed since they were not
2548 445 ERR_SUMMONDISABLED
2549 ":SUMMON has been disabled"
2551 - Returned as a response to the SUMMON command. Must be
2552 returned by any server which does not implement it.
2554 446 ERR_USERSDISABLED
2555 ":USERS has been disabled"
2557 - Returned as a response to the USERS command. Must be
2558 returned by any server which does not implement it.
2560 451 ERR_NOTREGISTERED
2561 ":You have not registered"
2563 - Returned by the server to indicate that the client
2564 must be registered before the server will allow it
2565 to be parsed in detail.
2567 461 ERR_NEEDMOREPARAMS
2568 "<command> :Not enough parameters"
2570 - Returned by the server by numerous commands to
2571 indicate to the client that it didn't supply enough
2574 462 ERR_ALREADYREGISTRED
2575 ":You may not reregister"
2577 - Returned by the server to any link which tries to
2578 change part of the registered details (such as
2579 password or user details from second USER message).
2582 463 ERR_NOPERMFORHOST
2583 ":Your host isn't among the privileged"
2585 - Returned to a client which attempts to register with
2586 a server which does not been setup to allow
2587 connections from the host the attempted connection
2592 Oikarinen & Reed [Page 46]
2594 RFC 1459 Internet Relay Chat Protocol May 1993
2597 464 ERR_PASSWDMISMATCH
2598 ":Password incorrect"
2600 - Returned to indicate a failed attempt at registering
2601 a connection for which a password was required and
2602 was either not given or incorrect.
2604 465 ERR_YOUREBANNEDCREEP
2605 ":You are banned from this server"
2607 - Returned after an attempt to connect and register
2608 yourself with a server which has been setup to
2609 explicitly deny connections to you.
2612 "<channel> :Channel key already set"
2613 471 ERR_CHANNELISFULL
2614 "<channel> :Cannot join channel (+l)"
2616 "<char> :is unknown mode char to me"
2617 473 ERR_INVITEONLYCHAN
2618 "<channel> :Cannot join channel (+i)"
2619 474 ERR_BANNEDFROMCHAN
2620 "<channel> :Cannot join channel (+b)"
2621 475 ERR_BADCHANNELKEY
2622 "<channel> :Cannot join channel (+k)"
2623 481 ERR_NOPRIVILEGES
2624 ":Permission Denied- You're not an IRC operator"
2626 - Any command requiring operator privileges to operate
2627 must return this error to indicate the attempt was
2630 482 ERR_CHANOPRIVSNEEDED
2631 "<channel> :You're not channel operator"
2633 - Any command requiring 'chanop' privileges (such as
2634 MODE messages) must return this error if the client
2635 making the attempt is not a chanop on the specified
2638 483 ERR_CANTKILLSERVER
2639 ":You cant kill a server!"
2641 - Any attempts to use the KILL command on a server
2642 are to be refused and this error returned directly
2648 Oikarinen & Reed [Page 47]
2650 RFC 1459 Internet Relay Chat Protocol May 1993
2654 ":No O-lines for your host"
2656 - If a client sends an OPER message and the server has
2657 not been configured to allow connections from the
2658 client's host as an operator, this error must be
2661 501 ERR_UMODEUNKNOWNFLAG
2662 ":Unknown MODE flag"
2664 - Returned by the server to indicate that a MODE
2665 message was sent with a nickname parameter and that
2666 the a mode flag sent was not recognized.
2668 502 ERR_USERSDONTMATCH
2669 ":Cant change mode for other users"
2671 - Error sent to any user trying to view or change the
2672 user mode for a user other than themselves.
2674 6.2 Command responses.
2677 Dummy reply number. Not used.
2680 ":[<reply>{<space><reply>}]"
2682 - Reply format used by USERHOST to list replies to
2683 the query list. The reply string is composed as
2686 <reply> ::= <nick>['*'] '=' <'+'|'-'><hostname>
2688 The '*' indicates whether the client has registered
2689 as an Operator. The '-' or '+' characters represent
2690 whether the client has set an AWAY message or not
2694 ":[<nick> {<space><nick>}]"
2696 - Reply format used by ISON to list replies to the
2700 "<nick> :<away message>"
2704 Oikarinen & Reed [Page 48]
2706 RFC 1459 Internet Relay Chat Protocol May 1993
2710 ":You are no longer marked as being away"
2712 ":You have been marked as being away"
2714 - These replies are used with the AWAY command (if
2715 allowed). RPL_AWAY is sent to any client sending a
2716 PRIVMSG to a client which is away. RPL_AWAY is only
2717 sent by the server to which the client is connected.
2718 Replies RPL_UNAWAY and RPL_NOWAWAY are sent when the
2719 client removes and sets an AWAY message.
2722 "<nick> <user> <host> * :<real name>"
2724 "<nick> <server> :<server info>"
2725 313 RPL_WHOISOPERATOR
2726 "<nick> :is an IRC operator"
2728 "<nick> <integer> :seconds idle"
2730 "<nick> :End of /WHOIS list"
2731 319 RPL_WHOISCHANNELS
2732 "<nick> :{[@|+]<channel><space>}"
2734 - Replies 311 - 313, 317 - 319 are all replies
2735 generated in response to a WHOIS message. Given that
2736 there are enough parameters present, the answering
2737 server must either formulate a reply out of the above
2738 numerics (if the query nick is found) or return an
2739 error reply. The '*' in RPL_WHOISUSER is there as
2740 the literal character and not as a wild card. For
2741 each reply set, only RPL_WHOISCHANNELS may appear
2742 more than once (for long lists of channel names).
2743 The '@' and '+' characters next to the channel name
2744 indicate whether a client is a channel operator or
2745 has been granted permission to speak on a moderated
2746 channel. The RPL_ENDOFWHOIS reply is used to mark
2747 the end of processing a WHOIS message.
2750 "<nick> <user> <host> * :<real name>"
2752 "<nick> :End of WHOWAS"
2754 - When replying to a WHOWAS message, a server must use
2755 the replies RPL_WHOWASUSER, RPL_WHOISSERVER or
2756 ERR_WASNOSUCHNICK for each nickname in the presented
2760 Oikarinen & Reed [Page 49]
2762 RFC 1459 Internet Relay Chat Protocol May 1993
2765 list. At the end of all reply batches, there must
2766 be RPL_ENDOFWHOWAS (even if there was only one reply
2767 and it was an error).
2770 "Channel :Users Name"
2772 "<channel> <# visible> :<topic>"
2776 - Replies RPL_LISTSTART, RPL_LIST, RPL_LISTEND mark
2777 the start, actual replies with data and end of the
2778 server's response to a LIST command. If there are
2779 no channels available to return, only the start
2780 and end reply must be sent.
2782 324 RPL_CHANNELMODEIS
2783 "<channel> <mode> <mode params>"
2786 "<channel> :No topic is set"
2788 "<channel> :<topic>"
2790 - When sending a TOPIC message to determine the
2791 channel topic, one of two replies is sent. If
2792 the topic is set, RPL_TOPIC is sent back else
2798 - Returned by the server to indicate that the
2799 attempted INVITE message was successful and is
2800 being passed onto the end client.
2803 "<user> :Summoning user to IRC"
2805 - Returned by a server answering a SUMMON message to
2806 indicate that it is summoning that user.
2809 "<version>.<debuglevel> <server> :<comments>"
2811 - Reply by the server showing its version details.
2812 The <version> is the version of the software being
2816 Oikarinen & Reed [Page 50]
2818 RFC 1459 Internet Relay Chat Protocol May 1993
2821 used (including any patchlevel revisions) and the
2822 <debuglevel> is used to indicate if the server is
2823 running in "debug mode".
2825 The "comments" field may contain any comments about
2826 the version or further version details.
2829 "<channel> <user> <host> <server> <nick> \
2830 <H|G>[*][@|+] :<hopcount> <real name>"
2832 "<name> :End of /WHO list"
2834 - The RPL_WHOREPLY and RPL_ENDOFWHO pair are used
2835 to answer a WHO message. The RPL_WHOREPLY is only
2836 sent if there is an appropriate match to the WHO
2837 query. If there is a list of parameters supplied
2838 with a WHO message, a RPL_ENDOFWHO must be sent
2839 after processing each list item with <name> being
2843 "<channel> :[[@|+]<nick> [[@|+]<nick> [...]]]"
2845 "<channel> :End of /NAMES list"
2847 - To reply to a NAMES message, a reply pair consisting
2848 of RPL_NAMREPLY and RPL_ENDOFNAMES is sent by the
2849 server back to the client. If there is no channel
2850 found as in the query, then only RPL_ENDOFNAMES is
2851 returned. The exception to this is when a NAMES
2852 message is sent with no parameters and all visible
2853 channels and contents are sent back in a series of
2854 RPL_NAMEREPLY messages with a RPL_ENDOFNAMES to mark
2858 "<mask> <server> :<hopcount> <server info>"
2860 "<mask> :End of /LINKS list"
2862 - In replying to the LINKS message, a server must send
2863 replies back using the RPL_LINKS numeric and mark the
2864 end of the list using an RPL_ENDOFLINKS reply.
2868 368 RPL_ENDOFBANLIST
2872 Oikarinen & Reed [Page 51]
2874 RFC 1459 Internet Relay Chat Protocol May 1993
2877 "<channel> :End of channel ban list"
2879 - When listing the active 'bans' for a given channel,
2880 a server is required to send the list back using the
2881 RPL_BANLIST and RPL_ENDOFBANLIST messages. A separate
2882 RPL_BANLIST is sent for each active banid. After the
2883 banids have been listed (or if none present) a
2884 RPL_ENDOFBANLIST must be sent.
2889 ":End of /INFO list"
2891 - A server responding to an INFO message is required to
2892 send all its 'info' in a series of RPL_INFO messages
2893 with a RPL_ENDOFINFO reply to indicate the end of the
2897 ":- <server> Message of the day - "
2901 ":End of /MOTD command"
2903 - When responding to the MOTD message and the MOTD file
2904 is found, the file is displayed line by line, with
2905 each line no longer than 80 characters, using
2906 RPL_MOTD format replies. These should be surrounded
2907 by a RPL_MOTDSTART (before the RPL_MOTDs) and an
2908 RPL_ENDOFMOTD (after).
2911 ":You are now an IRC operator"
2913 - RPL_YOUREOPER is sent back to a client which has
2914 just successfully issued an OPER message and gained
2918 "<config file> :Rehashing"
2920 - If the REHASH option is used and an operator sends
2921 a REHASH message, an RPL_REHASHING is sent back to
2928 Oikarinen & Reed [Page 52]
2930 RFC 1459 Internet Relay Chat Protocol May 1993
2933 "<server> :<string showing server's local time>"
2935 - When replying to the TIME message, a server must send
2936 the reply using the RPL_TIME format above. The string
2937 showing the time need only contain the correct day and
2938 time there. There is no further requirement for the
2942 ":UserID Terminal Host"
2950 - If the USERS message is handled by a server, the
2951 replies RPL_USERSTART, RPL_USERS, RPL_ENDOFUSERS and
2952 RPL_NOUSERS are used. RPL_USERSSTART must be sent
2953 first, following by either a sequence of RPL_USERS
2954 or a single RPL_NOUSER. Following this is
2958 "Link <version & debug level> <destination> \
2960 201 RPL_TRACECONNECTING
2961 "Try. <class> <server>"
2962 202 RPL_TRACEHANDSHAKE
2963 "H.S. <class> <server>"
2964 203 RPL_TRACEUNKNOWN
2965 "???? <class> [<client IP address in dot form>]"
2966 204 RPL_TRACEOPERATOR
2967 "Oper <class> <nick>"
2969 "User <class> <nick>"
2971 "Serv <class> <int>S <int>C <server> \
2972 <nick!user|*!*>@<host|server>"
2973 208 RPL_TRACENEWTYPE
2974 "<newtype> 0 <client name>"
2976 "File <logfile> <debug level>"
2978 - The RPL_TRACE* are all returned by the server in
2979 response to the TRACE message. How many are
2980 returned is dependent on the the TRACE message and
2984 Oikarinen & Reed [Page 53]
2986 RFC 1459 Internet Relay Chat Protocol May 1993
2989 whether it was sent by an operator or not. There
2990 is no predefined order for which occurs first.
2991 Replies RPL_TRACEUNKNOWN, RPL_TRACECONNECTING and
2992 RPL_TRACEHANDSHAKE are all used for connections
2993 which have not been fully established and are either
2994 unknown, still attempting to connect or in the
2995 process of completing the 'server handshake'.
2996 RPL_TRACELINK is sent by any server which handles
2997 a TRACE message and has to pass it on to another
2998 server. The list of RPL_TRACELINKs sent in
2999 response to a TRACE command traversing the IRC
3000 network should reflect the actual connectivity of
3001 the servers themselves along that path.
3002 RPL_TRACENEWTYPE is to be used for any connection
3003 which does not fit in the other categories but is
3004 being displayed anyway.
3006 211 RPL_STATSLINKINFO
3007 "<linkname> <sendq> <sent messages> \
3008 <sent bytes> <received messages> \
3009 <received bytes> <time open>"
3010 212 RPL_STATSCOMMANDS
3013 "C <host> * <name> <port> <class>"
3015 "N <host> * <name> <port> <class>"
3017 "I <host> * <host> <port> <class>"
3019 "K <host> * <username> <port> <class>"
3021 "Y <class> <ping frequency> <connect \
3022 frequency> <max sendq>"
3024 "<stats letter> :End of /STATS report"
3026 "L <hostmask> * <servername> <maxdepth>"
3028 ":Server Up %d days %d:%02d:%02d"
3030 "O <hostmask> * <name>"
3032 "H <hostmask> * <servername>"
3035 "<user mode string>"
3040 Oikarinen & Reed [Page 54]
3042 RFC 1459 Internet Relay Chat Protocol May 1993
3045 - To answer a query about a client's own mode,
3046 RPL_UMODEIS is sent back.
3049 ":There are <integer> users and <integer> \
3050 invisible on <integer> servers"
3052 "<integer> :operator(s) online"
3053 253 RPL_LUSERUNKNOWN
3054 "<integer> :unknown connection(s)"
3055 254 RPL_LUSERCHANNELS
3056 "<integer> :channels formed"
3058 ":I have <integer> clients and <integer> \
3061 - In processing an LUSERS message, the server
3062 sends a set of replies from RPL_LUSERCLIENT,
3063 RPL_LUSEROP, RPL_USERUNKNOWN,
3064 RPL_LUSERCHANNELS and RPL_LUSERME. When
3065 replying, a server must send back
3066 RPL_LUSERCLIENT and RPL_LUSERME. The other
3067 replies are only sent back if a non-zero count
3071 "<server> :Administrative info"
3079 - When replying to an ADMIN message, a server
3080 is expected to use replies RLP_ADMINME
3081 through to RPL_ADMINEMAIL and provide a text
3082 message with each. For RPL_ADMINLOC1 a
3083 description of what city, state and country
3084 the server is in is expected, followed by
3085 details of the university and department
3086 (RPL_ADMINLOC2) and finally the administrative
3087 contact for the server (an email address here
3088 is required) in RPL_ADMINEMAIL.
3096 Oikarinen & Reed [Page 55]
3098 RFC 1459 Internet Relay Chat Protocol May 1993
3101 6.3 Reserved numerics.
3103 These numerics are not described above since they fall into one of
3104 the following categories:
3106 1. no longer in use;
3108 2. reserved for future planned use;
3110 3. in current use but are part of a non-generic 'feature' of
3111 the current IRC server.
3113 209 RPL_TRACECLASS 217 RPL_STATSQLINE
3114 231 RPL_SERVICEINFO 232 RPL_ENDOFSERVICES
3115 233 RPL_SERVICE 234 RPL_SERVLIST
3117 316 RPL_WHOISCHANOP 361 RPL_KILLDONE
3118 362 RPL_CLOSING 363 RPL_CLOSEEND
3119 373 RPL_INFOSTART 384 RPL_MYPORTIS
3120 466 ERR_YOUWILLBEBANNED 476 ERR_BADCHANMASK
3121 492 ERR_NOSERVICEHOST
3123 7. Client and server authentication
3125 Clients and servers are both subject to the same level of
3126 authentication. For both, an IP number to hostname lookup (and
3127 reverse check on this) is performed for all connections made to the
3128 server. Both connections are then subject to a password check (if
3129 there is a password set for that connection). These checks are
3130 possible on all connections although the password check is only
3131 commonly used with servers.
3133 An additional check that is becoming of more and more common is that
3134 of the username responsible for making the connection. Finding the
3135 username of the other end of the connection typically involves
3136 connecting to an authentication server such as IDENT as described in
3139 Given that without passwords it is not easy to reliably determine who
3140 is on the other end of a network connection, use of passwords is
3141 strongly recommended on inter-server connections in addition to any
3142 other measures such as using an ident server.
3144 8. Current implementations
3146 The only current implementation of this protocol is the IRC server,
3147 version 2.8. Earlier versions may implement some or all of the
3148 commands described by this document with NOTICE messages replacing
3152 Oikarinen & Reed [Page 56]
3154 RFC 1459 Internet Relay Chat Protocol May 1993
3157 many of the numeric replies. Unfortunately, due to backward
3158 compatibility requirements, the implementation of some parts of this
3159 document varies with what is laid out. On notable difference is:
3161 * recognition that any LF or CR anywhere in a message marks the
3162 end of that message (instead of requiring CR-LF);
3164 The rest of this section deals with issues that are mostly of
3165 importance to those who wish to implement a server but some parts
3166 also apply directly to clients as well.
3168 8.1 Network protocol: TCP - why it is best used here.
3170 IRC has been implemented on top of TCP since TCP supplies a reliable
3171 network protocol which is well suited to this scale of conferencing.
3172 The use of multicast IP is an alternative, but it is not widely
3173 available or supported at the present time.
3175 8.1.1 Support of Unix sockets
3177 Given that Unix domain sockets allow listen/connect operations, the
3178 current implementation can be configured to listen and accept both
3179 client and server connections on a Unix domain socket. These are
3180 recognized as sockets where the hostname starts with a '/'.
3182 When providing any information about the connections on a Unix domain
3183 socket, the server is required to supplant the actual hostname in
3184 place of the pathname unless the actual socket name is being asked
3189 To provide useful 'non-buffered' network IO for clients and servers,
3190 each connection is given its own private 'input buffer' in which the
3191 results of the most recent read and parsing are kept. A buffer size
3192 of 512 bytes is used so as to hold 1 full message, although, this
3193 will usually hold several commands. The private buffer is parsed
3194 after every read operation for valid messages. When dealing with
3195 multiple messages from one client in the buffer, care should be taken
3196 in case one happens to cause the client to be 'removed'.
3198 8.3 Message delivery
3200 It is common to find network links saturated or hosts to which you
3201 are sending data unable to send data. Although Unix typically
3202 handles this through the TCP window and internal buffers, the server
3203 often has large amounts of data to send (especially when a new
3204 server-server link forms) and the small buffers provided in the
3208 Oikarinen & Reed [Page 57]
3210 RFC 1459 Internet Relay Chat Protocol May 1993
3213 kernel are not enough for the outgoing queue. To alleviate this
3214 problem, a "send queue" is used as a FIFO queue for data to be sent.
3215 A typical "send queue" may grow to 200 Kbytes on a large IRC network
3216 with a slow network connection when a new server connects.
3218 When polling its connections, a server will first read and parse all
3219 incoming data, queuing any data to be sent out. When all available
3220 input is processed, the queued data is sent. This reduces the number
3221 of write() system calls and helps TCP make bigger packets.
3223 8.4 Connection 'Liveness'
3225 To detect when a connection has died or become unresponsive, the
3226 server must ping each of its connections that it doesn't get a
3227 response from in a given amount of time.
3229 If a connection doesn't respond in time, its connection is closed
3230 using the appropriate procedures. A connection is also dropped if
3231 its sendq grows beyond the maximum allowed, because it is better to
3232 close a slow connection than have a server process block.
3234 8.5 Establishing a server to client connection
3236 Upon connecting to an IRC server, a client is sent the MOTD (if
3237 present) as well as the current user/server count (as per the LUSER
3238 command). The server is also required to give an unambiguous message
3239 to the client which states its name and version as well as any other
3240 introductory messages which may be deemed appropriate.
3242 After dealing with this, the server must then send out the new user's
3243 nickname and other information as supplied by itself (USER command)
3244 and as the server could discover (from DNS/authentication servers).
3245 The server must send this information out with NICK first followed by
3248 8.6 Establishing a server-server connection.
3250 The process of establishing of a server-to-server connection is
3251 fraught with danger since there are many possible areas where
3252 problems can occur - the least of which are race conditions.
3254 After a server has received a connection following by a PASS/SERVER
3255 pair which were recognised as being valid, the server should then
3256 reply with its own PASS/SERVER information for that connection as
3257 well as all of the other state information it knows about as
3260 When the initiating server receives a PASS/SERVER pair, it too then
3264 Oikarinen & Reed [Page 58]
3266 RFC 1459 Internet Relay Chat Protocol May 1993
3269 checks that the server responding is authenticated properly before
3270 accepting the connection to be that server.
3272 8.6.1 Server exchange of state information when connecting
3274 The order of state information being exchanged between servers is
3275 essential. The required order is as follows:
3277 * all known other servers;
3279 * all known user information;
3281 * all known channel information.
3283 Information regarding servers is sent via extra SERVER messages, user
3284 information with NICK/USER/MODE/JOIN messages and channels with MODE
3287 NOTE: channel topics are *NOT* exchanged here because the TOPIC
3288 command overwrites any old topic information, so at best, the two
3289 sides of the connection would exchange topics.
3291 By passing the state information about servers first, any collisions
3292 with servers that already exist occur before nickname collisions due
3293 to a second server introducing a particular nickname. Due to the IRC
3294 network only being able to exist as an acyclic graph, it may be
3295 possible that the network has already reconnected in another
3296 location, the place where the collision occurs indicating where the
3299 8.7 Terminating server-client connections
3301 When a client connection closes, a QUIT message is generated on
3302 behalf of the client by the server to which the client connected. No
3303 other message is to be generated or used.
3305 8.8 Terminating server-server connections
3307 If a server-server connection is closed, either via a remotely
3308 generated SQUIT or 'natural' causes, the rest of the connected IRC
3309 network must have its information updated with by the server which
3310 detected the closure. The server then sends a list of SQUITs (one
3311 for each server behind that connection) and a list of QUITs (again,
3312 one for each client behind that connection).
3320 Oikarinen & Reed [Page 59]
3322 RFC 1459 Internet Relay Chat Protocol May 1993
3325 8.9 Tracking nickname changes
3327 All IRC servers are required to keep a history of recent nickname
3328 changes. This is required to allow the server to have a chance of
3329 keeping in touch of things when nick-change race conditions occur
3330 with commands which manipulate them. Commands which must trace nick
3333 * KILL (the nick being killed)
3337 * KICK (the nick being kicked)
3339 No other commands are to have nick changes checked for.
3341 In the above cases, the server is required to first check for the
3342 existence of the nickname, then check its history to see who that
3343 nick currently belongs to (if anyone!). This reduces the chances of
3344 race conditions but they can still occur with the server ending up
3345 affecting the wrong client. When performing a change trace for an
3346 above command it is recommended that a time range be given and
3347 entries which are too old ignored.
3349 For a reasonable history, a server should be able to keep previous
3350 nickname for every client it knows about if they all decided to
3351 change. This size is limited by other factors (such as memory, etc).
3353 8.10 Flood control of clients
3355 With a large network of interconnected IRC servers, it is quite easy
3356 for any single client attached to the network to supply a continuous
3357 stream of messages that result in not only flooding the network, but
3358 also degrading the level of service provided to others. Rather than
3359 require every 'victim' to be provide their own protection, flood
3360 protection was written into the server and is applied to all clients
3361 except services. The current algorithm is as follows:
3363 * check to see if client's `message timer' is less than
3364 current time (set to be equal if it is);
3366 * read any data present from the client;
3368 * while the timer is less than ten seconds ahead of the current
3369 time, parse any present messages and penalize the client by
3370 2 seconds for each message;
3372 which in essence means that the client may send 1 message every 2
3376 Oikarinen & Reed [Page 60]
3378 RFC 1459 Internet Relay Chat Protocol May 1993
3381 seconds without being adversely affected.
3383 8.11 Non-blocking lookups
3385 In a real-time environment, it is essential that a server process do
3386 as little waiting as possible so that all the clients are serviced
3387 fairly. Obviously this requires non-blocking IO on all network
3388 read/write operations. For normal server connections, this was not
3389 difficult, but there are other support operations that may cause the
3390 server to block (such as disk reads). Where possible, such activity
3391 should be performed with a short timeout.
3393 8.11.1 Hostname (DNS) lookups
3395 Using the standard resolver libraries from Berkeley and others has
3396 meant large delays in some cases where replies have timed out. To
3397 avoid this, a separate set of DNS routines were written which were
3398 setup for non-blocking IO operations and then polled from within the
3399 main server IO loop.
3401 8.11.2 Username (Ident) lookups
3403 Although there are numerous ident libraries for use and inclusion
3404 into other programs, these caused problems since they operated in a
3405 synchronous manner and resulted in frequent delays. Again the
3406 solution was to write a set of routines which would cooperate with
3407 the rest of the server and work using non-blocking IO.
3409 8.12 Configuration File
3411 To provide a flexible way of setting up and running the server, it is
3412 recommended that a configuration file be used which contains
3413 instructions to the server on the following:
3415 * which hosts to accept client connections from;
3417 * which hosts to allow to connect as servers;
3419 * which hosts to connect to (both actively and
3422 * information about where the server is (university,
3423 city/state, company are examples of this);
3425 * who is responsible for the server and an email address
3426 at which they can be contacted;
3428 * hostnames and passwords for clients which wish to be given
3432 Oikarinen & Reed [Page 61]
3434 RFC 1459 Internet Relay Chat Protocol May 1993
3437 access to restricted operator commands.
3439 In specifying hostnames, both domain names and use of the 'dot'
3440 notation (127.0.0.1) should both be accepted. It must be possible to
3441 specify the password to be used/accepted for all outgoing and
3442 incoming connections (although the only outgoing connections are
3443 those to other servers).
3445 The above list is the minimum requirement for any server which wishes
3446 to make a connection with another server. Other items which may be
3449 * specifying which servers other server may introduce;
3451 * how deep a server branch is allowed to become;
3453 * hours during which clients may connect.
3455 8.12.1 Allowing clients to connect
3457 A server should use some sort of 'access control list' (either in the
3458 configuration file or elsewhere) that is read at startup and used to
3459 decide what hosts clients may use to connect to it.
3461 Both 'deny' and 'allow' should be implemented to provide the required
3462 flexibility for host access control.
3466 The granting of operator privileges to a disruptive person can have
3467 dire consequences for the well-being of the IRC net in general due to
3468 the powers given to them. Thus, the acquisition of such powers
3469 should not be very easy. The current setup requires two 'passwords'
3470 to be used although one of them is usually easy guessed. Storage of
3471 oper passwords in configuration files is preferable to hard coding
3472 them in and should be stored in a crypted format (ie using crypt(3)
3473 from Unix) to prevent easy theft.
3475 8.12.3 Allowing servers to connect
3477 The interconnection of server is not a trivial matter: a bad
3478 connection can have a large impact on the usefulness of IRC. Thus,
3479 each server should have a list of servers to which it may connect and
3480 which servers may connect to it. Under no circumstances should a
3481 server allow an arbitrary host to connect as a server. In addition
3482 to which servers may and may not connect, the configuration file
3483 should also store the password and other characteristics of that
3488 Oikarinen & Reed [Page 62]
3490 RFC 1459 Internet Relay Chat Protocol May 1993
3493 8.12.4 Administrivia
3495 To provide accurate and valid replies to the ADMIN command (see
3496 section 4.3.7), the server should find the relevant details in the
3499 8.13 Channel membership
3501 The current server allows any registered local user to join upto 10
3502 different channels. There is no limit imposed on non-local users so
3503 that the server remains (reasonably) consistant with all others on a
3504 channel membership basis
3508 There are a number of recognized problems with this protocol, all of
3509 which hope to be solved sometime in the near future during its
3510 rewrite. Currently, work is underway to find working solutions to
3515 It is widely recognized that this protocol does not scale
3516 sufficiently well when used in a large arena. The main problem comes
3517 from the requirement that all servers know about all other servers
3518 and users and that information regarding them be updated as soon as
3519 it changes. It is also desirable to keep the number of servers low
3520 so that the path length between any two points is kept minimal and
3521 the spanning tree as strongly branched as possible.
3525 The current IRC protocol has 3 types of labels: the nickname, the
3526 channel name and the server name. Each of the three types has its
3527 own domain and no duplicates are allowed inside that domain.
3528 Currently, it is possible for users to pick the label for any of the
3529 three, resulting in collisions. It is widely recognized that this
3530 needs reworking, with a plan for unique names for channels and nicks
3531 that don't collide being desirable as well as a solution allowing a
3536 The idea of the nickname on IRC is very convenient for users to use
3537 when talking to each other outside of a channel, but there is only a
3538 finite nickname space and being what they are, its not uncommon for
3539 several people to want to use the same nick. If a nickname is chosen
3540 by two people using this protocol, either one will not succeed or
3544 Oikarinen & Reed [Page 63]
3546 RFC 1459 Internet Relay Chat Protocol May 1993
3549 both will removed by use of KILL (4.6.1).
3553 The current channel layout requires that all servers know about all
3554 channels, their inhabitants and properties. Besides not scaling
3555 well, the issue of privacy is also a concern. A collision of
3556 channels is treated as an inclusive event (both people who create the
3557 new channel are considered to be members of it) rather than an
3558 exclusive one such as used to solve nickname collisions.
3562 Although the number of servers is usually small relative to the
3563 number of users and channels, they two currently required to be known
3564 globally, either each one separately or hidden behind a mask.
3568 In some places within the server code, it has not been possible to
3569 avoid N^2 algorithms such as checking the channel list of a set
3572 In current server versions, there are no database consistency checks,
3573 each server assumes that a neighbouring server is correct. This
3574 opens the door to large problems if a connecting server is buggy or
3575 otherwise tries to introduce contradictions to the existing net.
3577 Currently, because of the lack of unique internal and global labels,
3578 there are a multitude of race conditions that exist. These race
3579 conditions generally arise from the problem of it taking time for
3580 messages to traverse and effect the IRC network. Even by changing to
3581 unique labels, there are problems with channel-related commands being
3584 10. Current support and availability
3586 Mailing lists for IRC related discussion:
3587 Future protocol: ircd-three-request@eff.org
3588 General discussion: operlist-request@eff.org
3590 Software implemenations
3592 nic.funet.fi:/pub/irc
3593 coombs.anu.edu.au:/pub/irc
3600 Oikarinen & Reed [Page 64]
3602 RFC 1459 Internet Relay Chat Protocol May 1993
3605 Security Considerations
3607 Security issues are discussed in sections 4.1, 4.1.1, 4.1.3, 5.5, and
3610 12. Authors' Addresses
3617 Email: jto@tolsun.oulu.fi
3622 Watsonia, Victoria 3087
3625 Email: avalon@coombs.anu.edu.au
3656 Oikarinen & Reed [Page 65]
projects / ircu2.10.12-pk.git / blob