/[svn]/ircd-hybrid/doc/technical/rfc2812.txt
ViewVC logotype

Contents of /ircd-hybrid/doc/technical/rfc2812.txt

Parent Directory Parent Directory | Revision Log Revision Log


Revision 30 - (show annotations)
Sun Oct 2 20:03:27 2005 UTC (14 years, 2 months ago) by adx
File MIME type: text/plain
File size: 113014 byte(s)
- imported sources
- can be moved later according to the directory/branching scheme,
  but we need the svn up

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

Properties

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

svnadmin@ircd-hybrid.org
ViewVC Help
Powered by ViewVC 1.1.26