rfc2812.txt 1 Network Working Group C. Kalt
2 Request for Comments: 2812 April 2000
3 Updates: 1459
4 Category: Informational
5
6 Internet Relay Chat: Client Protocol
7
8 Status of this Memo
9
10 This memo provides information for the Internet community. It does
11 not specify an Internet standard of any kind. Distribution of this
12 memo is unlimited.
13
14 Copyright Notice
15
16 Copyright (C) The Internet Society (2000). All Rights Reserved.
17
18 IESG NOTE:
19
20 The IRC protocol itself enables several possibilities of transferring
21 data between clients, and just like with other transfer mechanisms
22 like email, the receiver of the data has to be careful about how the
23 data is handled. For more information on security issues with the IRC
24 protocol, see for example http://www.irchelp.org/irchelp/security/.
25
26 Abstract
27
28 The IRC (Internet Relay Chat) protocol is for use with text based
29 conferencing; the simplest client being any socket program capable of
30 connecting to the server.
31
32 This document defines the Client Protocol, and assumes that the
33 reader is familiar with the IRC Architecture [IRC-ARCH].
34
35 Table of Contents
36
37 1. Labels ..................................................... 3
38 1.1 Servers ................................................ 3
39 1.2 Clients ................................................ 3
40 1.2.1 Users ............................................. 4
41 1.2.1.1 Operators .................................... 4
42 1.2.2 Services .......................................... 4
43 1.3 Channels ............................................... 4
44 2. The IRC Client Specification ............................... 5
45 2.1 Overview ............................................... 5
46 2.2 Character codes ........................................ 5
47 2.3 Messages ............................................... 5
48
49 2.3.1 Message format in Augmented BNF ................... 6
50 2.4 Numeric replies ........................................ 8
51 2.5 Wildcard expressions ................................... 9
52 3. Message Details ............................................ 9
53 3.1 Connection Registration ................................ 10
54 3.1.1 Password message .................................. 10
55 3.1.2 Nick message ...................................... 10
56 3.1.3 User message ...................................... 11
57 3.1.4 Oper message ...................................... 12
58 3.1.5 User mode message ................................. 12
59 3.1.6 Service message ................................... 13
60 3.1.7 Quit .............................................. 14
61 3.1.8 Squit ............................................. 15
62 3.2 Channel operations ..................................... 15
63 3.2.1 Join message ...................................... 16
64 3.2.2 Part message ...................................... 17
65 3.2.3 Channel mode message .............................. 18
66 3.2.4 Topic message ..................................... 19
67 3.2.5 Names message ..................................... 20
68 3.2.6 List message ...................................... 21
69 3.2.7 Invite message .................................... 21
70 3.2.8 Kick command ...................................... 22
71 3.3 Sending messages ....................................... 23
72 3.3.1 Private messages .................................. 23
73 3.3.2 Notice ............................................ 24
74 3.4 Server queries and commands ............................ 25
75 3.4.1 Motd message ...................................... 25
76 3.4.2 Lusers message .................................... 25
77 3.4.3 Version message ................................... 26
78 3.4.4 Stats message ..................................... 26
79 3.4.5 Links message ..................................... 27
80 3.4.6 Time message ...................................... 28
81 3.4.7 Connect message ................................... 28
82 3.4.8 Trace message ..................................... 29
83 3.4.9 Admin command ..................................... 30
84 3.4.10 Info command ...................................... 31
85 3.5 Service Query and Commands ............................. 31
86 3.5.1 Servlist message .................................. 31
87 3.5.2 Squery ............................................ 32
88 3.6 User based queries ..................................... 32
89 3.6.1 Who query ......................................... 32
90 3.6.2 Whois query ....................................... 33
91 3.6.3 Whowas ............................................ 34
92 3.7 Miscellaneous messages ................................. 34
93 3.7.1 Kill message ...................................... 35
94 3.7.2 Ping message ...................................... 36
95 3.7.3 Pong message ...................................... 37
96 3.7.4 Error ............................................. 37
97
98 4. Optional features .......................................... 38
99 4.1 Away ................................................... 38
100 4.2 Rehash message ......................................... 39
101 4.3 Die message ............................................ 39
102 4.4 Restart message ........................................ 40
103 4.5 Summon message ......................................... 40
104 4.6 Users .................................................. 41
105 4.7 Operwall message ....................................... 41
106 4.8 Userhost message ....................................... 42
107 4.9 Ison message ........................................... 42
108 5. Replies .................................................... 43
109 5.1 Command responses ...................................... 43
110 5.2 Error Replies .......................................... 53
111 5.3 Reserved numerics ...................................... 59
112 6. Current implementations .................................... 60
113 7. Current problems ........................................... 60
114 7.1 Nicknames .............................................. 60
115 7.2 Limitation of wildcards ................................ 61
116 7.3 Security considerations ................................ 61
117 8. Current support and availability ........................... 61
118 9. Acknowledgements ........................................... 61
119 10. References ................................................ 62
120 11. Author's Address .......................................... 62
121 12. Full Copyright Statement .................................. 63
122
123 1. Labels
124
125 This section defines the identifiers used for the various components
126 of the IRC protocol.
127
128 1.1 Servers
129
130 Servers are uniquely identified by their name, which has a maximum
131 length of sixty three (63) characters. See the protocol grammar
132 rules (section 2.3.1) for what may and may not be used in a server
133 name.
134
135 1.2 Clients
136
137 For each client all servers MUST have the following information: a
138 netwide unique identifier (whose format depends on the type of
139 client) and the server which introduced the client.
140
141 1.2.1 Users
142
143 Each user is distinguished from other users by a unique nickname
144 having a maximum length of nine (9) characters. See the protocol
145 grammar rules (section 2.3.1) for what may and may not be used in a
146 nickname.
147
148 While the maximum length is limited to nine characters, clients
149 SHOULD accept longer strings as they may become used in future
150 evolutions of the protocol.
151
152 1.2.1.1 Operators
153
154 To allow a reasonable amount of order to be kept within the IRC
155 network, a special class of users (operators) is allowed to perform
156 general maintenance functions on the network. Although the powers
157 granted to an operator can be considered as 'dangerous', they are
158 nonetheless often necessary. Operators SHOULD be able to perform
159 basic network tasks such as disconnecting and reconnecting servers as
160 needed. In recognition of this need, the protocol discussed herein
161 provides for operators only to be able to perform such functions.
162 See sections 3.1.8 (SQUIT) and 3.4.7 (CONNECT).
163
164 A more controversial power of operators is the ability to remove a
165 user from the connected network by 'force', i.e., operators are able
166 to close the connection between any client and server. The
167 justification for this is very delicate since its abuse is both
168 destructive and annoying, and its benefits close to inexistent. For
169 further details on this type of action, see section 3.7.1 (KILL).
170
171 1.2.2 Services
172
173 Each service is distinguished from other services by a service name
174 composed of a nickname and a server name. As for users, the nickname
175 has a maximum length of nine (9) characters. See the protocol
176 grammar rules (section 2.3.1) for what may and may not be used in a
177 nickname.
178
179 1.3 Channels
180
181 Channels names are strings (beginning with a '&', '#', '+' or '!'
182 character) of length up to fifty (50) characters. Apart from the
183 requirement that the first character is either '&', '#', '+' or '!',
184 the only restriction on a channel name is that it SHALL NOT contain
185 any spaces (' '), a control G (^G or ASCII 7), a comma (','). Space
186 is used as parameter separator and command is used as a list item
187 separator by the protocol). A colon (':') can also be used as a
188 delimiter for the channel mask. Channel names are case insensitive.
189
190 See the protocol grammar rules (section 2.3.1) for the exact syntax
191 of a channel name.
192
193 Each prefix characterizes a different channel type. The definition
194 of the channel types is not relevant to the client-server protocol
195 and thus it is beyond the scope of this document. More details can
196 be found in "Internet Relay Chat: Channel Management" [IRC-CHAN].
197
198 2. The IRC Client Specification
199
200 2.1 Overview
201
202 The protocol as described herein is for use only with client to
203 server connections when the client registers as a user.
204
205 2.2 Character codes
206
207 No specific character set is specified. The protocol is based on a
208 set of codes which are composed of eight (8) bits, making up an
209 octet. Each message may be composed of any number of these octets;
210 however, some octet values are used for control codes, which act as
211 message delimiters.
212
213 Regardless of being an 8-bit protocol, the delimiters and keywords
214 are such that protocol is mostly usable from US-ASCII terminal and a
215 telnet connection.
216
217 Because of IRC's Scandinavian origin, the characters {}|^ are
218 considered to be the lower case equivalents of the characters []\~,
219 respectively. This is a critical issue when determining the
220 equivalence of two nicknames or channel names.
221
222 2.3 Messages
223
224 Servers and clients send each other messages, which may or may not
225 generate a reply. If the message contains a valid command, as
226 described in later sections, the client should expect a reply as
227 specified but it is not advised to wait forever for the reply; client
228 to server and server to server communication is essentially
229 asynchronous by nature.
230
231 Each IRC message may consist of up to three main parts: the prefix
232 (OPTIONAL), the command, and the command parameters (maximum of
233 fifteen (15)). The prefix, command, and all parameters are separated
234 by one ASCII space character (0x20) each.
235
236 The presence of a prefix is indicated with a single leading ASCII
237 colon character (':', 0x3b), which MUST be the first character of the
238 message itself. There MUST be NO gap (whitespace) between the colon
239 and the prefix. The prefix is used by servers to indicate the true
240 origin of the message. If the prefix is missing from the message, it
241 is assumed to have originated from the connection from which it was
242 received from. Clients SHOULD NOT use a prefix when sending a
243 message; if they use one, the only valid prefix is the registered
244 nickname associated with the client.
245
246 The command MUST either be a valid IRC command or a three (3) digit
247 number represented in ASCII text.
248
249 IRC messages are always lines of characters terminated with a CR-LF
250 (Carriage Return - Line Feed) pair, and these messages SHALL NOT
251 exceed 512 characters in length, counting all characters including
252 the trailing CR-LF. Thus, there are 510 characters maximum allowed
253 for the command and its parameters. There is no provision for
254 continuation of message lines. See section 6 for more details about
255 current implementations.
256
257 2.3.1 Message format in Augmented BNF
258
259 The protocol messages must be extracted from the contiguous stream of
260 octets. The current solution is to designate two characters, CR and
261 LF, as message separators. Empty messages are silently ignored,
262 which permits use of the sequence CR-LF between messages without
263 extra problems.
264
265 The extracted message is parsed into the components <prefix>,
266 <command> and list of parameters (<params>).
267
268 The Augmented BNF representation for this is:
269
270 message = [ ":" prefix SPACE ] command [ params ] crlf
271 prefix = servername / ( nickname [ [ "!" user ] "@" host ] )
272 command = 1*letter / 3digit
273 params = *14( SPACE middle ) [ SPACE ":" trailing ]
274 =/ 14( SPACE middle ) [ SPACE [ ":" ] trailing ]
275
276 nospcrlfcl = %x01-09 / %x0B-0C / %x0E-1F / %x21-39 / %x3B-FF
277 ; any octet except NUL, CR, LF, " " and ":"
278 middle = nospcrlfcl *( ":" / nospcrlfcl )
279 trailing = *( ":" / " " / nospcrlfcl )
280
281 SPACE = %x20 ; space character
282 crlf = %x0D %x0A ; "carriage return" "linefeed"
283
284 NOTES:
285 1) After extracting the parameter list, all parameters are equal
286 whether matched by <middle> or <trailing>. <trailing> is just a
287 syntactic trick to allow SPACE within the parameter.
288
289 2) The NUL (%x00) character is not special in message framing, and
290 basically could end up inside a parameter, but it would cause
291 extra complexities in normal C string handling. Therefore, NUL
292 is not allowed within messages.
293
294 Most protocol messages specify additional semantics and syntax for
295 the extracted parameter strings dictated by their position in the
296 list. For example, many server commands will assume that the first
297 parameter after the command is the list of targets, which can be
298 described with:
299
300 target = nickname / server
301 msgtarget = msgto *( "," msgto )
302 msgto = channel / ( user [ "%" host ] "@" servername )
303 msgto =/ ( user "%" host ) / targetmask
304 msgto =/ nickname / ( nickname "!" user "@" host )
305 channel = ( "#" / "+" / ( "!" channelid ) / "&" ) chanstring
306 [ ":" chanstring ]
307 servername = hostname
308 host = hostname / hostaddr
309 hostname = shortname *( "." shortname )
310 shortname = ( letter / digit ) *( letter / digit / "-" )
311 *( letter / digit )
312 ; as specified in RFC 1123 [HNAME]
313 hostaddr = ip4addr / ip6addr
314 ip4addr = 1*3digit "." 1*3digit "." 1*3digit "." 1*3digit
315 ip6addr = 1*hexdigit 7( ":" 1*hexdigit )
316 ip6addr =/ "0:0:0:0:0:" ( "0" / "FFFF" ) ":" ip4addr
317 nickname = ( letter / special ) *8( letter / digit / special / "-" )
318 targetmask = ( "$" / "#" ) mask
319 ; see details on allowed masks in section 3.3.1
320 chanstring = %x01-07 / %x08-09 / %x0B-0C / %x0E-1F / %x21-2B
321 chanstring =/ %x2D-39 / %x3B-FF
322 ; any octet except NUL, BELL, CR, LF, " ", "," and ":"
323 channelid = 5( %x41-5A / digit ) ; 5( A-Z / 0-9 )
324
325 Other parameter syntaxes are:
326
327 user = 1*( %x01-09 / %x0B-0C / %x0E-1F / %x21-3F / %x41-FF )
328 ; any octet except NUL, CR, LF, " " and "@"
329 key = 1*23( %x01-05 / %x07-08 / %x0C / %x0E-1F / %x21-7F )
330 ; any 7-bit US_ASCII character,
331 ; except NUL, CR, LF, FF, h/v TABs, and " "
332 letter = %x41-5A / %x61-7A ; A-Z / a-z
333 digit = %x30-39 ; 0-9
334 hexdigit = digit / "A" / "B" / "C" / "D" / "E" / "F"
335 special = %x5B-60 / %x7B-7D
336 ; "[", "]", "\", "`", "_", "^", "{", "|", "}"
337
338 NOTES:
339 1) The <hostaddr> syntax is given here for the sole purpose of
340 indicating the format to follow for IP addresses. This
341 reflects the fact that the only available implementations of
342 this protocol uses TCP/IP as underlying network protocol but is
343 not meant to prevent other protocols to be used.
344
345 2) <hostname> has a maximum length of 63 characters. This is a
346 limitation of the protocol as internet hostnames (in
347 particular) can be longer. Such restriction is necessary
348 because IRC messages are limited to 512 characters in length.
349 Clients connecting from a host which name is longer than 63
350 characters are registered using the host (numeric) address
351 instead of the host name.
352
353 3) Some parameters used in the following sections of this
354 documents are not defined here as there is nothing specific
355 about them besides the name that is used for convenience.
356 These parameters follow the general syntax defined for
357 <params>.
358
359 2.4 Numeric replies
360
361 Most of the messages sent to the server generate a reply of some
362 sort. The most common reply is the numeric reply, used for both
363 errors and normal replies. The numeric reply MUST be sent as one
364 message consisting of the sender prefix, the three-digit numeric, and
365 the target of the reply. A numeric reply is not allowed to originate
366 from a client. In all other respects, a numeric reply is just like a
367 normal message, except that the keyword is made up of 3 numeric
368 digits rather than a string of letters. A list of different replies
369 is supplied in section 5 (Replies).
370
371 2.5 Wildcard expressions
372
373 When wildcards are allowed in a string, it is referred as a "mask".
374
375 For string matching purposes, the protocol allows the use of two
376 special characters: '?' (%x3F) to match one and only one character,
377 and '*' (%x2A) to match any number of any characters. These two
378 characters can be escaped using the character '\' (%x5C).
379
380 The Augmented BNF syntax for this is:
381
382 mask = *( nowild / noesc wildone / noesc wildmany )
383 wildone = %x3F
384 wildmany = %x2A
385 nowild = %x01-29 / %x2B-3E / %x40-FF
386 ; any octet except NUL, "*", "?"
387 noesc = %x01-5B / %x5D-FF
388 ; any octet except NUL and "\"
389 matchone = %x01-FF
390 ; matches wildone
391 matchmany = *matchone
392 ; matches wildmany
393
394 Examples:
395
396 a?c ; Matches any string of 3 characters in length starting
397 with "a" and ending with "c"
398
399 a*c ; Matches any string of at least 2 characters in length
400 starting with "a" and ending with "c"
401
402 3. Message Details
403
404 On the following pages there are descriptions of each message
405 recognized by the IRC server and client. All commands described in
406 this section MUST be implemented by any server for this protocol.
407
408 Where the reply ERR_NOSUCHSERVER is returned, it means that the
409 target of the message could not be found. The server MUST NOT send
410 any other replies after this error for that command.
411
412 The server to which a client is connected is required to parse the
413 complete message, and return any appropriate errors.
414
415 If multiple parameters is presented, then each MUST be checked for
416 validity and appropriate responses MUST be sent back to the client.
417 In the case of incorrect messages which use parameter lists with
418 comma as an item separator, a reply MUST be sent for each item.
419
420 3.1 Connection Registration
421
422 The commands described here are used to register a connection with an
423 IRC server as a user as well as to correctly disconnect.
424
425 A "PASS" command is not required for a client connection to be
426 registered, but it MUST precede the latter of the NICK/USER
427 combination (for a user connection) or the SERVICE command (for a
428 service connection). The RECOMMENDED order for a client to register
429 is as follows:
430
431 1. Pass message
432 2. Nick message 2. Service message
433 3. User message
434
435 Upon success, the client will receive an RPL_WELCOME (for users) or
436 RPL_YOURESERVICE (for services) message indicating that the
437 connection is now registered and known the to the entire IRC network.
438 The reply message MUST contain the full client identifier upon which
439 it was registered.
440
441 3.1.1 Password message
442
443 Command: PASS
444 Parameters: <password>
445
446 The PASS command is used to set a 'connection password'. The
447 optional password can and MUST be set before any attempt to register
448 the connection is made. Currently this requires that user send a
449 PASS command before sending the NICK/USER combination.
450
451 Numeric Replies:
452
453 ERR_NEEDMOREPARAMS ERR_ALREADYREGISTRED
454
455 Example:
456
457 PASS secretpasswordhere
458
459 3.1.2 Nick message
460
461 Command: NICK
462 Parameters: <nickname>
463
464 NICK command is used to give user a nickname or change the existing
465 one.
466
467 Numeric Replies:
468
469 ERR_NONICKNAMEGIVEN ERR_ERRONEUSNICKNAME
470 ERR_NICKNAMEINUSE ERR_NICKCOLLISION
471 ERR_UNAVAILRESOURCE ERR_RESTRICTED
472
473 Examples:
474
475 NICK Wiz ; Introducing new nick "Wiz" if session is
476 still unregistered, or user changing his
477 nickname to "Wiz"
478
479 :WiZ!jto@tolsun.oulu.fi NICK Kilroy
480 ; Server telling that WiZ changed his
481 nickname to Kilroy.
482
483 3.1.3 User message
484
485 Command: USER
486 Parameters: <user> <mode> <unused> <realname>
487
488 The USER command is used at the beginning of connection to specify
489 the username, hostname and realname of a new user.
490
491 The <mode> parameter should be a numeric, and can be used to
492 automatically set user modes when registering with the server. This
493 parameter is a bitmask, with only 2 bits having any signification: if
494 the bit 2 is set, the user mode 'w' will be set and if the bit 3 is
495 set, the user mode 'i' will be set. (See Section 3.1.5 "User
496 Modes").
497
498 The <realname> may contain space characters.
499
500 Numeric Replies:
501
502 ERR_NEEDMOREPARAMS ERR_ALREADYREGISTRED
503
504 Example:
505
506 USER guest 0 * :Ronnie Reagan ; User registering themselves with a
507 username of "guest" and real name
508 "Ronnie Reagan".
509
510 USER guest 8 * :Ronnie Reagan ; User registering themselves with a
511 username of "guest" and real name
512 "Ronnie Reagan", and asking to be set
513 invisible.
514
515 3.1.4 Oper message
516
517 Command: OPER
518 Parameters: <name> <password>
519
520 A normal user uses the OPER command to obtain operator privileges.
521 The combination of <name> and <password> are REQUIRED to gain
522 Operator privileges. Upon success, the user will receive a MODE
523 message (see section 3.1.5) indicating the new user modes.
524
525 Numeric Replies:
526
527 ERR_NEEDMOREPARAMS RPL_YOUREOPER
528 ERR_NOOPERHOST ERR_PASSWDMISMATCH
529
530 Example:
531
532 OPER foo bar ; Attempt to register as an operator
533 using a username of "foo" and "bar"
534 as the password.
535
536 3.1.5 User mode message
537
538 Command: MODE
539 Parameters: <nickname>
540 *( ( "+" / "-" ) *( "i" / "w" / "o" / "O" / "r" ) )
541
542 The user MODE's are typically changes which affect either how the
543 client is seen by others or what 'extra' messages the client is sent.
544
545 A user MODE command MUST only be accepted if both the sender of the
546 message and the nickname given as a parameter are both the same. If
547 no other parameter is given, then the server will return the current
548 settings for the nick.
549
550 The available modes are as follows:
551
552 a - user is flagged as away;
553 i - marks a users as invisible;
554 w - user receives wallops;
555 r - restricted user connection;
556 o - operator flag;
557 O - local operator flag;
558 s - marks a user for receipt of server notices.
559
560 Additional modes may be available later on.
561
562 The flag 'a' SHALL NOT be toggled by the user using the MODE command,
563 instead use of the AWAY command is REQUIRED.
564
565 If a user attempts to make themselves an operator using the "+o" or
566 "+O" flag, the attempt SHOULD be ignored as users could bypass the
567 authentication mechanisms of the OPER command. There is no
568 restriction, however, on anyone `deopping' themselves (using "-o" or
569 "-O").
570
571 On the other hand, if a user attempts to make themselves unrestricted
572 using the "-r" flag, the attempt SHOULD be ignored. There is no
573 restriction, however, on anyone `deopping' themselves (using "+r").
574 This flag is typically set by the server upon connection for
575 administrative reasons. While the restrictions imposed are left up
576 to the implementation, it is typical that a restricted user not be
577 allowed to change nicknames, nor make use of the channel operator
578 status on channels.
579
580 The flag 's' is obsolete but MAY still be used.
581
582 Numeric Replies:
583
584 ERR_NEEDMOREPARAMS ERR_USERSDONTMATCH
585 ERR_UMODEUNKNOWNFLAG RPL_UMODEIS
586
587 Examples:
588
589 MODE WiZ -w ; Command by WiZ to turn off
590 reception of WALLOPS messages.
591
592 MODE Angel +i ; Command from Angel to make herself
593 invisible.
594
595 MODE WiZ -o ; WiZ 'deopping' (removing operator
596 status).
597
598 3.1.6 Service message
599
600 Command: SERVICE
601 Parameters: <nickname> <reserved> <distribution> <type>
602 <reserved> <info>
603
604 The SERVICE command to register a new service. Command parameters
605 specify the service nickname, distribution, type and info of a new
606 service.
607
608 The <distribution> parameter is used to specify the visibility of a
609 service. The service may only be known to servers which have a name
610 matching the distribution. For a matching server to have knowledge
611 of the service, the network path between that server and the server
612 on which the service is connected MUST be composed of servers which
613 names all match the mask.
614
615 The <type> parameter is currently reserved for future usage.
616
617 Numeric Replies:
618
619 ERR_ALREADYREGISTRED ERR_NEEDMOREPARAMS
620 ERR_ERRONEUSNICKNAME
621 RPL_YOURESERVICE RPL_YOURHOST
622 RPL_MYINFO
623
624 Example:
625
626 SERVICE dict * *.fr 0 0 :French Dictionary ; Service registering
627 itself with a name of "dict". This
628 service will only be available on
629 servers which name matches "*.fr".
630
631 3.1.7 Quit
632
633 Command: QUIT
634 Parameters: [ <Quit Message> ]
635
636 A client session is terminated with a quit message. The server
637 acknowledges this by sending an ERROR message to the client.
638
639 Numeric Replies:
640
641 None.
642
643 Example:
644
645 QUIT :Gone to have lunch ; Preferred message format.
646
647 :syrk!kalt@millennium.stealth.net QUIT :Gone to have lunch ; User
648 syrk has quit IRC to have lunch.
649
650 3.1.8 Squit
651
652 Command: SQUIT
653 Parameters: <server> <comment>
654
655 The SQUIT command is available only to operators. It is used to
656 disconnect server links. Also servers can generate SQUIT messages on
657 error conditions. A SQUIT message may also target a remote server
658 connection. In this case, the SQUIT message will simply be sent to
659 the remote server without affecting the servers in between the
660 operator and the remote server.
661
662 The <comment> SHOULD be supplied by all operators who execute a SQUIT
663 for a remote server. The server ordered to disconnect its peer
664 generates a WALLOPS message with <comment> included, so that other
665 users may be aware of the reason of this action.
666
667 Numeric replies:
668
669 ERR_NOPRIVILEGES ERR_NOSUCHSERVER
670 ERR_NEEDMOREPARAMS
671
672 Examples:
673
674 SQUIT tolsun.oulu.fi :Bad Link ? ; Command to uplink of the server
675 tolson.oulu.fi to terminate its
676 connection with comment "Bad Link".
677
678 :Trillian SQUIT cm22.eng.umd.edu :Server out of control ; Command
679 from Trillian from to disconnect
680 "cm22.eng.umd.edu" from the net with
681 comment "Server out of control".
682
683 3.2 Channel operations
684
685 This group of messages is concerned with manipulating channels, their
686 properties (channel modes), and their contents (typically users).
687 For this reason, these messages SHALL NOT be made available to
688 services.
689
690 All of these messages are requests which will or will not be granted
691 by the server. The server MUST send a reply informing the user
692 whether the request was granted, denied or generated an error. When
693 the server grants the request, the message is typically sent back
694 (eventually reformatted) to the user with the prefix set to the user
695 itself.
696
697 The rules governing how channels are managed are enforced by the
698 servers. These rules are beyond the scope of this document. More
699 details are found in "Internet Relay Chat: Channel Management" [IRC-
700 CHAN].
701
702 3.2.1 Join message
703
704 Command: JOIN
705 Parameters: ( <channel> *( "," <channel> ) [ <key> *( "," <key> ) ] )
706 / "0"
707
708 The JOIN command is used by a user to request to start listening to
709 the specific channel. Servers MUST be able to parse arguments in the
710 form of a list of target, but SHOULD NOT use lists when sending JOIN
711 messages to clients.
712
713 Once a user has joined a channel, he receives information about
714 all commands his server receives affecting the channel. This
715 includes JOIN, MODE, KICK, PART, QUIT and of course PRIVMSG/NOTICE.
716 This allows channel members to keep track of the other channel
717 members, as well as channel modes.
718
719 If a JOIN is successful, the user receives a JOIN message as
720 confirmation and is then sent the channel's topic (using RPL_TOPIC) and
721 the list of users who are on the channel (using RPL_NAMREPLY), which
722 MUST include the user joining.
723
724 Note that this message accepts a special argument ("0"), which is
725 a special request to leave all channels the user is currently a member
726 of. The server will process this message as if the user had sent
727 a PART command (See Section 3.2.2) for each channel he is a member
728 of.
729
730 Numeric Replies:
731
732 ERR_NEEDMOREPARAMS ERR_BANNEDFROMCHAN
733 ERR_INVITEONLYCHAN ERR_BADCHANNELKEY
734 ERR_CHANNELISFULL ERR_BADCHANMASK
735 ERR_NOSUCHCHANNEL ERR_TOOMANYCHANNELS
736 ERR_TOOMANYTARGETS ERR_UNAVAILRESOURCE
737 RPL_TOPIC
738
739 Examples:
740
741 JOIN #foobar ; Command to join channel #foobar.
742
743 JOIN &foo fubar ; Command to join channel &foo using
744 key "fubar".
745
746 JOIN #foo,&bar fubar ; Command to join channel #foo using
747 key "fubar" and &bar using no key.
748
749 JOIN #foo,#bar fubar,foobar ; Command to join channel #foo using
750 key "fubar", and channel #bar using
751 key "foobar".
752
753 JOIN #foo,#bar ; Command to join channels #foo and
754 #bar.
755
756 JOIN 0 ; Leave all currently joined
757 channels.
758
759 :WiZ!jto@tolsun.oulu.fi JOIN #Twilight_zone ; JOIN message from WiZ
760 on channel #Twilight_zone
761
762 3.2.2 Part message
763
764 Command: PART
765 Parameters: <channel> *( "," <channel> ) [ <Part Message> ]
766
767 The PART command causes the user sending the message to be removed
768 from the list of active members for all given channels listed in the
769 parameter string. If a "Part Message" is given, this will be sent
770 instead of the default message, the nickname. This request is always
771 granted by the server.
772
773 Servers MUST be able to parse arguments in the form of a list of
774 target, but SHOULD NOT use lists when sending PART messages to
775 clients.
776
777 Numeric Replies:
778
779 ERR_NEEDMOREPARAMS ERR_NOSUCHCHANNEL
780 ERR_NOTONCHANNEL
781
782 Examples:
783
784 PART #twilight_zone ; Command to leave channel
785 "#twilight_zone"
786
787 PART #oz-ops,&group5 ; Command to leave both channels
788 "&group5" and "#oz-ops".
789
790 :WiZ!jto@tolsun.oulu.fi PART #playzone :I lost
791 ; User WiZ leaving channel
792 "#playzone" with the message "I
793 lost".
794
795 3.2.3 Channel mode message
796
797 Command: MODE
798 Parameters: <channel> *( ( "-" / "+" ) *<modes> *<modeparams> )
799
800 The MODE command is provided so that users may query and change the
801 characteristics of a channel. For more details on available modes
802 and their uses, see "Internet Relay Chat: Channel Management" [IRC-
803 CHAN]. Note that there is a maximum limit of three (3) changes per
804 command for modes that take a parameter.
805
806 Numeric Replies:
807
808 ERR_NEEDMOREPARAMS ERR_KEYSET
809 ERR_NOCHANMODES ERR_CHANOPRIVSNEEDED
810 ERR_USERNOTINCHANNEL ERR_UNKNOWNMODE
811 RPL_CHANNELMODEIS
812 RPL_BANLIST RPL_ENDOFBANLIST
813 RPL_EXCEPTLIST RPL_ENDOFEXCEPTLIST
814 RPL_INVITELIST RPL_ENDOFINVITELIST
815 RPL_UNIQOPIS
816
817 The following examples are given to help understanding the syntax of
818 the MODE command, but refer to modes defined in "Internet Relay Chat:
819 Channel Management" [IRC-CHAN].
820
821 Examples:
822
823 MODE #Finnish +imI *!*@*.fi ; Command to make #Finnish channel
824 moderated and 'invite-only' with user
825 with a hostname matching *.fi
826 automatically invited.
827
828 MODE #Finnish +o Kilroy ; Command to give 'chanop' privileges
829 to Kilroy on channel #Finnish.
830
831 MODE #Finnish +v Wiz ; Command to allow WiZ to speak on
832 #Finnish.
833
834 MODE #Fins -s ; Command to remove 'secret' flag
835 from channel #Fins.
836
837 MODE #42 +k oulu ; Command to set the channel key to
838 "oulu".
839
840 MODE #42 -k oulu ; Command to remove the "oulu"
841 channel key on channel "#42".
842
843 MODE #eu-opers +l 10 ; Command to set the limit for the
844 number of users on channel
845 "#eu-opers" to 10.
846
847 :WiZ!jto@tolsun.oulu.fi MODE #eu-opers -l
848 ; User "WiZ" removing the limit for
849 the number of users on channel "#eu-
850 opers".
851
852 MODE &oulu +b ; Command to list ban masks set for
853 the channel "&oulu".
854
855 MODE &oulu +b *!*@* ; Command to prevent all users from
856 joining.
857
858 MODE &oulu +b *!*@*.edu +e *!*@*.bu.edu
859 ; Command to prevent any user from a
860 hostname matching *.edu from joining,
861 except if matching *.bu.edu
862
863 MODE #bu +be *!*@*.edu *!*@*.bu.edu
864 ; Comment to prevent any user from a
865 hostname matching *.edu from joining,
866 except if matching *.bu.edu
867
868 MODE #meditation e ; Command to list exception masks set
869 for the channel "#meditation".
870
871 MODE #meditation I ; Command to list invitations masks
872 set for the channel "#meditation".
873
874 MODE !12345ircd O ; Command to ask who the channel
875 creator for "!12345ircd" is
876
877 3.2.4 Topic message
878
879 Command: TOPIC
880 Parameters: <channel> [ <topic> ]
881
882 The TOPIC command is used to change or view the topic of a channel.
883 The topic for channel <channel> is returned if there is no <topic>
884 given. If the <topic> parameter is present, the topic for that
885 channel will be changed, if this action is allowed for the user
886 requesting it. If the <topic> parameter is an empty string, the
887 topic for that channel will be removed.
888
889 Numeric Replies:
890
891 ERR_NEEDMOREPARAMS ERR_NOTONCHANNEL
892 RPL_NOTOPIC RPL_TOPIC
893 ERR_CHANOPRIVSNEEDED ERR_NOCHANMODES
894
895 Examples:
896
897 :WiZ!jto@tolsun.oulu.fi TOPIC #test :New topic ; User Wiz setting the
898 topic.
899
900 TOPIC #test :another topic ; Command to set the topic on #test
901 to "another topic".
902
903 TOPIC #test : ; Command to clear the topic on
904 #test.
905
906 TOPIC #test ; Command to check the topic for
907 #test.
908
909 3.2.5 Names message
910
911 Command: NAMES
912 Parameters: [ <channel> *( "," <channel> ) [ <target> ] ]
913
914 By using the NAMES command, a user can list all nicknames that are
915 visible to him. For more details on what is visible and what is not,
916 see "Internet Relay Chat: Channel Management" [IRC-CHAN]. The
917 <channel> parameter specifies which channel(s) to return information
918 about. There is no error reply for bad channel names.
919
920 If no <channel> parameter is given, a list of all channels and their
921 occupants is returned. At the end of this list, a list of users who
922 are visible but either not on any channel or not on a visible channel
923 are listed as being on `channel' "*".
924
925 If the <target> parameter is specified, the request is forwarded to
926 that server which will generate the reply.
927
928 Wildcards are allowed in the <target> parameter.
929
930 Numerics:
931
932 ERR_TOOMANYMATCHES ERR_NOSUCHSERVER
933 RPL_NAMREPLY RPL_ENDOFNAMES
934
935 Examples:
936
937 NAMES #twilight_zone,#42 ; Command to list visible users on
938 #twilight_zone and #42
939
940 NAMES ; Command to list all visible
941 channels and users
942
943 3.2.6 List message
944
945 Command: LIST
946 Parameters: [ <channel> *( "," <channel> ) [ <target> ] ]
947
948 The list command is used to list channels and their topics. If the
949 <channel> parameter is used, only the status of that channel is
950 displayed.
951
952 If the <target> parameter is specified, the request is forwarded to
953 that server which will generate the reply.
954
955 Wildcards are allowed in the <target> parameter.
956
957 Numeric Replies:
958
959 ERR_TOOMANYMATCHES ERR_NOSUCHSERVER
960 RPL_LIST RPL_LISTEND
961
962 Examples:
963
964 LIST ; Command to list all channels.
965
966 LIST #twilight_zone,#42 ; Command to list channels
967 #twilight_zone and #42
968
969 3.2.7 Invite message
970
971 Command: INVITE
972 Parameters: <nickname> <channel>
973
974 The INVITE command is used to invite a user to a channel. The
975 parameter <nickname> is the nickname of the person to be invited to
976 the target channel <channel>. There is no requirement that the
977 channel the target user is being invited to must exist or be a valid
978 channel. However, if the channel exists, only members of the channel
979 are allowed to invite other users. When the channel has invite-only
980 flag set, only channel operators may issue INVITE command.
981
982 Only the user inviting and the user being invited will receive
983 notification of the invitation. Other channel members are not
984 notified. (This is unlike the MODE changes, and is occasionally the
985 source of trouble for users.)
986
987 Numeric Replies:
988
989 ERR_NEEDMOREPARAMS ERR_NOSUCHNICK
990 ERR_NOTONCHANNEL ERR_USERONCHANNEL
991 ERR_CHANOPRIVSNEEDED
992 RPL_INVITING RPL_AWAY
993
994 Examples:
995
996 :Angel!wings@irc.org INVITE Wiz #Dust
997
998 ; Message to WiZ when he has been
999 invited by user Angel to channel
1000 #Dust
1001
1002 INVITE Wiz #Twilight_Zone ; Command to invite WiZ to
1003 #Twilight_zone
1004
1005 3.2.8 Kick command
1006
1007 Command: KICK
1008 Parameters: <channel> *( "," <channel> ) <user> *( "," <user> )
1009 [<comment>]
1010
1011 The KICK command can be used to request the forced removal of a user
1012 from a channel. It causes the <user> to PART from the <channel> by
1013 force. For the message to be syntactically correct, there MUST be
1014 either one channel parameter and multiple user parameter, or as many
1015 channel parameters as there are user parameters. If a "comment" is
1016 given, this will be sent instead of the default message, the nickname
1017 of the user issuing the KICK.
1018
1019 The server MUST NOT send KICK messages with multiple channels or
1020 users to clients. This is necessarily to maintain backward
1021 compatibility with old client software.
1022
1023 Numeric Replies:
1024
1025 ERR_NEEDMOREPARAMS ERR_NOSUCHCHANNEL
1026 ERR_BADCHANMASK ERR_CHANOPRIVSNEEDED
1027 ERR_USERNOTINCHANNEL ERR_NOTONCHANNEL
1028
1029 Examples:
1030
1031 KICK &Melbourne Matthew ; Command to kick Matthew from
1032 &Melbourne
1033
1034 KICK #Finnish John :Speaking English
1035 ; Command to kick John from #Finnish
1036 using "Speaking English" as the
1037 reason (comment).
1038
1039 :WiZ!jto@tolsun.oulu.fi KICK #Finnish John
1040 ; KICK message on channel #Finnish
1041 from WiZ to remove John from channel
1042
1043 3.3 Sending messages
1044
1045 The main purpose of the IRC protocol is to provide a base for clients
1046 to communicate with each other. PRIVMSG, NOTICE and SQUERY
1047 (described in Section 3.5 on Service Query and Commands) are the only
1048 messages available which actually perform delivery of a text message
1049 from one client to another - the rest just make it possible and try
1050 to ensure it happens in a reliable and structured manner.
1051
1052 3.3.1 Private messages
1053
1054 Command: PRIVMSG
1055 Parameters: <msgtarget> <text to be sent>
1056
1057 PRIVMSG is used to send private messages between users, as well as to
1058 send messages to channels. <msgtarget> is usually the nickname of
1059 the recipient of the message, or a channel name.
1060
1061 The <msgtarget> parameter may also be a host mask (#<mask>) or server
1062 mask ($<mask>). In both cases the server will only send the PRIVMSG
1063 to those who have a server or host matching the mask. The mask MUST
1064 have at least 1 (one) "." in it and no wildcards following the last
1065 ".". This requirement exists to prevent people sending messages to
1066 "#*" or "$*", which would broadcast to all users. Wildcards are the
1067 '*' and '?' characters. This extension to the PRIVMSG command is
1068 only available to operators.
1069
1070 Numeric Replies:
1071
1072 ERR_NORECIPIENT ERR_NOTEXTTOSEND
1073 ERR_CANNOTSENDTOCHAN ERR_NOTOPLEVEL
1074 ERR_WILDTOPLEVEL ERR_TOOMANYTARGETS
1075 ERR_NOSUCHNICK
1076 RPL_AWAY
1077
1078 Examples:
1079
1080 :Angel!wings@irc.org PRIVMSG Wiz :Are you receiving this message ?
1081 ; Message from Angel to Wiz.
1082
1083 PRIVMSG Angel :yes I'm receiving it !
1084 ; Command to send a message to Angel.
1085
1086 PRIVMSG jto@tolsun.oulu.fi :Hello !
1087 ; Command to send a message to a user
1088 on server tolsun.oulu.fi with
1089 username of "jto".
1090
1091 PRIVMSG kalt%millennium.stealth.net@irc.stealth.net :Are you a frog?
1092 ; Message to a user on server
1093 irc.stealth.net with username of
1094 "kalt", and connected from the host
1095 millennium.stealth.net.
1096
1097 PRIVMSG kalt%millennium.stealth.net :Do you like cheese?
1098 ; Message to a user on the local
1099 server with username of "kalt", and
1100 connected from the host
1101 millennium.stealth.net.
1102
1103 PRIVMSG Wiz!jto@tolsun.oulu.fi :Hello !
1104 ; Message to the user with nickname
1105 Wiz who is connected from the host
1106 tolsun.oulu.fi and has the username
1107 "jto".
1108
1109 PRIVMSG $*.fi :Server tolsun.oulu.fi rebooting.
1110 ; Message to everyone on a server
1111 which has a name matching *.fi.
1112
1113 PRIVMSG #*.edu :NSFNet is undergoing work, expect interruptions
1114 ; Message to all users who come from
1115 a host which has a name matching
1116 *.edu.
1117
1118 3.3.2 Notice
1119
1120 Command: NOTICE
1121 Parameters: <msgtarget> <text>
1122
1123 The NOTICE command is used similarly to PRIVMSG. The difference
1124 between NOTICE and PRIVMSG is that automatic replies MUST NEVER be
1125 sent in response to a NOTICE message. This rule applies to servers
1126
1127 too - they MUST NOT send any error reply back to the client on
1128 receipt of a notice. The object of this rule is to avoid loops
1129 between clients automatically sending something in response to
1130 something it received.
1131
1132 This command is available to services as well as users.
1133
1134 This is typically used by services, and automatons (clients with
1135 either an AI or other interactive program controlling their actions).
1136
1137 See PRIVMSG for more details on replies and examples.
1138
1139 3.4 Server queries and commands
1140
1141 The server query group of commands has been designed to return
1142 information about any server which is connected to the network.
1143
1144 In these queries, where a parameter appears as <target>, wildcard
1145 masks are usually valid. For each parameter, however, only one query
1146 and set of replies is to be generated. In most cases, if a nickname
1147 is given, it will mean the server to which the user is connected.
1148
1149 These messages typically have little value for services, it is
1150 therefore RECOMMENDED to forbid services from using them.
1151
1152 3.4.1 Motd message
1153
1154 Command: MOTD
1155 Parameters: [ <target> ]
1156
1157 The MOTD command is used to get the "Message Of The Day" of the given
1158 server, or current server if <target> is omitted.
1159
1160 Wildcards are allowed in the <target> parameter.
1161
1162 Numeric Replies:
1163 RPL_MOTDSTART RPL_MOTD
1164 RPL_ENDOFMOTD ERR_NOMOTD
1165
1166 3.4.2 Lusers message
1167
1168 Command: LUSERS
1169 Parameters: [ <mask> [ <target> ] ]
1170
1171 The LUSERS command is used to get statistics about the size of the
1172 IRC network. If no parameter is given, the reply will be about the
1173 whole net. If a <mask> is specified, then the reply will only
1174
1175 concern the part of the network formed by the servers matching the
1176 mask. Finally, if the <target> parameter is specified, the request
1177 is forwarded to that server which will generate the reply.
1178
1179 Wildcards are allowed in the <target> parameter.
1180
1181 Numeric Replies:
1182
1183 RPL_LUSERCLIENT RPL_LUSEROP
1184 RPL_LUSERUNKOWN RPL_LUSERCHANNELS
1185 RPL_LUSERME ERR_NOSUCHSERVER
1186
1187 3.4.3 Version message
1188
1189 Command: VERSION
1190 Parameters: [ <target> ]
1191
1192 The VERSION command is used to query the version of the server
1193 program. An optional parameter <target> is used to query the version
1194 of the server program which a client is not directly connected to.
1195
1196 Wildcards are allowed in the <target> parameter.
1197
1198 Numeric Replies:
1199
1200 ERR_NOSUCHSERVER RPL_VERSION
1201
1202 Examples:
1203
1204 VERSION tolsun.oulu.fi ; Command to check the version of
1205 server "tolsun.oulu.fi".
1206
1207 3.4.4 Stats message
1208
1209 Command: STATS
1210 Parameters: [ <query> [ <target> ] ]
1211
1212 The stats command is used to query statistics of certain server. If
1213 <query> parameter is omitted, only the end of stats reply is sent
1214 back.
1215
1216 A query may be given for any single letter which is only checked by
1217 the destination server and is otherwise passed on by intermediate
1218 servers, ignored and unaltered.
1219
1220 Wildcards are allowed in the <target> parameter.
1221
1222 Except for the ones below, the list of valid queries is
1223 implementation dependent. The standard queries below SHOULD be
1224 supported by the server:
1225
1226 l - returns a list of the server's connections, showing how
1227 long each connection has been established and the
1228 traffic over that connection in Kbytes and messages for
1229 each direction;
1230 m - returns the usage count for each of commands supported
1231 by the server; commands for which the usage count is
1232 zero MAY be omitted;
1233 o - returns a list of configured privileged users,
1234 operators;
1235 u - returns a string showing how long the server has been
1236 up.
1237
1238 It is also RECOMMENDED that client and server access configuration be
1239 published this way.
1240
1241 Numeric Replies:
1242
1243 ERR_NOSUCHSERVER
1244 RPL_STATSLINKINFO RPL_STATSUPTIME
1245 RPL_STATSCOMMANDS RPL_STATSOLINE
1246 RPL_ENDOFSTATS
1247
1248 Examples:
1249
1250 STATS m ; Command to check the command usage
1251 for the server you are connected to
1252
1253 3.4.5 Links message
1254
1255 Command: LINKS
1256 Parameters: [ [ <remote server> ] <server mask> ]
1257
1258 With LINKS, a user can list all servernames, which are known by the
1259 server answering the query. The returned list of servers MUST match
1260 the mask, or if no mask is given, the full list is returned.
1261
1262 If <remote server> is given in addition to <server mask>, the LINKS
1263 command is forwarded to the first server found that matches that name
1264 (if any), and that server is then required to answer the query.
1265
1266 Numeric Replies:
1267
1268 ERR_NOSUCHSERVER
1269 RPL_LINKS RPL_ENDOFLINKS
1270
1271 Examples:
1272
1273 LINKS *.au ; Command to list all servers which
1274 have a name that matches *.au;
1275
1276 LINKS *.edu *.bu.edu ; Command to list servers matching
1277 *.bu.edu as seen by the first server
1278 matching *.edu.
1279
1280 3.4.6 Time message
1281
1282 Command: TIME
1283 Parameters: [ <target> ]
1284
1285 The time command is used to query local time from the specified
1286 server. If the <target> parameter is not given, the server receiving
1287 the command must reply to the query.
1288
1289 Wildcards are allowed in the <target> parameter.
1290
1291 Numeric Replies:
1292
1293 ERR_NOSUCHSERVER RPL_TIME
1294
1295 Examples:
1296 TIME tolsun.oulu.fi ; check the time on the server
1297 "tolson.oulu.fi"
1298
1299 3.4.7 Connect message
1300
1301 Command: CONNECT
1302 Parameters: <target server> <port> [ <remote server> ]
1303
1304 The CONNECT command can be used to request a server to try to
1305 establish a new connection to another server immediately. CONNECT is
1306 a privileged command and SHOULD be available only to IRC Operators.
1307 If a <remote server> is given and its mask doesn't match name of the
1308 parsing server, the CONNECT attempt is sent to the first match of
1309 remote server. Otherwise the CONNECT attempt is made by the server
1310 processing the request.
1311
1312 The server receiving a remote CONNECT command SHOULD generate a
1313 WALLOPS message describing the source and target of the request.
1314
1315 Numeric Replies:
1316
1317 ERR_NOSUCHSERVER ERR_NOPRIVILEGES
1318 ERR_NEEDMOREPARAMS
1319
1320 Examples:
1321
1322 CONNECT tolsun.oulu.fi 6667 ; Command to attempt to connect local
1323 server to tolsun.oulu.fi on port 6667
1324
1325 3.4.8 Trace message
1326
1327 Command: TRACE
1328 Parameters: [ <target> ]
1329
1330 TRACE command is used to find the route to specific server and
1331 information about its peers. Each server that processes this command
1332 MUST report to the sender about it. The replies from pass-through
1333 links form a chain, which shows route to destination. After sending
1334 this reply back, the query MUST be sent to the next server until
1335 given <target> server is reached.
1336
1337 TRACE command is used to find the route to specific server. Each
1338 server that processes this message MUST tell the sender about it by
1339 sending a reply indicating it is a pass-through link, forming a chain
1340 of replies. After sending this reply back, it MUST then send the
1341 TRACE message to the next server until given server is reached. If
1342 the <target> parameter is omitted, it is RECOMMENDED that TRACE
1343 command sends a message to the sender telling which servers the local
1344 server has direct connection to.
1345
1346 If the destination given by <target> is an actual server, the
1347 destination server is REQUIRED to report all servers, services and
1348 operators which are connected to it; if the command was issued by an
1349 operator, the server MAY also report all users which are connected to
1350 it. If the destination given by <target> is a nickname, then only a
1351 reply for that nickname is given. If the <target> parameter is
1352 omitted, it is RECOMMENDED that the TRACE command is parsed as
1353 targeted to the processing server.
1354
1355 Wildcards are allowed in the <target> parameter.
1356
1357 Numeric Replies:
1358
1359 ERR_NOSUCHSERVER
1360
1361 If the TRACE message is destined for another server, all
1362 intermediate servers must return a RPL_TRACELINK reply to indicate
1363 that the TRACE passed through it and where it is going next.
1364
1365 RPL_TRACELINK
1366
1367 A TRACE reply may be composed of any number of the following
1368 numeric replies.
1369
1370 RPL_TRACECONNECTING RPL_TRACEHANDSHAKE
1371 RPL_TRACEUNKNOWN RPL_TRACEOPERATOR
1372 RPL_TRACEUSER RPL_TRACESERVER
1373 RPL_TRACESERVICE RPL_TRACENEWTYPE
1374 RPL_TRACECLASS RPL_TRACELOG
1375 RPL_TRACEEND
1376
1377 Examples:
1378
1379 TRACE *.oulu.fi ; TRACE to a server matching
1380 *.oulu.fi
1381
1382 3.4.9 Admin command
1383
1384 Command: ADMIN
1385 Parameters: [ <target> ]
1386
1387 The admin command is used to find information about the administrator
1388 of the given server, or current server if <target> parameter is
1389 omitted. Each server MUST have the ability to forward ADMIN messages
1390 to other servers.
1391
1392 Wildcards are allowed in the <target> parameter.
1393
1394 Numeric Replies:
1395
1396 ERR_NOSUCHSERVER
1397 RPL_ADMINME RPL_ADMINLOC1
1398 RPL_ADMINLOC2 RPL_ADMINEMAIL
1399
1400 Examples:
1401
1402 ADMIN tolsun.oulu.fi ; request an ADMIN reply from
1403 tolsun.oulu.fi
1404
1405 ADMIN syrk ; ADMIN request for the server to
1406 which the user syrk is connected
1407
1408 3.4.10 Info command
1409
1410 Command: INFO
1411 Parameters: [ <target> ]
1412
1413 The INFO command is REQUIRED to return information describing the
1414 server: its version, when it was compiled, the patchlevel, when it
1415 was started, and any other miscellaneous information which may be
1416 considered to be relevant.
1417
1418 Wildcards are allowed in the <target> parameter.
1419
1420 Numeric Replies:
1421
1422 ERR_NOSUCHSERVER
1423 RPL_INFO RPL_ENDOFINFO
1424
1425 Examples:
1426
1427 INFO csd.bu.edu ; request an INFO reply from
1428 csd.bu.edu
1429
1430 INFO Angel ; request info from the server that
1431 Angel is connected to.
1432
1433 3.5 Service Query and Commands
1434
1435 The service query group of commands has been designed to return
1436 information about any service which is connected to the network.
1437
1438 3.5.1 Servlist message
1439
1440 Command: SERVLIST
1441 Parameters: [ <mask> [ <type> ] ]
1442
1443 The SERVLIST command is used to list services currently connected to
1444 the network and visible to the user issuing the command. The
1445 optional parameters may be used to restrict the result of the query
1446 (to matching services names, and services type).
1447
1448 Numeric Replies:
1449
1450 RPL_SERVLIST RPL_SERVLISTEND
1451
1452 3.5.2 Squery
1453
1454 Command: SQUERY
1455 Parameters: <servicename> <text>
1456
1457 The SQUERY command is used similarly to PRIVMSG. The only difference
1458 is that the recipient MUST be a service. This is the only way for a
1459 text message to be delivered to a service.
1460
1461 See PRIVMSG for more details on replies and example.
1462
1463 Examples:
1464
1465 SQUERY irchelp :HELP privmsg
1466 ; Message to the service with
1467 nickname irchelp.
1468
1469 SQUERY dict@irc.fr :fr2en blaireau
1470 ; Message to the service with name
1471 dict@irc.fr.
1472
1473 3.6 User based queries
1474
1475 User queries are a group of commands which are primarily concerned
1476 with finding details on a particular user or group users. When using
1477 wildcards with any of these commands, if they match, they will only
1478 return information on users who are 'visible' to you. The visibility
1479 of a user is determined as a combination of the user's mode and the
1480 common set of channels you are both on.
1481
1482 Although services SHOULD NOT be using this class of message, they are
1483 allowed to.
1484
1485 3.6.1 Who query
1486
1487 Command: WHO
1488 Parameters: [ <mask> [ "o" ] ]
1489
1490 The WHO command is used by a client to generate a query which returns
1491 a list of information which 'matches' the <mask> parameter given by
1492 the client. In the absence of the <mask> parameter, all visible
1493 (users who aren't invisible (user mode +i) and who don't have a
1494 common channel with the requesting client) are listed. The same
1495 result can be achieved by using a <mask> of "0" or any wildcard which
1496 will end up matching every visible user.
1497
1498 The <mask> passed to WHO is matched against users' host, server, real
1499 name and nickname if the channel <mask> cannot be found.
1500
1501 If the "o" parameter is passed only operators are returned according
1502 to the <mask> supplied.
1503
1504 Numeric Replies:
1505
1506 ERR_NOSUCHSERVER
1507 RPL_WHOREPLY RPL_ENDOFWHO
1508
1509 Examples:
1510
1511 WHO *.fi ; Command to list all users who match
1512 against "*.fi".
1513
1514 WHO jto* o ; Command to list all users with a
1515 match against "jto*" if they are an
1516 operator.
1517
1518 3.6.2 Whois query
1519
1520 Command: WHOIS
1521 Parameters: [ <target> ] <mask> *( "," <mask> )
1522
1523 This command is used to query information about particular user.
1524 The server will answer this command with several numeric messages
1525 indicating different statuses of each user which matches the mask (if
1526 you are entitled to see them). If no wildcard is present in the
1527 <mask>, any information about that nick which you are allowed to see
1528 is presented.
1529
1530 If the <target> parameter is specified, it sends the query to a
1531 specific server. It is useful if you want to know how long the user
1532 in question has been idle as only local server (i.e., the server the
1533 user is directly connected to) knows that information, while
1534 everything else is globally known.
1535
1536 Wildcards are allowed in the <target> parameter.
1537
1538 Numeric Replies:
1539
1540 ERR_NOSUCHSERVER ERR_NONICKNAMEGIVEN
1541 RPL_WHOISUSER RPL_WHOISCHANNELS
1542 RPL_WHOISCHANNELS RPL_WHOISSERVER
1543 RPL_AWAY RPL_WHOISOPERATOR
1544 RPL_WHOISIDLE ERR_NOSUCHNICK
1545 RPL_ENDOFWHOIS
1546
1547 Examples:
1548
1549 WHOIS wiz ; return available user information
1550 about nick WiZ
1551
1552 WHOIS eff.org trillian ; ask server eff.org for user
1553 information about trillian
1554
1555 3.6.3 Whowas
1556
1557 Command: WHOWAS
1558 Parameters: <nickname> *( "," <nickname> ) [ <count> [ <target> ] ]
1559
1560 Whowas asks for information about a nickname which no longer exists.
1561 This may either be due to a nickname change or the user leaving IRC.
1562 In response to this query, the server searches through its nickname
1563 history, looking for any nicks which are lexically the same (no wild
1564 card matching here). The history is searched backward, returning the
1565 most recent entry first. If there are multiple entries, up to
1566 <count> replies will be returned (or all of them if no <count>
1567 parameter is given). If a non-positive number is passed as being
1568 <count>, then a full search is done.
1569
1570 Wildcards are allowed in the <target> parameter.
1571
1572 Numeric Replies:
1573
1574 ERR_NONICKNAMEGIVEN ERR_WASNOSUCHNICK
1575 RPL_WHOWASUSER RPL_WHOISSERVER
1576 RPL_ENDOFWHOWAS
1577
1578 Examples:
1579
1580 WHOWAS Wiz ; return all information in the nick
1581 history about nick "WiZ";
1582
1583 WHOWAS Mermaid 9 ; return at most, the 9 most recent
1584 entries in the nick history for
1585 "Mermaid";
1586
1587 WHOWAS Trillian 1 *.edu ; return the most recent history for
1588 "Trillian" from the first server
1589 found to match "*.edu".
1590
1591 3.7 Miscellaneous messages
1592
1593 Messages in this category do not fit into any of the above categories
1594 but are nonetheless still a part of and REQUIRED by the protocol.
1595
1596 3.7.1 Kill message
1597
1598 Command: KILL
1599 Parameters: <nickname> <comment>
1600
1601 The KILL command is used to cause a client-server connection to be
1602 closed by the server which has the actual connection. Servers
1603 generate KILL messages on nickname collisions. It MAY also be
1604 available available to users who have the operator status.
1605
1606 Clients which have automatic reconnect algorithms effectively make
1607 this command useless since the disconnection is only brief. It does
1608 however break the flow of data and can be used to stop large amounts
1609 of 'flooding' from abusive users or accidents. Abusive users usually
1610 don't care as they will reconnect promptly and resume their abusive
1611 behaviour. To prevent this command from being abused, any user may
1612 elect to receive KILL messages generated for others to keep an 'eye'
1613 on would be trouble spots.
1614
1615 In an arena where nicknames are REQUIRED to be globally unique at all
1616 times, KILL messages are sent whenever 'duplicates' are detected
1617 (that is an attempt to register two users with the same nickname) in
1618 the hope that both of them will disappear and only 1 reappear.
1619
1620 When a client is removed as the result of a KILL message, the server
1621 SHOULD add the nickname to the list of unavailable nicknames in an
1622 attempt to avoid clients to reuse this name immediately which is
1623 usually the pattern of abusive behaviour often leading to useless
1624 "KILL loops". See the "IRC Server Protocol" document [IRC-SERVER]
1625 for more information on this procedure.
1626
1627 The comment given MUST reflect the actual reason for the KILL. For
1628 server-generated KILLs it usually is made up of details concerning
1629 the origins of the two conflicting nicknames. For users it is left
1630 up to them to provide an adequate reason to satisfy others who see
1631 it. To prevent/discourage fake KILLs from being generated to hide
1632 the identify of the KILLer, the comment also shows a 'kill-path'
1633 which is updated by each server it passes through, each prepending
1634 its name to the path.
1635
1636 Numeric Replies:
1637
1638 ERR_NOPRIVILEGES ERR_NEEDMOREPARAMS
1639 ERR_NOSUCHNICK ERR_CANTKILLSERVER
1640
1641 NOTE:
1642 It is RECOMMENDED that only Operators be allowed to kill other users
1643 with KILL command. This command has been the subject of many
1644 controversies over the years, and along with the above
1645 recommendation, it is also widely recognized that not even operators
1646 should be allowed to kill users on remote servers.
1647
1648 3.7.2 Ping message
1649
1650 Command: PING
1651 Parameters: <server1> [ <server2> ]
1652
1653 The PING command is used to test the presence of an active client or
1654 server at the other end of the connection. Servers send a PING
1655 message at regular intervals if no other activity detected coming
1656 from a connection. If a connection fails to respond to a PING
1657 message within a set amount of time, that connection is closed. A
1658 PING message MAY be sent even if the connection is active.
1659
1660 When a PING message is received, the appropriate PONG message MUST be
1661 sent as reply to <server1> (server which sent the PING message out)
1662 as soon as possible. If the <server2> parameter is specified, it
1663 represents the target of the ping, and the message gets forwarded
1664 there.
1665
1666 Numeric Replies:
1667
1668 ERR_NOORIGIN ERR_NOSUCHSERVER
1669
1670 Examples:
1671
1672 PING tolsun.oulu.fi ; Command to send a PING message to
1673 server
1674
1675 PING WiZ tolsun.oulu.fi ; Command from WiZ to send a PING
1676 message to server "tolsun.oulu.fi"
1677
1678 PING :irc.funet.fi ; Ping message sent by server
1679 "irc.funet.fi"
1680
1681 3.7.3 Pong message
1682
1683 Command: PONG
1684 Parameters: <server> [ <server2> ]
1685
1686 PONG message is a reply to ping message. If parameter <server2> is
1687 given, this message MUST be forwarded to given target. The <server>
1688 parameter is the name of the entity who has responded to PING message
1689 and generated this message.
1690
1691 Numeric Replies:
1692
1693 ERR_NOORIGIN ERR_NOSUCHSERVER
1694
1695 Example:
1696
1697 PONG csd.bu.edu tolsun.oulu.fi ; PONG message from csd.bu.edu to
1698 tolsun.oulu.fi
1699
1700 3.7.4 Error
1701
1702 Command: ERROR
1703 Parameters: <error message>
1704
1705 The ERROR command is for use by servers when reporting a serious or
1706 fatal error to its peers. It may also be sent from one server to
1707 another but MUST NOT be accepted from any normal unknown clients.
1708
1709 Only an ERROR message SHOULD be used for reporting errors which occur
1710 with a server-to-server link. An ERROR message is sent to the server
1711 at the other end (which reports it to appropriate local users and
1712 logs) and to appropriate local users and logs. It is not to be
1713 passed onto any other servers by a server if it is received from a
1714 server.
1715
1716 The ERROR message is also used before terminating a client
1717 connection.
1718
1719 When a server sends a received ERROR message to its operators, the
1720 message SHOULD be encapsulated inside a NOTICE message, indicating
1721 that the client was not responsible for the error.
1722
1723 Numerics:
1724
1725 None.
1726
1727 Examples:
1728
1729 ERROR :Server *.fi already exists ; ERROR message to the other server
1730 which caused this error.
1731
1732 NOTICE WiZ :ERROR from csd.bu.edu -- Server *.fi already exists
1733 ; Same ERROR message as above but
1734 sent to user WiZ on the other server.
1735
1736 4. Optional features
1737
1738 This section describes OPTIONAL messages. They are not required in a
1739 working server implementation of the protocol described herein. In
1740 the absence of the feature, an error reply message MUST be generated
1741 or an unknown command error. If the message is destined for another
1742 server to answer then it MUST be passed on (elementary parsing
1743 REQUIRED) The allocated numerics for this are listed with the
1744 messages below.
1745
1746 From this section, only the USERHOST and ISON messages are available
1747 to services.
1748
1749 4.1 Away
1750
1751 Command: AWAY
1752 Parameters: [ <text> ]
1753
1754 With the AWAY command, clients can set an automatic reply string for
1755 any PRIVMSG commands directed at them (not to a channel they are on).
1756 The server sends an automatic reply to the client sending the PRIVMSG
1757 command. The only replying server is the one to which the sending
1758 client is connected to.
1759
1760 The AWAY command is used either with one parameter, to set an AWAY
1761 message, or with no parameters, to remove the AWAY message.
1762
1763 Because of its high cost (memory and bandwidth wise), the AWAY
1764 message SHOULD only be used for client-server communication. A
1765 server MAY choose to silently ignore AWAY messages received from
1766 other servers. To update the away status of a client across servers,
1767 the user mode 'a' SHOULD be used instead. (See Section 3.1.5)
1768
1769 Numeric Replies:
1770
1771 RPL_UNAWAY RPL_NOWAWAY
1772
1773 Example:
1774
1775 AWAY :Gone to lunch. Back in 5 ; Command to set away message to
1776 "Gone to lunch. Back in 5".
1777
1778 4.2 Rehash message
1779
1780 Command: REHASH
1781 Parameters: None
1782
1783 The rehash command is an administrative command which can be used by
1784 an operator to force the server to re-read and process its
1785 configuration file.
1786
1787 Numeric Replies:
1788
1789 RPL_REHASHING ERR_NOPRIVILEGES
1790
1791 Example:
1792
1793 REHASH ; message from user with operator
1794 status to server asking it to reread
1795 its configuration file.
1796
1797 4.3 Die message
1798
1799 Command: DIE
1800 Parameters: None
1801
1802 An operator can use the DIE command to shutdown the server. This
1803 message is optional since it may be viewed as a risk to allow
1804 arbitrary people to connect to a server as an operator and execute
1805 this command.
1806
1807 The DIE command MUST always be fully processed by the server to which
1808 the sending client is connected and MUST NOT be passed onto other
1809 connected servers.
1810
1811 Numeric Replies:
1812
1813 ERR_NOPRIVILEGES
1814
1815 Example:
1816
1817 DIE ; no parameters required.
1818
1819 4.4 Restart message
1820
1821 Command: RESTART
1822 Parameters: None
1823
1824 An operator can use the restart command to force the server to
1825 restart itself. This message is optional since it may be viewed as a
1826 risk to allow arbitrary people to connect to a server as an operator
1827 and execute this command, causing (at least) a disruption to service.
1828
1829 The RESTART command MUST always be fully processed by the server to
1830 which the sending client is connected and MUST NOT be passed onto
1831 other connected servers.
1832
1833 Numeric Replies:
1834
1835 ERR_NOPRIVILEGES
1836
1837 Example:
1838
1839 RESTART ; no parameters required.
1840
1841 4.5 Summon message
1842
1843 Command: SUMMON
1844 Parameters: <user> [ <target> [ <channel> ] ]
1845
1846 The SUMMON command can be used to give users who are on a host
1847 running an IRC server a message asking them to please join IRC. This
1848 message is only sent if the target server (a) has SUMMON enabled, (b)
1849 the user is logged in and (c) the server process can write to the
1850 user's tty (or similar).
1851
1852 If no <server> parameter is given it tries to summon <user> from the
1853 server the client is connected to is assumed as the target.
1854
1855 If summon is not enabled in a server, it MUST return the
1856 ERR_SUMMONDISABLED numeric.
1857
1858 Numeric Replies:
1859
1860 ERR_NORECIPIENT ERR_FILEERROR
1861 ERR_NOLOGIN ERR_NOSUCHSERVER
1862 ERR_SUMMONDISABLED RPL_SUMMONING
1863
1864 Examples:
1865
1866 SUMMON jto ; summon user jto on the server's
1867 host
1868
1869 SUMMON jto tolsun.oulu.fi ; summon user jto on the host which a
1870 server named "tolsun.oulu.fi" is
1871 running.
1872
1873 4.6 Users
1874
1875 Command: USERS
1876 Parameters: [ <target> ]
1877
1878 The USERS command returns a list of users logged into the server in a
1879 format similar to the UNIX commands who(1), rusers(1) and finger(1).
1880 If disabled, the correct numeric MUST be returned to indicate this.
1881
1882 Because of the security implications of such a command, it SHOULD be
1883 disabled by default in server implementations. Enabling it SHOULD
1884 require recompiling the server or some equivalent change rather than
1885 simply toggling an option and restarting the server. The procedure
1886 to enable this command SHOULD also include suitable large comments.
1887
1888 Numeric Replies:
1889
1890 ERR_NOSUCHSERVER ERR_FILEERROR
1891 RPL_USERSSTART RPL_USERS
1892 RPL_NOUSERS RPL_ENDOFUSERS
1893 ERR_USERSDISABLED
1894
1895 Disabled Reply:
1896
1897 ERR_USERSDISABLED
1898
1899 Example:
1900
1901 USERS eff.org ; request a list of users logged in
1902 on server eff.org
1903
1904 4.7 Operwall message
1905
1906 Command: WALLOPS
1907 Parameters: <Text to be sent>
1908
1909 The WALLOPS command is used to send a message to all currently
1910 connected users who have set the 'w' user mode for themselves. (See
1911 Section 3.1.5 "User modes").
1912
1913 After implementing WALLOPS as a user command it was found that it was
1914 often and commonly abused as a means of sending a message to a lot of
1915 people. Due to this, it is RECOMMENDED that the implementation of
1916 WALLOPS allows and recognizes only servers as the originators of
1917 WALLOPS.
1918
1919 Numeric Replies:
1920
1921 ERR_NEEDMOREPARAMS
1922
1923 Example:
1924
1925 :csd.bu.edu WALLOPS :Connect '*.uiuc.edu 6667' from Joshua ; WALLOPS
1926 message from csd.bu.edu announcing a
1927 CONNECT message it received from
1928 Joshua and acted upon.
1929
1930 4.8 Userhost message
1931
1932 Command: USERHOST
1933 Parameters: <nickname> *( SPACE <nickname> )
1934
1935 The USERHOST command takes a list of up to 5 nicknames, each
1936 separated by a space character and returns a list of information
1937 about each nickname that it found. The returned list has each reply
1938 separated by a space.
1939
1940 Numeric Replies:
1941
1942 RPL_USERHOST ERR_NEEDMOREPARAMS
1943
1944 Example:
1945
1946 USERHOST Wiz Michael syrk ; USERHOST request for information on
1947 nicks "Wiz", "Michael", and "syrk"
1948
1949 :ircd.stealth.net 302 yournick :syrk=+syrk@millennium.stealth.net
1950 ; Reply for user syrk
1951
1952 4.9 Ison message
1953
1954 Command: ISON
1955 Parameters: <nickname> *( SPACE <nickname> )
1956
1957 The ISON command was implemented to provide a quick and efficient
1958 means to get a response about whether a given nickname was currently
1959 on IRC. ISON only takes one (1) type of parameter: a space-separated
1960 list of nicks. For each nickname in the list that is present, the
1961
1962 server adds that to its reply string. Thus the reply string may
1963 return empty (none of the given nicks are present), an exact copy of
1964 the parameter string (all of them present) or any other subset of the
1965 set of nicks given in the parameter. The only limit on the number of
1966 nicks that may be checked is that the combined length MUST NOT be too
1967 large as to cause the server to chop it off so it fits in 512
1968 characters.
1969
1970 ISON is only processed by the server local to the client sending the
1971 command and thus not passed onto other servers for further
1972 processing.
1973
1974 Numeric Replies:
1975
1976 RPL_ISON ERR_NEEDMOREPARAMS
1977
1978 Example:
1979
1980 ISON phone trillian WiZ jarlek Avalon Angel Monstah syrk
1981 ; Sample ISON request for 7 nicks.
1982
1983 5. Replies
1984
1985 The following is a list of numeric replies which are generated in
1986 response to the commands given above. Each numeric is given with its
1987 number, name and reply string.
1988
1989 5.1 Command responses
1990
1991 Numerics in the range from 001 to 099 are used for client-server
1992 connections only and should never travel between servers. Replies
1993 generated in the response to commands are found in the range from 200
1994 to 399.
1995
1996 001 RPL_WELCOME
1997 "Welcome to the Internet Relay Network
1998 <nick>!<user>@<host>"
1999 002 RPL_YOURHOST
2000 "Your host is <servername>, running version <ver>"
2001 003 RPL_CREATED
2002 "This server was created <date>"
2003 004 RPL_MYINFO
2004 "<servername> <version> <available user modes>
2005 <available channel modes>"
2006
2007 - The server sends Replies 001 to 004 to a user upon
2008 successful registration.
2009
2010 005 RPL_BOUNCE
2011 "Try server <server name>, port <port number>"
2012
2013 - Sent by the server to a user to suggest an alternative
2014 server. This is often used when the connection is
2015 refused because the server is already full.
2016
2017 302 RPL_USERHOST
2018 ":*1<reply> *( " " <reply> )"
2019
2020 - Reply format used by USERHOST to list replies to
2021 the query list. The reply string is composed as
2022 follows:
2023
2024 reply = nickname [ "*" ] "=" ( "+" / "-" ) hostname
2025
2026 The '*' indicates whether the client has registered
2027 as an Operator. The '-' or '+' characters represent
2028 whether the client has set an AWAY message or not
2029 respectively.
2030
2031 303 RPL_ISON
2032 ":*1<nick> *( " " <nick> )"
2033
2034 - Reply format used by ISON to list replies to the
2035 query list.
2036
2037 301 RPL_AWAY
2038 "<nick> :<away message>"
2039 305 RPL_UNAWAY
2040 ":You are no longer marked as being away"
2041 306 RPL_NOWAWAY
2042 ":You have been marked as being away"
2043
2044 - These replies are used with the AWAY command (if
2045 allowed). RPL_AWAY is sent to any client sending a
2046 PRIVMSG to a client which is away. RPL_AWAY is only
2047 sent by the server to which the client is connected.
2048 Replies RPL_UNAWAY and RPL_NOWAWAY are sent when the
2049 client removes and sets an AWAY message.
2050
2051 311 RPL_WHOISUSER
2052 "<nick> <user> <host> * :<real name>"
2053 312 RPL_WHOISSERVER
2054 "<nick> <server> :<server info>"
2055 313 RPL_WHOISOPERATOR
2056 "<nick> :is an IRC operator"
2057
2058 317 RPL_WHOISIDLE
2059 "<nick> <integer> :seconds idle"
2060 318 RPL_ENDOFWHOIS
2061 "<nick> :End of WHOIS list"
2062 319 RPL_WHOISCHANNELS
2063 "<nick> :*( ( "@" / "+" ) <channel> " " )"
2064
2065 - Replies 311 - 313, 317 - 319 are all replies
2066 generated in response to a WHOIS message. Given that
2067 there are enough parameters present, the answering
2068 server MUST either formulate a reply out of the above
2069 numerics (if the query nick is found) or return an
2070 error reply. The '*' in RPL_WHOISUSER is there as
2071 the literal character and not as a wild card. For
2072 each reply set, only RPL_WHOISCHANNELS may appear
2073 more than once (for long lists of channel names).
2074 The '@' and '+' characters next to the channel name
2075 indicate whether a client is a channel operator or
2076 has been granted permission to speak on a moderated
2077 channel. The RPL_ENDOFWHOIS reply is used to mark
2078 the end of processing a WHOIS message.
2079
2080 314 RPL_WHOWASUSER
2081 "<nick> <user> <host> * :<real name>"
2082 369 RPL_ENDOFWHOWAS
2083 "<nick> :End of WHOWAS"
2084
2085 - When replying to a WHOWAS message, a server MUST use
2086 the replies RPL_WHOWASUSER, RPL_WHOISSERVER or
2087 ERR_WASNOSUCHNICK for each nickname in the presented
2088 list. At the end of all reply batches, there MUST
2089 be RPL_ENDOFWHOWAS (even if there was only one reply
2090 and it was an error).
2091
2092 321 RPL_LISTSTART
2093 Obsolete. Not used.
2094
2095 322 RPL_LIST
2096 "<channel> <# visible> :<topic>"
2097 323 RPL_LISTEND
2098 ":End of LIST"
2099
2100 - Replies RPL_LIST, RPL_LISTEND mark the actual replies
2101 with data and end of the server's response to a LIST
2102 command. If there are no channels available to return,
2103 only the end reply MUST be sent.
2104
2105 325 RPL_UNIQOPIS
2106 "<channel> <nickname>"
2107
2108 324 RPL_CHANNELMODEIS
2109 "<channel> <mode> <mode params>"
2110
2111 331 RPL_NOTOPIC
2112 "<channel> :No topic is set"
2113 332 RPL_TOPIC
2114 "<channel> :<topic>"
2115
2116 - When sending a TOPIC message to determine the
2117 channel topic, one of two replies is sent. If
2118 the topic is set, RPL_TOPIC is sent back else
2119 RPL_NOTOPIC.
2120
2121 341 RPL_INVITING
2122 "<channel> <nick>"
2123
2124 - Returned by the server to indicate that the
2125 attempted INVITE message was successful and is
2126 being passed onto the end client.
2127
2128 342 RPL_SUMMONING
2129 "<user> :Summoning user to IRC"
2130
2131 - Returned by a server answering a SUMMON message to
2132 indicate that it is summoning that user.
2133
2134 346 RPL_INVITELIST
2135 "<channel> <invitemask>"
2136 347 RPL_ENDOFINVITELIST
2137 "<channel> :End of channel invite list"
2138
2139 - When listing the 'invitations masks' for a given channel,
2140 a server is required to send the list back using the
2141 RPL_INVITELIST and RPL_ENDOFINVITELIST messages. A
2142 separate RPL_INVITELIST is sent for each active mask.
2143 After the masks have been listed (or if none present) a
2144 RPL_ENDOFINVITELIST MUST be sent.
2145
2146 348 RPL_EXCEPTLIST
2147 "<channel> <exceptionmask>"
2148 349 RPL_ENDOFEXCEPTLIST
2149 "<channel> :End of channel exception list"
2150
2151 - When listing the 'exception masks' for a given channel,
2152 a server is required to send the list back using the
2153 RPL_EXCEPTLIST and RPL_ENDOFEXCEPTLIST messages. A
2154 separate RPL_EXCEPTLIST is sent for each active mask.
2155 After the masks have been listed (or if none present)
2156 a RPL_ENDOFEXCEPTLIST MUST be sent.
2157
2158 351 RPL_VERSION
2159 "<version>.<debuglevel> <server> :<comments>"
2160
2161 - Reply by the server showing its version details.
2162 The <version> is the version of the software being
2163 used (including any patchlevel revisions) and the
2164 <debuglevel> is used to indicate if the server is
2165 running in "debug mode".
2166
2167 The "comments" field may contain any comments about
2168 the version or further version details.
2169
2170 352 RPL_WHOREPLY
2171 "<channel> <user> <host> <server> <nick>
2172 ( "H" / "G" > ["*"] [ ( "@" / "+" ) ]
2173 :<hopcount> <real name>"
2174
2175 315 RPL_ENDOFWHO
2176 "<name> :End of WHO list"
2177
2178 - The RPL_WHOREPLY and RPL_ENDOFWHO pair are used
2179 to answer a WHO message. The RPL_WHOREPLY is only
2180 sent if there is an appropriate match to the WHO
2181 query. If there is a list of parameters supplied
2182 with a WHO message, a RPL_ENDOFWHO MUST be sent
2183 after processing each list item with <name> being
2184 the item.
2185
2186 353 RPL_NAMREPLY
2187 "( "=" / "*" / "@" ) <channel>
2188 :[ "@" / "+" ] <nick> *( " " [ "@" / "+" ] <nick> )
2189 - "@" is used for secret channels, "*" for private
2190 channels, and "=" for others (public channels).
2191
2192 366 RPL_ENDOFNAMES
2193 "<channel> :End of NAMES list"
2194
2195 - To reply to a NAMES message, a reply pair consisting
2196 of RPL_NAMREPLY and RPL_ENDOFNAMES is sent by the
2197 server back to the client. If there is no channel
2198 found as in the query, then only RPL_ENDOFNAMES is
2199
2200 returned. The exception to this is when a NAMES
2201 message is sent with no parameters and all visible
2202 channels and contents are sent back in a series of
2203 RPL_NAMEREPLY messages with a RPL_ENDOFNAMES to mark
2204 the end.
2205
2206 364 RPL_LINKS
2207 "<mask> <server> :<hopcount> <server info>"
2208 365 RPL_ENDOFLINKS
2209 "<mask> :End of LINKS list"
2210
2211 - In replying to the LINKS message, a server MUST send
2212 replies back using the RPL_LINKS numeric and mark the
2213 end of the list using an RPL_ENDOFLINKS reply.
2214
2215 367 RPL_BANLIST
2216 "<channel> <banmask>"
2217 368 RPL_ENDOFBANLIST
2218 "<channel> :End of channel ban list"
2219
2220 - When listing the active 'bans' for a given channel,
2221 a server is required to send the list back using the
2222 RPL_BANLIST and RPL_ENDOFBANLIST messages. A separate
2223 RPL_BANLIST is sent for each active banmask. After the
2224 banmasks have been listed (or if none present) a
2225 RPL_ENDOFBANLIST MUST be sent.
2226
2227 371 RPL_INFO
2228 ":<string>"
2229 374 RPL_ENDOFINFO
2230 ":End of INFO list"
2231
2232 - A server responding to an INFO message is required to
2233 send all its 'info' in a series of RPL_INFO messages
2234 with a RPL_ENDOFINFO reply to indicate the end of the
2235 replies.
2236
2237 375 RPL_MOTDSTART
2238 ":- <server> Message of the day - "
2239 372 RPL_MOTD
2240 ":- <text>"
2241 376 RPL_ENDOFMOTD
2242 ":End of MOTD command"
2243
2244 - When responding to the MOTD message and the MOTD file
2245 is found, the file is displayed line by line, with
2246 each line no longer than 80 characters, using
2247
2248 RPL_MOTD format replies. These MUST be surrounded
2249 by a RPL_MOTDSTART (before the RPL_MOTDs) and an
2250 RPL_ENDOFMOTD (after).
2251
2252 381 RPL_YOUREOPER
2253 ":You are now an IRC operator"
2254
2255 - RPL_YOUREOPER is sent back to a client which has
2256 just successfully issued an OPER message and gained
2257 operator status.
2258
2259 382 RPL_REHASHING
2260 "<config file> :Rehashing"
2261
2262 - If the REHASH option is used and an operator sends
2263 a REHASH message, an RPL_REHASHING is sent back to
2264 the operator.
2265
2266 383 RPL_YOURESERVICE
2267 "You are service <servicename>"
2268
2269 - Sent by the server to a service upon successful
2270 registration.
2271
2272 391 RPL_TIME
2273 "<server> :<string showing server's local time>"
2274
2275 - When replying to the TIME message, a server MUST send
2276 the reply using the RPL_TIME format above. The string
2277 showing the time need only contain the correct day and
2278 time there. There is no further requirement for the
2279 time string.
2280
2281 392 RPL_USERSSTART
2282 ":UserID Terminal Host"
2283 393 RPL_USERS
2284 ":<username> <ttyline> <hostname>"
2285 394 RPL_ENDOFUSERS
2286 ":End of users"
2287 395 RPL_NOUSERS
2288 ":Nobody logged in"
2289
2290 - If the USERS message is handled by a server, the
2291 replies RPL_USERSTART, RPL_USERS, RPL_ENDOFUSERS and
2292 RPL_NOUSERS are used. RPL_USERSSTART MUST be sent
2293 first, following by either a sequence of RPL_USERS
2294 or a single RPL_NOUSER. Following this is
2295 RPL_ENDOFUSERS.
2296
2297 200 RPL_TRACELINK
2298 "Link <version & debug level> <destination>
2299 <next server> V<protocol version>
2300 <link uptime in seconds> <backstream sendq>
2301 <upstream sendq>"
2302 201 RPL_TRACECONNECTING
2303 "Try. <class> <server>"
2304 202 RPL_TRACEHANDSHAKE
2305 "H.S. <class> <server>"
2306 203 RPL_TRACEUNKNOWN
2307 "???? <class> [<client IP address in dot form>]"
2308 204 RPL_TRACEOPERATOR
2309 "Oper <class> <nick>"
2310 205 RPL_TRACEUSER
2311 "User <class> <nick>"
2312 206 RPL_TRACESERVER
2313 "Serv <class> <int>S <int>C <server>
2314 <nick!user|*!*>@<host|server> V<protocol version>"
2315 207 RPL_TRACESERVICE
2316 "Service <class> <name> <type> <active type>"
2317 208 RPL_TRACENEWTYPE
2318 "<newtype> 0 <client name>"
2319 209 RPL_TRACECLASS
2320 "Class <class> <count>"
2321 210 RPL_TRACERECONNECT
2322 Unused.
2323 261 RPL_TRACELOG
2324 "File <logfile> <debug level>"
2325 262 RPL_TRACEEND
2326 "<server name> <version & debug level> :End of TRACE"
2327
2328 - The RPL_TRACE* are all returned by the server in
2329 response to the TRACE message. How many are
2330 returned is dependent on the TRACE message and
2331 whether it was sent by an operator or not. There
2332 is no predefined order for which occurs first.
2333 Replies RPL_TRACEUNKNOWN, RPL_TRACECONNECTING and
2334 RPL_TRACEHANDSHAKE are all used for connections
2335 which have not been fully established and are either
2336 unknown, still attempting to connect or in the
2337 process of completing the 'server handshake'.
2338 RPL_TRACELINK is sent by any server which handles
2339 a TRACE message and has to pass it on to another
2340 server. The list of RPL_TRACELINKs sent in
2341 response to a TRACE command traversing the IRC
2342 network should reflect the actual connectivity of
2343 the servers themselves along that path.
2344
2345 RPL_TRACENEWTYPE is to be used for any connection
2346 which does not fit in the other categories but is
2347 being displayed anyway.
2348 RPL_TRACEEND is sent to indicate the end of the list.
2349
2350 211 RPL_STATSLINKINFO
2351 "<linkname> <sendq> <sent messages>
2352 <sent Kbytes> <received messages>
2353 <received Kbytes> <time open>"
2354
2355 - reports statistics on a connection. <linkname>
2356 identifies the particular connection, <sendq> is
2357 the amount of data that is queued and waiting to be
2358 sent <sent messages> the number of messages sent,
2359 and <sent Kbytes> the amount of data sent, in
2360 Kbytes. <received messages> and <received Kbytes>
2361 are the equivalent of <sent messages> and <sent
2362 Kbytes> for received data, respectively. <time
2363 open> indicates how long ago the connection was
2364 opened, in seconds.
2365
2366 212 RPL_STATSCOMMANDS
2367 "<command> <count> <byte count> <remote count>"
2368
2369 - reports statistics on commands usage.
2370
2371 219 RPL_ENDOFSTATS
2372 "<stats letter> :End of STATS report"
2373
2374 242 RPL_STATSUPTIME
2375 ":Server Up %d days %d:%02d:%02d"
2376
2377 - reports the server uptime.
2378
2379 243 RPL_STATSOLINE
2380 "O <hostmask> * <name>"
2381
2382 - reports the allowed hosts from where user may become IRC
2383 operators.
2384
2385 221 RPL_UMODEIS
2386 "<user mode string>"
2387
2388 - To answer a query about a client's own mode,
2389 RPL_UMODEIS is sent back.
2390
2391 234 RPL_SERVLIST
2392 "<name> <server> <mask> <type> <hopcount> <info>"
2393
2394 235 RPL_SERVLISTEND
2395 "<mask> <type> :End of service listing"
2396
2397 - When listing services in reply to a SERVLIST message,
2398 a server is required to send the list back using the
2399 RPL_SERVLIST and RPL_SERVLISTEND messages. A separate
2400 RPL_SERVLIST is sent for each service. After the
2401 services have been listed (or if none present) a
2402 RPL_SERVLISTEND MUST be sent.
2403
2404 251 RPL_LUSERCLIENT
2405 ":There are <integer> users and <integer>
2406 services on <integer> servers"
2407 252 RPL_LUSEROP
2408 "<integer> :operator(s) online"
2409 253 RPL_LUSERUNKNOWN
2410 "<integer> :unknown connection(s)"
2411 254 RPL_LUSERCHANNELS
2412 "<integer> :channels formed"
2413 255 RPL_LUSERME
2414 ":I have <integer> clients and <integer>
2415 servers"
2416
2417 - In processing an LUSERS message, the server
2418 sends a set of replies from RPL_LUSERCLIENT,
2419 RPL_LUSEROP, RPL_USERUNKNOWN,
2420 RPL_LUSERCHANNELS and RPL_LUSERME. When
2421 replying, a server MUST send back
2422 RPL_LUSERCLIENT and RPL_LUSERME. The other
2423 replies are only sent back if a non-zero count
2424 is found for them.
2425
2426 256 RPL_ADMINME
2427 "<server> :Administrative info"
2428 257 RPL_ADMINLOC1
2429 ":<admin info>"
2430 258 RPL_ADMINLOC2
2431 ":<admin info>"
2432 259 RPL_ADMINEMAIL
2433 ":<admin info>"
2434
2435 - When replying to an ADMIN message, a server
2436 is expected to use replies RPL_ADMINME
2437 through to RPL_ADMINEMAIL and provide a text
2438 message with each. For RPL_ADMINLOC1 a
2439 description of what city, state and country
2440 the server is in is expected, followed by
2441 details of the institution (RPL_ADMINLOC2)
2442
2443 and finally the administrative contact for the
2444 server (an email address here is REQUIRED)
2445 in RPL_ADMINEMAIL.
2446
2447 263 RPL_TRYAGAIN
2448 "<command> :Please wait a while and try again."
2449
2450 - When a server drops a command without processing it,
2451 it MUST use the reply RPL_TRYAGAIN to inform the
2452 originating client.
2453
2454 5.2 Error Replies
2455
2456 Error replies are found in the range from 400 to 599.
2457
2458 401 ERR_NOSUCHNICK
2459 "<nickname> :No such nick/channel"
2460
2461 - Used to indicate the nickname parameter supplied to a
2462 command is currently unused.
2463
2464 402 ERR_NOSUCHSERVER
2465 "<server name> :No such server"
2466
2467 - Used to indicate the server name given currently
2468 does not exist.
2469
2470 403 ERR_NOSUCHCHANNEL
2471 "<channel name> :No such channel"
2472
2473 - Used to indicate the given channel name is invalid.
2474
2475 404 ERR_CANNOTSENDTOCHAN
2476 "<channel name> :Cannot send to channel"
2477
2478 - Sent to a user who is either (a) not on a channel
2479 which is mode +n or (b) not a chanop (or mode +v) on
2480 a channel which has mode +m set or where the user is
2481 banned and is trying to send a PRIVMSG message to
2482 that channel.
2483
2484 405 ERR_TOOMANYCHANNELS
2485 "<channel name> :You have joined too many channels"
2486
2487 - Sent to a user when they have joined the maximum
2488 number of allowed channels and they try to join
2489 another channel.
2490
2491 406 ERR_WASNOSUCHNICK
2492 "<nickname> :There was no such nickname"
2493
2494 - Returned by WHOWAS to indicate there is no history
2495 information for that nickname.
2496
2497 407 ERR_TOOMANYTARGETS
2498 "<target> :<error code> recipients. <abort message>"
2499
2500 - Returned to a client which is attempting to send a
2501 PRIVMSG/NOTICE using the user@host destination format
2502 and for a user@host which has several occurrences.
2503
2504 - Returned to a client which trying to send a
2505 PRIVMSG/NOTICE to too many recipients.
2506
2507 - Returned to a client which is attempting to JOIN a safe
2508 channel using the shortname when there are more than one
2509 such channel.
2510
2511 408 ERR_NOSUCHSERVICE
2512 "<service name> :No such service"
2513
2514 - Returned to a client which is attempting to send a SQUERY
2515 to a service which does not exist.
2516
2517 409 ERR_NOORIGIN
2518 ":No origin specified"
2519
2520 - PING or PONG message missing the originator parameter.
2521
2522 411 ERR_NORECIPIENT
2523 ":No recipient given (<command>)"
2524 412 ERR_NOTEXTTOSEND
2525 ":No text to send"
2526 413 ERR_NOTOPLEVEL
2527 "<mask> :No toplevel domain specified"
2528 414 ERR_WILDTOPLEVEL
2529 "<mask> :Wildcard in toplevel domain"
2530 415 ERR_BADMASK
2531 "<mask> :Bad Server/host mask"
2532
2533 - 412 - 415 are returned by PRIVMSG to indicate that
2534 the message wasn't delivered for some reason.
2535 ERR_NOTOPLEVEL and ERR_WILDTOPLEVEL are errors that
2536 are returned when an invalid use of
2537 "PRIVMSG $<server>" or "PRIVMSG #<host>" is attempted.
2538
2539 421 ERR_UNKNOWNCOMMAND
2540 "<command> :Unknown command"
2541
2542 - Returned to a registered client to indicate that the
2543 command sent is unknown by the server.
2544
2545 422 ERR_NOMOTD
2546 ":MOTD File is missing"
2547
2548 - Server's MOTD file could not be opened by the server.
2549
2550 423 ERR_NOADMININFO
2551 "<server> :No administrative info available"
2552
2553 - Returned by a server in response to an ADMIN message
2554 when there is an error in finding the appropriate
2555 information.
2556
2557 424 ERR_FILEERROR
2558 ":File error doing <file op> on <file>"
2559
2560 - Generic error message used to report a failed file
2561 operation during the processing of a message.
2562
2563 431 ERR_NONICKNAMEGIVEN
2564 ":No nickname given"
2565
2566 - Returned when a nickname parameter expected for a
2567 command and isn't found.
2568
2569 432 ERR_ERRONEUSNICKNAME
2570 "<nick> :Erroneous nickname"
2571
2572 - Returned after receiving a NICK message which contains
2573 characters which do not fall in the defined set. See
2574 section 2.3.1 for details on valid nicknames.
2575
2576 433 ERR_NICKNAMEINUSE
2577 "<nick> :Nickname is already in use"
2578
2579 - Returned when a NICK message is processed that results
2580 in an attempt to change to a currently existing
2581 nickname.
2582
2583 436 ERR_NICKCOLLISION
2584 "<nick> :Nickname collision KILL from <user>@<host>"
2585
2586 - Returned by a server to a client when it detects a
2587 nickname collision (registered of a NICK that
2588 already exists by another server).
2589
2590 437 ERR_UNAVAILRESOURCE
2591 "<nick/channel> :Nick/channel is temporarily unavailable"
2592
2593 - Returned by a server to a user trying to join a channel
2594 currently blocked by the channel delay mechanism.
2595
2596 - Returned by a server to a user trying to change nickname
2597 when the desired nickname is blocked by the nick delay
2598 mechanism.
2599
2600 441 ERR_USERNOTINCHANNEL
2601 "<nick> <channel> :They aren't on that channel"
2602
2603 - Returned by the server to indicate that the target
2604 user of the command is not on the given channel.
2605
2606 442 ERR_NOTONCHANNEL
2607 "<channel> :You're not on that channel"
2608
2609 - Returned by the server whenever a client tries to
2610 perform a channel affecting command for which the
2611 client isn't a member.
2612
2613 443 ERR_USERONCHANNEL
2614 "<user> <channel> :is already on channel"
2615
2616 - Returned when a client tries to invite a user to a
2617 channel they are already on.
2618
2619 444 ERR_NOLOGIN
2620 "<user> :User not logged in"
2621
2622 - Returned by the summon after a SUMMON command for a
2623 user was unable to be performed since they were not
2624 logged in.
2625
2626 445 ERR_SUMMONDISABLED
2627 ":SUMMON has been disabled"
2628
2629 - Returned as a response to the SUMMON command. MUST be
2630 returned by any server which doesn't implement it.
2631
2632 446 ERR_USERSDISABLED
2633 ":USERS has been disabled"
2634
2635 - Returned as a response to the USERS command. MUST be
2636 returned by any server which does not implement it.
2637
2638 451 ERR_NOTREGISTERED
2639 ":You have not registered"
2640
2641 - Returned by the server to indicate that the client
2642 MUST be registered before the server will allow it
2643 to be parsed in detail.
2644
2645 461 ERR_NEEDMOREPARAMS
2646 "<command> :Not enough parameters"
2647
2648 - Returned by the server by numerous commands to
2649 indicate to the client that it didn't supply enough
2650 parameters.
2651
2652 462 ERR_ALREADYREGISTRED
2653 ":Unauthorized command (already registered)"
2654
2655 - Returned by the server to any link which tries to
2656 change part of the registered details (such as
2657 password or user details from second USER message).
2658
2659 463 ERR_NOPERMFORHOST
2660 ":Your host isn't among the privileged"
2661
2662 - Returned to a client which attempts to register with
2663 a server which does not been setup to allow
2664 connections from the host the attempted connection
2665 is tried.
2666
2667 464 ERR_PASSWDMISMATCH
2668 ":Password incorrect"
2669
2670 - Returned to indicate a failed attempt at registering
2671 a connection for which a password was required and
2672 was either not given or incorrect.
2673
2674 465 ERR_YOUREBANNEDCREEP
2675 ":You are banned from this server"
2676
2677 - Returned after an attempt to connect and register
2678 yourself with a server which has been setup to
2679 explicitly deny connections to you.
2680
2681 466 ERR_YOUWILLBEBANNED
2682
2683 - Sent by a server to a user to inform that access to the
2684 server will soon be denied.
2685
2686 467 ERR_KEYSET
2687 "<channel> :Channel key already set"
2688 471 ERR_CHANNELISFULL
2689 "<channel> :Cannot join channel (+l)"
2690 472 ERR_UNKNOWNMODE
2691 "<char> :is unknown mode char to me for <channel>"
2692 473 ERR_INVITEONLYCHAN
2693 "<channel> :Cannot join channel (+i)"
2694 474 ERR_BANNEDFROMCHAN
2695 "<channel> :Cannot join channel (+b)"
2696 475 ERR_BADCHANNELKEY
2697 "<channel> :Cannot join channel (+k)"
2698 476 ERR_BADCHANMASK
2699 "<channel> :Bad Channel Mask"
2700 477 ERR_NOCHANMODES
2701 "<channel> :Channel doesn't support modes"
2702 478 ERR_BANLISTFULL
2703 "<channel> <char> :Channel list is full"
2704
2705 481 ERR_NOPRIVILEGES
2706 ":Permission Denied- You're not an IRC operator"
2707
2708 - Any command requiring operator privileges to operate
2709 MUST return this error to indicate the attempt was
2710 unsuccessful.
2711
2712 482 ERR_CHANOPRIVSNEEDED
2713 "<channel> :You're not channel operator"
2714
2715 - Any command requiring 'chanop' privileges (such as
2716 MODE messages) MUST return this error if the client
2717 making the attempt is not a chanop on the specified
2718 channel.
2719
2720 483 ERR_CANTKILLSERVER
2721 ":You can't kill a server!"
2722
2723 - Any attempts to use the KILL command on a server
2724 are to be refused and this error returned directly
2725 to the client.
2726
2727 484 ERR_RESTRICTED
2728 ":Your connection is restricted!"
2729
2730 - Sent by the server to a user upon connection to indicate
2731 the restricted nature of the connection (user mode "+r").
2732
2733 485 ERR_UNIQOPPRIVSNEEDED
2734 ":You're not the original channel operator"
2735
2736 - Any MODE requiring "channel creator" privileges MUST
2737 return this error if the client making the attempt is not
2738 a chanop on the specified channel.
2739
2740 491 ERR_NOOPERHOST
2741 ":No O-lines for your host"
2742
2743 - If a client sends an OPER message and the server has
2744 not been configured to allow connections from the
2745 client's host as an operator, this error MUST be
2746 returned.
2747
2748 501 ERR_UMODEUNKNOWNFLAG
2749 ":Unknown MODE flag"
2750
2751 - Returned by the server to indicate that a MODE
2752 message was sent with a nickname parameter and that
2753 the a mode flag sent was not recognized.
2754
2755 502 ERR_USERSDONTMATCH
2756 ":Cannot change mode for other users"
2757
2758 - Error sent to any user trying to view or change the
2759 user mode for a user other than themselves.
2760
2761 5.3 Reserved numerics
2762
2763 These numerics are not described above since they fall into one of
2764 the following categories:
2765
2766 1. no longer in use;
2767
2768 2. reserved for future planned use;
2769
2770 3. in current use but are part of a non-generic 'feature' of
2771 the current IRC server.
2772
2773 231 RPL_SERVICEINFO 232 RPL_ENDOFSERVICES
2774 233 RPL_SERVICE
2775 300 RPL_NONE 316 RPL_WHOISCHANOP
2776 361 RPL_KILLDONE 362 RPL_CLOSING
2777 363 RPL_CLOSEEND 373 RPL_INFOSTART
2778 384 RPL_MYPORTIS
2779
2780 213 RPL_STATSCLINE 214 RPL_STATSNLINE
2781 215 RPL_STATSILINE 216 RPL_STATSKLINE
2782 217 RPL_STATSQLINE 218 RPL_STATSYLINE
2783 240 RPL_STATSVLINE 241 RPL_STATSLLINE
2784 244 RPL_STATSHLINE 244 RPL_STATSSLINE
2785 246 RPL_STATSPING 247 RPL_STATSBLINE
2786 250 RPL_STATSDLINE
2787
2788 492 ERR_NOSERVICEHOST
2789
2790 6. Current implementations
2791
2792 The IRC software, version 2.10 is the only complete implementation of
2793 the IRC protocol (client and server). Because of the small amount of
2794 changes in the client protocol since the publication of RFC 1459
2795 [IRC], implementations that follow it are likely to be compliant with
2796 this protocol or to require a small amount of changes to reach
2797 compliance.
2798
2799 7. Current problems
2800
2801 There are a number of recognized problems with the IRC Client
2802 Protocol, and more generally with the IRC Server Protocol. In order
2803 to preserve backward compatibility with old clients, this protocol
2804 has almost not evolved since the publication of RFC 1459 [IRC].
2805
2806 7.1 Nicknames
2807
2808 The idea of the nickname on IRC is very convenient for users to use
2809 when talking to each other outside of a channel, but there is only a
2810 finite nickname space and being what they are, it's not uncommon for
2811 several people to want to use the same nick. If a nickname is chosen
2812 by two people using this protocol, either one will not succeed or
2813 both will removed by use of a server KILL (See Section 3.7.1).
2814
2815 7.2 Limitation of wildcards
2816
2817 There is no way to escape the escape character "\" (%x5C). While
2818 this isn't usually a problem, it makes it impossible to form a mask
2819 with a backslash character ("\") preceding a wildcard.
2820
2821 7.3 Security considerations
2822
2823 Security issues related to this protocol are discussed in the "IRC
2824 Server Protocol" [IRC-SERVER] as they are mostly an issue for the
2825 server side of the connection.
2826
2827 8. Current support and availability
2828
2829 Mailing lists for IRC related discussion:
2830 General discussion: ircd-users@irc.org
2831 Protocol development: ircd-dev@irc.org
2832
2833 Software implementations:
2834 ftp://ftp.irc.org/irc/server
2835 ftp://ftp.funet.fi/pub/unix/irc
2836 ftp://ftp.irc.org/irc/clients
2837
2838 Newsgroup: alt.irc
2839
2840 9. Acknowledgements
2841
2842 Parts of this document were copied from the RFC 1459 [IRC] which
2843 first formally documented the IRC Protocol. It has also benefited
2844 from many rounds of review and comments. In particular, the
2845 following people have made significant contributions to this
2846 document:
2847
2848 Matthew Green, Michael Neumayer, Volker Paulsen, Kurt Roeckx, Vesa
2849 Ruokonen, Magnus Tjernstrom, Stefan Zehl.
2850
2851 10. References
2852
2853 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
2854 Requirement Levels", BCP 14, RFC 2119, March 1997.
2855
2856 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
2857 Specifications: ABNF", RFC 2234, November 1997.
2858
2859 [HNAME] Braden, R., "Requirements for Internet Hosts --
2860 Application and Support", STD 3, RFC 1123, October 1989.
2861
2862 [IRC] Oikarinen, J. & D. Reed, "Internet Relay Chat Protocol",
2863 RFC 1459, May 1993.
2864
2865 [IRC-ARCH] Kalt, C., "Internet Relay Chat: Architecture", RFC 2810,
2866 April 2000.
2867
2868 [IRC-CHAN] Kalt, C., "Internet Relay Chat: Channel Management", RFC
2869 2811, April 2000.
2870
2871 [IRC-SERVER] Kalt, C., "Internet Relay Chat: Server Protocol", RFC
2872 2813, April 2000.
2873
2874 11. Author's Address
2875
2876 Christophe Kalt
2877 99 Teaneck Rd, Apt #117
2878 Ridgefield Park, NJ 07660
2879 USA
2880
2881 EMail: kalt@stealth.net
2882
2883 12. Full Copyright Statement
2884
2885 Copyright (C) The Internet Society (2000). All Rights Reserved.
2886
2887 This document and translations of it may be copied and furnished to
2888 others, and derivative works that comment on or otherwise explain it
2889 or assist in its implementation may be prepared, copied, published
2890 and distributed, in whole or in part, without restriction of any
2891 kind, provided that the above copyright notice and this paragraph are
2892 included on all such copies and derivative works. However, this
2893 document itself may not be modified in any way, such as by removing
2894 the copyright notice or references to the Internet Society or other
2895 Internet organizations, except as needed for the purpose of
2896 developing Internet standards in which case the procedures for
2897 copyrights defined in the Internet Standards process must be
2898 followed, or as required to translate it into languages other than
2899 English.
2900
2901 The limited permissions granted above are perpetual and will not be
2902 revoked by the Internet Society or its successors or assigns.
2903
2904 This document and the information contained herein is provided on an
2905 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
2906 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
2907 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
2908 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
2909 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
2910
2911 Acknowledgement
2912
2913 Funding for the RFC Editor function is currently provided by the
2914 Internet Society.