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