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