hirc

[archived] IRC client
git clone https://hhvn.uk/hirc
git clone git://hhvn.uk/hirc
Log | Files | Refs

RFC1459 (138964B)


      1 
      2 
      3 
      4 
      5 
      6 
      7 Network Working Group                                      J. Oikarinen
      8 Request for Comments: 1459                                      D. Reed
      9                                                                May 1993
     10 
     11 
     12                       Internet Relay Chat Protocol
     13 
     14 Status of This Memo
     15 
     16    This memo defines an Experimental Protocol for the Internet
     17    community.  Discussion and suggestions for improvement are requested.
     18    Please refer to the current edition of the "IAB Official Protocol
     19    Standards" for the standardization state and status of this protocol.
     20    Distribution of this memo is unlimited.
     21 
     22 Abstract
     23 
     24    The IRC protocol was developed over the last 4 years since it was
     25    first implemented as a means for users on a BBS to chat amongst
     26    themselves.  Now it supports a world-wide network of servers and
     27    clients, and is stringing to cope with growth. Over the past 2 years,
     28    the average number of users connected to the main IRC network has
     29    grown by a factor of 10.
     30 
     31    The IRC protocol is a text-based protocol, with the simplest client
     32    being any socket program capable of connecting to the server.
     33 
     34 Table of Contents
     35 
     36    1.  INTRODUCTION ...............................................    4
     37       1.1  Servers ................................................    4
     38       1.2  Clients ................................................    5
     39          1.2.1 Operators ..........................................    5
     40       1.3 Channels ................................................    5
     41       1.3.1  Channel Operators ....................................    6
     42    2. THE IRC SPECIFICATION .......................................    7
     43       2.1 Overview ................................................    7
     44       2.2 Character codes .........................................    7
     45       2.3 Messages ................................................    7
     46          2.3.1  Message format in 'pseudo' BNF ....................    8
     47       2.4 Numeric replies .........................................   10
     48    3. IRC Concepts ................................................   10
     49       3.1 One-to-one communication ................................   10
     50       3.2 One-to-many .............................................   11
     51          3.2.1 To a list ..........................................   11
     52          3.2.2 To a group (channel) ...............................   11
     53          3.2.3 To a host/server mask ..............................   12
     54       3.3 One to all ..............................................   12
     55 
     56 
     57 
     58 Oikarinen & Reed                                                [Page 1]
     59 
     60 RFC 1459              Internet Relay Chat Protocol              May 1993
     61 
     62 
     63          3.3.1 Client to Client ...................................   12
     64          3.3.2 Clients to Server ..................................   12
     65          3.3.3 Server to Server ...................................   12
     66    4. MESSAGE DETAILS .............................................   13
     67       4.1 Connection Registration .................................   13
     68          4.1.1 Password message ...................................   14
     69          4.1.2 Nickname message ...................................   14
     70          4.1.3 User message .......................................   15
     71          4.1.4 Server message .....................................   16
     72          4.1.5 Operator message ...................................   17
     73          4.1.6 Quit message .......................................   17
     74          4.1.7 Server Quit message ................................   18
     75       4.2 Channel operations ......................................   19
     76          4.2.1 Join message .......................................   19
     77          4.2.2 Part message .......................................   20
     78          4.2.3 Mode message .......................................   21
     79             4.2.3.1 Channel modes .................................   21
     80             4.2.3.2 User modes ....................................   22
     81          4.2.4 Topic message ......................................   23
     82          4.2.5 Names message ......................................   24
     83          4.2.6 List message .......................................   24
     84          4.2.7 Invite message .....................................   25
     85          4.2.8 Kick message .......................................   25
     86       4.3 Server queries and commands .............................   26
     87          4.3.1 Version message ....................................   26
     88          4.3.2 Stats message ......................................   27
     89          4.3.3 Links message ......................................   28
     90          4.3.4 Time message .......................................   29
     91          4.3.5 Connect message ....................................   29
     92          4.3.6 Trace message ......................................   30
     93          4.3.7 Admin message ......................................   31
     94          4.3.8 Info message .......................................   31
     95       4.4 Sending messages ........................................   32
     96          4.4.1 Private messages ...................................   32
     97          4.4.2 Notice messages ....................................   33
     98       4.5 User-based queries ......................................   33
     99          4.5.1 Who query ..........................................   33
    100          4.5.2 Whois query ........................................   34
    101          4.5.3 Whowas message .....................................   35
    102       4.6 Miscellaneous messages ..................................   35
    103          4.6.1 Kill message .......................................   36
    104          4.6.2 Ping message .......................................   37
    105          4.6.3 Pong message .......................................   37
    106          4.6.4 Error message ......................................   38
    107    5. OPTIONAL MESSAGES ...........................................   38
    108       5.1 Away message ............................................   38
    109       5.2 Rehash command ..........................................   39
    110       5.3 Restart command .........................................   39
    111 
    112 
    113 
    114 Oikarinen & Reed                                                [Page 2]
    115 
    116 RFC 1459              Internet Relay Chat Protocol              May 1993
    117 
    118 
    119       5.4 Summon message ..........................................   40
    120       5.5 Users message ...........................................   40
    121       5.6 Operwall command ........................................   41
    122       5.7 Userhost message ........................................   42
    123       5.8 Ison message ............................................   42
    124    6. REPLIES .....................................................   43
    125       6.1 Error Replies ...........................................   43
    126       6.2 Command responses .......................................   48
    127       6.3 Reserved numerics .......................................   56
    128    7. Client and server authentication ............................   56
    129    8. Current Implementations Details .............................   56
    130       8.1 Network protocol: TCP ...................................   57
    131          8.1.1 Support of Unix sockets ............................   57
    132       8.2 Command Parsing .........................................   57
    133       8.3 Message delivery ........................................   57
    134       8.4 Connection 'Liveness' ...................................   58
    135       8.5 Establishing a server-client connection .................   58
    136       8.6 Establishing a server-server connection .................   58
    137          8.6.1 State information exchange when connecting .........   59
    138       8.7 Terminating server-client connections ...................   59
    139       8.8 Terminating server-server connections ...................   59
    140       8.9 Tracking nickname changes ...............................   60
    141       8.10 Flood control of clients ...............................   60
    142       8.11 Non-blocking lookups ...................................   61
    143          8.11.1 Hostname (DNS) lookups ............................   61
    144          8.11.2 Username (Ident) lookups ..........................   61
    145       8.12 Configuration file .....................................   61
    146          8.12.1 Allowing clients to connect .......................   62
    147          8.12.2 Operators .........................................   62
    148          8.12.3 Allowing servers to connect .......................   62
    149          8.12.4 Administrivia .....................................   63
    150       8.13 Channel membership .....................................   63
    151    9. Current problems ............................................   63
    152       9.1 Scalability .............................................   63
    153       9.2 Labels ..................................................   63
    154          9.2.1 Nicknames ..........................................   63
    155          9.2.2 Channels ...........................................   64
    156          9.2.3 Servers ............................................   64
    157       9.3 Algorithms ..............................................   64
    158    10. Support and availability ...................................   64
    159    11. Security Considerations ....................................   65
    160    12. Authors' Addresses .........................................   65
    161 
    162 
    163 
    164 
    165 
    166 
    167 
    168 
    169 
    170 Oikarinen & Reed                                                [Page 3]
    171 
    172 RFC 1459              Internet Relay Chat Protocol              May 1993
    173 
    174 
    175 1.  INTRODUCTION
    176 
    177    The IRC (Internet Relay Chat) protocol has been designed over a
    178    number of years for use with text based conferencing.  This document
    179    describes the current IRC protocol.
    180 
    181    The IRC protocol has been developed on systems using the TCP/IP
    182    network protocol, although there is no requirement that this remain
    183    the only sphere in which it operates.
    184 
    185    IRC itself is a teleconferencing system, which (through the use of
    186    the client-server model) is well-suited to running on many machines
    187    in a distributed fashion.  A typical setup involves a single process
    188    (the server) forming a central point for clients (or other servers)
    189    to connect to, performing the required message delivery/multiplexing
    190    and other functions.
    191 
    192 1.1 Servers
    193 
    194    The server forms the backbone of IRC, providing a point to which
    195    clients may connect to to talk to each other, and a point for other
    196    servers to connect to, forming an IRC network.  The only network
    197    configuration allowed for IRC servers is that of a spanning tree [see
    198    Fig. 1] where each server acts as a central node for the rest of the
    199    net it sees.
    200 
    201 
    202                            [ Server 15 ]  [ Server 13 ] [ Server 14]
    203                                  /                \         /
    204                                 /                  \       /
    205         [ Server 11 ] ------ [ Server 1 ]       [ Server 12]
    206                               /        \          /
    207                              /          \        /
    208                   [ Server 2 ]          [ Server 3 ]
    209                     /       \                      \
    210                    /         \                      \
    211            [ Server 4 ]    [ Server 5 ]         [ Server 6 ]
    212             /    |    \                           /
    213            /     |     \                         /
    214           /      |      \____                   /
    215          /       |           \                 /
    216  [ Server 7 ] [ Server 8 ] [ Server 9 ]   [ Server 10 ]
    217 
    218                                   :
    219                                [ etc. ]
    220                                   :
    221 
    222                  [ Fig. 1. Format of IRC server network ]
    223 
    224 
    225 
    226 Oikarinen & Reed                                                [Page 4]
    227 
    228 RFC 1459              Internet Relay Chat Protocol              May 1993
    229 
    230 
    231 1.2 Clients
    232 
    233    A client is anything connecting to a server that is not another
    234    server.  Each client is distinguished from other clients by a unique
    235    nickname having a maximum length of nine (9) characters.  See the
    236    protocol grammar rules for what may and may not be used in a
    237    nickname.  In addition to the nickname, all servers must have the
    238    following information about all clients: the real name of the host
    239    that the client is running on, the username of the client on that
    240    host, and the server to which the client is connected.
    241 
    242 1.2.1 Operators
    243 
    244    To allow a reasonable amount of order to be kept within the IRC
    245    network, a special class of clients (operators) is allowed to perform
    246    general maintenance functions on the network.  Although the powers
    247    granted to an operator can be considered as 'dangerous', they are
    248    nonetheless required.  Operators should be able to perform basic
    249    network tasks such as disconnecting and reconnecting servers as
    250    needed to prevent long-term use of bad network routing.  In
    251    recognition of this need, the protocol discussed herein provides for
    252    operators only to be able to perform such functions.  See sections
    253    4.1.7 (SQUIT) and 4.3.5 (CONNECT).
    254 
    255    A more controversial power of operators is the ability  to  remove  a
    256    user  from  the connected network by 'force', i.e. operators are able
    257    to close the connection between any client and server.   The
    258    justification for  this  is delicate since its abuse is both
    259    destructive and annoying.  For further details on this type of
    260    action, see section 4.6.1 (KILL).
    261 
    262 1.3 Channels
    263 
    264    A channel is a named group of one or more clients which will all
    265    receive messages addressed to that channel.  The channel is created
    266    implicitly when the first client joins it, and the channel ceases to
    267    exist when the last client leaves it.  While channel exists, any
    268    client can reference the channel using the name of the channel.
    269 
    270    Channels names are strings (beginning with a '&' or '#' character) of
    271    length up to 200 characters.  Apart from the the requirement that the
    272    first character being either '&' or '#'; the only restriction on a
    273    channel name is that it may not contain any spaces (' '), a control G
    274    (^G or ASCII 7), or a comma (',' which is used as a list item
    275    separator by the protocol).
    276 
    277    There are two types of channels allowed by this protocol.  One is a
    278    distributed channel which is known to all the servers that are
    279 
    280 
    281 
    282 Oikarinen & Reed                                                [Page 5]
    283 
    284 RFC 1459              Internet Relay Chat Protocol              May 1993
    285 
    286 
    287    connected to the network. These channels are marked by the first
    288    character being a only clients on the server where it exists may join
    289    it.  These are distinguished by a leading '&' character.  On top of
    290    these two types, there are the various channel modes available to
    291    alter the characteristics of individual channels.  See section 4.2.3
    292    (MODE command) for more details on this.
    293 
    294    To create a new channel or become part of an existing channel, a user
    295    is required to JOIN the channel.  If the channel doesn't exist prior
    296    to joining, the channel is created and the creating user becomes a
    297    channel operator.  If the channel already exists, whether or not your
    298    request to JOIN that channel is honoured depends on the current modes
    299    of the channel. For example, if the channel is invite-only, (+i),
    300    then you may only join if invited.  As part of the protocol, a user
    301    may be a part of several channels at once, but a limit of ten (10)
    302    channels is recommended as being ample for both experienced and
    303    novice users.  See section 8.13 for more information on this.
    304 
    305    If the IRC network becomes disjoint because of a split between two
    306    servers, the channel on each side is only composed of those clients
    307    which are connected to servers on the respective sides of the split,
    308    possibly ceasing to exist on one side of the split.  When the split
    309    is healed, the connecting servers announce to each other who they
    310    think is in each channel and the mode of that channel.  If the
    311    channel exists on both sides, the JOINs and MODEs are interpreted in
    312    an inclusive manner so that both sides of the new connection will
    313    agree about which clients are in the channel and what modes the
    314    channel has.
    315 
    316 1.3.1 Channel Operators
    317 
    318    The channel operator (also referred to as a "chop" or "chanop") on a
    319    given channel is considered to 'own' that channel.  In recognition of
    320    this status, channel operators are endowed with certain powers which
    321    enable them to keep control and some sort of sanity in their channel.
    322    As an owner of a channel, a channel operator is not required to have
    323    reasons for their actions, although if their actions are generally
    324    antisocial or otherwise abusive, it might be reasonable to ask an IRC
    325    operator to intervene, or for the usersjust leave and go elsewhere
    326    and form their own channel.
    327 
    328    The commands which may only be used by channel operators are:
    329 
    330         KICK    - Eject a client from the channel
    331         MODE    - Change the channel's mode
    332         INVITE  - Invite a client to an invite-only channel (mode +i)
    333         TOPIC   - Change the channel topic in a mode +t channel
    334 
    335 
    336 
    337 
    338 Oikarinen & Reed                                                [Page 6]
    339 
    340 RFC 1459              Internet Relay Chat Protocol              May 1993
    341 
    342 
    343    A channel operator is identified by the '@' symbol next to their
    344    nickname whenever it is associated with a channel (ie replies to the
    345    NAMES, WHO and WHOIS commands).
    346 
    347 2. The IRC Specification
    348 
    349 2.1 Overview
    350 
    351    The protocol as described herein is for use both with server to
    352    server and client to server connections.  There are, however, more
    353    restrictions on client connections (which are considered to be
    354    untrustworthy) than on server connections.
    355 
    356 2.2 Character codes
    357 
    358    No specific character set is specified. The protocol is based on a a
    359    set of codes which are composed of eight (8) bits, making up an
    360    octet.  Each message may be composed of any number of these octets;
    361    however, some octet values are used for control codes which act as
    362    message delimiters.
    363 
    364    Regardless of being an 8-bit protocol, the delimiters and keywords
    365    are such that protocol is mostly usable from USASCII terminal and a
    366    telnet connection.
    367 
    368    Because of IRC's scandanavian origin, the characters {}| are
    369    considered to be the lower case equivalents of the characters []\,
    370    respectively. This is a critical issue when determining the
    371    equivalence of two nicknames.
    372 
    373 2.3 Messages
    374 
    375    Servers and clients send eachother messages which may or may not
    376    generate a reply.  If the message contains a valid command, as
    377    described in later sections, the client should expect a reply as
    378    specified but it is not advised to wait forever for the reply; client
    379    to server and server to server communication is essentially
    380    asynchronous in nature.
    381 
    382    Each IRC message may consist of up to three main parts: the prefix
    383    (optional), the command, and the command parameters (of which there
    384    may be up to 15).  The prefix, command, and all parameters are
    385    separated by one (or more) ASCII space character(s) (0x20).
    386 
    387    The presence of a prefix is indicated with a single leading ASCII
    388    colon character (':', 0x3b), which must be the first character of the
    389    message itself.  There must be no gap (whitespace) between the colon
    390    and the prefix.  The prefix is used by servers to indicate the true
    391 
    392 
    393 
    394 Oikarinen & Reed                                                [Page 7]
    395 
    396 RFC 1459              Internet Relay Chat Protocol              May 1993
    397 
    398 
    399    origin of the message.  If the prefix is missing from the message, it
    400    is assumed to have originated from the connection from which it was
    401    received.  Clients should not use prefix when sending a message from
    402    themselves; if they use a prefix, the only valid prefix is the
    403    registered nickname associated with the client.  If the source
    404    identified by the prefix cannot be found from the server's internal
    405    database, or if the source is registered from a different link than
    406    from which the message arrived, the server must ignore the message
    407    silently.
    408 
    409    The command must either be a valid IRC command or a three (3) digit
    410    number represented in ASCII text.
    411 
    412    IRC messages are always lines of characters terminated with a CR-LF
    413    (Carriage Return - Line Feed) pair, and these messages shall not
    414    exceed 512 characters in length, counting all characters including
    415    the trailing CR-LF. Thus, there are 510 characters maximum allowed
    416    for the command and its parameters.  There is no provision for
    417    continuation message lines.  See section 7 for more details about
    418    current implementations.
    419 
    420 2.3.1 Message format in 'pseudo' BNF
    421 
    422    The protocol messages must be extracted from the contiguous stream of
    423    octets.  The current solution is to designate two characters, CR and
    424    LF, as message separators.   Empty  messages  are  silently  ignored,
    425    which permits  use  of  the  sequence  CR-LF  between  messages
    426    without extra problems.
    427 
    428    The extracted message is parsed into the components <prefix>,
    429    <command> and list of parameters matched either by <middle> or
    430    <trailing> components.
    431 
    432    The BNF representation for this is:
    433 
    434 
    435 <message>  ::= [':' <prefix> <SPACE> ] <command> <params> <crlf>
    436 <prefix>   ::= <servername> | <nick> [ '!' <user> ] [ '@' <host> ]
    437 <command>  ::= <letter> { <letter> } | <number> <number> <number>
    438 <SPACE>    ::= ' ' { ' ' }
    439 <params>   ::= <SPACE> [ ':' <trailing> | <middle> <params> ]
    440 
    441 <middle>   ::= <Any *non-empty* sequence of octets not including SPACE
    442                or NUL or CR or LF, the first of which may not be ':'>
    443 <trailing> ::= <Any, possibly *empty*, sequence of octets not including
    444                  NUL or CR or LF>
    445 
    446 <crlf>     ::= CR LF
    447 
    448 
    449 
    450 Oikarinen & Reed                                                [Page 8]
    451 
    452 RFC 1459              Internet Relay Chat Protocol              May 1993
    453 
    454 
    455 NOTES:
    456 
    457   1)    <SPACE> is consists only of SPACE character(s) (0x20).
    458         Specially notice that TABULATION, and all other control
    459         characters are considered NON-WHITE-SPACE.
    460 
    461   2)    After extracting the parameter list, all parameters are equal,
    462         whether matched by <middle> or <trailing>. <Trailing> is just
    463         a syntactic trick to allow SPACE within parameter.
    464 
    465   3)    The fact that CR and LF cannot appear in parameter strings is
    466         just artifact of the message framing. This might change later.
    467 
    468   4)    The NUL character is not special in message framing, and
    469         basically could end up inside a parameter, but as it would
    470         cause extra complexities in normal C string handling. Therefore
    471         NUL is not allowed within messages.
    472 
    473   5)    The last parameter may be an empty string.
    474 
    475   6)    Use of the extended prefix (['!' <user> ] ['@' <host> ]) must
    476         not be used in server to server communications and is only
    477         intended for server to client messages in order to provide
    478         clients with more useful information about who a message is
    479         from without the need for additional queries.
    480 
    481    Most protocol messages specify additional semantics and syntax for
    482    the extracted parameter strings dictated by their position in the
    483    list.  For example, many server commands will assume that the first
    484    parameter after the command is the list of targets, which can be
    485    described with:
    486 
    487    <target>     ::= <to> [ "," <target> ]
    488    <to>         ::= <channel> | <user> '@' <servername> | <nick> | <mask>
    489    <channel>    ::= ('#' | '&') <chstring>
    490    <servername> ::= <host>
    491    <host>       ::= see RFC 952 [DNS:4] for details on allowed hostnames
    492    <nick>       ::= <letter> { <letter> | <number> | <special> }
    493    <mask>       ::= ('#' | '$') <chstring>
    494    <chstring>   ::= <any 8bit code except SPACE, BELL, NUL, CR, LF and
    495                      comma (',')>
    496 
    497    Other parameter syntaxes are:
    498 
    499    <user>       ::= <nonwhite> { <nonwhite> }
    500    <letter>     ::= 'a' ... 'z' | 'A' ... 'Z'
    501    <number>     ::= '0' ... '9'
    502    <special>    ::= '-' | '[' | ']' | '\' | '`' | '^' | '{' | '}'
    503 
    504 
    505 
    506 Oikarinen & Reed                                                [Page 9]
    507 
    508 RFC 1459              Internet Relay Chat Protocol              May 1993
    509 
    510 
    511    <nonwhite>   ::= <any 8bit code except SPACE (0x20), NUL (0x0), CR
    512                      (0xd), and LF (0xa)>
    513 
    514 2.4 Numeric replies
    515 
    516    Most of the messages sent to the server generate a reply of some
    517    sort.  The most common reply is the numeric reply, used for both
    518    errors and normal replies.  The numeric reply must be sent as one
    519    message consisting of the sender prefix, the three digit numeric, and
    520    the target of the reply.  A numeric reply is not allowed to originate
    521    from a client; any such messages received by a server are silently
    522    dropped. In all other respects, a numeric reply is just like a normal
    523    message, except that the keyword is made up of 3 numeric digits
    524    rather than a string of letters.  A list of different replies is
    525    supplied in section 6.
    526 
    527 3. IRC Concepts.
    528 
    529    This section is devoted to describing the actual concepts behind  the
    530    organization  of  the  IRC  protocol and how the current
    531    implementations deliver different classes of messages.
    532 
    533 
    534 
    535                           1--\
    536                               A        D---4
    537                           2--/ \      /
    538                                 B----C
    539                                /      \
    540                               3        E
    541 
    542    Servers: A, B, C, D, E         Clients: 1, 2, 3, 4
    543 
    544                     [ Fig. 2. Sample small IRC network ]
    545 
    546 3.1 One-to-one communication
    547 
    548    Communication on a one-to-one basis is usually only performed by
    549    clients, since most server-server traffic is not a result of servers
    550    talking only to each other.  To provide a secure means for clients to
    551    talk to each other, it is required that all servers be able to send a
    552    message in exactly one direction along the spanning tree in order to
    553    reach any client.  The path of a message being delivered is the
    554    shortest path between any two points on the spanning tree.
    555 
    556    The following examples all refer to Figure 2 above.
    557 
    558 
    559 
    560 
    561 
    562 Oikarinen & Reed                                               [Page 10]
    563 
    564 RFC 1459              Internet Relay Chat Protocol              May 1993
    565 
    566 
    567 Example 1:
    568      A message between clients 1 and 2 is only seen by server A, which
    569      sends it straight to client 2.
    570 
    571 Example 2:
    572      A message between clients 1 and 3 is seen by servers A & B, and
    573      client 3.  No other clients or servers are allowed see the message.
    574 
    575 Example 3:
    576      A message between clients 2 and 4 is seen by servers A, B, C & D
    577      and client 4 only.
    578 
    579 3.2 One-to-many
    580 
    581    The main goal of IRC is to provide a  forum  which  allows  easy  and
    582    efficient  conferencing (one to many conversations).  IRC offers
    583    several means to achieve this, each serving its own purpose.
    584 
    585 3.2.1 To a list
    586 
    587    The least efficient style of one-to-many conversation is through
    588    clients talking to a 'list' of users.  How this is done is almost
    589    self explanatory: the client gives a list of destinations to which
    590    the message is to be delivered and the server breaks it up and
    591    dispatches a separate copy of the message to each given destination.
    592    This isn't as efficient as using a group since the destination list
    593    is broken up and the dispatch sent without checking to make sure
    594    duplicates aren't sent down each path.
    595 
    596 3.2.2 To a group (channel)
    597 
    598    In IRC the channel has a role equivalent to that of the multicast
    599    group; their existence is dynamic (coming and going as people join
    600    and leave channels) and the actual conversation carried out on a
    601    channel is only sent to servers which are supporting users on a given
    602    channel.  If there are multiple users on a server in the same
    603    channel, the message text is sent only once to that server and then
    604    sent to each client on the channel.  This action is then repeated for
    605    each client-server combination until the original message has fanned
    606    out and reached each member of the channel.
    607 
    608    The following examples all refer to Figure 2.
    609 
    610 Example 4:
    611      Any channel with 1 client in it. Messages to the channel go to the
    612      server and then nowhere else.
    613 
    614 
    615 
    616 
    617 
    618 Oikarinen & Reed                                               [Page 11]
    619 
    620 RFC 1459              Internet Relay Chat Protocol              May 1993
    621 
    622 
    623 Example 5:
    624      2 clients in a channel. All messages traverse a path as if they
    625      were private messages between the two clients outside a channel.
    626 
    627 Example 6:
    628      Clients 1, 2 and 3 in a channel.  All messages to the channel are
    629      sent to all clients and only those servers which must be traversed
    630      by the message if it were a private message to a single client.  If
    631      client 1 sends a message, it goes back to client 2 and then via
    632      server B to client 3.
    633 
    634 3.2.3 To a host/server mask
    635 
    636    To provide IRC operators with some mechanism to send  messages  to  a
    637    large body of related users, host and server mask messages are
    638    provided.  These messages are sent to users whose host or server
    639    information  match that  of  the mask.  The messages are only sent to
    640    locations where users are, in a fashion similar to that of channels.
    641 
    642 3.3 One-to-all
    643 
    644    The one-to-all type of message is better described as a broadcast
    645    message, sent to all clients or servers or both.  On a large network
    646    of users and servers, a single message can result in a lot of traffic
    647    being sent over the network in an effort to reach all of the desired
    648    destinations.
    649 
    650    For some messages, there is no option but to broadcast it to all
    651    servers so that the state information held by each server is
    652    reasonably consistent between servers.
    653 
    654 3.3.1 Client-to-Client
    655 
    656    There is no class of message which, from a single message, results in
    657    a message being sent to every other client.
    658 
    659 3.3.2 Client-to-Server
    660 
    661    Most of the commands which result in a change of state information
    662    (such as channel membership, channel mode, user status, etc) must be
    663    sent to all servers by default, and this distribution may not be
    664    changed by the client.
    665 
    666 3.3.3 Server-to-Server.
    667 
    668    While most messages between servers are distributed to all 'other'
    669    servers, this is only required for any message that affects either a
    670    user, channel or server.  Since these are the basic items found in
    671 
    672 
    673 
    674 Oikarinen & Reed                                               [Page 12]
    675 
    676 RFC 1459              Internet Relay Chat Protocol              May 1993
    677 
    678 
    679    IRC, nearly all messages originating from a server are broadcast to
    680    all other connected servers.
    681 
    682 4. Message details
    683 
    684    On the following pages are descriptions of each message recognized by
    685    the IRC server and client.  All commands described in this section
    686    must be implemented by any server for this protocol.
    687 
    688    Where the reply ERR_NOSUCHSERVER is listed, it means that the
    689    <server> parameter could not be found.  The server must not send any
    690    other replies after this for that command.
    691 
    692    The server to which a client is connected is required to parse the
    693    complete message, returning any appropriate errors.  If the server
    694    encounters a fatal error while parsing a message, an error must be
    695    sent back to the client and the parsing terminated.  A fatal error
    696    may be considered to be incorrect command, a destination which is
    697    otherwise unknown to the server (server, nick or channel names fit
    698    this category), not enough parameters or incorrect privileges.
    699 
    700    If a full set of parameters is presented, then each must be checked
    701    for validity and appropriate responses sent back to the client.  In
    702    the case of messages which use parameter lists using the comma as an
    703    item separator, a reply must be sent for each item.
    704 
    705    In the examples below, some messages appear using the full format:
    706 
    707    :Name COMMAND parameter list
    708 
    709    Such examples represent a message from "Name" in transit between
    710    servers, where it is essential to include the name of the original
    711    sender of the message so remote servers may send back a reply along
    712    the correct path.
    713 
    714 4.1 Connection Registration
    715 
    716    The commands described here are used to register a connection with an
    717    IRC server as either a user or a server as well as correctly
    718    disconnect.
    719 
    720    A "PASS" command is not required for either client or server
    721    connection to be registered, but it must precede the server message
    722    or the latter of the NICK/USER combination.  It is strongly
    723    recommended that all server connections have a password in order to
    724    give some level of security to the actual connections.  The
    725    recommended order for a client to register is as follows:
    726 
    727 
    728 
    729 
    730 Oikarinen & Reed                                               [Page 13]
    731 
    732 RFC 1459              Internet Relay Chat Protocol              May 1993
    733 
    734 
    735            1. Pass message
    736            2. Nick message
    737            3. User message
    738 
    739 4.1.1 Password message
    740 
    741 
    742       Command: PASS
    743    Parameters: <password>
    744 
    745    The PASS command is used to set a 'connection password'.  The
    746    password can and must be set before any attempt to register the
    747    connection is made.  Currently this requires that clients send a PASS
    748    command before sending the NICK/USER combination and servers *must*
    749    send a PASS command before any SERVER command.  The password supplied
    750    must match the one contained in the C/N lines (for servers) or I
    751    lines (for clients).  It is possible to send multiple PASS commands
    752    before registering but only the last one sent is used for
    753    verification and it may not be changed once registered.  Numeric
    754    Replies:
    755 
    756            ERR_NEEDMOREPARAMS              ERR_ALREADYREGISTRED
    757 
    758    Example:
    759 
    760            PASS secretpasswordhere
    761 
    762 4.1.2 Nick message
    763 
    764       Command: NICK
    765    Parameters: <nickname> [ <hopcount> ]
    766 
    767    NICK message is used to give user a nickname or change the previous
    768    one.  The <hopcount> parameter is only used by servers to indicate
    769    how far away a nick is from its home server.  A local connection has
    770    a hopcount of 0.  If supplied by a client, it must be ignored.
    771 
    772    If a NICK message arrives at a server which already knows about an
    773    identical nickname for another client, a nickname collision occurs.
    774    As a result of a nickname collision, all instances of the nickname
    775    are removed from the server's database, and a KILL command is issued
    776    to remove the nickname from all other server's database. If the NICK
    777    message causing the collision was a nickname change, then the
    778    original (old) nick must be removed as well.
    779 
    780    If the server recieves an identical NICK from a client which is
    781    directly connected, it may issue an ERR_NICKCOLLISION to the local
    782    client, drop the NICK command, and not generate any kills.
    783 
    784 
    785 
    786 Oikarinen & Reed                                               [Page 14]
    787 
    788 RFC 1459              Internet Relay Chat Protocol              May 1993
    789 
    790 
    791    Numeric Replies:
    792 
    793            ERR_NONICKNAMEGIVEN             ERR_ERRONEUSNICKNAME
    794            ERR_NICKNAMEINUSE               ERR_NICKCOLLISION
    795 
    796    Example:
    797 
    798    NICK Wiz                        ; Introducing new nick "Wiz".
    799 
    800    :WiZ NICK Kilroy                ; WiZ changed his nickname to Kilroy.
    801 
    802 4.1.3 User message
    803 
    804       Command: USER
    805    Parameters: <username> <hostname> <servername> <realname>
    806 
    807    The USER message is used at the beginning of connection to specify
    808    the username, hostname, servername and realname of s new user.  It is
    809    also used in communication between servers to indicate new user
    810    arriving on IRC, since only after both USER and NICK have been
    811    received from a client does a user become registered.
    812 
    813    Between servers USER must to be prefixed with client's NICKname.
    814    Note that hostname and servername are normally ignored by the IRC
    815    server when the USER command comes from a directly connected client
    816    (for security reasons), but they are used in server to server
    817    communication.  This means that a NICK must always be sent to a
    818    remote server when a new user is being introduced to the rest of the
    819    network before the accompanying USER is sent.
    820 
    821    It must be noted that realname parameter must be the last parameter,
    822    because it may contain space characters and must be prefixed with a
    823    colon (':') to make sure this is recognised as such.
    824 
    825    Since it is easy for a client to lie about its username by relying
    826    solely on the USER message, the use of an "Identity Server" is
    827    recommended.  If the host which a user connects from has such a
    828    server enabled the username is set to that as in the reply from the
    829    "Identity Server".
    830 
    831    Numeric Replies:
    832 
    833            ERR_NEEDMOREPARAMS              ERR_ALREADYREGISTRED
    834 
    835    Examples:
    836 
    837 
    838    USER guest tolmoon tolsun :Ronnie Reagan
    839 
    840 
    841 
    842 Oikarinen & Reed                                               [Page 15]
    843 
    844 RFC 1459              Internet Relay Chat Protocol              May 1993
    845 
    846 
    847                                    ; User registering themselves with a
    848                                    username of "guest" and real name
    849                                    "Ronnie Reagan".
    850 
    851 
    852    :testnick USER guest tolmoon tolsun :Ronnie Reagan
    853                                    ; message between servers with the
    854                                    nickname for which the USER command
    855                                    belongs to
    856 
    857 4.1.4 Server message
    858 
    859       Command: SERVER
    860    Parameters: <servername> <hopcount> <info>
    861 
    862    The server message is used to tell a server that the other end of a
    863    new connection is a server. This message is also used to pass server
    864    data over whole net.  When a new server is connected to net,
    865    information about it be broadcast to the whole network.  <hopcount>
    866    is used to give all servers some internal information on how far away
    867    all servers are.  With a full server list, it would be possible to
    868    construct a map of the entire server tree, but hostmasks prevent this
    869    from being done.
    870 
    871    The SERVER message must only be accepted from either (a) a connection
    872    which is yet to be registered and is attempting to register as a
    873    server, or (b) an existing connection to another server, in  which
    874    case the SERVER message is introducing a new server behind that
    875    server.
    876 
    877    Most errors that occur with the receipt of a SERVER command result in
    878    the connection being terminated by the destination host (target
    879    SERVER).  Error replies are usually sent using the "ERROR" command
    880    rather than the numeric since the ERROR command has several useful
    881    properties which make it useful here.
    882 
    883    If a SERVER message is parsed and attempts to introduce a server
    884    which is already known to the receiving server, the connection from
    885    which that message must be closed (following the correct procedures),
    886    since a duplicate route to a server has formed and the acyclic nature
    887    of the IRC tree broken.
    888 
    889    Numeric Replies:
    890 
    891            ERR_ALREADYREGISTRED
    892 
    893    Example:
    894 
    895 
    896 
    897 
    898 Oikarinen & Reed                                               [Page 16]
    899 
    900 RFC 1459              Internet Relay Chat Protocol              May 1993
    901 
    902 
    903 SERVER test.oulu.fi 1 :[tolsun.oulu.fi] Experimental server
    904                                 ; New server test.oulu.fi introducing
    905                                 itself and attempting to register.  The
    906                                 name in []'s is the hostname for the
    907                                 host running test.oulu.fi.
    908 
    909 
    910 :tolsun.oulu.fi SERVER csd.bu.edu 5 :BU Central Server
    911                                 ; Server tolsun.oulu.fi is our uplink
    912                                 for csd.bu.edu which is 5 hops away.
    913 
    914 4.1.5 Oper
    915 
    916       Command: OPER
    917    Parameters: <user> <password>
    918 
    919    OPER message is used by a normal user to obtain operator privileges.
    920    The combination of <user> and <password> are required to gain
    921    Operator privileges.
    922 
    923    If the client sending the OPER command supplies the correct password
    924    for the given user, the server then informs the rest of the network
    925    of the new operator by issuing a "MODE +o" for the clients nickname.
    926 
    927    The OPER message is client-server only.
    928 
    929    Numeric Replies:
    930 
    931            ERR_NEEDMOREPARAMS              RPL_YOUREOPER
    932            ERR_NOOPERHOST                  ERR_PASSWDMISMATCH
    933 
    934    Example:
    935 
    936    OPER foo bar                    ; Attempt to register as an operator
    937                                    using a username of "foo" and "bar" as
    938                                    the password.
    939 
    940 4.1.6 Quit
    941 
    942       Command: QUIT
    943    Parameters: [<Quit message>]
    944 
    945    A client session is ended with a quit message.  The server must close
    946    the connection to a client which sends a QUIT message. If a "Quit
    947    Message" is given, this will be sent instead of the default message,
    948    the nickname.
    949 
    950    When netsplits (disconnecting of two servers) occur, the quit message
    951 
    952 
    953 
    954 Oikarinen & Reed                                               [Page 17]
    955 
    956 RFC 1459              Internet Relay Chat Protocol              May 1993
    957 
    958 
    959    is composed of the names of two servers involved, separated by a
    960    space.  The first name is that of the server which is still connected
    961    and the second name is that of the server that has become
    962    disconnected.
    963 
    964    If, for some other reason, a client connection is closed without  the
    965    client  issuing  a  QUIT  command  (e.g.  client  dies and EOF occurs
    966    on socket), the server is required to fill in the quit  message  with
    967    some sort  of  message  reflecting the nature of the event which
    968    caused it to happen.
    969 
    970    Numeric Replies:
    971 
    972            None.
    973 
    974    Examples:
    975 
    976    QUIT :Gone to have lunch        ; Preferred message format.
    977 
    978 4.1.7 Server quit message
    979 
    980       Command: SQUIT
    981    Parameters: <server> <comment>
    982 
    983    The SQUIT message is needed to tell about quitting or dead servers.
    984    If a server wishes to break the connection to another server it must
    985    send a SQUIT message to the other server, using the the name of the
    986    other server as the server parameter, which then closes its
    987    connection to the quitting server.
    988 
    989    This command is also available operators to help keep a network of
    990    IRC servers connected in an orderly fashion.  Operators may also
    991    issue an SQUIT message for a remote server connection.  In this case,
    992    the SQUIT must be parsed by each server inbetween the operator and
    993    the remote server, updating the view of the network held by each
    994    server as explained below.
    995 
    996    The <comment> should be supplied by all operators who execute a SQUIT
    997    for a remote server (that is not connected to the server they are
    998    currently on) so that other operators are aware for the reason of
    999    this action.  The <comment> is also filled in by servers which may
   1000    place an error or similar message here.
   1001 
   1002    Both of the servers which are on either side of the connection being
   1003    closed are required to to send out a SQUIT message (to all its other
   1004    server connections) for all other servers which are considered to be
   1005    behind that link.
   1006 
   1007 
   1008 
   1009 
   1010 Oikarinen & Reed                                               [Page 18]
   1011 
   1012 RFC 1459              Internet Relay Chat Protocol              May 1993
   1013 
   1014 
   1015    Similarly, a QUIT message must be sent to the other connected servers
   1016    rest of the network on behalf of all clients behind that link.  In
   1017    addition to this, all channel members of a channel which lost a
   1018    member due to the split must be sent a QUIT message.
   1019 
   1020    If a server connection is terminated prematurely (e.g. the server  on
   1021    the  other  end  of  the  link  died),  the  server  which  detects
   1022    this disconnection is required to inform the rest of  the  network
   1023    that  the connection  has  closed  and  fill  in  the comment field
   1024    with something appropriate.
   1025 
   1026    Numeric replies:
   1027 
   1028            ERR_NOPRIVILEGES                ERR_NOSUCHSERVER
   1029 
   1030    Example:
   1031 
   1032    SQUIT tolsun.oulu.fi :Bad Link ? ; the server link tolson.oulu.fi has
   1033                                    been terminated because of "Bad Link".
   1034 
   1035    :Trillian SQUIT cm22.eng.umd.edu :Server out of control
   1036                                     ; message from Trillian to disconnect
   1037                                    "cm22.eng.umd.edu" from the net
   1038                                     because "Server out of control".
   1039 
   1040 4.2 Channel operations
   1041 
   1042    This group of messages is concerned with manipulating channels, their
   1043    properties (channel modes), and their contents (typically clients).
   1044    In implementing these, a number of race conditions are inevitable
   1045    when clients at opposing ends of a network send commands which will
   1046    ultimately clash.  It is also required that servers keep a nickname
   1047    history to ensure that wherever a <nick> parameter is given, the
   1048    server check its history in case it has recently been changed.
   1049 
   1050 4.2.1 Join message
   1051 
   1052       Command: JOIN
   1053    Parameters: <channel>{,<channel>} [<key>{,<key>}]
   1054 
   1055    The JOIN command is used by client to start listening a specific
   1056    channel. Whether or not a client is allowed to join a channel is
   1057    checked only by the server the client is connected to; all other
   1058    servers automatically add the user to the channel when it is received
   1059    from other servers.  The conditions which affect this are as follows:
   1060 
   1061            1.  the user must be invited if the channel is invite-only;
   1062 
   1063 
   1064 
   1065 
   1066 Oikarinen & Reed                                               [Page 19]
   1067 
   1068 RFC 1459              Internet Relay Chat Protocol              May 1993
   1069 
   1070 
   1071            2.  the user's nick/username/hostname must not match any
   1072                active bans;
   1073 
   1074            3.  the correct key (password) must be given if it is set.
   1075 
   1076    These are discussed in more detail under the MODE command (see
   1077    section 4.2.3 for more details).
   1078 
   1079    Once a user has joined a channel, they receive notice about all
   1080    commands their server receives which affect the channel.  This
   1081    includes MODE, KICK, PART, QUIT and of course PRIVMSG/NOTICE.  The
   1082    JOIN command needs to be broadcast to all servers so that each server
   1083    knows where to find the users who are on the channel.  This allows
   1084    optimal delivery of PRIVMSG/NOTICE messages to the channel.
   1085 
   1086    If a JOIN is successful, the user is then sent the channel's topic
   1087    (using RPL_TOPIC) and the list of users who are on the channel (using
   1088    RPL_NAMREPLY), which must include the user joining.
   1089 
   1090    Numeric Replies:
   1091 
   1092            ERR_NEEDMOREPARAMS              ERR_BANNEDFROMCHAN
   1093            ERR_INVITEONLYCHAN              ERR_BADCHANNELKEY
   1094            ERR_CHANNELISFULL               ERR_BADCHANMASK
   1095            ERR_NOSUCHCHANNEL               ERR_TOOMANYCHANNELS
   1096            RPL_TOPIC
   1097 
   1098    Examples:
   1099 
   1100    JOIN #foobar                    ; join channel #foobar.
   1101 
   1102    JOIN &foo fubar                 ; join channel &foo using key "fubar".
   1103 
   1104    JOIN #foo,&bar fubar            ; join channel #foo using key "fubar"
   1105                                    and &bar using no key.
   1106 
   1107    JOIN #foo,#bar fubar,foobar     ; join channel #foo using key "fubar".
   1108                                    and channel #bar using key "foobar".
   1109 
   1110    JOIN #foo,#bar                  ; join channels #foo and #bar.
   1111 
   1112    :WiZ JOIN #Twilight_zone        ; JOIN message from WiZ
   1113 
   1114 4.2.2 Part message
   1115 
   1116       Command: PART
   1117    Parameters: <channel>{,<channel>}
   1118 
   1119 
   1120 
   1121 
   1122 Oikarinen & Reed                                               [Page 20]
   1123 
   1124 RFC 1459              Internet Relay Chat Protocol              May 1993
   1125 
   1126 
   1127    The PART message causes the client sending the message to be removed
   1128    from the list of active users for all given channels listed in the
   1129    parameter string.
   1130 
   1131    Numeric Replies:
   1132 
   1133            ERR_NEEDMOREPARAMS              ERR_NOSUCHCHANNEL
   1134            ERR_NOTONCHANNEL
   1135 
   1136    Examples:
   1137 
   1138    PART #twilight_zone             ; leave channel "#twilight_zone"
   1139 
   1140    PART #oz-ops,&group5            ; leave both channels "&group5" and
   1141                                    "#oz-ops".
   1142 
   1143 4.2.3 Mode message
   1144 
   1145       Command: MODE
   1146 
   1147    The MODE command is a dual-purpose command in IRC.  It allows both
   1148    usernames and channels to have their mode changed.  The rationale for
   1149    this choice is that one day nicknames will be obsolete and the
   1150    equivalent property will be the channel.
   1151 
   1152    When parsing MODE messages, it is recommended that the entire message
   1153    be parsed first and then the changes which resulted then passed on.
   1154 
   1155 4.2.3.1 Channel modes
   1156 
   1157    Parameters: <channel> {[+|-]|o|p|s|i|t|n|b|v} [<limit>] [<user>]
   1158                [<ban mask>]
   1159 
   1160    The MODE command is provided so that channel operators may change the
   1161    characteristics of `their' channel.  It is also required that servers
   1162    be able to change channel modes so that channel operators may be
   1163    created.
   1164 
   1165    The various modes available for channels are as follows:
   1166 
   1167            o - give/take channel operator privileges;
   1168            p - private channel flag;
   1169            s - secret channel flag;
   1170            i - invite-only channel flag;
   1171            t - topic settable by channel operator only flag;
   1172            n - no messages to channel from clients on the outside;
   1173            m - moderated channel;
   1174            l - set the user limit to channel;
   1175 
   1176 
   1177 
   1178 Oikarinen & Reed                                               [Page 21]
   1179 
   1180 RFC 1459              Internet Relay Chat Protocol              May 1993
   1181 
   1182 
   1183            b - set a ban mask to keep users out;
   1184            v - give/take the ability to speak on a moderated channel;
   1185            k - set a channel key (password).
   1186 
   1187    When using the 'o' and 'b' options, a restriction on a total of three
   1188    per mode command has been imposed.  That is, any combination of 'o'
   1189    and
   1190 
   1191 4.2.3.2 User modes
   1192 
   1193    Parameters: <nickname> {[+|-]|i|w|s|o}
   1194 
   1195    The user MODEs are typically changes which affect either how the
   1196    client is seen by others or what 'extra' messages the client is sent.
   1197    A user MODE command may only be accepted if both the sender of the
   1198    message and the nickname given as a parameter are both the same.
   1199 
   1200    The available modes are as follows:
   1201 
   1202            i - marks a users as invisible;
   1203            s - marks a user for receipt of server notices;
   1204            w - user receives wallops;
   1205            o - operator flag.
   1206 
   1207    Additional modes may be available later on.
   1208 
   1209    If a user attempts to make themselves an operator using the "+o"
   1210    flag, the attempt should be ignored.  There is no restriction,
   1211    however, on anyone `deopping' themselves (using "-o").  Numeric
   1212    Replies:
   1213 
   1214            ERR_NEEDMOREPARAMS              RPL_CHANNELMODEIS
   1215            ERR_CHANOPRIVSNEEDED            ERR_NOSUCHNICK
   1216            ERR_NOTONCHANNEL                ERR_KEYSET
   1217            RPL_BANLIST                     RPL_ENDOFBANLIST
   1218            ERR_UNKNOWNMODE                 ERR_NOSUCHCHANNEL
   1219 
   1220            ERR_USERSDONTMATCH              RPL_UMODEIS
   1221            ERR_UMODEUNKNOWNFLAG
   1222 
   1223    Examples:
   1224 
   1225            Use of Channel Modes:
   1226 
   1227 MODE #Finnish +im               ; Makes #Finnish channel moderated and
   1228                                 'invite-only'.
   1229 
   1230 MODE #Finnish +o Kilroy         ; Gives 'chanop' privileges to Kilroy on
   1231 
   1232 
   1233 
   1234 Oikarinen & Reed                                               [Page 22]
   1235 
   1236 RFC 1459              Internet Relay Chat Protocol              May 1993
   1237 
   1238 
   1239                                 channel #Finnish.
   1240 
   1241 MODE #Finnish +v Wiz            ; Allow WiZ to speak on #Finnish.
   1242 
   1243 MODE #Fins -s                   ; Removes 'secret' flag from channel
   1244                                 #Fins.
   1245 
   1246 MODE #42 +k oulu                ; Set the channel key to "oulu".
   1247 
   1248 MODE #eu-opers +l 10            ; Set the limit for the number of users
   1249                                 on channel to 10.
   1250 
   1251 MODE &oulu +b                   ; list ban masks set for channel.
   1252 
   1253 MODE &oulu +b *!*@*             ; prevent all users from joining.
   1254 
   1255 MODE &oulu +b *!*@*.edu         ; prevent any user from a hostname
   1256                                 matching *.edu from joining.
   1257 
   1258         Use of user Modes:
   1259 
   1260 :MODE WiZ -w                    ; turns reception of WALLOPS messages
   1261                                 off for WiZ.
   1262 
   1263 :Angel MODE Angel +i            ; Message from Angel to make themselves
   1264                                 invisible.
   1265 
   1266 MODE WiZ -o                     ; WiZ 'deopping' (removing operator
   1267                                 status).  The plain reverse of this
   1268                                 command ("MODE WiZ +o") must not be
   1269                                 allowed from users since would bypass
   1270                                 the OPER command.
   1271 
   1272 4.2.4 Topic message
   1273 
   1274       Command: TOPIC
   1275    Parameters: <channel> [<topic>]
   1276 
   1277    The TOPIC message is used to change or view the topic of a channel.
   1278    The topic for channel <channel> is returned if there is no <topic>
   1279    given.  If the <topic> parameter is present, the topic for that
   1280    channel will be changed, if the channel modes permit this action.
   1281 
   1282    Numeric Replies:
   1283 
   1284            ERR_NEEDMOREPARAMS              ERR_NOTONCHANNEL
   1285            RPL_NOTOPIC                     RPL_TOPIC
   1286            ERR_CHANOPRIVSNEEDED
   1287 
   1288 
   1289 
   1290 Oikarinen & Reed                                               [Page 23]
   1291 
   1292 RFC 1459              Internet Relay Chat Protocol              May 1993
   1293 
   1294 
   1295    Examples:
   1296 
   1297    :Wiz TOPIC #test :New topic     ;User Wiz setting the topic.
   1298 
   1299    TOPIC #test :another topic      ;set the topic on #test to "another
   1300                                    topic".
   1301 
   1302    TOPIC #test                     ; check the topic for #test.
   1303 
   1304 4.2.5 Names message
   1305 
   1306       Command: NAMES
   1307    Parameters: [<channel>{,<channel>}]
   1308 
   1309    By using the NAMES command, a user can list all nicknames that are
   1310    visible to them on any channel that they can see.  Channel names
   1311    which they can see are those which aren't private (+p) or secret (+s)
   1312    or those which they are actually on.  The <channel> parameter
   1313    specifies which channel(s) to return information about if valid.
   1314    There is no error reply for bad channel names.
   1315 
   1316    If no <channel> parameter is given, a list of all channels and their
   1317    occupants is returned.  At the end of this list, a list of users who
   1318    are visible but either not on any channel or not on a visible channel
   1319    are listed as being on `channel' "*".
   1320 
   1321    Numerics:
   1322 
   1323            RPL_NAMREPLY                    RPL_ENDOFNAMES
   1324 
   1325    Examples:
   1326 
   1327    NAMES #twilight_zone,#42        ; list visible users on #twilight_zone
   1328                                    and #42 if the channels are visible to
   1329                                    you.
   1330 
   1331    NAMES                           ; list all visible channels and users
   1332 
   1333 4.2.6 List message
   1334 
   1335       Command: LIST
   1336    Parameters: [<channel>{,<channel>} [<server>]]
   1337 
   1338    The list message is used to list channels and their topics.  If  the
   1339    <channel>  parameter  is  used,  only  the  status  of  that  channel
   1340    is displayed.  Private  channels  are  listed  (without  their
   1341    topics)  as channel "Prv" unless the client generating the query is
   1342    actually on that channel.  Likewise, secret channels are not listed
   1343 
   1344 
   1345 
   1346 Oikarinen & Reed                                               [Page 24]
   1347 
   1348 RFC 1459              Internet Relay Chat Protocol              May 1993
   1349 
   1350 
   1351    at  all  unless  the client is a member of the channel in question.
   1352 
   1353    Numeric Replies:
   1354 
   1355            ERR_NOSUCHSERVER                RPL_LISTSTART
   1356            RPL_LIST                        RPL_LISTEND
   1357 
   1358    Examples:
   1359 
   1360    LIST                            ; List all channels.
   1361 
   1362    LIST #twilight_zone,#42         ; List channels #twilight_zone and #42
   1363 
   1364 4.2.7 Invite message
   1365 
   1366       Command: INVITE
   1367    Parameters: <nickname> <channel>
   1368 
   1369    The INVITE message is used to invite users to a channel.  The
   1370    parameter <nickname> is the nickname of the person to be invited to
   1371    the target channel <channel>.  There is no requirement that the
   1372    channel the target user is being invited to must exist or be a valid
   1373    channel.  To invite a user to a channel which is invite only (MODE
   1374    +i), the client sending the invite must be recognised as being a
   1375    channel operator on the given channel.
   1376 
   1377    Numeric Replies:
   1378 
   1379            ERR_NEEDMOREPARAMS              ERR_NOSUCHNICK
   1380            ERR_NOTONCHANNEL                ERR_USERONCHANNEL
   1381            ERR_CHANOPRIVSNEEDED
   1382            RPL_INVITING                    RPL_AWAY
   1383 
   1384    Examples:
   1385 
   1386    :Angel INVITE Wiz #Dust         ; User Angel inviting WiZ to channel
   1387                                    #Dust
   1388 
   1389    INVITE Wiz #Twilight_Zone       ; Command to invite WiZ to
   1390                                    #Twilight_zone
   1391 
   1392 4.2.8 Kick command
   1393 
   1394       Command: KICK
   1395    Parameters: <channel> <user> [<comment>]
   1396 
   1397    The KICK command can be  used  to  forcibly  remove  a  user  from  a
   1398    channel.   It  'kicks  them  out'  of the channel (forced PART).
   1399 
   1400 
   1401 
   1402 Oikarinen & Reed                                               [Page 25]
   1403 
   1404 RFC 1459              Internet Relay Chat Protocol              May 1993
   1405 
   1406 
   1407    Only a channel operator may kick another user out of a  channel.
   1408    Each  server that  receives  a KICK message checks that it is valid
   1409    (ie the sender is actually a  channel  operator)  before  removing
   1410    the  victim  from  the channel.
   1411 
   1412    Numeric Replies:
   1413 
   1414            ERR_NEEDMOREPARAMS              ERR_NOSUCHCHANNEL
   1415            ERR_BADCHANMASK                 ERR_CHANOPRIVSNEEDED
   1416            ERR_NOTONCHANNEL
   1417 
   1418    Examples:
   1419 
   1420 KICK &Melbourne Matthew         ; Kick Matthew from &Melbourne
   1421 
   1422 KICK #Finnish John :Speaking English
   1423                                 ; Kick John from #Finnish using
   1424                                 "Speaking English" as the reason
   1425                                 (comment).
   1426 
   1427 :WiZ KICK #Finnish John         ; KICK message from WiZ to remove John
   1428                                 from channel #Finnish
   1429 
   1430 NOTE:
   1431      It is possible to extend the KICK command parameters to the
   1432 following:
   1433 
   1434 <channel>{,<channel>} <user>{,<user>} [<comment>]
   1435 
   1436 4.3 Server queries and commands
   1437 
   1438    The server query group of commands has been designed to return
   1439    information about any server which is connected to the network.  All
   1440    servers connected must respond to these queries and respond
   1441    correctly.  Any invalid response (or lack thereof) must be considered
   1442    a sign of a broken server and it must be disconnected/disabled as
   1443    soon as possible until the situation is remedied.
   1444 
   1445    In these queries, where a parameter appears as "<server>", it will
   1446    usually mean it can be a nickname or a server or a wildcard name of
   1447    some sort.  For each parameter, however, only one query and set of
   1448    replies is to be generated.
   1449 
   1450 4.3.1 Version message
   1451 
   1452       Command: VERSION
   1453    Parameters: [<server>]
   1454 
   1455 
   1456 
   1457 
   1458 Oikarinen & Reed                                               [Page 26]
   1459 
   1460 RFC 1459              Internet Relay Chat Protocol              May 1993
   1461 
   1462 
   1463    The VERSION message is used  to  query  the  version  of  the  server
   1464    program.  An optional parameter <server> is used to query the version
   1465    of the server program which a client is not directly connected to.
   1466 
   1467    Numeric Replies:
   1468 
   1469            ERR_NOSUCHSERVER                RPL_VERSION
   1470 
   1471    Examples:
   1472 
   1473    :Wiz VERSION *.se               ; message from Wiz to check the version
   1474                                    of a server matching "*.se"
   1475 
   1476    VERSION tolsun.oulu.fi          ; check the version of server
   1477                                    "tolsun.oulu.fi".
   1478 
   1479 4.3.2 Stats message
   1480 
   1481       Command: STATS
   1482    Parameters: [<query> [<server>]]
   1483 
   1484    The stats message is used to query statistics of certain server.  If
   1485    <server> parameter is omitted, only the end of stats reply is sent
   1486    back.  The implementation of this command is highly dependent on the
   1487    server which replies, although the server must be able to supply
   1488    information as described by the queries below (or similar).
   1489 
   1490    A query may be given by any single letter which is only checked by
   1491    the destination server (if given as the <server> parameter) and is
   1492    otherwise passed on by intermediate servers, ignored and unaltered.
   1493    The following queries are those found in the current IRC
   1494    implementation and provide a large portion of the setup information
   1495    for that server.  Although these may not be supported in the same way
   1496    by other versions, all servers should be able to supply a valid reply
   1497    to a STATS query which is consistent with the reply formats currently
   1498    used and the purpose of the query.
   1499 
   1500    The currently supported queries are:
   1501 
   1502            c - returns a list of servers which the server may connect
   1503                to or allow connections from;
   1504            h - returns a list of servers which are either forced to be
   1505                treated as leaves or allowed to act as hubs;
   1506            i - returns a list of hosts which the server allows a client
   1507                to connect from;
   1508            k - returns a list of banned username/hostname combinations
   1509                for that server;
   1510            l - returns a list of the server's connections, showing how
   1511 
   1512 
   1513 
   1514 Oikarinen & Reed                                               [Page 27]
   1515 
   1516 RFC 1459              Internet Relay Chat Protocol              May 1993
   1517 
   1518 
   1519                long each connection has been established and the traffic
   1520                over that connection in bytes and messages for each
   1521                direction;
   1522            m - returns a list of commands supported by the server and
   1523                the usage count for each if the usage count is non zero;
   1524            o - returns a list of hosts from which normal clients may
   1525                become operators;
   1526            y - show Y (Class) lines from server's configuration file;
   1527            u - returns a string showing how long the server has been up.
   1528 
   1529    Numeric Replies:
   1530 
   1531            ERR_NOSUCHSERVER
   1532            RPL_STATSCLINE                  RPL_STATSNLINE
   1533            RPL_STATSILINE                  RPL_STATSKLINE
   1534            RPL_STATSQLINE                  RPL_STATSLLINE
   1535            RPL_STATSLINKINFO               RPL_STATSUPTIME
   1536            RPL_STATSCOMMANDS               RPL_STATSOLINE
   1537            RPL_STATSHLINE                  RPL_ENDOFSTATS
   1538 
   1539    Examples:
   1540 
   1541 STATS m                         ; check the command usage for the server
   1542                                 you are connected to
   1543 
   1544 :Wiz STATS c eff.org            ; request by WiZ for C/N line
   1545                                 information from server eff.org
   1546 
   1547 4.3.3 Links message
   1548 
   1549       Command: LINKS
   1550    Parameters: [[<remote server>] <server mask>]
   1551 
   1552    With LINKS, a user can list all servers which are known by the server
   1553    answering the query.  The returned list of servers must match the
   1554    mask, or if no mask is given, the full list is returned.
   1555 
   1556    If <remote server> is given in addition to <server mask>, the LINKS
   1557    command is forwarded to the first server found that matches that name
   1558    (if any), and that server is then required to answer the query.
   1559 
   1560    Numeric Replies:
   1561 
   1562            ERR_NOSUCHSERVER
   1563            RPL_LINKS                       RPL_ENDOFLINKS
   1564 
   1565    Examples:
   1566 
   1567 
   1568 
   1569 
   1570 Oikarinen & Reed                                               [Page 28]
   1571 
   1572 RFC 1459              Internet Relay Chat Protocol              May 1993
   1573 
   1574 
   1575 LINKS *.au                      ; list all servers which have a name
   1576                                 that matches *.au;
   1577 
   1578 :WiZ LINKS *.bu.edu *.edu       ; LINKS message from WiZ to the first
   1579                                 server matching *.edu for a list of
   1580                                 servers matching *.bu.edu.
   1581 
   1582 4.3.4 Time message
   1583 
   1584       Command: TIME
   1585    Parameters: [<server>]
   1586 
   1587    The time message is used to query local time from the specified
   1588    server. If the server parameter is not given, the server handling the
   1589    command must reply to the query.
   1590 
   1591    Numeric Replies:
   1592 
   1593            ERR_NOSUCHSERVER                RPL_TIME
   1594 
   1595    Examples:
   1596 
   1597    TIME tolsun.oulu.fi             ; check the time on the server
   1598                                    "tolson.oulu.fi"
   1599 
   1600    Angel TIME *.au                 ; user angel checking the time on a
   1601                                    server matching "*.au"
   1602 
   1603 4.3.5 Connect message
   1604 
   1605       Command: CONNECT
   1606    Parameters: <target server> [<port> [<remote server>]]
   1607 
   1608    The CONNECT command can be used to force a server to try to establish
   1609    a new connection to another server immediately.  CONNECT is a
   1610    privileged command and is to be available only to IRC Operators.  If
   1611    a remote server is given then the CONNECT attempt is made by that
   1612    server to <target server> and <port>.
   1613 
   1614    Numeric Replies:
   1615 
   1616            ERR_NOSUCHSERVER                ERR_NOPRIVILEGES
   1617            ERR_NEEDMOREPARAMS
   1618 
   1619    Examples:
   1620 
   1621 CONNECT tolsun.oulu.fi          ; Attempt to connect a server to
   1622                                 tolsun.oulu.fi
   1623 
   1624 
   1625 
   1626 Oikarinen & Reed                                               [Page 29]
   1627 
   1628 RFC 1459              Internet Relay Chat Protocol              May 1993
   1629 
   1630 
   1631 :WiZ CONNECT eff.org 6667 csd.bu.edu
   1632                                 ; CONNECT attempt by WiZ to get servers
   1633                                 eff.org and csd.bu.edu connected on port
   1634                                 6667.
   1635 
   1636 4.3.6 Trace message
   1637 
   1638       Command: TRACE
   1639    Parameters: [<server>]
   1640 
   1641    TRACE command is used to find the route to specific server.  Each
   1642    server that processes this message must tell the sender about it by
   1643    sending a reply indicating it is a pass-through link, forming a chain
   1644    of replies similar to that gained from using "traceroute".  After
   1645    sending this reply back, it must then send the TRACE message to the
   1646    next server until given server is reached.  If the <server> parameter
   1647    is omitted, it is recommended that TRACE command send a message to
   1648    the sender telling which servers the current server has direct
   1649    connection to.
   1650 
   1651    If the destination given by "<server>" is an actual server, then the
   1652    destination server is required to report all servers and users which
   1653    are connected to it, although only operators are permitted to see
   1654    users present.  If the destination given by <server> is a nickname,
   1655    they only a reply for that nickname is given.
   1656 
   1657    Numeric Replies:
   1658 
   1659            ERR_NOSUCHSERVER
   1660 
   1661    If the TRACE message is destined for another server, all intermediate
   1662    servers must return a RPL_TRACELINK reply to indicate that the TRACE
   1663    passed through it and where its going next.
   1664 
   1665            RPL_TRACELINK
   1666    A TRACE reply may be composed of any number of the following numeric
   1667    replies.
   1668 
   1669            RPL_TRACECONNECTING             RPL_TRACEHANDSHAKE
   1670            RPL_TRACEUNKNOWN                RPL_TRACEOPERATOR
   1671            RPL_TRACEUSER                   RPL_TRACESERVER
   1672            RPL_TRACESERVICE                RPL_TRACENEWTYPE
   1673            RPL_TRACECLASS
   1674 
   1675    Examples:
   1676 
   1677 TRACE *.oulu.fi                 ; TRACE to a server matching *.oulu.fi
   1678 
   1679 
   1680 
   1681 
   1682 Oikarinen & Reed                                               [Page 30]
   1683 
   1684 RFC 1459              Internet Relay Chat Protocol              May 1993
   1685 
   1686 
   1687 :WiZ TRACE AngelDust            ; TRACE issued by WiZ to nick AngelDust
   1688 
   1689 4.3.7 Admin command
   1690 
   1691       Command: ADMIN
   1692    Parameters: [<server>]
   1693 
   1694    The admin message is used to find the name of the administrator of
   1695    the given server, or current server if <server> parameter is omitted.
   1696    Each server must have the ability to forward ADMIN messages to other
   1697    servers.
   1698 
   1699    Numeric Replies:
   1700 
   1701            ERR_NOSUCHSERVER
   1702            RPL_ADMINME                     RPL_ADMINLOC1
   1703            RPL_ADMINLOC2                   RPL_ADMINEMAIL
   1704 
   1705    Examples:
   1706 
   1707    ADMIN tolsun.oulu.fi            ; request an ADMIN reply from
   1708                                    tolsun.oulu.fi
   1709 
   1710    :WiZ ADMIN *.edu                ; ADMIN request from WiZ for first
   1711                                    server found to match *.edu.
   1712 
   1713 4.3.8 Info command
   1714 
   1715       Command: INFO
   1716    Parameters: [<server>]
   1717 
   1718    The INFO command is required to return information which describes
   1719    the server: its version, when it was compiled, the patchlevel, when
   1720    it was started, and any other miscellaneous information which may be
   1721    considered to be relevant.
   1722 
   1723    Numeric Replies:
   1724 
   1725            ERR_NOSUCHSERVER
   1726            RPL_INFO                        RPL_ENDOFINFO
   1727 
   1728    Examples:
   1729 
   1730    INFO csd.bu.edu                 ; request an INFO reply from
   1731    csd.bu.edu
   1732 
   1733    :Avalon INFO *.fi               ; INFO request from Avalon for first
   1734                                    server found to match *.fi.
   1735 
   1736 
   1737 
   1738 Oikarinen & Reed                                               [Page 31]
   1739 
   1740 RFC 1459              Internet Relay Chat Protocol              May 1993
   1741 
   1742 
   1743    INFO Angel                      ; request info from the server that
   1744                                    Angel is connected to.
   1745 
   1746 4.4 Sending messages
   1747 
   1748    The main purpose of the IRC protocol is to provide a base for clients
   1749    to communicate with each other.  PRIVMSG and NOTICE are the only
   1750    messages available which actually perform delivery of a text message
   1751    from one client to another - the rest just make it possible and try
   1752    to ensure it happens in a reliable and structured manner.
   1753 
   1754 4.4.1 Private messages
   1755 
   1756       Command: PRIVMSG
   1757    Parameters: <receiver>{,<receiver>} <text to be sent>
   1758 
   1759    PRIVMSG is used to send private messages between users.  <receiver>
   1760    is the nickname of the receiver of the message.  <receiver> can also
   1761    be a list of names or channels separated with commas.
   1762 
   1763    The <receiver> parameter may also me a host mask  (#mask)  or  server
   1764    mask  ($mask).   In  both cases the server will only send the PRIVMSG
   1765    to those who have a server or host matching the mask.  The mask  must
   1766    have at  least  1  (one)  "."  in it and no wildcards following the
   1767    last ".".  This requirement exists to prevent people sending messages
   1768    to  "#*"  or "$*",  which  would  broadcast  to  all  users; from
   1769    experience, this is abused more than used responsibly and properly.
   1770    Wildcards are  the  '*' and  '?'   characters.   This  extension  to
   1771    the PRIVMSG command is only available to Operators.
   1772 
   1773    Numeric Replies:
   1774 
   1775            ERR_NORECIPIENT                 ERR_NOTEXTTOSEND
   1776            ERR_CANNOTSENDTOCHAN            ERR_NOTOPLEVEL
   1777            ERR_WILDTOPLEVEL                ERR_TOOMANYTARGETS
   1778            ERR_NOSUCHNICK
   1779            RPL_AWAY
   1780 
   1781    Examples:
   1782 
   1783 :Angel PRIVMSG Wiz :Hello are you receiving this message ?
   1784                                 ; Message from Angel to Wiz.
   1785 
   1786 PRIVMSG Angel :yes I'm receiving it !receiving it !'u>(768u+1n) .br ;
   1787                                 Message to Angel.
   1788 
   1789 PRIVMSG jto@tolsun.oulu.fi :Hello !
   1790                                 ; Message to a client on server
   1791 
   1792 
   1793 
   1794 Oikarinen & Reed                                               [Page 32]
   1795 
   1796 RFC 1459              Internet Relay Chat Protocol              May 1993
   1797 
   1798 
   1799                                 tolsun.oulu.fi with username of "jto".
   1800 
   1801 PRIVMSG $*.fi :Server tolsun.oulu.fi rebooting.
   1802                                 ; Message to everyone on a server which
   1803                                 has a name matching *.fi.
   1804 
   1805 PRIVMSG #*.edu :NSFNet is undergoing work, expect interruptions
   1806                                 ; Message to all users who come from a
   1807                                 host which has a name matching *.edu.
   1808 
   1809 4.4.2 Notice
   1810 
   1811       Command: NOTICE
   1812    Parameters: <nickname> <text>
   1813 
   1814    The NOTICE message is used similarly to PRIVMSG.  The difference
   1815    between NOTICE and PRIVMSG is that automatic replies must never be
   1816    sent in response to a NOTICE message.  This rule applies to servers
   1817    too - they must not send any error reply back to the client on
   1818    receipt of a notice.  The object of this rule is to avoid loops
   1819    between a client automatically sending something in response to
   1820    something it received.  This is typically used by automatons (clients
   1821    with either an AI or other interactive program controlling their
   1822    actions) which are always seen to be replying lest they end up in a
   1823    loop with another automaton.
   1824 
   1825    See PRIVMSG for more details on replies and examples.
   1826 
   1827 4.5 User based queries
   1828 
   1829    User queries are a group of commands which are primarily concerned
   1830    with finding details on a particular user or group users.  When using
   1831    wildcards with any of these commands, if they match, they will only
   1832    return information on users who are 'visible' to you.  The visibility
   1833    of a user is determined as a combination of the user's mode and the
   1834    common set of channels you are both on.
   1835 
   1836 4.5.1 Who query
   1837 
   1838       Command: WHO
   1839    Parameters: [<name> [<o>]]
   1840 
   1841    The WHO message is used by a client to generate a query which returns
   1842    a list of information which 'matches' the <name> parameter given by
   1843    the client.  In the absence of the <name> parameter, all visible
   1844    (users who aren't invisible (user mode +i) and who don't have a
   1845    common channel with the requesting client) are listed.  The same
   1846    result can be achieved by using a <name> of "0" or any wildcard which
   1847 
   1848 
   1849 
   1850 Oikarinen & Reed                                               [Page 33]
   1851 
   1852 RFC 1459              Internet Relay Chat Protocol              May 1993
   1853 
   1854 
   1855    will end up matching every entry possible.
   1856 
   1857    The <name> passed to WHO is matched against users' host, server, real
   1858    name and nickname if the channel <name> cannot be found.
   1859 
   1860    If the "o" parameter is passed only operators are returned according
   1861    to the name mask supplied.
   1862 
   1863    Numeric Replies:
   1864 
   1865            ERR_NOSUCHSERVER
   1866            RPL_WHOREPLY                    RPL_ENDOFWHO
   1867 
   1868    Examples:
   1869 
   1870    WHO *.fi                        ; List all users who match against
   1871                                    "*.fi".
   1872 
   1873    WHO jto* o                      ; List all users with a match against
   1874                                    "jto*" if they are an operator.
   1875 
   1876 4.5.2 Whois query
   1877 
   1878       Command: WHOIS
   1879    Parameters: [<server>] <nickmask>[,<nickmask>[,...]]
   1880 
   1881    This message is used to query information about particular user.  The
   1882    server will answer this message with several numeric messages
   1883    indicating different statuses of each user which matches the nickmask
   1884    (if you are entitled to see them).  If no wildcard is present in the
   1885    <nickmask>, any information about that nick which you are allowed to
   1886    see is presented.  A comma (',') separated list of nicknames may be
   1887    given.
   1888 
   1889    The latter version sends the query to a specific server.  It is
   1890    useful if you want to know how long the user in question has been
   1891    idle as only local server (ie. the server the user is directly
   1892    connected to) knows that information, while everything else is
   1893    globally known.
   1894 
   1895    Numeric Replies:
   1896 
   1897            ERR_NOSUCHSERVER                ERR_NONICKNAMEGIVEN
   1898            RPL_WHOISUSER                   RPL_WHOISCHANNELS
   1899            RPL_WHOISCHANNELS               RPL_WHOISSERVER
   1900            RPL_AWAY                        RPL_WHOISOPERATOR
   1901            RPL_WHOISIDLE                   ERR_NOSUCHNICK
   1902            RPL_ENDOFWHOIS
   1903 
   1904 
   1905 
   1906 Oikarinen & Reed                                               [Page 34]
   1907 
   1908 RFC 1459              Internet Relay Chat Protocol              May 1993
   1909 
   1910 
   1911    Examples:
   1912 
   1913    WHOIS wiz                       ; return available user information
   1914                                    about nick WiZ
   1915 
   1916    WHOIS eff.org trillian          ; ask server eff.org for user
   1917                                    information about trillian
   1918 
   1919 4.5.3 Whowas
   1920 
   1921       Command: WHOWAS
   1922    Parameters: <nickname> [<count> [<server>]]
   1923 
   1924    Whowas asks for information about a nickname which no longer exists.
   1925    This may either be due to a nickname change or the user leaving IRC.
   1926    In response to this query, the server searches through its nickname
   1927    history, looking for any nicks which are lexically the same (no wild
   1928    card matching here).  The history is searched backward, returning the
   1929    most recent entry first.  If there are multiple entries, up to
   1930    <count> replies will be returned (or all of them if no <count>
   1931    parameter is given).  If a non-positive number is passed as being
   1932    <count>, then a full search is done.
   1933 
   1934    Numeric Replies:
   1935 
   1936            ERR_NONICKNAMEGIVEN             ERR_WASNOSUCHNICK
   1937            RPL_WHOWASUSER                  RPL_WHOISSERVER
   1938            RPL_ENDOFWHOWAS
   1939 
   1940    Examples:
   1941 
   1942    WHOWAS Wiz                      ; return all information in the nick
   1943                                    history about nick "WiZ";
   1944 
   1945    WHOWAS Mermaid 9                ; return at most, the 9 most recent
   1946                                    entries in the nick history for
   1947                                    "Mermaid";
   1948 
   1949    WHOWAS Trillian 1 *.edu         ; return the most recent history for
   1950                                    "Trillian" from the first server found
   1951                                    to match "*.edu".
   1952 
   1953 4.6 Miscellaneous messages
   1954 
   1955    Messages in this category do not fit into any of the above categories
   1956    but are nonetheless still a part of and required by the protocol.
   1957 
   1958 
   1959 
   1960 
   1961 
   1962 Oikarinen & Reed                                               [Page 35]
   1963 
   1964 RFC 1459              Internet Relay Chat Protocol              May 1993
   1965 
   1966 
   1967 4.6.1 Kill message
   1968 
   1969       Command: KILL
   1970    Parameters: <nickname> <comment>
   1971 
   1972    The KILL message is used to cause a client-server connection to be
   1973    closed by the server which has the actual connection.  KILL is used
   1974    by servers when they encounter a duplicate entry in the list of valid
   1975    nicknames and is used to remove both entries.  It is also available
   1976    to operators.
   1977 
   1978    Clients which have automatic reconnect algorithms effectively make
   1979    this command useless since the disconnection is only brief.  It does
   1980    however break the flow of data and can be used to stop large amounts
   1981    of being abused, any user may elect to receive KILL messages
   1982    generated for others to keep an 'eye' on would be trouble spots.
   1983 
   1984    In an arena where nicknames are required to be globally unique at all
   1985    times, KILL messages are sent whenever 'duplicates' are detected
   1986    (that is an attempt to register two users with the same nickname) in
   1987    the hope that both of them will disappear and only 1 reappear.
   1988 
   1989    The comment given must reflect the actual reason for the KILL.  For
   1990    server-generated KILLs it usually is made up of details concerning
   1991    the origins of the two conflicting nicknames.  For users it is left
   1992    up to them to provide an adequate reason to satisfy others who see
   1993    it.  To prevent/discourage fake KILLs from being generated to hide
   1994    the identify of the KILLer, the comment also shows a 'kill-path'
   1995    which is updated by each server it passes through, each prepending
   1996    its name to the path.
   1997 
   1998    Numeric Replies:
   1999 
   2000            ERR_NOPRIVILEGES                ERR_NEEDMOREPARAMS
   2001            ERR_NOSUCHNICK                  ERR_CANTKILLSERVER
   2002 
   2003 
   2004    KILL David (csd.bu.edu <- tolsun.oulu.fi)
   2005                                    ; Nickname collision between csd.bu.edu
   2006                                    and tolson.oulu.fi
   2007 
   2008 
   2009    NOTE:
   2010    It is recommended that only Operators be allowed to kill other users
   2011    with KILL message.  In an ideal world not even operators would need
   2012    to do this and it would be left to servers to deal with.
   2013 
   2014 
   2015 
   2016 
   2017 
   2018 Oikarinen & Reed                                               [Page 36]
   2019 
   2020 RFC 1459              Internet Relay Chat Protocol              May 1993
   2021 
   2022 
   2023 4.6.2 Ping message
   2024 
   2025       Command: PING
   2026    Parameters: <server1> [<server2>]
   2027 
   2028    The PING message is used to test the presence of an active client at
   2029    the other end of the connection.  A PING message is sent at regular
   2030    intervals if no other activity detected coming from a connection.  If
   2031    a connection fails to respond to a PING command within a set amount
   2032    of time, that connection is closed.
   2033 
   2034    Any client which receives a PING message must respond to <server1>
   2035    (server which sent the PING message out) as quickly as possible with
   2036    an appropriate PONG message to indicate it is still there and alive.
   2037    Servers should not respond to PING commands but rely on PINGs from
   2038    the other end of the connection to indicate the connection is alive.
   2039    If the <server2> parameter is specified, the PING message gets
   2040    forwarded there.
   2041 
   2042    Numeric Replies:
   2043 
   2044            ERR_NOORIGIN                    ERR_NOSUCHSERVER
   2045 
   2046    Examples:
   2047 
   2048    PING tolsun.oulu.fi             ; server sending a PING message to
   2049                                    another server to indicate it is still
   2050                                    alive.
   2051 
   2052    PING WiZ                        ; PING message being sent to nick WiZ
   2053 
   2054 4.6.3 Pong message
   2055 
   2056       Command: PONG
   2057    Parameters: <daemon> [<daemon2>]
   2058 
   2059    PONG message is a reply to ping message.  If parameter <daemon2> is
   2060    given this message must be forwarded to given daemon.  The <daemon>
   2061    parameter is the name of the daemon who has responded to PING message
   2062    and generated this message.
   2063 
   2064    Numeric Replies:
   2065 
   2066            ERR_NOORIGIN                    ERR_NOSUCHSERVER
   2067 
   2068    Examples:
   2069 
   2070    PONG csd.bu.edu tolsun.oulu.fi  ; PONG message from csd.bu.edu to
   2071 
   2072 
   2073 
   2074 Oikarinen & Reed                                               [Page 37]
   2075 
   2076 RFC 1459              Internet Relay Chat Protocol              May 1993
   2077 
   2078 
   2079                                    tolsun.oulu.fi
   2080 
   2081 4.6.4 Error
   2082 
   2083       Command: ERROR
   2084    Parameters: <error message>
   2085 
   2086    The ERROR command is for use by servers when reporting a serious or
   2087    fatal error to its operators.  It may also be sent from one server to
   2088    another but must not be accepted from any normal unknown clients.
   2089 
   2090    An ERROR message is for use for reporting errors which occur with a
   2091    server-to-server link only.  An ERROR message is sent to the server
   2092    at the other end (which sends it to all of its connected operators)
   2093    and to all operators currently connected.  It is not to be passed
   2094    onto any other servers by a server if it is received from a server.
   2095 
   2096    When a server sends a received ERROR message to its operators, the
   2097    message should be encapsulated inside a NOTICE message, indicating
   2098    that the client was not responsible for the error.
   2099 
   2100    Numerics:
   2101 
   2102            None.
   2103 
   2104    Examples:
   2105 
   2106    ERROR :Server *.fi already exists; ERROR message to the other server
   2107                                    which caused this error.
   2108 
   2109    NOTICE WiZ :ERROR from csd.bu.edu -- Server *.fi already exists
   2110                                    ; Same ERROR message as above but sent
   2111                                    to user WiZ on the other server.
   2112 
   2113 5. OPTIONALS
   2114 
   2115    This section describes OPTIONAL messages.  They are not required in a
   2116    working server implementation of the protocol described herein.  In
   2117    the absence of the option, an error reply message must be generated
   2118    or an unknown command error.  If the message is destined for another
   2119    server to answer then it must be passed on (elementary parsing
   2120    required) The allocated numerics for this are listed with the
   2121    messages below.
   2122 
   2123 5.1 Away
   2124 
   2125       Command: AWAY
   2126    Parameters: [message]
   2127 
   2128 
   2129 
   2130 Oikarinen & Reed                                               [Page 38]
   2131 
   2132 RFC 1459              Internet Relay Chat Protocol              May 1993
   2133 
   2134 
   2135    With the AWAY message, clients can set an automatic reply string for
   2136    any PRIVMSG commands directed at them (not to a channel they are on).
   2137    The automatic reply is sent by the server to client sending the
   2138    PRIVMSG command.  The only replying server is the one to which the
   2139    sending client is connected to.
   2140 
   2141    The AWAY message is used either with one parameter (to set an AWAY
   2142    message) or with no parameters (to remove the AWAY message).
   2143 
   2144    Numeric Replies:
   2145 
   2146            RPL_UNAWAY                      RPL_NOWAWAY
   2147 
   2148    Examples:
   2149 
   2150    AWAY :Gone to lunch.  Back in 5 ; set away message to "Gone to lunch.
   2151                                    Back in 5".
   2152 
   2153    :WiZ AWAY                       ; unmark WiZ as being away.
   2154 
   2155 
   2156 5.2 Rehash message
   2157 
   2158       Command: REHASH
   2159    Parameters: None
   2160 
   2161    The rehash message can be used by the operator to force the server to
   2162    re-read and process its configuration file.
   2163 
   2164    Numeric Replies:
   2165 
   2166         RPL_REHASHING                   ERR_NOPRIVILEGES
   2167 
   2168 Examples:
   2169 
   2170 REHASH                          ; message from client with operator
   2171                                 status to server asking it to reread its
   2172                                 configuration file.
   2173 
   2174 5.3 Restart message
   2175 
   2176       Command: RESTART
   2177    Parameters: None
   2178 
   2179    The restart message can only be used by an operator to force a server
   2180    restart itself.  This message is optional since it may be viewed as a
   2181    risk to allow arbitrary people to connect to a server as an operator
   2182    and execute this command, causing (at least) a disruption to service.
   2183 
   2184 
   2185 
   2186 Oikarinen & Reed                                               [Page 39]
   2187 
   2188 RFC 1459              Internet Relay Chat Protocol              May 1993
   2189 
   2190 
   2191    The RESTART command must always be fully processed by the server to
   2192    which the sending client is connected and not be passed onto other
   2193    connected servers.
   2194 
   2195    Numeric Replies:
   2196 
   2197            ERR_NOPRIVILEGES
   2198 
   2199    Examples:
   2200 
   2201    RESTART                         ; no parameters required.
   2202 
   2203 5.4 Summon message
   2204 
   2205       Command: SUMMON
   2206    Parameters: <user> [<server>]
   2207 
   2208    The SUMMON command can be used to give users who are on a host
   2209    running an IRC server a message asking them to please join IRC.  This
   2210    message is only sent if the target server (a) has SUMMON enabled, (b)
   2211    the user is logged in and (c) the server process can write to the
   2212    user's tty (or similar).
   2213 
   2214    If no <server> parameter is given it tries to summon <user> from the
   2215    server the client is connected to is assumed as the target.
   2216 
   2217    If summon is not enabled in a server, it must return the
   2218    ERR_SUMMONDISABLED numeric and pass the summon message onwards.
   2219 
   2220    Numeric Replies:
   2221 
   2222            ERR_NORECIPIENT                 ERR_FILEERROR
   2223            ERR_NOLOGIN                     ERR_NOSUCHSERVER
   2224            RPL_SUMMONING
   2225 
   2226    Examples:
   2227 
   2228    SUMMON jto                      ; summon user jto on the server's host
   2229 
   2230    SUMMON jto tolsun.oulu.fi       ; summon user jto on the host which a
   2231                                    server named "tolsun.oulu.fi" is
   2232                                    running.
   2233 
   2234 
   2235 5.5 Users
   2236 
   2237       Command: USERS
   2238    Parameters: [<server>]
   2239 
   2240 
   2241 
   2242 Oikarinen & Reed                                               [Page 40]
   2243 
   2244 RFC 1459              Internet Relay Chat Protocol              May 1993
   2245 
   2246 
   2247    The USERS command returns a list of users logged into the server in a
   2248    similar  format  to  who(1),  rusers(1)  and finger(1).  Some people
   2249    may disable this command on their server for security related
   2250    reasons.   If disabled, the correct numeric must be returned to
   2251    indicate this.
   2252 
   2253    Numeric Replies:
   2254 
   2255            ERR_NOSUCHSERVER                ERR_FILEERROR
   2256            RPL_USERSSTART                  RPL_USERS
   2257            RPL_NOUSERS                     RPL_ENDOFUSERS
   2258            ERR_USERSDISABLED
   2259 
   2260    Disabled Reply:
   2261 
   2262            ERR_USERSDISABLED
   2263 
   2264    Examples:
   2265 
   2266 USERS eff.org                   ; request a list of users logged in on
   2267                                 server eff.org
   2268 
   2269 :John USERS tolsun.oulu.fi      ; request from John for a list of users
   2270                                 logged in on server tolsun.oulu.fi
   2271 
   2272 5.6 Operwall message
   2273 
   2274       Command: WALLOPS
   2275    Parameters: Text to be sent to all operators currently online
   2276 
   2277    Sends  a  message  to  all   operators   currently   online.    After
   2278    implementing  WALLOPS  as  a user command it was found that it was
   2279    often and commonly abused as a means of sending a message to a lot
   2280    of  people (much  similar to WALL).  Due to this it is recommended
   2281    that the current implementation of  WALLOPS  be  used  as  an
   2282    example  by  allowing  and recognising only servers as the senders of
   2283    WALLOPS.
   2284 
   2285    Numeric Replies:
   2286 
   2287            ERR_NEEDMOREPARAMS
   2288 
   2289    Examples:
   2290 
   2291    :csd.bu.edu WALLOPS :Connect '*.uiuc.edu 6667' from Joshua; WALLOPS
   2292                                    message from csd.bu.edu announcing a
   2293                                    CONNECT message it received and acted
   2294                                    upon from Joshua.
   2295 
   2296 
   2297 
   2298 Oikarinen & Reed                                               [Page 41]
   2299 
   2300 RFC 1459              Internet Relay Chat Protocol              May 1993
   2301 
   2302 
   2303 5.7 Userhost message
   2304 
   2305       Command: USERHOST
   2306    Parameters: <nickname>{<space><nickname>}
   2307 
   2308    The USERHOST command takes a list of up to 5 nicknames, each
   2309    separated by a space character and returns a list of information
   2310    about each nickname that it found.  The returned list has each reply
   2311    separated by a space.
   2312 
   2313    Numeric Replies:
   2314 
   2315            RPL_USERHOST                    ERR_NEEDMOREPARAMS
   2316 
   2317    Examples:
   2318 
   2319    USERHOST Wiz Michael Marty p    ;USERHOST request for information on
   2320                                    nicks "Wiz", "Michael", "Marty" and "p"
   2321 
   2322 5.8 Ison message
   2323 
   2324       Command: ISON
   2325    Parameters: <nickname>{<space><nickname>}
   2326 
   2327    The ISON command was implemented to provide  a  quick  and  efficient
   2328    means  to get a response about whether a given nickname was currently
   2329    on IRC. ISON only takes one (1) parameter: a space-separated list of
   2330    nicks.  For  each  nickname in the list that is present, the server
   2331    adds that to its reply string.  Thus the reply string may return
   2332    empty (none  of  the given  nicks are present), an exact copy of the
   2333    parameter string (all of them present) or as any other subset of the
   2334    set of nicks  given  in  the parameter.  The only limit on the number
   2335    of nicks that may be checked is that the combined length must not be
   2336    too large as to cause the server to chop it off so it fits in 512
   2337    characters.
   2338 
   2339    ISON is only be processed by the server local to the client sending
   2340    the command and thus not passed onto other servers for further
   2341    processing.
   2342 
   2343    Numeric Replies:
   2344 
   2345            RPL_ISON                ERR_NEEDMOREPARAMS
   2346 
   2347    Examples:
   2348 
   2349    ISON phone trillian WiZ jarlek Avalon Angel Monstah
   2350                                    ; Sample ISON request for 7 nicks.
   2351 
   2352 
   2353 
   2354 Oikarinen & Reed                                               [Page 42]
   2355 
   2356 RFC 1459              Internet Relay Chat Protocol              May 1993
   2357 
   2358 
   2359 6. REPLIES
   2360 
   2361    The following is a list of numeric replies which are generated in
   2362    response to the commands given above.  Each numeric is given with its
   2363    number, name and reply string.
   2364 
   2365 6.1 Error Replies.
   2366 
   2367         401     ERR_NOSUCHNICK
   2368                         "<nickname> :No such nick/channel"
   2369 
   2370                 - Used to indicate the nickname parameter supplied to a
   2371                   command is currently unused.
   2372 
   2373         402     ERR_NOSUCHSERVER
   2374                         "<server name> :No such server"
   2375 
   2376                 - Used to indicate the server name given currently
   2377                   doesn't exist.
   2378 
   2379         403     ERR_NOSUCHCHANNEL
   2380                         "<channel name> :No such channel"
   2381 
   2382                 - Used to indicate the given channel name is invalid.
   2383 
   2384         404     ERR_CANNOTSENDTOCHAN
   2385                         "<channel name> :Cannot send to channel"
   2386 
   2387                 - Sent to a user who is either (a) not on a channel
   2388                   which is mode +n or (b) not a chanop (or mode +v) on
   2389                   a channel which has mode +m set and is trying to send
   2390                   a PRIVMSG message to that channel.
   2391 
   2392         405     ERR_TOOMANYCHANNELS
   2393                         "<channel name> :You have joined too many \
   2394                          channels"
   2395                 - Sent to a user when they have joined the maximum
   2396                   number of allowed channels and they try to join
   2397                   another channel.
   2398 
   2399         406     ERR_WASNOSUCHNICK
   2400                         "<nickname> :There was no such nickname"
   2401 
   2402                 - Returned by WHOWAS to indicate there is no history
   2403                   information for that nickname.
   2404 
   2405         407     ERR_TOOMANYTARGETS
   2406                         "<target> :Duplicate recipients. No message \
   2407 
   2408 
   2409 
   2410 Oikarinen & Reed                                               [Page 43]
   2411 
   2412 RFC 1459              Internet Relay Chat Protocol              May 1993
   2413 
   2414 
   2415                          delivered"
   2416 
   2417                 - Returned to a client which is attempting to send a
   2418                   PRIVMSG/NOTICE using the user@host destination format
   2419                   and for a user@host which has several occurrences.
   2420 
   2421         409     ERR_NOORIGIN
   2422                         ":No origin specified"
   2423 
   2424                 - PING or PONG message missing the originator parameter
   2425                   which is required since these commands must work
   2426                   without valid prefixes.
   2427 
   2428         411     ERR_NORECIPIENT
   2429                         ":No recipient given (<command>)"
   2430         412     ERR_NOTEXTTOSEND
   2431                         ":No text to send"
   2432         413     ERR_NOTOPLEVEL
   2433                         "<mask> :No toplevel domain specified"
   2434         414     ERR_WILDTOPLEVEL
   2435                         "<mask> :Wildcard in toplevel domain"
   2436 
   2437                 - 412 - 414 are returned by PRIVMSG to indicate that
   2438                   the message wasn't delivered for some reason.
   2439                   ERR_NOTOPLEVEL and ERR_WILDTOPLEVEL are errors that
   2440                   are returned when an invalid use of
   2441                   "PRIVMSG $<server>" or "PRIVMSG #<host>" is attempted.
   2442 
   2443         421     ERR_UNKNOWNCOMMAND
   2444                         "<command> :Unknown command"
   2445 
   2446                 - Returned to a registered client to indicate that the
   2447                   command sent is unknown by the server.
   2448 
   2449         422     ERR_NOMOTD
   2450                         ":MOTD File is missing"
   2451 
   2452                 - Server's MOTD file could not be opened by the server.
   2453 
   2454         423     ERR_NOADMININFO
   2455                         "<server> :No administrative info available"
   2456 
   2457                 - Returned by a server in response to an ADMIN message
   2458                   when there is an error in finding the appropriate
   2459                   information.
   2460 
   2461         424     ERR_FILEERROR
   2462                 ":File error doing <file op> on <file>"
   2463 
   2464 
   2465 
   2466 Oikarinen & Reed                                               [Page 44]
   2467 
   2468 RFC 1459              Internet Relay Chat Protocol              May 1993
   2469 
   2470 
   2471                 - Generic error message used to report a failed file
   2472                   operation during the processing of a message.
   2473 
   2474         431     ERR_NONICKNAMEGIVEN
   2475                         ":No nickname given"
   2476 
   2477                 - Returned when a nickname parameter expected for a
   2478                   command and isn't found.
   2479 
   2480         432     ERR_ERRONEUSNICKNAME
   2481                         "<nick> :Erroneus nickname"
   2482 
   2483                 - Returned after receiving a NICK message which contains
   2484                   characters which do not fall in the defined set.  See
   2485                   section x.x.x for details on valid nicknames.
   2486 
   2487         433     ERR_NICKNAMEINUSE
   2488                         "<nick> :Nickname is already in use"
   2489 
   2490                 - Returned when a NICK message is processed that results
   2491                   in an attempt to change to a currently existing
   2492                   nickname.
   2493 
   2494         436     ERR_NICKCOLLISION
   2495                         "<nick> :Nickname collision KILL"
   2496 
   2497                 - Returned by a server to a client when it detects a
   2498                   nickname collision (registered of a NICK that
   2499                   already exists by another server).
   2500 
   2501         441     ERR_USERNOTINCHANNEL
   2502                         "<nick> <channel> :They aren't on that channel"
   2503 
   2504                 - Returned by the server to indicate that the target
   2505                   user of the command is not on the given channel.
   2506 
   2507         442     ERR_NOTONCHANNEL
   2508                         "<channel> :You're not on that channel"
   2509 
   2510                 - Returned by the server whenever a client tries to
   2511                   perform a channel effecting command for which the
   2512                   client isn't a member.
   2513 
   2514         443     ERR_USERONCHANNEL
   2515                         "<user> <channel> :is already on channel"
   2516 
   2517                 - Returned when a client tries to invite a user to a
   2518                   channel they are already on.
   2519 
   2520 
   2521 
   2522 Oikarinen & Reed                                               [Page 45]
   2523 
   2524 RFC 1459              Internet Relay Chat Protocol              May 1993
   2525 
   2526 
   2527         444     ERR_NOLOGIN
   2528                         "<user> :User not logged in"
   2529 
   2530                 - Returned by the summon after a SUMMON command for a
   2531                   user was unable to be performed since they were not
   2532                   logged in.
   2533 
   2534         445     ERR_SUMMONDISABLED
   2535                         ":SUMMON has been disabled"
   2536 
   2537                 - Returned as a response to the SUMMON command.  Must be
   2538                   returned by any server which does not implement it.
   2539 
   2540         446     ERR_USERSDISABLED
   2541                         ":USERS has been disabled"
   2542 
   2543                 - Returned as a response to the USERS command.  Must be
   2544                   returned by any server which does not implement it.
   2545 
   2546         451     ERR_NOTREGISTERED
   2547                         ":You have not registered"
   2548 
   2549                 - Returned by the server to indicate that the client
   2550                   must be registered before the server will allow it
   2551                   to be parsed in detail.
   2552 
   2553         461     ERR_NEEDMOREPARAMS
   2554                         "<command> :Not enough parameters"
   2555 
   2556                 - Returned by the server by numerous commands to
   2557                   indicate to the client that it didn't supply enough
   2558                   parameters.
   2559 
   2560         462     ERR_ALREADYREGISTRED
   2561                         ":You may not reregister"
   2562 
   2563                 - Returned by the server to any link which tries to
   2564                   change part of the registered details (such as
   2565                   password or user details from second USER message).
   2566 
   2567 
   2568         463     ERR_NOPERMFORHOST
   2569                         ":Your host isn't among the privileged"
   2570 
   2571                 - Returned to a client which attempts to register with
   2572                   a server which does not been setup to allow
   2573                   connections from the host the attempted connection
   2574                   is tried.
   2575 
   2576 
   2577 
   2578 Oikarinen & Reed                                               [Page 46]
   2579 
   2580 RFC 1459              Internet Relay Chat Protocol              May 1993
   2581 
   2582 
   2583         464     ERR_PASSWDMISMATCH
   2584                         ":Password incorrect"
   2585 
   2586                 - Returned to indicate a failed attempt at registering
   2587                   a connection for which a password was required and
   2588                   was either not given or incorrect.
   2589 
   2590         465     ERR_YOUREBANNEDCREEP
   2591                         ":You are banned from this server"
   2592 
   2593                 - Returned after an attempt to connect and register
   2594                   yourself with a server which has been setup to
   2595                   explicitly deny connections to you.
   2596 
   2597         467     ERR_KEYSET
   2598                         "<channel> :Channel key already set"
   2599         471     ERR_CHANNELISFULL
   2600                         "<channel> :Cannot join channel (+l)"
   2601         472     ERR_UNKNOWNMODE
   2602                         "<char> :is unknown mode char to me"
   2603         473     ERR_INVITEONLYCHAN
   2604                         "<channel> :Cannot join channel (+i)"
   2605         474     ERR_BANNEDFROMCHAN
   2606                         "<channel> :Cannot join channel (+b)"
   2607         475     ERR_BADCHANNELKEY
   2608                         "<channel> :Cannot join channel (+k)"
   2609         481     ERR_NOPRIVILEGES
   2610                         ":Permission Denied- You're not an IRC operator"
   2611 
   2612                 - Any command requiring operator privileges to operate
   2613                   must return this error to indicate the attempt was
   2614                   unsuccessful.
   2615 
   2616         482     ERR_CHANOPRIVSNEEDED
   2617                         "<channel> :You're not channel operator"
   2618 
   2619                 - Any command requiring 'chanop' privileges (such as
   2620                   MODE messages) must return this error if the client
   2621                   making the attempt is not a chanop on the specified
   2622                   channel.
   2623 
   2624         483     ERR_CANTKILLSERVER
   2625                         ":You cant kill a server!"
   2626 
   2627                 - Any attempts to use the KILL command on a server
   2628                   are to be refused and this error returned directly
   2629                   to the client.
   2630 
   2631 
   2632 
   2633 
   2634 Oikarinen & Reed                                               [Page 47]
   2635 
   2636 RFC 1459              Internet Relay Chat Protocol              May 1993
   2637 
   2638 
   2639         491     ERR_NOOPERHOST
   2640                         ":No O-lines for your host"
   2641 
   2642                 - If a client sends an OPER message and the server has
   2643                   not been configured to allow connections from the
   2644                   client's host as an operator, this error must be
   2645                   returned.
   2646 
   2647         501     ERR_UMODEUNKNOWNFLAG
   2648                         ":Unknown MODE flag"
   2649 
   2650                 - Returned by the server to indicate that a MODE
   2651                   message was sent with a nickname parameter and that
   2652                   the a mode flag sent was not recognized.
   2653 
   2654         502     ERR_USERSDONTMATCH
   2655                         ":Cant change mode for other users"
   2656 
   2657                 - Error sent to any user trying to view or change the
   2658                   user mode for a user other than themselves.
   2659 
   2660 6.2 Command responses.
   2661 
   2662         300     RPL_NONE
   2663                         Dummy reply number. Not used.
   2664 
   2665         302     RPL_USERHOST
   2666                         ":[<reply>{<space><reply>}]"
   2667 
   2668                 - Reply format used by USERHOST to list replies to
   2669                   the query list.  The reply string is composed as
   2670                   follows:
   2671 
   2672                   <reply> ::= <nick>['*'] '=' <'+'|'-'><hostname>
   2673 
   2674                   The '*' indicates whether the client has registered
   2675                   as an Operator.  The '-' or '+' characters represent
   2676                   whether the client has set an AWAY message or not
   2677                   respectively.
   2678 
   2679         303     RPL_ISON
   2680                         ":[<nick> {<space><nick>}]"
   2681 
   2682                 - Reply format used by ISON to list replies to the
   2683                   query list.
   2684 
   2685         301     RPL_AWAY
   2686                         "<nick> :<away message>"
   2687 
   2688 
   2689 
   2690 Oikarinen & Reed                                               [Page 48]
   2691 
   2692 RFC 1459              Internet Relay Chat Protocol              May 1993
   2693 
   2694 
   2695         305     RPL_UNAWAY
   2696                         ":You are no longer marked as being away"
   2697         306     RPL_NOWAWAY
   2698                         ":You have been marked as being away"
   2699 
   2700                 - These replies are used with the AWAY command (if
   2701                   allowed).  RPL_AWAY is sent to any client sending a
   2702                   PRIVMSG to a client which is away.  RPL_AWAY is only
   2703                   sent by the server to which the client is connected.
   2704                   Replies RPL_UNAWAY and RPL_NOWAWAY are sent when the
   2705                   client removes and sets an AWAY message.
   2706 
   2707         311     RPL_WHOISUSER
   2708                         "<nick> <user> <host> * :<real name>"
   2709         312     RPL_WHOISSERVER
   2710                         "<nick> <server> :<server info>"
   2711         313     RPL_WHOISOPERATOR
   2712                         "<nick> :is an IRC operator"
   2713         317     RPL_WHOISIDLE
   2714                         "<nick> <integer> :seconds idle"
   2715         318     RPL_ENDOFWHOIS
   2716                         "<nick> :End of /WHOIS list"
   2717         319     RPL_WHOISCHANNELS
   2718                         "<nick> :{[@|+]<channel><space>}"
   2719 
   2720                 - Replies 311 - 313, 317 - 319 are all replies
   2721                   generated in response to a WHOIS message.  Given that
   2722                   there are enough parameters present, the answering
   2723                   server must either formulate a reply out of the above
   2724                   numerics (if the query nick is found) or return an
   2725                   error reply.  The '*' in RPL_WHOISUSER is there as
   2726                   the literal character and not as a wild card.  For
   2727                   each reply set, only RPL_WHOISCHANNELS may appear
   2728                   more than once (for long lists of channel names).
   2729                   The '@' and '+' characters next to the channel name
   2730                   indicate whether a client is a channel operator or
   2731                   has been granted permission to speak on a moderated
   2732                   channel.  The RPL_ENDOFWHOIS reply is used to mark
   2733                   the end of processing a WHOIS message.
   2734 
   2735         314     RPL_WHOWASUSER
   2736                         "<nick> <user> <host> * :<real name>"
   2737         369     RPL_ENDOFWHOWAS
   2738                         "<nick> :End of WHOWAS"
   2739 
   2740                 - When replying to a WHOWAS message, a server must use
   2741                   the replies RPL_WHOWASUSER, RPL_WHOISSERVER or
   2742                   ERR_WASNOSUCHNICK for each nickname in the presented
   2743 
   2744 
   2745 
   2746 Oikarinen & Reed                                               [Page 49]
   2747 
   2748 RFC 1459              Internet Relay Chat Protocol              May 1993
   2749 
   2750 
   2751                   list.  At the end of all reply batches, there must
   2752                   be RPL_ENDOFWHOWAS (even if there was only one reply
   2753                   and it was an error).
   2754 
   2755         321     RPL_LISTSTART
   2756                         "Channel :Users  Name"
   2757         322     RPL_LIST
   2758                         "<channel> <# visible> :<topic>"
   2759         323     RPL_LISTEND
   2760                         ":End of /LIST"
   2761 
   2762                 - Replies RPL_LISTSTART, RPL_LIST, RPL_LISTEND mark
   2763                   the start, actual replies with data and end of the
   2764                   server's response to a LIST command.  If there are
   2765                   no channels available to return, only the start
   2766                   and end reply must be sent.
   2767 
   2768         324     RPL_CHANNELMODEIS
   2769                         "<channel> <mode> <mode params>"
   2770 
   2771         331     RPL_NOTOPIC
   2772                         "<channel> :No topic is set"
   2773         332     RPL_TOPIC
   2774                         "<channel> :<topic>"
   2775 
   2776                 - When sending a TOPIC message to determine the
   2777                   channel topic, one of two replies is sent.  If
   2778                   the topic is set, RPL_TOPIC is sent back else
   2779                   RPL_NOTOPIC.
   2780 
   2781         341     RPL_INVITING
   2782                         "<channel> <nick>"
   2783 
   2784                 - Returned by the server to indicate that the
   2785                   attempted INVITE message was successful and is
   2786                   being passed onto the end client.
   2787 
   2788         342     RPL_SUMMONING
   2789                         "<user> :Summoning user to IRC"
   2790 
   2791                 - Returned by a server answering a SUMMON message to
   2792                   indicate that it is summoning that user.
   2793 
   2794         351     RPL_VERSION
   2795                         "<version>.<debuglevel> <server> :<comments>"
   2796 
   2797                 - Reply by the server showing its version details.
   2798                   The <version> is the version of the software being
   2799 
   2800 
   2801 
   2802 Oikarinen & Reed                                               [Page 50]
   2803 
   2804 RFC 1459              Internet Relay Chat Protocol              May 1993
   2805 
   2806 
   2807                   used (including any patchlevel revisions) and the
   2808                   <debuglevel> is used to indicate if the server is
   2809                   running in "debug mode".
   2810 
   2811                   The "comments" field may contain any comments about
   2812                   the version or further version details.
   2813 
   2814         352     RPL_WHOREPLY
   2815                         "<channel> <user> <host> <server> <nick> \
   2816                          <H|G>[*][@|+] :<hopcount> <real name>"
   2817         315     RPL_ENDOFWHO
   2818                         "<name> :End of /WHO list"
   2819 
   2820                 - The RPL_WHOREPLY and RPL_ENDOFWHO pair are used
   2821                   to answer a WHO message.  The RPL_WHOREPLY is only
   2822                   sent if there is an appropriate match to the WHO
   2823                   query.  If there is a list of parameters supplied
   2824                   with a WHO message, a RPL_ENDOFWHO must be sent
   2825                   after processing each list item with <name> being
   2826                   the item.
   2827 
   2828         353     RPL_NAMREPLY
   2829                         "<channel> :[[@|+]<nick> [[@|+]<nick> [...]]]"
   2830         366     RPL_ENDOFNAMES
   2831                         "<channel> :End of /NAMES list"
   2832 
   2833                 - To reply to a NAMES message, a reply pair consisting
   2834                   of RPL_NAMREPLY and RPL_ENDOFNAMES is sent by the
   2835                   server back to the client.  If there is no channel
   2836                   found as in the query, then only RPL_ENDOFNAMES is
   2837                   returned.  The exception to this is when a NAMES
   2838                   message is sent with no parameters and all visible
   2839                   channels and contents are sent back in a series of
   2840                   RPL_NAMEREPLY messages with a RPL_ENDOFNAMES to mark
   2841                   the end.
   2842 
   2843         364     RPL_LINKS
   2844                         "<mask> <server> :<hopcount> <server info>"
   2845         365     RPL_ENDOFLINKS
   2846                         "<mask> :End of /LINKS list"
   2847 
   2848                 - In replying to the LINKS message, a server must send
   2849                   replies back using the RPL_LINKS numeric and mark the
   2850                   end of the list using an RPL_ENDOFLINKS reply.
   2851 
   2852         367     RPL_BANLIST
   2853                         "<channel> <banid>"
   2854         368     RPL_ENDOFBANLIST
   2855 
   2856 
   2857 
   2858 Oikarinen & Reed                                               [Page 51]
   2859 
   2860 RFC 1459              Internet Relay Chat Protocol              May 1993
   2861 
   2862 
   2863                         "<channel> :End of channel ban list"
   2864 
   2865                 - When listing the active 'bans' for a given channel,
   2866                   a server is required to send the list back using the
   2867                   RPL_BANLIST and RPL_ENDOFBANLIST messages.  A separate
   2868                   RPL_BANLIST is sent for each active banid.  After the
   2869                   banids have been listed (or if none present) a
   2870                   RPL_ENDOFBANLIST must be sent.
   2871 
   2872         371     RPL_INFO
   2873                         ":<string>"
   2874         374     RPL_ENDOFINFO
   2875                         ":End of /INFO list"
   2876 
   2877                 - A server responding to an INFO message is required to
   2878                   send all its 'info' in a series of RPL_INFO messages
   2879                   with a RPL_ENDOFINFO reply to indicate the end of the
   2880                   replies.
   2881 
   2882         375     RPL_MOTDSTART
   2883                         ":- <server> Message of the day - "
   2884         372     RPL_MOTD
   2885                         ":- <text>"
   2886         376     RPL_ENDOFMOTD
   2887                         ":End of /MOTD command"
   2888 
   2889                 - When responding to the MOTD message and the MOTD file
   2890                   is found, the file is displayed line by line, with
   2891                   each line no longer than 80 characters, using
   2892                   RPL_MOTD format replies.  These should be surrounded
   2893                   by a RPL_MOTDSTART (before the RPL_MOTDs) and an
   2894                   RPL_ENDOFMOTD (after).
   2895 
   2896         381     RPL_YOUREOPER
   2897                         ":You are now an IRC operator"
   2898 
   2899                 - RPL_YOUREOPER is sent back to a client which has
   2900                   just successfully issued an OPER message and gained
   2901                   operator status.
   2902 
   2903         382     RPL_REHASHING
   2904                         "<config file> :Rehashing"
   2905 
   2906                 - If the REHASH option is used and an operator sends
   2907                   a REHASH message, an RPL_REHASHING is sent back to
   2908                   the operator.
   2909 
   2910         391     RPL_TIME
   2911 
   2912 
   2913 
   2914 Oikarinen & Reed                                               [Page 52]
   2915 
   2916 RFC 1459              Internet Relay Chat Protocol              May 1993
   2917 
   2918 
   2919                         "<server> :<string showing server's local time>"
   2920 
   2921                 - When replying to the TIME message, a server must send
   2922                   the reply using the RPL_TIME format above.  The string
   2923                   showing the time need only contain the correct day and
   2924                   time there.  There is no further requirement for the
   2925                   time string.
   2926 
   2927         392     RPL_USERSSTART
   2928                         ":UserID   Terminal  Host"
   2929         393     RPL_USERS
   2930                         ":%-8s %-9s %-8s"
   2931         394     RPL_ENDOFUSERS
   2932                         ":End of users"
   2933         395     RPL_NOUSERS
   2934                         ":Nobody logged in"
   2935 
   2936                 - If the USERS message is handled by a server, the
   2937                   replies RPL_USERSTART, RPL_USERS, RPL_ENDOFUSERS and
   2938                   RPL_NOUSERS are used.  RPL_USERSSTART must be sent
   2939                   first, following by either a sequence of RPL_USERS
   2940                   or a single RPL_NOUSER.  Following this is
   2941                   RPL_ENDOFUSERS.
   2942 
   2943         200     RPL_TRACELINK
   2944                         "Link <version & debug level> <destination> \
   2945                          <next server>"
   2946         201     RPL_TRACECONNECTING
   2947                         "Try. <class> <server>"
   2948         202     RPL_TRACEHANDSHAKE
   2949                         "H.S. <class> <server>"
   2950         203     RPL_TRACEUNKNOWN
   2951                         "???? <class> [<client IP address in dot form>]"
   2952         204     RPL_TRACEOPERATOR
   2953                         "Oper <class> <nick>"
   2954         205     RPL_TRACEUSER
   2955                         "User <class> <nick>"
   2956         206     RPL_TRACESERVER
   2957                         "Serv <class> <int>S <int>C <server> \
   2958                          <nick!user|*!*>@<host|server>"
   2959         208     RPL_TRACENEWTYPE
   2960                         "<newtype> 0 <client name>"
   2961         261     RPL_TRACELOG
   2962                         "File <logfile> <debug level>"
   2963 
   2964                 - The RPL_TRACE* are all returned by the server in
   2965                   response to the TRACE message.  How many are
   2966                   returned is dependent on the the TRACE message and
   2967 
   2968 
   2969 
   2970 Oikarinen & Reed                                               [Page 53]
   2971 
   2972 RFC 1459              Internet Relay Chat Protocol              May 1993
   2973 
   2974 
   2975                   whether it was sent by an operator or not.  There
   2976                   is no predefined order for which occurs first.
   2977                   Replies RPL_TRACEUNKNOWN, RPL_TRACECONNECTING and
   2978                   RPL_TRACEHANDSHAKE are all used for connections
   2979                   which have not been fully established and are either
   2980                   unknown, still attempting to connect or in the
   2981                   process of completing the 'server handshake'.
   2982                   RPL_TRACELINK is sent by any server which handles
   2983                   a TRACE message and has to pass it on to another
   2984                   server.  The list of RPL_TRACELINKs sent in
   2985                   response to a TRACE command traversing the IRC
   2986                   network should reflect the actual connectivity of
   2987                   the servers themselves along that path.
   2988                   RPL_TRACENEWTYPE is to be used for any connection
   2989                   which does not fit in the other categories but is
   2990                   being displayed anyway.
   2991 
   2992         211     RPL_STATSLINKINFO
   2993                         "<linkname> <sendq> <sent messages> \
   2994                          <sent bytes> <received messages> \
   2995                          <received bytes> <time open>"
   2996         212     RPL_STATSCOMMANDS
   2997                         "<command> <count>"
   2998         213     RPL_STATSCLINE
   2999                         "C <host> * <name> <port> <class>"
   3000         214     RPL_STATSNLINE
   3001                         "N <host> * <name> <port> <class>"
   3002         215     RPL_STATSILINE
   3003                         "I <host> * <host> <port> <class>"
   3004         216     RPL_STATSKLINE
   3005                         "K <host> * <username> <port> <class>"
   3006         218     RPL_STATSYLINE
   3007                         "Y <class> <ping frequency> <connect \
   3008                          frequency> <max sendq>"
   3009         219     RPL_ENDOFSTATS
   3010                         "<stats letter> :End of /STATS report"
   3011         241     RPL_STATSLLINE
   3012                         "L <hostmask> * <servername> <maxdepth>"
   3013         242     RPL_STATSUPTIME
   3014                         ":Server Up %d days %d:%02d:%02d"
   3015         243     RPL_STATSOLINE
   3016                         "O <hostmask> * <name>"
   3017         244     RPL_STATSHLINE
   3018                         "H <hostmask> * <servername>"
   3019 
   3020         221     RPL_UMODEIS
   3021                         "<user mode string>"
   3022 
   3023 
   3024 
   3025 
   3026 Oikarinen & Reed                                               [Page 54]
   3027 
   3028 RFC 1459              Internet Relay Chat Protocol              May 1993
   3029 
   3030 
   3031                         - To answer a query about a client's own mode,
   3032                           RPL_UMODEIS is sent back.
   3033 
   3034         251     RPL_LUSERCLIENT
   3035                         ":There are <integer> users and <integer> \
   3036                          invisible on <integer> servers"
   3037         252     RPL_LUSEROP
   3038                         "<integer> :operator(s) online"
   3039         253     RPL_LUSERUNKNOWN
   3040                         "<integer> :unknown connection(s)"
   3041         254     RPL_LUSERCHANNELS
   3042                         "<integer> :channels formed"
   3043         255     RPL_LUSERME
   3044                         ":I have <integer> clients and <integer> \
   3045                           servers"
   3046 
   3047                         - In processing an LUSERS message, the server
   3048                           sends a set of replies from RPL_LUSERCLIENT,
   3049                           RPL_LUSEROP, RPL_USERUNKNOWN,
   3050                           RPL_LUSERCHANNELS and RPL_LUSERME.  When
   3051                           replying, a server must send back
   3052                           RPL_LUSERCLIENT and RPL_LUSERME.  The other
   3053                           replies are only sent back if a non-zero count
   3054                           is found for them.
   3055 
   3056         256     RPL_ADMINME
   3057                         "<server> :Administrative info"
   3058         257     RPL_ADMINLOC1
   3059                         ":<admin info>"
   3060         258     RPL_ADMINLOC2
   3061                         ":<admin info>"
   3062         259     RPL_ADMINEMAIL
   3063                         ":<admin info>"
   3064 
   3065                         - When replying to an ADMIN message, a server
   3066                           is expected to use replies RLP_ADMINME
   3067                           through to RPL_ADMINEMAIL and provide a text
   3068                           message with each.  For RPL_ADMINLOC1 a
   3069                           description of what city, state and country
   3070                           the server is in is expected, followed by
   3071                           details of the university and department
   3072                           (RPL_ADMINLOC2) and finally the administrative
   3073                           contact for the server (an email address here
   3074                           is required) in RPL_ADMINEMAIL.
   3075 
   3076 
   3077 
   3078 
   3079 
   3080 
   3081 
   3082 Oikarinen & Reed                                               [Page 55]
   3083 
   3084 RFC 1459              Internet Relay Chat Protocol              May 1993
   3085 
   3086 
   3087 6.3 Reserved numerics.
   3088 
   3089    These numerics are not described above since they fall into one of
   3090    the following categories:
   3091 
   3092         1. no longer in use;
   3093 
   3094         2. reserved for future planned use;
   3095 
   3096         3. in current use but are part of a non-generic 'feature' of
   3097            the current IRC server.
   3098 
   3099         209     RPL_TRACECLASS          217     RPL_STATSQLINE
   3100         231     RPL_SERVICEINFO         232     RPL_ENDOFSERVICES
   3101         233     RPL_SERVICE             234     RPL_SERVLIST
   3102         235     RPL_SERVLISTEND
   3103         316     RPL_WHOISCHANOP         361     RPL_KILLDONE
   3104         362     RPL_CLOSING             363     RPL_CLOSEEND
   3105         373     RPL_INFOSTART           384     RPL_MYPORTIS
   3106         466     ERR_YOUWILLBEBANNED     476     ERR_BADCHANMASK
   3107         492     ERR_NOSERVICEHOST
   3108 
   3109 7. Client and server authentication
   3110 
   3111    Clients and servers are both subject to the same level of
   3112    authentication.  For both, an IP number to hostname lookup (and
   3113    reverse check on this) is performed for all connections made to the
   3114    server.  Both connections are then subject to a password check (if
   3115    there is a password set for that connection).  These checks are
   3116    possible on all connections although the password check is only
   3117    commonly used with servers.
   3118 
   3119    An additional check that is becoming of more and more common is that
   3120    of the username responsible for making the connection.  Finding the
   3121    username of the other end of the connection typically involves
   3122    connecting to an authentication server such as IDENT as described in
   3123    RFC 1413.
   3124 
   3125    Given that without passwords it is not easy to reliably determine who
   3126    is on the other end of a network connection, use of passwords is
   3127    strongly recommended on inter-server connections in addition to any
   3128    other measures such as using an ident server.
   3129 
   3130 8. Current implementations
   3131 
   3132    The only current implementation of this protocol is the IRC server,
   3133    version 2.8. Earlier versions may implement some or all of the
   3134    commands described by this document with NOTICE messages replacing
   3135 
   3136 
   3137 
   3138 Oikarinen & Reed                                               [Page 56]
   3139 
   3140 RFC 1459              Internet Relay Chat Protocol              May 1993
   3141 
   3142 
   3143    many of the numeric replies.  Unfortunately, due to backward
   3144    compatibility requirements, the implementation of some parts of this
   3145    document varies with what is laid out.  On notable difference is:
   3146 
   3147         * recognition that any LF or CR anywhere in a message marks the
   3148           end of that message (instead of requiring CR-LF);
   3149 
   3150    The rest of this section deals with issues that are mostly of
   3151    importance to those who wish to implement a server but some parts
   3152    also apply directly to clients as well.
   3153 
   3154 8.1 Network protocol: TCP - why it is best used here.
   3155 
   3156    IRC has been implemented on top of TCP since TCP supplies a reliable
   3157    network protocol which is well suited to this scale of conferencing.
   3158    The use of multicast IP is an alternative, but it is not widely
   3159    available or supported at the present time.
   3160 
   3161 8.1.1 Support of Unix sockets
   3162 
   3163    Given that Unix domain sockets allow listen/connect operations, the
   3164    current implementation can be configured to listen and accept both
   3165    client and server connections on a Unix domain socket.  These are
   3166    recognized as sockets where the hostname starts with a '/'.
   3167 
   3168    When providing any information about the connections on a Unix domain
   3169    socket, the server is required to supplant the actual hostname in
   3170    place of the pathname unless the actual socket name is being asked
   3171    for.
   3172 
   3173 8.2 Command Parsing
   3174 
   3175    To provide useful 'non-buffered' network IO for clients and servers,
   3176    each connection is given its own private 'input buffer' in which the
   3177    results of the most recent read and parsing are kept.  A buffer size
   3178    of 512 bytes is used so as to hold 1 full message, although, this
   3179    will usually hold several commands.  The private buffer is parsed
   3180    after every read operation for valid messages.  When dealing with
   3181    multiple messages from one client in the buffer, care should be taken
   3182    in case one happens to cause the client to be 'removed'.
   3183 
   3184 8.3 Message delivery
   3185 
   3186    It is common to find network links saturated or hosts to which you
   3187    are sending data unable to send data.  Although Unix typically
   3188    handles this through the TCP window and internal buffers, the server
   3189    often has large amounts of data to send (especially when a new
   3190    server-server link forms) and the small buffers provided in the
   3191 
   3192 
   3193 
   3194 Oikarinen & Reed                                               [Page 57]
   3195 
   3196 RFC 1459              Internet Relay Chat Protocol              May 1993
   3197 
   3198 
   3199    kernel are not enough for the outgoing queue.  To alleviate this
   3200    problem, a "send queue" is used as a FIFO queue for data to be sent.
   3201    A typical "send queue" may grow to 200 Kbytes on a large IRC network
   3202    with a slow network connection when a new server connects.
   3203 
   3204    When polling its connections, a server will first read and parse all
   3205    incoming data, queuing any data to be sent out. When all available
   3206    input is processed, the queued data is sent. This reduces the number
   3207    of write() system calls and helps TCP make bigger packets.
   3208 
   3209 8.4 Connection 'Liveness'
   3210 
   3211    To detect when a connection has died or become unresponsive, the
   3212    server must ping each of its connections that it doesn't get a
   3213    response from in a given amount of time.
   3214 
   3215    If a connection doesn't respond in time, its connection is closed
   3216    using the appropriate procedures.  A connection is also dropped if
   3217    its sendq grows beyond the maximum allowed, because it is better to
   3218    close a slow connection than have a server process block.
   3219 
   3220 8.5 Establishing a server to client connection
   3221 
   3222    Upon connecting to an IRC server, a client is sent the MOTD (if
   3223    present) as well as the current user/server count (as per the LUSER
   3224    command).  The server is also required to give an unambiguous message
   3225    to the client which states its name and version as well as any other
   3226    introductory messages which may be deemed appropriate.
   3227 
   3228    After dealing with this, the server must then send out the new user's
   3229    nickname and other information as supplied by itself (USER command)
   3230    and as the server could discover (from DNS/authentication servers).
   3231    The server must send this information out with NICK first followed by
   3232    USER.
   3233 
   3234 8.6 Establishing a server-server connection.
   3235 
   3236    The process of establishing of a server-to-server connection is
   3237    fraught with danger since there are many possible areas where
   3238    problems can occur - the least of which are race conditions.
   3239 
   3240    After a server has received a connection following by a PASS/SERVER
   3241    pair which were recognised as being valid, the server should then
   3242    reply with its own PASS/SERVER information for that connection as
   3243    well as all of the other state information it knows about as
   3244    described below.
   3245 
   3246    When the initiating server receives a PASS/SERVER pair, it too then
   3247 
   3248 
   3249 
   3250 Oikarinen & Reed                                               [Page 58]
   3251 
   3252 RFC 1459              Internet Relay Chat Protocol              May 1993
   3253 
   3254 
   3255    checks that the server responding is authenticated properly before
   3256    accepting the connection to be that server.
   3257 
   3258 8.6.1 Server exchange of state information when connecting
   3259 
   3260    The order of state information being exchanged between servers is
   3261    essential.  The required order is as follows:
   3262 
   3263         * all known other servers;
   3264 
   3265         * all known user information;
   3266 
   3267         * all known channel information.
   3268 
   3269    Information regarding servers is sent via extra SERVER messages, user
   3270    information with NICK/USER/MODE/JOIN messages and channels with MODE
   3271    messages.
   3272 
   3273    NOTE: channel topics are *NOT* exchanged here because the TOPIC
   3274    command overwrites any old topic information, so at best, the two
   3275    sides of the connection would exchange topics.
   3276 
   3277    By passing the state information about servers first, any collisions
   3278    with servers that already exist occur before nickname collisions due
   3279    to a second server introducing a particular nickname.  Due to the IRC
   3280    network only being able to exist as an acyclic graph, it may be
   3281    possible that the network has already reconnected in another
   3282    location, the place where the collision occurs indicating where the
   3283    net needs to split.
   3284 
   3285 8.7 Terminating server-client connections
   3286 
   3287    When a client connection closes, a QUIT message is generated on
   3288    behalf of the client by the server to which the client connected.  No
   3289    other message is to be generated or used.
   3290 
   3291 8.8 Terminating server-server connections
   3292 
   3293    If a server-server connection is closed, either via a remotely
   3294    generated SQUIT or 'natural' causes, the rest of the connected IRC
   3295    network must have its information updated with by the server which
   3296    detected the closure.  The server then sends a list of SQUITs (one
   3297    for each server behind that connection) and a list of QUITs (again,
   3298    one for each client behind that connection).
   3299 
   3300 
   3301 
   3302 
   3303 
   3304 
   3305 
   3306 Oikarinen & Reed                                               [Page 59]
   3307 
   3308 RFC 1459              Internet Relay Chat Protocol              May 1993
   3309 
   3310 
   3311 8.9 Tracking nickname changes
   3312 
   3313    All IRC servers are required to keep a history of recent nickname
   3314    changes.  This is required to allow the server to have a chance of
   3315    keeping in touch of things when nick-change race conditions occur
   3316    with commands which manipulate them.  Commands which must trace nick
   3317    changes are:
   3318 
   3319         * KILL (the nick being killed)
   3320 
   3321         * MODE (+/- o,v)
   3322 
   3323         * KICK (the nick being kicked)
   3324 
   3325    No other commands are to have nick changes checked for.
   3326 
   3327    In the above cases, the server is required to first check for the
   3328    existence of the nickname, then check its history to see who that
   3329    nick currently belongs to (if anyone!).  This reduces the chances of
   3330    race conditions but they can still occur with the server ending up
   3331    affecting the wrong client.  When performing a change trace for an
   3332    above command it is recommended that a time range be given and
   3333    entries which are too old ignored.
   3334 
   3335    For a reasonable history, a server should be able to keep previous
   3336    nickname for every client it knows about if they all decided to
   3337    change.  This size is limited by other factors (such as memory, etc).
   3338 
   3339 8.10 Flood control of clients
   3340 
   3341    With a large network of interconnected IRC servers, it is quite easy
   3342    for any single client attached to the network to supply a continuous
   3343    stream of messages that result in not only flooding the network, but
   3344    also degrading the level of service provided to others.  Rather than
   3345    require every 'victim' to be provide their own protection, flood
   3346    protection was written into the server and is applied to all clients
   3347    except services.  The current algorithm is as follows:
   3348 
   3349         * check to see if client's `message timer' is less than
   3350           current time (set to be equal if it is);
   3351 
   3352         * read any data present from the client;
   3353 
   3354         * while the timer is less than ten seconds ahead of the current
   3355           time, parse any present messages and penalize the client by
   3356           2 seconds for each message;
   3357 
   3358    which in essence means that the client may send 1 message every 2
   3359 
   3360 
   3361 
   3362 Oikarinen & Reed                                               [Page 60]
   3363 
   3364 RFC 1459              Internet Relay Chat Protocol              May 1993
   3365 
   3366 
   3367    seconds without being adversely affected.
   3368 
   3369 8.11 Non-blocking lookups
   3370 
   3371    In a real-time environment, it is essential that a server process do
   3372    as little waiting as possible so that all the clients are serviced
   3373    fairly.  Obviously this requires non-blocking IO on all network
   3374    read/write operations.  For normal server connections, this was not
   3375    difficult, but there are other support operations that may cause the
   3376    server to block (such as disk reads).  Where possible, such activity
   3377    should be performed with a short timeout.
   3378 
   3379 8.11.1 Hostname (DNS) lookups
   3380 
   3381    Using the standard resolver libraries from Berkeley and others has
   3382    meant large delays in some cases where replies have timed out.  To
   3383    avoid this, a separate set of DNS routines were written which were
   3384    setup for non-blocking IO operations and then polled from within the
   3385    main server IO loop.
   3386 
   3387 8.11.2 Username (Ident) lookups
   3388 
   3389    Although there are numerous ident libraries for use and inclusion
   3390    into other programs, these caused problems since they operated in a
   3391    synchronous manner and resulted in frequent delays.  Again the
   3392    solution was to write a set of routines which would cooperate with
   3393    the rest of the server and work using non-blocking IO.
   3394 
   3395 8.12 Configuration File
   3396 
   3397    To provide a flexible way of setting up and running the server, it is
   3398    recommended that a configuration file be used which contains
   3399    instructions to the server on the following:
   3400 
   3401         * which hosts to accept client connections from;
   3402 
   3403         * which hosts to allow to connect as servers;
   3404 
   3405         * which hosts to connect to (both actively and
   3406           passively);
   3407 
   3408         * information about where the server is (university,
   3409           city/state, company are examples of this);
   3410 
   3411         * who is responsible for the server and an email address
   3412           at which they can be contacted;
   3413 
   3414         * hostnames and passwords for clients which wish to be given
   3415 
   3416 
   3417 
   3418 Oikarinen & Reed                                               [Page 61]
   3419 
   3420 RFC 1459              Internet Relay Chat Protocol              May 1993
   3421 
   3422 
   3423           access to restricted operator commands.
   3424 
   3425    In specifying hostnames, both domain names and use of the 'dot'
   3426    notation (127.0.0.1) should both be accepted.  It must be possible to
   3427    specify the password to be used/accepted for all outgoing and
   3428    incoming connections (although the only outgoing connections are
   3429    those to other servers).
   3430 
   3431    The above list is the minimum requirement for any server which wishes
   3432    to make a connection with another server.  Other items which may be
   3433    of use are:
   3434 
   3435         * specifying which servers other server may introduce;
   3436 
   3437         * how deep a server branch is allowed to become;
   3438 
   3439         * hours during which clients may connect.
   3440 
   3441 8.12.1 Allowing clients to connect
   3442 
   3443    A server should use some sort of 'access control list' (either in the
   3444    configuration file or elsewhere) that is read at startup and used to
   3445    decide what hosts clients may use to connect to it.
   3446 
   3447    Both 'deny' and 'allow' should be implemented to provide the required
   3448    flexibility for host access control.
   3449 
   3450 8.12.2 Operators
   3451 
   3452    The granting of operator privileges to a disruptive person can have
   3453    dire consequences for the well-being of the IRC net in general due to
   3454    the powers given to them.  Thus, the acquisition of such powers
   3455    should not be very easy.  The current setup requires two 'passwords'
   3456    to be used although one of them is usually easy guessed.  Storage of
   3457    oper passwords in configuration files is preferable to hard coding
   3458    them in and should be stored in a crypted format (ie using crypt(3)
   3459    from Unix) to prevent easy theft.
   3460 
   3461 8.12.3 Allowing servers to connect
   3462 
   3463    The interconnection of server is not a trivial matter: a bad
   3464    connection can have a large impact on the usefulness of IRC.  Thus,
   3465    each server should have a list of servers to which it may connect and
   3466    which servers may connect to it.  Under no circumstances should a
   3467    server allow an arbitrary host to connect as a server.  In addition
   3468    to which servers may and may not connect, the configuration file
   3469    should also store the password and other characteristics of that
   3470    link.
   3471 
   3472 
   3473 
   3474 Oikarinen & Reed                                               [Page 62]
   3475 
   3476 RFC 1459              Internet Relay Chat Protocol              May 1993
   3477 
   3478 
   3479 8.12.4 Administrivia
   3480 
   3481    To provide accurate and valid replies to the ADMIN command (see
   3482    section 4.3.7), the server should find the relevant details in the
   3483    configuration.
   3484 
   3485 8.13 Channel membership
   3486 
   3487    The current server allows any registered local user to join upto 10
   3488    different channels.  There is no limit imposed on non-local users so
   3489    that the server remains (reasonably) consistant with all others on a
   3490    channel membership basis
   3491 
   3492 9. Current problems
   3493 
   3494    There are a number of recognized problems with this protocol, all  of
   3495    which  hope to be solved sometime in the near future during its
   3496    rewrite.  Currently, work is underway to find working solutions to
   3497    these problems.
   3498 
   3499 9.1 Scalability
   3500 
   3501    It is widely recognized that this protocol does not scale
   3502    sufficiently well when used in a large arena.  The main problem comes
   3503    from the requirement that all servers know about all other servers
   3504    and users and that information regarding them be updated as soon as
   3505    it changes.  It is also desirable to keep the number of servers low
   3506    so that the path length between any two points is kept minimal and
   3507    the spanning tree as strongly branched as possible.
   3508 
   3509 9.2 Labels
   3510 
   3511    The current IRC protocol has 3 types of labels: the nickname, the
   3512    channel name and the server name.  Each of the three types has its
   3513    own domain and no duplicates are allowed inside that domain.
   3514    Currently, it is possible for users to pick the label for any of the
   3515    three, resulting in collisions.  It is widely recognized that this
   3516    needs reworking, with a plan for unique names for channels and nicks
   3517    that don't collide being desirable as well as a solution allowing a
   3518    cyclic tree.
   3519 
   3520 9.2.1 Nicknames
   3521 
   3522    The idea of the nickname on IRC is very convenient for users to use
   3523    when talking to each other outside of a channel, but there is only a
   3524    finite nickname space and being what they are, its not uncommon for
   3525    several people to want to use the same nick.  If a nickname is chosen
   3526    by two people using this protocol, either one will not succeed or
   3527 
   3528 
   3529 
   3530 Oikarinen & Reed                                               [Page 63]
   3531 
   3532 RFC 1459              Internet Relay Chat Protocol              May 1993
   3533 
   3534 
   3535    both will removed by use of KILL (4.6.1).
   3536 
   3537 9.2.2 Channels
   3538 
   3539    The current channel layout requires that all servers know about all
   3540    channels, their inhabitants and properties.  Besides not scaling
   3541    well, the issue of privacy is also a concern.  A collision of
   3542    channels is treated as an inclusive event (both people who create the
   3543    new channel are considered to be members of it) rather than an
   3544    exclusive one such as used to solve nickname collisions.
   3545 
   3546 9.2.3 Servers
   3547 
   3548    Although the number of servers is usually small relative to the
   3549    number of users and channels, they two currently required to be known
   3550    globally, either each one separately or hidden behind a mask.
   3551 
   3552 9.3 Algorithms
   3553 
   3554    In some places within the server code, it has not  been  possible  to
   3555    avoid  N^2  algorithms  such  as  checking  the channel list of a set
   3556    of clients.
   3557 
   3558    In current server versions, there are no database consistency checks,
   3559    each server assumes that a neighbouring server is correct.  This
   3560    opens the door to large problems if a connecting server is buggy or
   3561    otherwise tries to introduce contradictions to the existing net.
   3562 
   3563    Currently, because of the lack of unique internal and global labels,
   3564    there are a multitude of race conditions that exist.  These race
   3565    conditions generally arise from the problem of it taking time for
   3566    messages to traverse and effect the IRC network.  Even by changing to
   3567    unique labels, there are problems with channel-related commands being
   3568    disrupted.
   3569 
   3570 10. Current support and availability
   3571 
   3572            Mailing lists for IRC related discussion:
   3573                 Future protocol: ircd-three-request@eff.org
   3574                 General discussion: operlist-request@eff.org
   3575 
   3576            Software implemenations
   3577                 cs.bu.edu:/irc
   3578                 nic.funet.fi:/pub/irc
   3579                 coombs.anu.edu.au:/pub/irc
   3580 
   3581            Newsgroup: alt.irc
   3582 
   3583 
   3584 
   3585 
   3586 Oikarinen & Reed                                               [Page 64]
   3587 
   3588 RFC 1459              Internet Relay Chat Protocol              May 1993
   3589 
   3590 
   3591 Security Considerations
   3592 
   3593    Security issues are discussed in sections 4.1, 4.1.1, 4.1.3, 5.5, and
   3594    7.
   3595 
   3596 12. Authors' Addresses
   3597 
   3598    Jarkko Oikarinen
   3599    Tuirantie 17 as 9
   3600    90500 OULU
   3601    FINLAND
   3602 
   3603    Email: jto@tolsun.oulu.fi
   3604 
   3605 
   3606    Darren Reed
   3607    4 Pateman Street
   3608    Watsonia, Victoria 3087
   3609    Australia
   3610 
   3611    Email: avalon@coombs.anu.edu.au
   3612 
   3613 
   3614 
   3615 
   3616 
   3617 
   3618 
   3619 
   3620 
   3621 
   3622 
   3623 
   3624 
   3625 
   3626 
   3627 
   3628 
   3629 
   3630 
   3631 
   3632 
   3633 
   3634 
   3635 
   3636 
   3637 
   3638 
   3639 
   3640 
   3641 
   3642 Oikarinen & Reed                                               [Page 65]
   3643