irc-documentation-jilles
view client protocol.txt @ 105:54870aec98e4
Add 005 BNF and acknowledgement.
| author | Jilles Tjoelker <jilles@stack.nl> |
|---|---|
| date | Sat Jan 05 01:16:12 2008 +0100 (2008-01-05) |
| parents | 0d284af9266b |
| children |
line source
1 IRC: Client Protocol
2 --------------------
4 Abstract
5 The IRC (Internet Relay Chat) protocol is for use with text based conferencing; the simplest client being any socket program capable of connecting to the server.
7 This document defines the Client Protocol, and assumes that the reader is familiar with the IRC Architecture [IRC-ARCH].
9 1. Labels
10 This section defines the identifiers used for the various components of the IRC protocol.
12 1.1 Servers
13 Servers are uniquely identified by their name.
15 See the protocol grammar rules (section 2.3.1) for what may and may not be used in a server name.
17 1.2 Clients
18 For each client all servers MUST have the following information: a net-wide unique identifier (whose format depends on the type of client) and the server which introduced the client.
20 1.2.1 Users
21 Each user is distinguished from other users by a unique nickname having a maximum length of characters defined in RPL_ISUPPORT's NICKLEN token. A recommended value is twelve (12) characters, but note that a network may negotiate a different length, and a dangerous caveat is that some server sofware implementations may allow a longer length name than is specified in NICKLEN, though this behaviour SHOULD NOT be used.
23 The maximum length of a nickname MUST be no less than nine (9).
25 See the protocol grammar rules (section 2.3.1) for what may and may not be used in a nickname.
27 1.2.1.1 Operators
28 To allow a reasonable amount of order to be kept within the IRC network, a special class of users (operators) is allowed to perform general maintenance functions on the network. These functions may be controversial and dangerous to the network, but are generally necessary.
30 Some examples of power that an Operator may have (though this is by no means an exhaustive list) is that of connecting and disconnecting additional servers to the network, and removing a troublesome user from the connected network by 'force', i.e., operators are able to close the connection between any client and server.
32 For further details on this type of action, see section 3.7.1 (KILL).
34 1.3 Channels
35 Channels names are strings which begin with an identifying character which implies which type of channel it is. Valid identifying characters differ from implementation to implementation, and are given in the RPL_ISUPPORT CHANTYPES token.
37 Each prefix characterizes a different channel type.
39 The total length of a channel name may vary from network to network, and is dictated by RPL_ISUPPORT's CHANNELLEN token. A recommended value is fifty (50) characters, though a network may allow a longer length.
41 The only restriction on a channel name is that it SHALL NOT contain any spaces (' '), a control G (^G or ASCII 7), a comma (',').
43 Space is used as parameter separator and comma is used as a list item separator by the protocol). Channel names are case insensitive.
45 See the protocol grammar rules (section 2.3.1) for the exact syntax of a channel name.
47 The definition of the channel types is not relevant to the client-server protocol and thus it is beyond the scope of this document. More details can be found in "Internet Relay Chat: Channel Management" [IRC-CHAN].
50 2. The IRC Client Specification
52 2.1 Overview
53 The protocol as described herein is for use only with client to server connections.
55 2.2 Character codes
56 No specific character set is specified. The protocol is based on a set of codes which are composed of eight (8) bits, making up an octet. Each message may be composed of any number of these octets; however, some octet values are used for control codes, which act as message delimiters.
58 In previous evolutions of the IRC protocol, there was a requirement for the use of Scandinavian casemapping to determine the equivilance of nicknames and channels. This is counterproductive and creates confusion and complexity, and SHOULD NOT be used. Scandinavian casemapping should be phased out in favour of ASCII casemapping.
60 2.3 Messages
62 Servers and clients send each other messages, which may or may not generate a reply. Clients are however not advised to wait forever for this reply; client to server and server to server communication is essentially asynchronous by nature.
64 Each IRC message may consist of up to three main parts: the prefix (OPTIONAL), the command, and the command parameters.
66 Each command can take a certain maximum of parameters, traditionally 15. This is implementation dependant. Clients MUST use the value given in RPL_ISUPPORT token MAXPARA. A recommended value is thirty two (32).
68 The prefix, command, and all parameters are separated by one ASCII space character (0x20) each.
70 The presence of a prefix is indicated with a single leading ASCII colon character (':', 0x3b), which MUST be the first character of the message itself.
72 There MUST be NO gap (whitespace) between the colon and the prefix.
74 The prefix is used by servers to indicate the true origin of the message. If the prefix is missing from the message, it is assumed to have originated from the connection from which it was received from.
76 Clients MUST NOT use a prefix when sending a message.
78 The command MUST either be an alphabetical command, or a number (known as a numeric) not exceeding 2147483647 (0x7FFFFFFF), and represented in ASCII text. Numerics less than 100 MUST be prepended with leading zeroes to make the code 3 digits long; other numerics MUST NOT be prepended. See section 2.4 for more detailed coverage of numerics.
80 IRC messages are always lines of characters terminated with a CR-LF (Carriage Return - Line Feed) pair, and these messages SHALL NOT exceed 512 characters in length, counting all characters including the trailing CR-LF. Thus, there are 510 characters maximum allowed for the command and its parameters. There is no provision for continuation of message lines.
82 If an IRC message exceeds 510 bytes, it MUST be truncated at 510 bytes, with a CR-LF appended, taking the total length to 512.
84 2.3.1 Message format in Augmented BNF
85 The protocol messages must be extracted from the contiguous stream of octets. The current solution is to designate two characters, CR and LF, as message separators. Empty messages are silently ignored, which permits use of the sequence CR-LF between messages without extra problems.
87 The extracted message is parsed into the components <prefix>, <command> and list of parameters (<params>).
88 The Augmented BNF representation for this is:
89 message = [ ":" prefix SPACE ] command [ params ] crlf
90 prefix = servername / ( nickname [ "!" user "@" host ] ) / ( nickname "@" host )
91 ; Normal prefixes are servername and
92 ; nickname "!" user "@" host for messages from servers
93 ; and clients, respectively. A prefix of only a nickname
94 ; MAY be used for a client changing their own user mode and
95 ; SHOULD NOT be used in any other case.
96 ; Clients SHOULD treat prefixes of the form nickname "@" host
97 ; as entities named the entire prefix.
98 nickname = ( letter / digit / special ) *( letter / digit / special / "-" )
99 ; additional restrictions above
100 user = 1*( %x01-09 / %x0B-0C / %x0E-1F / %x21-3F / %x41-FF )
101 ; any octet except NUL, CR, LF, " " and "@"
102 ; servers MAY restrict this further
103 servername = [ ( "*" / shortname ) 1*( "." [ shortname ] )
104 ; names starting with "*" are used for server
105 ; hostmasking and hiding.
106 shortname = ( letter / digit ) *( letter / digit / "-" ) *( letter / digit )
107 host = hostchar *( hostchar / "-" / "." / ":")
108 hostchar = "_" / "/" / digit / letter
109 command = 1*letter / 3digit / ( %x31-39 3*digit )
110 params = *14( SPACE middle ) [ SPACE ":" trailing ]
111 =/ 14( SPACE middle ) [ SPACE [ ":" ] trailing ]
112 nospcrlfcl = %x01-09 / %x0B-0C / %x0E-1F / %x21-39 / %x3B-FF
113 ; any octet except NUL, CR, LF, " " and ":"
114 middle = nospcrlfcl *( ":" / nospcrlfcl )
115 trailing= *( ":" / " " / nospcrlfcl )
116 SPACE= %x20 ; space character
117 crlf = %x0D %x0A; "carriage return" "linefeed"
119 NOTES:
120 1) After extracting the parameter list, all parameters are equal whether matched by <middle> or <trailing>. <trailing> is just a syntactic trick to allow SPACE within the parameter.
121 2) The NUL (%x00) character is not special in message framing, and basically could end up inside a parameter, but it would create extra complexities in normal C string handling. Therefore, NUL
122 is not allowed within messages. Most protocol messages specify additional semantics and syntax for
123 the extracted parameter strings dictated by their position in the
124 list.
125 3) Hostname has a maximum length of 63 characters. This is a limitation of the protocol as internet hostnames (in particular) can be longer. Such restriction is necessary because IRC messages are limited to 512 characters in length. Clients connecting from a host which name is longer than 63 characters are registered using the host (numeric) address instead of the host name.
127 Some other parameter syntaxes are:
129 key = 1*23( %x01-05 / %x07-08 / %x0C / %x0E-1F / %x21-2B / %x2D-39 / %x3B-7F )
130 ; any 7-bit US_ASCII character,
131 ; except NUL, CR, LF, FF, h/v TABs, " ", "," and ":"
132 timestamp = "0" / ( %x31-39 *digit )
133 ; Decimal representation of Unix timestamp
134 ; (number of seconds since 1 Jan 1970 00:00:00 UTC)
135 ; The value 0 sometimes has a special meaning.
136 setter = servername / ( nickname [ "!" user "@" host ] )
137 ; Who set a ban, topic, etc.
138 ; Servers may mix the various forms freely.
139 msgto = channel / schannel / nickname / targetmask / directedmsg
140 msgto =/ "*"
141 channel = chantype *( %x01-06 / %x08-09 / %x0B-0C / %x0E-1F /
142 %x21-2B / %x2D-FF )
143 chantype = <any one char in RPL_ISUPPORT CHANTYPES>
144 schannel = statusmsgchar channel
145 statusmsgchar = <any one char in RPL_ISUPPORT STATUSMSG>
146 targetmask = "$" 1*( %x01-09 / %x0B-0C / %x0E-1F / %x21-2B / %x2D-FF )
147 ; syntax of the latter part undefined
148 directedmsg = user [ "%" host ] "@" servername
149 isupport = [ ":" servername SPACE ] "005" SPACE nick SPACE
150 1*13( token SPACE ) ":are supported by this server"
151 ; RPL_ISUPPORT numeric, entire line
152 tokens = 1*13( token SPACE )
153 token = *1"-" isupportparam / isupportparam *1( "=" isupportvalue )
154 ; For RPL_ISUPPORT numeric
155 isupportparam = 1*20( letter / digit )
156 isupportvalue = *( letter / digit / punct )
157 target = 1*( letter / digit / special / "-" / "." / "*" / "?")
158 ; nickname or servername with wildcards (see section 3.4)
159 letter = %x41-5A / %x61-7A ; A-Z / a-z
160 digit = %x30-39 ; 0-9
161 hexdigit = digit / "A" / "B" / "C" / "D" / "E" / "F"
162 special = %x5B-60 / %x7B-7D
163 ; "[", "]", "\", "`", "_", "^", "{", "|", "}"
164 punct = %d33-47 / %d58-64 / %d91-96 / %d123-126
166 2.4 Numeric replies
167 Most of the messages sent to the server generate a reply of some sort. The most common reply is the numeric reply, used for both errors and normal replies. The numeric reply MUST be sent as one message consisting of the sender prefix, the numeric, and the target of the reply. A numeric reply is not allowed to originate from a client. In all other respects, a numeric reply is just like a normal message, except that the keyword is made up exclusively of digits rather than a string of letters. A list of different replies is supplied in section 5 (Replies).
169 2.5 Wildcard expressions
170 When wildcards are allowed in a string, it is referred as a "mask". For string matching purposes, the protocol allows the use of two special characters: '?' (%x3F) to match one and only one character, and '*' (%x2A) to match any number of any characters.
171 Some implementations treat the character '\' (%x5C) specially, see section 7.2. This is not recommended.
172 Examples:
173 a?c
174 Matches any string of 3 characters in length starting with "a" and ending with "c"
175 a*c
176 Matches any string of at least 2 characters in length starting with "a" and ending with "c"
178 3. Message Details
179 On the following pages there are descriptions of each message recognized by the IRC server and client. All commands described in this section MUST be implemented by any server for this protocol.
181 The server to which a client is connected SHOULD parse the complete message, and return any appropriate errors.
183 If multiple parameters is presented, then each MUST be checked for validity and appropriate responses MUST be sent back to the client.
185 In the case of incorrect messages which use parameter lists with comma as an item separator, a reply MUST be sent for each item.
187 3.1 Connection Registration
188 The commands described here are used to register a connection with an IRC server as a user as well as to correctly disconnect.
190 A "PASS" command is not required for a client connection to be registered, but it MUST precede the latter of the NICK/USER combination.
192 The order for a client to register is as follows:
193 Pass message
194 Nick message
195 User message
197 Upon success, the client will receive a series of numerics including RPL_WELCOME indicating that the connection is now registered and known the to the entire IRC network.
199 3.1.1 Password message
200 Command: PASS
201 Parameters: <password>
203 The PASS command is used to set a 'connection password'. The optional password can and MUST be set before any attempt to register the connection is made. This requires that user send a PASS command before sending the NICK/USER combination.
205 Numeric Replies:
206 ERR_NEEDMOREPARAMS
207 ERR_ALREADYREGISTRED
209 Example:
210 PASS secretpasswordhere
212 3.1.2 Nick message
214 Command: NICK
215 Parameters: <nickname>
217 The NICK command is used to give user a nickname or change the existing one. If sent by a client, it is a request that may or may not be granted by the server.
219 Nicknames starting with a digit are reserved for special purposes (e.g. resolving nick collisions); clients SHOULD NOT send them in a NICK command.
221 A server MAY forcibly change a client's nickname by sending NICK messages as if the client sent a NICK command.
223 To know its initial nickname (which MAY be different from the one requested), a client SHOULD use the target field in the RPL_WELCOME numeric.
225 Numeric Replies:
226 ERR_NONICKNAMEGIVEN
227 ERR_ERRONEUSNICKNAME
228 ERR_NICKNAMEINUSE
229 ERR_UNAVAILRESOURCE
230 ERR_RESTRICTED
232 Examples:
233 NICK Wiz
234 Introducing new nick "Wiz" if session is still unregistered, or user changing his nickname to "Wiz"
235 :WiZ!jto@tolsun.oulu.fi NICK Kilroy
236 Server telling that WiZ changed his nickname to Kilroy.
237 :jilles!~jilles@this.is.a.spoof NICK 1JJAAAAAC
238 Server forcibly changing jilles's nickname to 1JJAAAAAC.
240 3.1.3 User message
242 Command: USER
243 Parameters: <user> <mode> <servername> <realname>
245 The USER command is used at the beginning of connection to specify the username, hostname and realname of a new user.
247 The <mode> parameter must be an ASCII string of modes to apply to the client on connect. Both the adding (‘+’) and removing (‘-‘) of modes is to be supported by this field. Replies produced by the processing of this field must reflect replies given by the MODE message. Interpretation of this field by the server is OPTIONAL.
249 If the content of the <servername> parameter is a recognised server hostname, it should be accepted as the server name the user is connecting to. The behaviour due to this is determined by server software and may vary between simple changes to messages to full virtual hosting. Support for virtual hosting is optional, and if the value is not recognised as a server name or the server does not support virtual hosting, a default server name must be used.
251 The <realname> may contain space characters.
253 Numeric Replies:
255 ERR_NEEDMOREPARAMS
256 ERR_ALREADYREGISTRED
258 Example:
260 USER guest 0 * :Ronnie Reagan
261 User registering themselves with a username of "guest" and real name "Ronnie Reagan".
262 USER guest +i-w * :Ronnie Reagan
263 User registering themselves with a username of "guest" and real name "Ronnie Reagan", and asking to be set invisible, and to not receive wallops.
264 USER viroteck +i svn.viroteck.net :Master of all trades; jack of none
265 User registering themselves with a username of “viroteck”, a realname of “Master of all trades; jack of none”, asking to be set invisible and to connect to virtual server svn.viroteck.net.
268 3.1.4 Oper message
270 Command: OPER
271 Parameters: <name> <password>
273 A normal user uses the OPER command to obtain operator privileges. The combination of <name> and <password> are REQUIRED to gain Operator privileges. Upon success, the user will receive a MODE message (see section 3.1.5) indicating the new user modes.
275 Additional measures MAY be used in addition to a password, such as an SSL fingerprint, but servers SHOULD require a password in addition to other such measures.
277 Numeric Replies:
279 ERR_NEEDMOREPARAMS
280 RPL_YOUREOPER
281 ERR_NOOPERHOST
282 ERR_PASSWDMISMATCH
284 Example:
286 OPER foo bar
287 Attempt to register as an operator using a username of "foo" and "bar" as the password.
289 3.1.5 User mode message
291 Command: MODE
292 Parameters: <nickname> *( ( "+" / "-" ) *( "i" / "w" / "o" ) )
294 The user MODE's are typically changes which affect either how the client is seen by others or what 'extra' messages the client is sent.
296 A user MODE command MUST only be accepted if both the sender of the message and the nickname given as a parameter are both the same.
298 If no other parameter is given, then the server will return the current settings for the nick. Otherwise, it is a request to change the user mode; the server will send a MODE message back with the effective changes, if any, and an error message, if any. (This means that it is possible to get no reply at all.)
300 Note that other user modes MAY exist. Their existance is generally implementation defined, however they MUST be given in RPL_MYINFO.
302 3.1.5.1 Available modes
303 i
304 Marks a user as invisible
305 w
306 User receives wallops
307 o
308 Operator flag
309 s
310 Marks a user for receipt of server notices.
312 Additional modes MAY be added as required by the implementation.
313 If a user attempts to make themselves an operator using the "+o" flag, the attempt SHOULD be ignored as users could bypass the authentication mechanisms of the OPER command. There is no restriction, however, on anyone `deopering' themselves (using "-o").
314 The flag 's' is different in implementation from other modes. See FIXME SNOMASKS.
315 Numeric Replies:
316 ERR_NEEDMOREPARAMS
317 ERR_USERSDONTMATCH
318 ERR_UMODEUNKNOWNFLAG
319 RPL_UMODEIS
321 Examples:
322 MODE WiZ -w
323 Command by WiZ to turn off reception of WALLOPS messages.
324 MODE Angel +i
325 Command from Angel to make herself invisible.
326 MODE WiZ -o
327 WiZ 'deopering' (removing operator status).
329 3.1.6 Away
331 Command: AWAY
332 Parameters: [ <text> ]
334 With the AWAY command, clients can set an automatic reply string for any PRIVMSG commands directed at them (not to a channel they are on). The server sends an automatic reply to the client sending the PRIVMSG command. The only replying server is the one to which the sending client is connected to.
335 The AWAY command is used either with one non-empty parameter, to set an AWAY message, or with no parameters, to remove the AWAY message.
337 Numeric Replies:
339 RPL_UNAWAY RPL_NOWAWAY
341 Example:
343 AWAY :Gone to lunch. Back in 5 ; Command to set away message to
344 "Gone to lunch. Back in 5".
346 3.1.7 Quit
348 Command: QUIT
349 Parameters: [ <Quit Message> ]
351 A client session is terminated with a quit message. The server acknowledges this by sending an ERROR message to the client.
353 Numeric Replies:
355 None.
357 Example:
359 QUIT :Gone to have lunch
360 Preferred message format.
361 :syrk!kalt@millennium.stealth.net QUIT :Gone to have lunch
362 User syrk has quit IRC to have lunch.
364 3.1.8 Squit
366 Command: SQUIT
367 Parameters: <server> <comment>
369 The SQUIT command is available only to operators. It is used to disconnect server links. More precisely, it is a command to the last server on the path from the operator to the given server to disconnect it. The effect of executing a SQUIT with the operator's own server is undefined.
371 The <comment> SHOULD be supplied by all operators who execute a SQUIT for a remote server. The server ordered to disconnect its peer generates a WALLOPS message with <comment> included, both for accountability purposes and so that other users remain informed.
373 Numeric replies:
375 ERR_NOPRIVILEGES
376 ERR_NOSUCHSERVER
377 ERR_NEEDMOREPARAMS
379 Examples:
380 SQUIT tolsun.oulu.fi :Bad Link
381 Command to uplink of the server tolson.oulu.fi to terminate its connection with comment "Bad Link".
383 3.2 Channel operations
384 This group of messages is concerned with manipulating channels, their properties (channel modes), and their contents (typically users).
385 All of these messages are requests which will or will not be granted by the server. The server MUST send a reply informing the user whether the request was granted, denied or generated an error.
386 When the server grants the request, the message is typically sent back (eventually reformatted) to the user with the prefix set to the user itself.
387 The rules governing how channels are managed are enforced by the servers. These rules are beyond the scope of this document. More details are found in "Internet Relay Chat: Channel Management" [IRC-CHAN].
389 3.2.1 Join message
391 Command: JOIN
392 Parameters: ( <channel> *( "," <channel> ) [ <key> *( "," <key> ) ] )
394 The JOIN command is used by a user to request to start listening to the specific channel. Servers MUST be able to parse arguments in the form of a list of target, but MUST NOT use lists when sending JOIN messages to clients.
395 Once a user has joined a channel, he receives information about all commands his server receives affecting the channel. This includes JOIN, MODE, KICK, PART, QUIT and of course PRIVMSG/NOTICE.
396 This allows channel members to keep track of the other channel members, as well as channel modes.
397 If a JOIN is successful, the user receives a JOIN message as confirmation and is then sent the channel's topic (using RPL_TOPIC) and the list of users who are on the channel (using RPL_NAMREPLY), which MUST include the user joining.
400 Numeric Replies:
401 ERR_NEEDMOREPARAMS
402 ERR_BANNEDFROMCHAN
403 ERR_INVITEONLYCHAN
404 ERR_BADCHANNELKEY
405 ERR_BADCHANNAME
406 ERR_CHANNELISFULL
407 ERR_BADCHANMASK
408 ERR_NOSUCHCHANNEL
409 ERR_TOOMANYCHANNELS
410 ERR_TOOMANYTARGETS
411 ERR_UNAVAILRESOURCE
412 RPL_TOPIC
413 RPL_TOPICWHOTIME
415 Examples:
416 JOIN #foobar
417 Command to join channel #foobar.
418 JOIN &foo fubar
419 Command to join channel &foo using key "fubar".
420 JOIN #foo,&bar fubar
421 Command to join channel #foo using key "fubar" and &bar using no key.
422 JOIN #foo,#bar fubar,foobar
423 Command to join channel #foo using key "fubar", and channel #bar using key "foobar".
424 JOIN #foo,#bar
425 Command to join channels #foo and #bar.
426 :WiZ!jto@tolsun.oulu.fi JOIN #Twilight_zone
427 JOIN message from WiZ on channel #Twilight_zone
429 3.2.2 Part message
431 Command: PART
432 Parameters: <channel> *( "," <channel> ) [ <Part Message> ]
434 The PART command causes the user sending the message to be removed from the list of active members for all given channels listed in the parameter string. If a "Part Message" is given, this will be sent instead of the default message.
435 This request is always granted by the server.
436 Servers MUST be able to parse arguments in the form of a list of targets, separated by a comma (‘,’), but MUST NOT use lists when sending PART messages to clients.
437 Numeric Replies:
438 ERR_NEEDMOREPARAMS
439 ERR_NOSUCHCHANNEL
440 ERR_NOTONCHANNEL
442 Examples:
443 PART #twilight_zone
444 Command to leave channel "#twilight_zone"
445 PART #oz-ops,&group5
446 Command to leave both channels "&group5" and "#oz-ops".
447 :WiZ!jto@tolsun.oulu.fi PART #playzone :I lost
448 User WiZ leaving channel "#playzone" with the message "I lost".
450 3.2.3 Channel mode message
452 Command: MODE
453 Parameters: <channel> *( ( "-" / "+" ) *<modes> *<modeparams> )
455 The MODE command is provided so that users may query and change the characteristics of a channel. For more details on available modes and their uses, see "Internet Relay Chat: Channel Management" [IRC-CHAN]. Note that there is a maximum limit of three (3) FIXME changes per command for modes that take a parameter.
457 If no modes are given, the server will return the simple modes and channel TS (if supported) for the channel.
459 Numeric Replies:
460 ERR_NEEDMOREPARAMS
461 ERR_KEYSET
462 ERR_NOCHANMODES
463 ERR_BADCHANNAME
464 ERR_CHANOPRIVSNEEDED
465 ERR_USERNOTINCHANNEL
466 ERR_UNKNOWNMODE
467 RPL_CHANNELMODEIS
468 RPL_CREATIONTIME
469 RPL_BANLIST
470 RPL_ENDOFBANLIST
471 RPL_EXCEPTLIST
472 RPL_ENDOFEXCEPTLIST
473 RPL_INVITELIST
474 RPL_ENDOFINVITELIST
475 RPL_UNIQOPIS
476 The following examples are given to help understanding the syntax of the MODE command, but refer to modes defined in "Internet Relay Chat: Channel Management" [IRC-CHAN].
477 Examples:
478 MODE #Finnish +imI *!*@*.fi
479 Command to make #Finnish channel moderated and 'invite-only' with user with a hostname matching *.fi automatically invited.
480 MODE #Finnish +o Kilroy
481 Command to give channel operator privileges to Kilroy on channel #Finnish.
482 MODE #Finnish +v Wiz
483 Command to allow WiZ to speak on #Finnish.
484 MODE #Fins -s
485 Command to remove 'secret' flag from channel #Fins.
486 MODE #42 +k ouluc
487 Command to set the channel key to "oulu".
488 MODE #42 -k oulu
489 Command to remove the "oulu" channel key on channel "#42".
490 MODE #eu-opers +l 10; Command to set the limit for the number of users on channel "#eu-opers" to 10.
491 :WiZ!jto@tolsun.oulu.fi MODE #eu-opers -l
492 User "WiZ" removing the limit for the number of users on channel "#eu-opers".
493 MODE &oulu +b
494 Command to list ban masks set for the channel "&oulu".
495 MODE &oulu +b *!*@*
496 Command to prevent all users from joining.
497 MODE &oulu +b *!*@*.edu +e *!*@*.bu.edu
498 Command to prevent any user from a hostname matching *.edu from joining, except if matching *.bu.edu
499 MODE #bu +be *!*@*.edu *!*@*.bu.edu
500 Command to prevent any user from a hostname matching *.edu from joining, except if matching *.bu.edu
501 MODE #meditation e
502 Command to list exception masks set for the channel "#meditation".
503 MODE #meditation I
504 Command to list invitations masks set for the channel "#meditation".
505 MODE #chatspike +beI
506 Command to list bans, excecption masks and invite exception masks for the channel “#chatspike”
507 3.2.4 Topic message
509 Command: TOPIC
510 Parameters: <channel> [ <topic> ]
512 The TOPIC command is used to change or view the topic of a channel.
513 The topic for channel <channel> is returned if there is no <topic>
514 given. If the <topic> parameter is present, the topic for that
515 channel will be changed, if this action is allowed for the user
516 requesting it. If the <topic> parameter is an empty string, the
517 topic for that channel will be removed.
519 Numeric Replies:
521 RPL_NOTOPIC RPL_TOPIC
522 RPL_TOPICWHOTIME
523 ERR_NEEDMOREPARAMS ERR_NOTONCHANNEL
524 ERR_CHANOPRIVSNEEDED ERR_NOCHANMODES
526 Examples:
528 :WiZ!jto@tolsun.oulu.fi TOPIC #test :New topic ; User Wiz setting the
529 topic.
531 :irc2.example.net TOPIC #test :A topic ; Server irc2.example.net restoring the topic after a split.
533 TOPIC #test :another topic; Command to set the topic on #test
534 to "another topic".
536 TOPIC #test : ; Command to clear the topic on
537 #test.
539 TOPIC #test; Command to check the topic for
540 #test.
542 3.2.5 Names message
544 Command: NAMES
545 Parameters: [ <channel> ]
547 By using the NAMES command, a user can list all nicknames that are
548 visible to him. For more details on what is visible and what is not,
549 see "Internet Relay Chat: Channel Management" [IRC-CHAN]. The
550 <channel> parameter specifies which channel(s) to return information
551 about. There is no error reply for bad channel names.
553 If no <channel> parameter is given, a list of all channels and their
554 occupants MAY be returned. At the end of this list, all users who
555 are visible but either not on any channel or not on a visible channel
556 MAY be listed as being on `channel' "*".
558 Numerics:
560 ERR_TOOMANYMATCHES ERR_NOSUCHSERVER
561 RPL_NAMREPLY RPL_ENDOFNAMES
563 Examples:
565 NAMES #twilight_zone,#42 ; Command to list visible users on
566 #twilight_zone and #42
568 NAMES; Command to list all visible
569 channels and users
571 3.2.6 List message
573 Command: LIST
574 Parameters: [ <channel> ]
576 The list command is used to list channels and their topics. If the
577 <channel> parameter is used, only the status of that channel is
578 displayed.
580 Numeric Replies:
582 ERR_TOOMANYMATCHES ERR_NOSUCHSERVER
583 RPL_LIST RPL_LISTEND
585 Examples:
587 LIST ; Command to list a server-defined default selection of channels.
589 LIST #twilight_zone,#42; Command to list channels
590 #twilight_zone and #42
592 3.2.7 Invite message
594 Command: INVITE
595 Parameters: <nickname> <channel>
597 The INVITE command is used to invite a user to a channel. The
598 parameter <nickname> is the nickname of the person to be invited to
599 the target channel <channel>. Servers SHOULD NOT allow invites to
600 nonexistent channels and MUST NOT allow invites to existing channels
601 from users who are not members of the channel. See the channel management
602 document [IRC-CHAN] for more details on what is allowed and the exact effects.
604 Only the user inviting and the user being invited will receive
605 notification of the invitation. Other channel members are not
606 notified. (This is unlike the MODE changes, and is occasionally the
607 source of trouble for users.)
609 Numeric Replies:
611 ERR_NEEDMOREPARAMS ERR_NOSUCHNICK
612 ERR_NOTONCHANNEL ERR_USERONCHANNEL
613 ERR_CHANOPRIVSNEEDED
614 RPL_INVITING RPL_AWAY
616 Examples:
618 :Angel!wings@irc.org INVITE Wiz #Dust
620 ; Message to WiZ when he has been
621 invited by user Angel to channel
622 #Dust
624 INVITE Wiz #Twilight_Zone ; Command to invite WiZ to
625 #Twilight_zone
627 3.2.8 Kick command
629 Command: KICK
630 Parameters: <channel> <nick> [<comment>]
632 The KICK command can be used to request the forced removal of a user
633 from a channel. It causes the <user> to PART from the <channel> by
634 force. If a "comment" is given, this will be sent instead of the
635 default message.
637 Numeric Replies:
639 ERR_NEEDMOREPARAMS ERR_NOSUCHCHANNEL
640 ERR_BADCHANMASK ERR_CHANOPRIVSNEEDED
641 ERR_USERNOTINCHANNEL ERR_NOTONCHANNEL
643 Examples:
645 KICK &Melbourne Matthew; Command to kick Matthew from
646 &Melbourne
648 KICK #Finnish John :Speaking English
649 ; Command to kick John from #Finnish
650 using "Speaking English" as the
651 reason (comment).
653 :WiZ!jto@tolsun.oulu.fi KICK #Finnish John
654 ; KICK message on channel #Finnish
655 from WiZ to remove John from channel
657 :irc.example.net KICK #secret John :Net Rider
658 ; Server irc.example.net kicking user
659 who appears to be abusing a network split
661 3.3 Sending messages
663 The main purpose of the IRC protocol is to provide a base for clients
664 to communicate with each other. PRIVMSG and NOTICE are the only
665 messages available which actually perform delivery of a text message
666 from one client to another - the rest just make it possible and try
667 to ensure it happens in a reliable and structured manner.
669 3.3.1 Private messages
671 Command: PRIVMSG
672 Parameters: <msgto> *( "," <msgto> ) <text to be sent>
674 PRIVMSG is used to send private messages between users, as well as to
675 send messages to channels. <msgto> is usually the nickname of
676 the recipient of the message, a channel name or a particular status (e.g. "@")
677 on a channel which sends to all users with that status or higher.
679 Directed messages (<directedmsg> BNF) are sent to a user or users on the given server. This document does not specify how this is determined. In particular, a server MAY not allow any message of this type at all, or conversely a server MAY require directed messages to send to certain clients.
681 For operators, the <msgtarget> parameter may also be a host mask or server mask. The syntax is not specified here but must follow the <targetmask> BNF. The server will send the PRIVMSG to those who have a server or host matching the mask. The server MAY require that the mask have at least 1 (one) "." in it and no wildcards following the last ".", to prevent people broadcasting messages to all users. Wildcards are the '*' and '?' characters.
683 Messages to the special target '*' may only be sent by servers. This is useful to send the exact same message to a group of users which cannot be described by another <msgto>, for example all users receiving a certain kind of server notice.
685 Servers MAY limit the number of recipients in a PRIVMSG and SHOULD NOT process duplicate recipients.
687 Numeric Replies:
689 ERR_NORECIPIENT ERR_NOTEXTTOSEND
690 ERR_CANNOTSENDTOCHAN ERR_NOTOPLEVEL
691 ERR_WILDTOPLEVEL ERR_TOOMANYTARGETS
692 ERR_NOSUCHNICK
693 RPL_AWAY
695 Examples:
697 :Angel!wings@irc.org PRIVMSG Wiz :Are you receiving this message ?
698 ; Message from Angel to Wiz.
700 PRIVMSG Angel :yes I'm receiving it !
701 ; Command to send a message to Angel.
703 PRIVMSG #chat :hi there
704 ; Command to send a message to channel #chat.
706 PRIVMSG jto@tolsun.oulu.fi :Hello !
707 ; Command to send a message to some user
708 on server tolsun.oulu.fi identified
709 by "jto".
711 3.3.2 Notice
713 Command: NOTICE
714 Parameters: <msgto> *( "," <msgto> ) <text>
716 The NOTICE command is used similarly to PRIVMSG. The difference
717 between NOTICE and PRIVMSG is that automatic replies MUST NEVER be
718 sent in response to a NOTICE message. This rule applies to servers
719 too - they MUST NOT send any error reply back to the client on
720 receipt of a notice. The object of this rule is to avoid loops
721 between clients automatically sending something in response to
722 something they received.
724 This is typically used by servers and automata (clients with either an AI or other interactive program controlling their actions).
726 Servers MAY limit the number of recipients in a NOTICE and SHOULD NOT process duplicate recipients.
728 See PRIVMSG for more details on replies and examples.
730 NOTICE $*.fi :{*.fi} Server tolsun.oulu.fi rebooting.
731 ; Some sort of global message.
733 :irc.example.net NOTICE * :*** Notice -- No response from irc2.example.net, closing link
734 ; Server notifying operators of a ping timeout on a server link.
736 3.4 Server queries and commands
738 The server query group of commands has been designed to return
739 information about any server which is connected to the network.
741 In these queries, where a parameter appears as <target>, wildcard
742 masks are usually valid. For each parameter, however, only one query
743 and set of replies is to be generated. In most cases, if a nickname
744 is given, it will mean the server to which the user is connected.
746 3.3.3 Wallops message
748 Command: WALLOPS
749 Parameters: <Text to be sent>
751 The WALLOPS command is used to send a message to all currently connected users who have set the 'w' user mode for themselves. (See Section 3.1.5 "User modes").
753 Numeric Replies:
755 ERR_NEEDMOREPARAMS
757 Example:
759 :csd.bu.edu WALLOPS :Connect '*.uiuc.edu 6667' from Joshua
760 WALLOPS message from csd.bu.edu announcing a CONNECT message it received from Joshua and acted upon.
762 3.4.1 Motd message
764 Command: MOTD
765 Parameters: [ <target> ]
767 The MOTD command is used to get the "Message Of The Day" of the given
768 server, or current server if <target> is omitted.
770 Wildcards are allowed in the <target> parameter.
772 Numeric Replies:
773 RPL_MOTDSTART RPL_MOTD
774 RPL_ENDOFMOTD ERR_NOMOTD
776 3.4.2 Lusers message
778 Command: LUSERS
779 Parameters: [ <mask> [ <target> ] ]
781 The LUSERS command is used to get statistics about the size of the
782 IRC network. If no parameter is given, the reply will be about the
783 whole net. If a <mask> is specified, then the reply MAY only
784 concern the part of the network formed by the servers matching the
785 mask, but it MAY also be about the whole net. Finally, if the
786 <target> parameter is specified, the request is forwarded to that
787 server which will generate the reply.
789 Wildcards are allowed in the <target> parameter.
791 Numeric Replies:
793 RPL_LUSERCLIENT RPL_LUSEROP
794 RPL_LUSERUNKNOWN RPL_LUSERCHANNELS
795 RPL_LUSERME ERR_NOSUCHSERVER
797 3.4.3 Version message
799 Command: VERSION
800 Parameters: [ <target> ]
802 The VERSION command is used to query the version of the server
803 program. An optional parameter <target> is used to query the version
804 of the server program which a client is not directly connected to.
806 Wildcards are allowed in the <target> parameter.
808 Numeric Replies:
810 ERR_NOSUCHSERVER RPL_VERSION
812 Examples:
814 VERSION tolsun.oulu.fi ; Command to check the version of
815 server "tolsun.oulu.fi".
817 3.4.4 Stats message
819 Command: STATS
820 Parameters: <query> [ <target> ]
822 The stats command is used to query statistics of certain server.
824 A query may be given for any single letter which is only checked by
825 the destination server and is otherwise passed on by intermediate
826 servers, ignored and unaltered.
828 Wildcards are allowed in the <target> parameter.
830 Except for the ones below, the list of valid queries is
831 implementation dependent. The standard queries below SHOULD be
832 supported by the server:
834 l - returns a list of the server's connections, showing how
835 long each connection has been established and the
836 traffic over that connection in Kbytes and messages for
837 each direction;
838 m - returns the usage count for each of commands supported
839 by the server; commands for which the usage count is
840 zero MAY be omitted;
841 o - returns a list of configured privileged users,
842 operators;
843 u - returns a string showing how long the server has been
844 up.
846 It is also RECOMMENDED that client and server access configuration be
847 published this way.
849 Numeric Replies:
851 ERR_NOSUCHSERVER
852 RPL_STATSLINKINFO RPL_STATSUPTIME
853 RPL_STATSCOMMANDS RPL_STATSOLINE
854 RPL_ENDOFSTATS
856 Examples:
858 STATS m ; Command to check the command usage
859 for the server you are connected to
861 3.4.5 Links message
863 Command: LINKS
864 Parameters: [ [ <remote server> ] <server mask> ]
866 With LINKS, a user can list all servernames, which are known by the
867 server answering the query. The returned list of servers MUST match
868 the mask, or if no mask is given, the full list is returned.
870 If <remote server> is given in addition to <server mask>, the LINKS
871 command is forwarded to the first server found that matches that name
872 (if any), and that server is then required to answer the query.
874 Numeric Replies:
876 ERR_NOSUCHSERVER
877 RPL_LINKS RPL_ENDOFLINKS
879 Examples:
881 LINKS *.au ; Command to list all servers which
882 have a name that matches *.au;
884 LINKS *.edu *.bu.edu; Command to list servers matching
885 *.bu.edu as seen by the first server
886 matching *.edu.
888 3.4.6 Time message
890 Command: TIME
891 Parameters: [ <target> ]
893 The time command is used to query local time from the specified
894 server. If the <target> parameter is not given, the server receiving
895 the command must reply to the query.
897 Wildcards are allowed in the <target> parameter.
899 Numeric Replies:
901 ERR_NOSUCHSERVER RPL_TIME
903 Examples:
904 TIME tolsun.oulu.fi ; check the time on the server
905 "tolson.oulu.fi"
907 3.4.7 Connect message
909 Command: CONNECT
910 Parameters: <target server> <port> [ <remote server> ]
912 The CONNECT command can be used to request a server to try to
913 establish a new connection to another server immediately. CONNECT is
914 a privileged command and SHOULD be available only to IRC Operators.
915 If a <remote server> is given and its mask doesn't match name of the
916 parsing server, the CONNECT attempt is sent to the first match of
917 remote server. Otherwise the CONNECT attempt is made by the server
918 processing the request.
920 The server receiving a remote CONNECT command SHOULD generate a
921 WALLOPS message describing the source and target of the request.
923 Numeric Replies:
925 ERR_NOSUCHSERVER ERR_NOPRIVILEGES
926 ERR_NEEDMOREPARAMS
928 Examples:
930 CONNECT tolsun.oulu.fi 6667 ; Command to attempt to connect local
931 server to tolsun.oulu.fi on port 6667
933 3.4.8 Trace message
935 Command: TRACE
936 Parameters: [ <target> ]
938 TRACE command is used to find the route to specific server and
939 information about its peers. Each server that processes this command
940 MUST report to the sender about it. The replies from pass-through
941 links form a chain, which shows route to destination. After sending
942 this reply back, the query MUST be sent to the next server until
943 given <target> server is reached.
945 TRACE command is used to find the route to specific server. Each
946 server that processes this message MUST tell the sender about it by
947 sending a reply indicating it is a pass-through link, forming a chain
948 of replies. After sending this reply back, it MUST then send the
949 TRACE message to the next server until given server is reached. If
950 the <target> parameter is omitted, it is RECOMMENDED that TRACE
951 command sends a message to the sender telling which servers the local
952 server has direct connection to.
954 If the destination given by <target> is an actual server, the
955 destination server is REQUIRED to report all servers and
956 operators which are connected to it; if the command was issued by an
957 operator, the server MAY also report all users which are connected to
958 it. If the destination given by <target> is a nickname, then only a
959 reply for that nickname is given. If the <target> parameter is
960 omitted, it is RECOMMENDED that the TRACE command is parsed as
961 targeted to the processing server.
963 Wildcards are allowed in the <target> parameter.
965 Numeric Replies:
967 ERR_NOSUCHSERVER
969 If the TRACE message is destined for another server, all
970 intermediate servers must return a RPL_TRACELINK reply to indicate
971 that the TRACE passed through it and where it is going next.
973 RPL_TRACELINK
975 A TRACE reply may be composed of any number of the following
976 numeric replies.
978 RPL_TRACECONNECTING RPL_TRACEHANDSHAKE
979 RPL_TRACEUNKNOWN RPL_TRACEOPERATOR
980 RPL_TRACEUSER RPL_TRACESERVER
981 RPL_TRACESERVICE RPL_TRACENEWTYPE
982 RPL_TRACECLASS RPL_TRACELOG
983 RPL_TRACEEND
985 Examples:
987 TRACE *.oulu.fi ; TRACE to a server matching
988 *.oulu.fi
990 3.4.9 Admin command
992 Command: ADMIN
993 Parameters: [ <target> ]
995 The admin command is used to find information about the administrator
996 of the given server, or current server if <target> parameter is
997 omitted. Each server MUST have the ability to forward ADMIN messages
998 to other servers.
1000 Wildcards are allowed in the <target> parameter.
1002 Numeric Replies:
1004 ERR_NOSUCHSERVER ERR_NOADMININFO
1005 RPL_ADMINME RPL_ADMINLOC1
1006 RPL_ADMINLOC2 RPL_ADMINEMAIL
1008 Examples:
1010 ADMIN tolsun.oulu.fi; request an ADMIN reply from
1011 tolsun.oulu.fi
1013 ADMIN syrk ; ADMIN request for the server to
1014 which the user syrk is connected
1016 3.4.10 Info command
1018 Command: INFO
1019 Parameters: [ <target> ]
1021 The INFO command is REQUIRED to return information describing the
1022 server: its version, when it was compiled, the patchlevel, when it
1023 was started, and any other miscellaneous information which may be
1024 considered to be relevant.
1026 Wildcards are allowed in the <target> parameter.
1028 Numeric Replies:
1030 ERR_NOSUCHSERVER
1031 RPL_INFO RPL_ENDOFINFO
1033 Examples:
1035 INFO csd.bu.edu ; request an INFO reply from
1036 csd.bu.edu
1038 INFO Angel ; request info from the server that
1039 Angel is connected to.
1041 3.6 User based queries
1043 User queries are a group of commands which are primarily concerned
1044 with finding details on a particular user or group users. When using
1045 wildcards with any of these commands, if they match, they will only
1046 return information on users who are 'visible' to you. The visibility
1047 of a user is determined as a combination of the user's mode and the
1048 common set of channels you are both on.
1050 3.6.1 Who query
1052 Command: WHO
1053 Parameters: <mask> [ "o" ]
1055 The WHO command is used by a client to generate a query which returns
1056 a list of information which 'matches' the <mask> parameter given by
1057 the client.
1059 The <mask> passed to WHO is matched against users' host, server, real
1060 name and nickname if the channel <mask> cannot be found.
1062 If the "o" parameter is passed only operators are returned according
1063 to the <mask> supplied.
1065 Numeric Replies:
1067 RPL_WHOREPLY
1068 RPL_ENDOFWHO
1070 Examples:
1072 WHO *.fi; Command to list all users who match
1073 against "*.fi".
1075 WHO jto* o ; Command to list all users with a
1076 match against "jto*" if they are an
1077 operator.
1079 3.6.2 Whois query
1081 Command: WHOIS
1082 Parameters: [ <target> ] <nick>
1084 This command is used to query information about particular user.
1085 The server will answer this command with several numeric messages
1086 indicating different statuses of the user (if the nick is in use).
1088 If the <target> parameter is specified, it sends the query to a
1089 specific server. It is useful if you want to know how long the user
1090 in question has been idle as only local server (i.e., the server the
1091 user is directly connected to) knows that information, while
1092 everything else is globally known.
1094 Wildcards are allowed in the <target> parameter.
1096 Numeric Replies:
1098 ERR_NOSUCHSERVER ERR_NONICKNAMEGIVEN
1099 RPL_WHOISUSER RPL_WHOISCHANNELS
1100 RPL_WHOISCHANNELS RPL_WHOISSERVER
1101 RPL_AWAY RPL_WHOISOPERATOR
1102 RPL_WHOISIDLE ERR_NOSUCHNICK
1103 RPL_ENDOFWHOIS
1105 Examples:
1107 WHOIS WiZ ; return available user information
1108 about nick WiZ
1110 WHOIS WiZ WiZ ; return available user information
1111 about nick WiZ including idle time
1113 WHOIS eff.org trillian ; ask server eff.org for user
1114 information about trillian
1116 3.6.3 Whowas
1118 Command: WHOWAS
1119 Parameters: <nickname> [ <count> ]
1121 Whowas asks for information about a nickname which no longer exists.
1122 This may either be due to a nickname change or the user leaving IRC.
1123 In response to this query, the server searches through its nickname
1124 history, looking for any nicks which are lexically the same (no wild
1125 card matching here). The history is searched backward, returning the
1126 most recent entry first. If there are multiple entries, up to
1127 <count> replies will be returned (or all of them if no <count>
1128 parameter is given). If a non-positive number is passed as being
1129 <count>, then a full search is done.
1131 Numeric Replies:
1133 ERR_NONICKNAMEGIVEN ERR_WASNOSUCHNICK
1134 RPL_WHOWASUSER RPL_WHOISSERVER
1135 RPL_ENDOFWHOWAS
1137 Examples:
1139 WHOWAS Wiz ; return all information in the nick
1140 history about nick "WiZ";
1142 WHOWAS Mermaid 9 ; return at most, the 9 most recent
1143 entries in the nick history for
1144 "Mermaid";
1146 3.6.4 Userhost message
1148 Command: USERHOST
1149 Parameters: <nickname> *( SPACE <nickname> )
1151 The USERHOST command takes up to 5 nicknames (each as a separate parameter) and returns a list of information about each nickname that it found. The returned list has each reply separated by a space.
1153 If and only if the reply would exceed the maximum line length, the server MUST omit the last nick (or more, if it still does not fit). The client cannot distinguish this from nonexistent nicks, so it SHOULD take this occurence into account and send fewer nicks if it could occur.
1155 If the client is querying its own nick, the server MAY send the client's IP address instead of its hostname.
1157 Numeric Replies:
1159 RPL_USERHOST ERR_NEEDMOREPARAMS
1161 Example:
1162 USERHOST Wiz Michael syrk ; USERHOST request for information on
1163 nicks "Wiz", "Michael", and "syrk"
1164 :ircd.stealth.net 302 yournick :syrk=+syrk@millennium.stealth.net
1165 ; Reply for user syrk
1167 3.6.5 Ison message
1169 Command: ISON
1170 Parameters: <nickname> *( SPACE <nickname> )
1172 The ISON command was implemented to provide a quick and efficient means to get a response about whether a given nickname was currently on IRC. ISON only takes one (1) type of parameter: a space-separated list of nicks. For each nickname in the list that is present, the server adds that to its reply string. Thus the reply string may return empty (none of the given nicks are present), an exact copy of the parameter string (all of them present) or any other subset of the set of nicks given in the parameter. The only limit on the number of nicks that may be checked is that the combined length MUST NOT be too large as to cause the server to chop it off so it fits in 512 characters.
1174 The nicks may be sent in one parameter or in multiple parameters; in the latter case the MAXPARA limit applies.
1176 ISON is only processed by the server local to the client sending the command and thus not passed onto other servers for further processing.
1178 Numeric Replies:
1180 RPL_ISON ERR_NEEDMOREPARAMS
1182 Example:
1184 ISON phone trillian WiZ jarlek Avalon Angel Monstah syrk
1185 ; Sample ISON request for 7 nicks.
1187 3.7 Miscellaneous messages
1189 Messages in this category do not fit into any of the above categories
1190 but are nonetheless still a part of and REQUIRED by the protocol.
1192 3.7.1 Kill message
1194 Command: KILL
1195 Parameters: <nickname> <comment>
1197 The KILL command is used to cause a client-server connection to be
1198 closed by the server which has the actual connection. Servers
1199 generate KILL messages on nickname collisions. It MAY also be
1200 available available to users who have the operator status.
1202 Clients which have automatic reconnect algorithms effectively make
1203 this command useless since the disconnection is only brief. It does
1204 however break the flow of data and can be used to stop large amounts
1205 of 'flooding' from abusive users or accidents. Abusive users usually
1206 don't care as they will reconnect promptly and resume their abusive
1207 behaviour. To prevent this command from being abused, any user may
1208 elect to receive KILL messages generated for others to keep an 'eye'
1209 on would be trouble spots.
1211 In an arena where nicknames are REQUIRED to be globally unique at all
1212 times, KILL messages are sent whenever 'duplicates' are detected
1213 (that is an attempt to register two users with the same nickname) in
1214 the hope that both of them will disappear and only 1 reappear.
1216 When a client is removed as the result of a KILL message, the server
1217 SHOULD add the nickname to the list of unavailable nicknames in an
1218 attempt to avoid clients to reuse this name immediately which is
1219 usually the pattern of abusive behaviour often leading to useless
1220 "KILL loops". See the "IRC Server Protocol" document [IRC-SERVER]
1221 for more information on this procedure.
1223 The comment given MUST reflect the actual reason for the KILL. For
1224 server-generated KILLs it usually is made up of details concerning
1225 the origins of the two conflicting nicknames. For users it is left
1226 up to them to provide an adequate reason to satisfy others who see
1227 it. To prevent/discourage fake KILLs from being generated to hide
1228 the identify of the KILLer, the comment also shows a 'kill-path'
1229 which is updated by each server it passes through, each prepending
1230 its name to the path.
1232 Numeric Replies:
1234 ERR_NOPRIVILEGES ERR_NEEDMOREPARAMS
1235 ERR_NOSUCHNICK ERR_CANTKILLSERVER
1237 NOTE:
1238 It is RECOMMENDED that only Operators be allowed to kill other users
1239 with KILL command. This command has been the subject of many
1240 controversies over the years, and along with the above
1241 recommendation, it is also widely recognized that not even operators
1242 should be allowed to kill users on remote servers.
1244 3.7.2 Ping message
1246 Command: PING
1247 Parameters: <server1> [ <server2> ]
1249 The PING command is used to test the presence of an active client or
1250 server at the other end of the connection. Servers send a PING
1251 message at regular intervals if no other activity detected coming
1252 from a connection. If a connection fails to respond to a PING
1253 message within a set amount of time, that connection is closed. A
1254 PING message MAY be sent even if the connection is active.
1256 When a PING message is received, the appropriate PONG message MUST be
1257 sent as reply to <server1> (server which sent the PING message out)
1258 as soon as possible. If the <server2> parameter is specified, it
1259 represents the target of the ping, and the message gets forwarded
1260 there.
1262 Numeric Replies:
1264 ERR_NOORIGIN ERR_NOSUCHSERVER
1266 Examples:
1268 PING tolsun.oulu.fi ; Command to send a PING message to
1269 server
1271 PING WiZ tolsun.oulu.fi; Command from WiZ to send a PING
1272 message to server "tolsun.oulu.fi"
1274 PING :irc.funet.fi ; Ping message sent by server
1275 "irc.funet.fi"
1277 3.7.3 Pong message
1279 Command: PONG
1280 Parameters: <server> [ <server2> ]
1282 PONG message is a reply to ping message. If parameter <server2> is
1283 given, this message MUST be forwarded to given target. The <server>
1284 parameter is the name of the entity who has responded to PING message
1285 and generated this message.
1287 Numeric Replies:
1289 ERR_NOORIGIN ERR_NOSUCHSERVER
1291 Example:
1293 PONG csd.bu.edu tolsun.oulu.fi ; PONG message from csd.bu.edu to
1294 tolsun.oulu.fi
1296 3.7.4 Error
1298 Command: ERROR
1299 Parameters: <error message>
1301 The ERROR command is for use by servers when reporting a serious or
1302 fatal error to its peers. It may also be sent from one server to
1303 another but MUST NOT be accepted from any normal unknown clients.
1305 Only an ERROR message SHOULD be used for reporting errors which occur
1306 with a server-to-server link. An ERROR message is sent to the server
1307 at the other end (which reports it to appropriate local users and
1308 logs) and to appropriate local users and logs. It is not to be
1309 passed onto any other servers by a server if it is received from a
1310 server.
1312 The ERROR message is also used before terminating a client
1313 connection.
1315 When a server sends a received ERROR message to its operators, the
1316 message SHOULD be encapsulated inside a NOTICE message, indicating
1317 that the client was not responsible for the error.
1319 Numerics:
1321 None.
1323 Examples:
1325 ERROR :Server *.fi already exists ; ERROR message to the other server
1326 which caused this error.
1328 NOTICE WiZ :ERROR from csd.bu.edu -- Server *.fi already exists
1329 ; Same ERROR message as above but
1330 sent to user WiZ on the other server.
1332 4. Optional features
1334 This section describes OPTIONAL messages. They are not required in a working server implementation of the protocol described herein.
1336 4.1 Rehash message
1338 Command: REHASH
1339 Parameters: None
1341 The rehash command is an administrative command which can be used by an operator to force the server to re-read and process its configuration file.
1343 Numeric Replies:
1345 RPL_REHASHING ERR_NOPRIVILEGES
1347 Example:
1349 REHASH ; message from user with operator
1350 status to server asking it to reread
1351 its configuration file.
1353 4.2 Die message
1355 Command: DIE
1356 Parameters: None
1358 An operator can use the DIE command to shutdown the server. This message is optional since it may be viewed as a risk to allow arbitrary people to connect to a server as an operator and execute this command.
1359 Numeric Replies:
1361 ERR_NOPRIVILEGES
1363 Example:
1365 DIE ; no parameters required.
1367 4.3 Restart message
1369 Command: RESTART
1370 Parameters: None
1372 An operator can use the restart command to force the server to restart itself. This message is optional since it may be viewed as a risk to allow arbitrary people to connect to a server as an operator and execute this command, causing (at least) a disruption to service.
1373 Numeric Replies:
1375 ERR_NOPRIVILEGES
1377 Example:
1379 RESTART ; no parameters required.
1381 5. Replies
1383 The following is a list of numeric replies which are generated in response to the commands given above. Each numeric is given with its number, name and reply string.
1385 5.1 Command responses
1387 Numerics in the range from 001 to 099 are used for client-server connections only and should never travel between servers. Replies generated in the response to commands are found in the range from 200 to 399.
1389 001 RPL_WELCOME
1390 "Welcome to the Internet Relay Network
1391 <nick>!<user>@<host>"
1392 002 RPL_YOURHOST
1393 "Your host is <servername>, running version <ver>"
1394 003 RPL_CREATED
1395 "This server was created <date>"
1396 004 RPL_MYINFO
1397 "<servername> <version> <available user modes>
1398 <available channel modes>"
1400 - The server sends Replies 001 to 004 to a user upon
1401 successful registration.
1403 005 RPL_ISUPPORT
1404 see isupport in BNF
1406 - Sent upon successful registration, somewhere after
1407 RPL_MYINFO, and possibly when the information changes.
1409 010 RPL_BOUNCE
1410 "<server name> <port number> :Please use this Server/Port instead"
1411 "Try server <server name>, port <port number>"
1413 - Sent by the server to a user to suggest an alternative
1414 server. This is often used when the connection is
1415 refused because the server is already full.
1417 302 RPL_USERHOST
1418 ":*1<reply> *( " " <reply> )"
1420 - Reply format used by USERHOST to list replies to
1421 the query list. The reply string is composed as
1422 follows:
1424 reply = nickname [ "*" ] "=" ( "+" / "-" ) user "@" hostname
1426 The '*' indicates whether the client has registered
1427 as an Operator. The '-' or '+' characters represent
1428 whether the client has set an AWAY message or not
1429 respectively.
1431 303 RPL_ISON
1432 ":*1<nick> *( " " <nick> )"
1434 - Reply format used by ISON to list replies to the
1435 query list.
1437 301 RPL_AWAY
1438 "<nick> :<away message>"
1439 305 RPL_UNAWAY
1440 ":You are no longer marked as being away"
1441 306 RPL_NOWAWAY
1442 ":You have been marked as being away"
1444 - These replies are used with the AWAY command (if
1445 allowed). RPL_AWAY is sent to any client sending a
1446 PRIVMSG or INVITE to a client which is away. RPL_AWAY
1447 is only sent by the server to which the client is
1448 connected. RPL_AWAY is also sent in a WHOIS reply.
1449 Replies RPL_UNAWAY and RPL_NOWAWAY are sent when the
1450 client removes and sets an AWAY message.
1452 311 RPL_WHOISUSER
1453 "<nick> <user> <host> * :<real name>"
1454 312 RPL_WHOISSERVER
1455 "<nick> <server> :<server info>"
1456 313 RPL_WHOISOPERATOR
1457 "<nick> :is an IRC operator"
1459 317 RPL_WHOISIDLE
1460 "<nick> <integer> <timestamp> :seconds idle, signon time"
1461 "<nick> <integer> :seconds idle"
1462 318 RPL_ENDOFWHOIS
1463 "<nick> :End of WHOIS list"
1464 319 RPL_WHOISCHANNELS
1465 "<nick> :*( ( "@" / "+" ) <channel> " " )"
1467 - Replies 311 - 313, 317 - 319 are all replies
1468 generated in response to a WHOIS message. Given that
1469 there are enough parameters present, the answering
1470 server MUST either formulate a reply out of the above
1471 numerics (if the query nick is found) or return an
1472 error reply. The '*' in RPL_WHOISUSER is there as
1473 the literal character and not as a wild card. For
1474 each reply set, only RPL_WHOISCHANNELS may appear
1475 more than once (for long lists of channel names).
1476 The '@' and '+' characters next to the channel name
1477 indicate whether a client is a channel operator or
1478 has been granted permission to speak on a moderated
1479 channel. The RPL_ENDOFWHOIS reply is used to mark
1480 the end of processing a WHOIS message.
1482 RPL_WHOISIDLE has a current form with signon time
1483 and an obsolete form which SHOULD NOT be used.
1485 314 RPL_WHOWASUSER
1486 "<nick> <user> <host> * :<real name>"
1487 369 RPL_ENDOFWHOWAS
1488 "<nick> :End of WHOWAS"
1490 - When replying to a WHOWAS message, a server MUST use
1491 the replies RPL_WHOWASUSER, RPL_WHOISSERVER or
1492 ERR_WASNOSUCHNICK for each nickname in the presented
1493 list. At the end of all reply batches, there MUST
1494 be RPL_ENDOFWHOWAS (even if there was only one reply
1495 and it was an error).
1497 The server info in RPL_WHOISSERVER should be replaced
1498 by a human-readable representation of the date and time
1499 the user disconnected or changed nick. The time zone
1500 should be the same as in RPL_TIME.
1502 321 RPL_LISTSTART
1503 "Channel :Users Name"
1504 322 RPL_LIST
1505 "<channel> <integer> :<topic>"
1506 323 RPL_LISTEND
1507 ":End of LIST"
1509 - RPL_LISTSTART MAY be sent at the start of the list.
1510 Replies RPL_LIST, RPL_LISTEND mark the actual replies
1511 with data and end of the server's response to a LIST
1512 command. The number in RPL_LIST is the number of
1513 channel members. If there are no channels available
1514 to return, only the end reply MUST be sent.
1516 325 RPL_UNIQOPIS
1517 "<channel> <nickname>"
1519 324 RPL_CHANNELMODEIS
1520 "<channel> <mode> <mode params>"
1522 329 RPL_CREATIONTIME
1523 "<channel> <timestamp>"
1525 - RPL_CHANNELMODEIS is sent when querying the channel mode via MODE with
1526 just a channel name. If the user is not on the channel, the mode
1527 parameters MUST be either entirely omitted or masked as necessary
1528 to comply with the rules in the channel management document.
1529 If the server supports channel TS, it should send RPL_CREATIONTIME after
1530 RPL_CHANNELMODEIS, listing the channel's timestamp.
1531 See channel management document.
1533 331 RPL_NOTOPIC
1534 "<channel> :No topic is set"
1535 332 RPL_TOPIC
1536 "<channel> :<topic>"
1537 333 RPL_TOPICWHOTIME
1538 "<channel> <setter> <timestamp>"
1540 - When sending a TOPIC message to determine the
1541 channel topic, either a RPL_NOTOPIC reply is
1542 sent, or a RPL_TOPIC reply which SHOULD be
1543 followed by RPL_TOPICWHOTIME.
1545 341 RPL_INVITING
1546 "<channel> <nick>"
1548 - Returned by the server to indicate that the
1549 attempted INVITE message was successful and is
1550 being passed onto the end client.
1552 346 RPL_INVITELIST
1553 "<channel> <invitemask> <setter> <timestamp>"
1554 "<channel> <invitemask>"
1555 347 RPL_ENDOFINVITELIST
1556 "<channel> :End of channel invite list"
1558 - When listing the 'invitations masks' for a given channel,
1559 a server is required to send the list back using the
1560 RPL_INVITELIST and RPL_ENDOFINVITELIST messages. A
1561 separate RPL_INVITELIST is sent for each active mask,
1562 which SHOULD include the setter and timestamp.
1563 After the masks have been listed (or if none present) a
1564 RPL_ENDOFINVITELIST MUST be sent.
1566 348 RPL_EXCEPTLIST
1567 "<channel> <exceptionmask> <setter> <timestamp>"
1568 "<channel> <exceptionmask>"
1569 349 RPL_ENDOFEXCEPTLIST
1570 "<channel> :End of channel exception list"
1572 - When listing the 'exception masks' for a given channel,
1573 a server is required to send the list back using the
1574 RPL_EXCEPTLIST and RPL_ENDOFEXCEPTLIST messages. A
1575 separate RPL_EXCEPTLIST is sent for each active mask,
1576 which SHOULD include the setter and timestamp.
1577 After the masks have been listed (or if none present)
1578 a RPL_ENDOFEXCEPTLIST MUST be sent.
1580 351 RPL_VERSION
1581 "<version>.<debuglevel> <server> :<comments>"
1583 - Reply by the server showing its version details.
1584 The <version> is the version of the software being
1585 used (including any patchlevel revisions) and the
1586 <debuglevel> is used to indicate if the server is
1587 running in "debug mode".
1589 The "comments" field may contain any comments about
1590 the version or further version details.
1592 352 RPL_WHOREPLY
1593 "<channel> <user> <host> <server> <nick>
1594 ( "H" / "G" > ["*"] [ ( "@" / "+" ) ]
1595 :<hopcount> <real name>"
1597 315 RPL_ENDOFWHO
1598 "<name> :End of WHO list"
1600 - The RPL_WHOREPLY and RPL_ENDOFWHO pair are used
1601 to answer a WHO message. The RPL_WHOREPLY is only
1602 sent if there is an appropriate match to the WHO
1603 query. If there is a list of parameters supplied
1604 with a WHO message, a RPL_ENDOFWHO MUST be sent
1605 after processing each list item with <name> being
1606 the item.
1608 'H' (here) and 'G' (gone) indicate AWAY status.
1609 The '*' indicates IRC operator status; it SHOULD
1610 be consistent with the '*' in RPL_USERHOST, the
1611 presence or absence of RPL_WHOISOPERATOR in a WHOIS
1612 reply and the use of RPL_TRACEUSER or
1613 RPL_TRACEOPERATOR in a TRACE reply.
1614 '@' and '+' (or another PREFIX character) indicate
1615 status in the channel listed.
1617 353 RPL_NAMREPLY
1618 "( "=" / "*" / "@" ) <channel>
1619 :[ "@" / "+" ] <nick> *( " " [ "@" / "+" ] <nick> )
1620 - "@" is used for secret channels, "*" for private
1621 channels, and "=" for others (public channels).
1623 366 RPL_ENDOFNAMES
1624 "<channel> :End of NAMES list"
1626 - To reply to a NAMES message, a reply pair consisting
1627 of RPL_NAMREPLY and RPL_ENDOFNAMES is sent by the
1628 server back to the client. If there is no channel
1629 found as in the query, then only RPL_ENDOFNAMES is
1631 returned. The exception to this is when a NAMES
1632 message is sent with no parameters and all visible
1633 channels and contents are sent back in a series of
1634 RPL_NAMREPLY messages with a RPL_ENDOFNAMES to mark
1635 the end.
1637 364 RPL_LINKS
1638 "<mask> <server> :<hopcount> <server info>"
1639 365 RPL_ENDOFLINKS
1640 "<mask> :End of LINKS list"
1642 - In replying to the LINKS message, a server MUST send
1643 replies back using the RPL_LINKS numeric and mark the
1644 end of the list using an RPL_ENDOFLINKS reply.
1646 367 RPL_BANLIST
1647 "<channel> <banmask> <setter> <timestamp>"
1648 "<channel> <banmask>"
1649 368 RPL_ENDOFBANLIST
1650 "<channel> :End of channel ban list"
1652 - When listing the active 'bans' for a given channel,
1653 a server is required to send the list back using the
1654 RPL_BANLIST and RPL_ENDOFBANLIST messages. A separate
1655 RPL_BANLIST is sent for each active banmask, which
1656 SHOULD include the setter and timestamp. After the
1657 banmasks have been listed (or if none present) a
1658 RPL_ENDOFBANLIST MUST be sent.
1660 371 RPL_INFO
1661 ":<string>"
1662 374 RPL_ENDOFINFO
1663 ":End of INFO list"
1665 - A server responding to an INFO message is required to
1666 send all its 'info' in a series of RPL_INFO messages
1667 with a RPL_ENDOFINFO reply to indicate the end of the
1668 replies.
1670 375 RPL_MOTDSTART
1671 ":- <server> Message of the day - "
1672 372 RPL_MOTD
1673 ":- <text>"
1674 376 RPL_ENDOFMOTD
1675 ":End of MOTD command"
1677 - When responding to the MOTD message and the MOTD file
1678 is found, the file is displayed line by line, with
1679 each line no longer than 80 characters, using
1681 RPL_MOTD format replies. These MUST be surrounded
1682 by a RPL_MOTDSTART (before the RPL_MOTDs) and an
1683 RPL_ENDOFMOTD (after).
1685 381 RPL_YOUREOPER
1686 ":You are now an IRC operator"
1688 - RPL_YOUREOPER is sent back to a client which has
1689 just successfully issued an OPER message and gained
1690 operator status.
1692 382 RPL_REHASHING
1693 "<config file> :Rehashing"
1695 - If the REHASH option is used and an operator sends
1696 a REHASH message, an RPL_REHASHING is sent back to
1697 the operator.
1699 391 RPL_TIME
1700 "<server> :<string showing server's local time>"
1702 - When replying to the TIME message, a server MUST send
1703 the reply using the RPL_TIME format above. The string
1704 showing the time need only contain the correct day and
1705 time there. There is no further requirement for the
1706 time string.
1708 200 RPL_TRACELINK
1709 "Link <version & debug level> <destination>
1710 <next server> V<protocol version>
1711 <link uptime in seconds> <backstream sendq>
1712 <upstream sendq>"
1713 201 RPL_TRACECONNECTING
1714 "Try. <class> <server>"
1715 202 RPL_TRACEHANDSHAKE
1716 "H.S. <class> <server>"
1717 203 RPL_TRACEUNKNOWN
1718 "???? <class> [<client IP address in dot form>]"
1719 204 RPL_TRACEOPERATOR
1720 "Oper <class> <nick>"
1721 205 RPL_TRACEUSER
1722 "User <class> <nick>"
1723 206 RPL_TRACESERVER
1724 "Serv <class> <int>S <int>C <server>
1725 <nick!user|*!*>@<host|server> V<protocol version>"
1726 208 RPL_TRACENEWTYPE
1727 "<newtype> 0 <client name>"
1728 209 RPL_TRACECLASS
1729 "Class <class> <count>"
1730 210 RPL_TRACERECONNECT
1731 Unused.
1732 261 RPL_TRACELOG
1733 "File <logfile> <debug level>"
1734 262 RPL_TRACEEND
1735 "<server name> <version & debug level> :End of TRACE"
1737 - The RPL_TRACE* are all returned by the server in
1738 response to the TRACE message. How many are
1739 returned is dependent on the TRACE message and
1740 whether it was sent by an operator or not. There
1741 is no predefined order for which occurs first.
1742 Replies RPL_TRACEUNKNOWN, RPL_TRACECONNECTING and
1743 RPL_TRACEHANDSHAKE are all used for connections
1744 which have not been fully established and are either
1745 unknown, still attempting to connect or in the
1746 process of completing the 'server handshake'.
1747 RPL_TRACELINK is sent by any server which handles
1748 a TRACE message and has to pass it on to another
1749 server. The list of RPL_TRACELINKs sent in
1750 response to a TRACE command traversing the IRC
1751 network should reflect the actual connectivity of
1752 the servers themselves along that path.
1754 RPL_TRACENEWTYPE is to be used for any connection
1755 which does not fit in the other categories but is
1756 being displayed anyway.
1757 RPL_TRACEEND is sent to indicate the end of the list.
1759 211 RPL_STATSLINKINFO
1760 "<linkname> <sendq> <sent messages>
1761 <sent Kbytes> <received messages>
1762 <received Kbytes> <time open>"
1764 - reports statistics on a connection. <linkname>
1765 identifies the particular connection, <sendq> is
1766 the amount of data that is queued and waiting to be
1767 sent <sent messages> the number of messages sent,
1768 and <sent Kbytes> the amount of data sent, in
1769 Kbytes. <received messages> and <received Kbytes>
1770 are the equivalent of <sent messages> and <sent
1771 Kbytes> for received data, respectively. <time
1772 open> indicates how long ago the connection was
1773 opened, in seconds.
1775 212 RPL_STATSCOMMANDS
1776 "<command> <count> <byte count> <remote count>"
1778 - reports statistics on commands usage.
1780 219 RPL_ENDOFSTATS
1781 "<stats letter> :End of STATS report"
1783 242 RPL_STATSUPTIME
1784 ":Server Up %d days %d:%02d:%02d"
1786 - reports the server uptime.
1788 243 RPL_STATSOLINE
1789 "O <hostmask> * <name>"
1791 - reports the allowed hosts from where user may become IRC
1792 operators.
1794 221 RPL_UMODEIS
1795 "<user mode string>"
1797 - To answer a query about a client's own mode,
1798 RPL_UMODEIS is sent back.
1800 251 RPL_LUSERCLIENT
1801 ":There are <integer> users and <integer>
1802 invisible on <integer> servers"
1803 252 RPL_LUSEROP
1804 "<integer> :operator(s) online"
1805 253 RPL_LUSERUNKNOWN
1806 "<integer> :unknown connection(s)"
1807 254 RPL_LUSERCHANNELS
1808 "<integer> :channels formed"
1809 255 RPL_LUSERME
1810 ":I have <integer> clients and <integer>
1811 servers"
1813 - In processing an LUSERS message, the server
1814 sends a set of replies from RPL_LUSERCLIENT,
1815 RPL_LUSEROP, RPL_USERUNKNOWN,
1816 RPL_LUSERCHANNELS and RPL_LUSERME. When
1817 replying, a server MUST send back
1818 RPL_LUSERCLIENT and RPL_LUSERME. The other
1819 replies are only sent back if a non-zero count
1820 is found for them.
1822 256 RPL_ADMINME
1823 "<server> :Administrative info"
1824 ":Administrative info about <server>"
1825 257 RPL_ADMINLOC1
1826 ":<admin info>"
1827 258 RPL_ADMINLOC2
1828 ":<admin info>"
1829 259 RPL_ADMINEMAIL
1830 ":<admin info>"
1832 - When replying to an ADMIN message, a server
1833 is expected to use replies RPL_ADMINME
1834 through to RPL_ADMINEMAIL and provide a text
1835 message with each. This MUST contain an
1836 administrative contact for the server or
1837 network such as an email address and MAY
1838 contain other information such as location
1839 of the server.
1841 263 RPL_TRYAGAIN
1842 "<command> :Please wait a while and try again."
1844 - When a server drops a command without processing it,
1845 it MUST use the reply RPL_TRYAGAIN to inform the
1846 originating client.
1848 5.2 Error Replies
1850 Error replies are found in the range from 400 to 599.
1852 401 ERR_NOSUCHNICK
1853 "<middle> :No such nick/channel"
1855 - Used to indicate the nickname parameter supplied to a
1856 command is currently unused, or there is no match for
1857 a given nickname mask.
1859 If the nickname parameter given by the client is not known,
1860 e.g. because the server-server protocol uses unique IDs
1861 instead of nicknames, an asterisk is sent instead and the
1862 accompanying text may contain additional information.
1864 402 ERR_NOSUCHSERVER
1865 "<target> :No such server"
1867 - Used to indicate that the target parameter of any command
1868 with such a parameter, or a given server name currently
1869 does not exist.
1871 As with ERR_NOSUCHNICK, if the parameter given by the
1872 client is not known, an asterisk is sent instead and the
1873 accompanying text may contain additional information.
1875 403 ERR_NOSUCHCHANNEL
1876 "<channel name> :No such channel"
1878 - Used to indicate the given channel name is invalid.
1880 404 ERR_CANNOTSENDTOCHAN
1881 "<channel name> :Cannot send to channel"
1883 - Sent to a user who is trying to send a PRIVMSG message
1884 to a channel but is not allowed to.
1886 405 ERR_TOOMANYCHANNELS
1887 "<channel name> :You have joined too many channels"
1889 - Sent to a user when they have joined the maximum
1890 number of allowed channels and they try to join
1891 another channel. If this happens, the server MAY
1892 ignore the rest of the channels in the message.
1894 406 ERR_WASNOSUCHNICK
1895 "<nickname> :There was no such nickname"
1897 - Returned by WHOWAS to indicate there is no history
1898 information for that nickname.
1900 407 ERR_TOOMANYTARGETS
1901 "<target> :<error code> recipients. <abort message>"
1903 - Returned to a client which is attempting to send a
1904 PRIVMSG/NOTICE using the user@host destination format
1905 and for a user@host which has several occurrences.
1907 - Returned to a client which trying to send a
1908 PRIVMSG/NOTICE to too many recipients.
1910 - Returned to a client which is attempting to JOIN a safe
1911 channel using the shortname when there are more than one
1912 such channel.
1914 409 ERR_NOORIGIN
1915 ":No origin specified"
1917 - PING or PONG message missing the originator parameter.
1919 411 ERR_NORECIPIENT
1920 ":No recipient given (<command>)"
1921 412 ERR_NOTEXTTOSEND
1922 ":No text to send"
1923 413 ERR_NOTOPLEVEL
1924 "<mask> :No toplevel domain specified"
1925 414 ERR_WILDTOPLEVEL
1926 "<mask> :Wildcard in toplevel domain"
1927 415 ERR_BADMASK
1928 "<mask> :Bad Server/host mask"
1930 - 412 - 415 are returned by PRIVMSG to indicate that
1931 the message wasn't delivered for some reason.
1932 ERR_NOTOPLEVEL and ERR_WILDTOPLEVEL are errors that
1933 are returned when an invalid use of
1934 "PRIVMSG $<server>" or "PRIVMSG #<host>" is attempted.
1936 421 ERR_UNKNOWNCOMMAND
1937 "<command> :Unknown command"
1939 - Returned to a registered client to indicate that the
1940 command sent is unknown by the server.
1942 422 ERR_NOMOTD
1943 ":MOTD File is missing"
1945 - Server's MOTD file could not be opened by the server.
1947 423 ERR_NOADMININFO
1948 "<server> :No administrative info available"
1950 - Returned by a server in response to an ADMIN message
1951 when there is an error in finding the appropriate
1952 information.
1954 424 ERR_FILEERROR
1955 ":File error doing <file op> on <file>"
1957 - Generic error message used to report a failed file
1958 operation during the processing of a message.
1960 431 ERR_NONICKNAMEGIVEN
1961 ":No nickname given"
1963 - Returned when a nickname parameter expected for a
1964 command and isn't found.
1966 432 ERR_ERRONEUSNICKNAME
1967 "<nick> :Erroneous nickname"
1969 - Returned after receiving a NICK message which contains
1970 characters which do not fall in the defined set, or which
1971 is an administratively disallowed nickname. See
1972 section 2.3.1 for details on valid nicknames.
1974 433 ERR_NICKNAMEINUSE
1975 "<nick> :Nickname is already in use"
1977 - Returned when a NICK message is processed that results
1978 in an attempt to change to a currently existing
1979 nickname.
1981 XXX removed
1982 436 ERR_NICKCOLLISION
1983 "<nick> :Nickname collision KILL from <user>@<host>"
1985 - Returned by a server to a client when it detects a
1986 nickname collision (registered of a NICK that
1987 already exists by another server).
1989 437 ERR_UNAVAILRESOURCE
1990 "<nick/channel> :Nick/channel is temporarily unavailable"
1992 - Returned by a server to a user trying to use a nickname or
1993 channel which may not be used at this time.
1995 441 ERR_USERNOTINCHANNEL
1996 "<nick> <channel> :They aren't on that channel"
1998 - Returned by the server to indicate that the target
1999 user of the command is not on the given channel.
2001 442 ERR_NOTONCHANNEL
2002 "<channel> :You're not on that channel"
2004 - Returned by the server whenever a client tries to
2005 perform a channel affecting command for which the
2006 client isn't a member.
2008 443 ERR_USERONCHANNEL
2009 "<user> <channel> :is already on channel"
2011 - Returned when a client tries to invite a user to a
2012 channel they are already on.
2014 451 ERR_NOTREGISTERED
2015 ":You have not registered"
2017 - Returned by the server to indicate that the client
2018 MUST be registered before the server will allow it
2019 to be parsed in detail.
2021 461 ERR_NEEDMOREPARAMS
2022 "<command> :Not enough parameters"
2024 - Returned by the server by numerous commands to
2025 indicate to the client that it didn't supply enough
2026 parameters.
2028 462 ERR_ALREADYREGISTRED
2029 ":Unauthorized command (already registered)"
2031 - Returned by the server to any link which tries to
2032 change part of the registered details (such as
2033 password or user details from second USER message).
2035 463 ERR_NOPERMFORHOST
2036 ":Your host isn't among the privileged"
2038 - Returned to a client which attempts to register with
2039 a server which does not been setup to allow
2040 connections from the host the attempted connection
2041 is tried.
2043 464 ERR_PASSWDMISMATCH
2044 ":Password incorrect"
2046 - Returned to indicate a failed attempt at registering
2047 a connection for which a password was required and
2048 was either not given or incorrect.
2050 465 ERR_YOUREBANNEDCREEP
2051 ":You are banned from this server"
2053 - Returned after an attempt to connect and register
2054 yourself with a server which has been setup to
2055 explicitly deny connections to you.
2057 466 ERR_YOUWILLBEBANNED
2059 - Sent by a server to a user to inform that access to the
2060 server will soon be denied.
2062 467 ERR_KEYSET
2063 "<channel> :Channel key already set"
2064 471 ERR_CHANNELISFULL
2065 "<channel> :Cannot join channel (+l)"
2066 472 ERR_UNKNOWNMODE
2067 "<char> :is unknown mode char to me for <channel>"
2068 473 ERR_INVITEONLYCHAN
2069 "<channel> :Cannot join channel (+i)"
2070 474 ERR_BANNEDFROMCHAN
2071 "<channel> :Cannot join channel (+b)"
2072 475 ERR_BADCHANNELKEY
2073 "<channel> :Cannot join channel (+k)"
2074 476 ERR_BADCHANMASK
2075 "<channel> :Bad Channel Mask"
2076 477 ERR_NOCHANMODES
2077 "<channel> :Channel doesn't support modes"
2078 478 ERR_BANLISTFULL
2079 "<channel> <char> :Channel list is full"
2080 479 ERR_BADCHANNAME
2081 "<channel> :Illegal channel name"
2083 481 ERR_NOPRIVILEGES
2084 ":Permission Denied- You're not an IRC operator"
2086 - Any command requiring operator privileges to operate
2087 MUST return this error to indicate the attempt was
2088 unsuccessful.
2090 482 ERR_CHANOPRIVSNEEDED
2091 "<channel> :You're not channel operator"
2093 - Any command requiring 'chanop' privileges (such as
2094 MODE messages) MUST return this error if the client
2095 making the attempt is not a chanop on the specified
2096 channel.
2098 483 ERR_CANTKILLSERVER
2099 ":You can't kill a server!"
2101 - Any attempts to use the KILL command on a server
2102 are to be refused and this error returned directly
2103 to the client.
2105 484 ERR_RESTRICTED
2106 ":Your connection is restricted!"
2108 - Sent by the server to a user upon connection to indicate
2109 the restricted nature of the connection (user mode "+r").
2111 485 ERR_UNIQOPPRIVSNEEDED
2112 ":You're not the original channel operator"
2114 - Any MODE requiring "channel creator" privileges MUST
2115 return this error if the client making the attempt is not
2116 a chanop on the specified channel.
2118 491 ERR_NOOPERHOST
2119 ":No O-lines for your host"
2121 - If a client sends an OPER message and the server has
2122 not been configured to allow connections from the
2123 client's host as an operator, this error MUST be
2124 returned.
2126 501 ERR_UMODEUNKNOWNFLAG
2127 ":Unknown MODE flag"
2129 - Returned by the server to indicate that a MODE
2130 message was sent with a nickname parameter and that
2131 the a mode flag sent was not recognized.
2133 502 ERR_USERSDONTMATCH
2134 ":Cannot change mode for other users"
2136 - Error sent to any user trying to view or change the
2137 user mode for a user other than themselves.
2139 5.3 Reserved numerics
2141 These numerics are not described above since they fall into one of
2142 the following categories:
2144 1. no longer in use;
2146 2. reserved for future planned use;
2148 3. in current use but are part of a non-generic 'feature' of
2149 the current IRC server.
2151 5.3.1 No longer in use
2153 Very old:
2154 316 RPL_WHOISCHANOP
2155 361 RPL_KILLDONE
2156 373 RPL_INFOSTART
2157 384 RPL_MYPORTIS
2159 Summon/users:
2160 342 RPL_SUMMONING
2161 392 RPL_USERSSTART
2162 393 RPL_USERS
2163 394 RPL_ENDOFUSERS
2164 395 RPL_NOUSERS
2165 444 ERR_NOLOGIN
2166 445 ERR_SUMMONDISABLED
2167 446 ERR_USERSDISABLED
2169 5.3.2 Reserved
2171 300 RPL_NONE
2173 5.3.3 Non-generic features
2175 Close:
2176 362 RPL_CLOSING
2177 363 RPL_CLOSEEND
2179 IRCnet-style services:
2180 207 RPL_TRACESERVICE
2181 231 RPL_SERVICEINFO (appears to be unused)
2182 232 RPL_ENDOFSERVICES (appears to be unused)
2183 233 RPL_SERVICE (appears to be unused)
2184 234 RPL_SERVLIST
2185 235 RPL_SERVLISTEND
2186 383 RPL_YOURESERVICE
2187 408 ERR_NOSUCHSERVICE
2188 492 ERR_NOSERVICEHOST (appears to be unused)
2190 Non-generic stats replies, some specific to IRCnet:
2191 213 RPL_STATSCLINE
2192 214 RPL_STATSNLINE
2193 215 RPL_STATSILINE
2194 216 RPL_STATSKLINE
2195 217 RPL_STATSQLINE
2196 218 RPL_STATSYLINE
2197 240 RPL_STATSVLINE
2198 241 RPL_STATSLLINE
2199 244 RPL_STATSHLINE
2200 244 RPL_STATSSLINE
2201 246 RPL_STATSPING
2202 247 RPL_STATSBLINE
2203 250 RPL_STATSDLINE
2205 6. Current implementations
2207 The specifications outlined in this document and its accompanying documents (Architecture and Server) are not fully implemented anywhere. These documents are guidelines detailing a new standard now publicized for acceptance.
2209 7. Current problems
2211 There are a number of recognized problems with the IRC Client Protocol, and more generally with the IRC Server Protocol. In order to preserve backward compatibility with old clients, this protocol has almost not evolved since the publication of RFC 1459 [IRC].
2213 7.1 Nicknames
2215 The idea of the nickname on IRC is very convenient for users to use when talking to each other outside of a channel, but there is only a finite nickname space and being what they are, it's not uncommon for several people to want to use the same nick. If a nickname is chosen by two people using this protocol, there must be collision resolution. The details of collision resolution are outside the scope of this document. For reference, see the “IRC Server Protocol” document [IRC-SERVER].
2216 7.2 Limitation of wildcards
2218 In some implementations, there is no escape character. This is not usually a problem because nicks, usernames and hostnames cannot contain '*' or '?'. Other implementations recognize '\' (%x5C) as an escape character. There is no way to escape the escape character "\" (%x5C). This makes it impossible to form a mask with a backslash character ("\") preceding a wildcard.
2220 7.3 Security considerations
2221 Security issues related to this protocol are discussed in the "IRC Server Protocol" [IRC-SERVER] as they are mostly an issue for the server side of the connection.
2222 Client authors are advised to aid users in education on best practices for both IRC usage and the internet.
2224 8. Current support and availability
2225 IRC
2226 irc.chatspike.net #inspircd, #coding
2227 E-Mail
2228 surreal.w00t@gmail.com
2229 Software Implementations
2230 http://www.inspircd.org
2231 9. Acknowledgements
2233 This document makes heavy reference to RFCs 1459, 2811, 2812, and 2813 – previous documented standards of the IRC protocol. It has also benefited from many rounds of review and comments. In particular, the following people have made significant contributions to this document:
2234 Craig Edwards
2235 Jilles Tjoelker
2236 Carsten V. Munk
2238 Some RPL_ISUPPORT information has been taken from a draft by:
2239 Lee Hardy
2240 Edward Brocklesby
2241 Kevin L. Mitchell
2243 10. References
2244 [KEYWORDS]Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
2245 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
2246 [HNAME]Braden, R., "Requirements for Internet Hosts -- Application and Support", STD 3, RFC 1123, October 1989.
2247 [IRC] Oikarinen, J. & D. Reed, "Internet Relay Chat Protocol", RFC 1459, May 1993.
2248 [IRC-ARCH]Kalt, C., "Internet Relay Chat: Architecture", RFC 2810, April 2000.
2249 [IRC-CHAN]Kalt, C., "Internet Relay Chat: Channel Management", RFC 2811, April 2000.
2250 [IRC-SERVER] Kalt, C., "Internet Relay Chat: Server Protocol", RFC 2813, April 2000.
2252 11. Author's Address
2253 Robin Burchell
2254 EMail: surreal.w00t@gmail.com
2255 Jilles Tjoelker
2257 12. Full Copyright Statement
2259 Copyright (C) The Internet Society (2000). All Rights Reserved.
2260 This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
2261 The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
2262 This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
2263 Acknowledgement
2264 Funding for the RFC Editor function is currently provided by the Internet Society.