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