archive

- Random tools & helpful resources for IRC
git clone git://git.acid.vegas/archive.git
Log | Files | Refs | Archive

rfc2813.txt (56681B)

      1 
      2 
      3 
      4 
      5 
      6 
      7 Network Working Group                                           C. Kalt
      8 Request for Comments: 2813                                   April 2000
      9 Updates: 1459
     10 Category: Informational
     11 
     12 
     13                   Internet Relay Chat: Server Protocol
     14 
     15 Status of this Memo
     16 
     17    This memo provides information for the Internet community.  It does
     18    not specify an Internet standard of any kind.  Distribution of this
     19    memo is unlimited.
     20 
     21 Copyright Notice
     22 
     23    Copyright (C) The Internet Society (2000).  All Rights Reserved.
     24 
     25 Abstract
     26 
     27    While based on the client-server model, the IRC (Internet Relay Chat)
     28    protocol allows servers to connect to each other effectively forming
     29    a network.
     30 
     31    This document defines the protocol used by servers to talk to each
     32    other.  It was originally a superset of the client protocol but has
     33    evolved differently.
     34 
     35    First formally documented in May 1993 as part of RFC 1459 [IRC], most
     36    of the changes brought since then can be found in this document as
     37    development was focused on making the protocol scale better.  Better
     38    scalability has allowed existing world-wide networks to keep growing
     39    and reach sizes which defy the old specification.
     40 
     41 
     42 
     43 
     44 
     45 
     46 
     47 
     48 
     49 
     50 
     51 
     52 
     53 
     54 
     55 
     56 
     57 
     58 Kalt                         Informational                      [Page 1]
     59 
     60 RFC 2813          Internet Relay Chat: Server Protocol        April 2000
     61 
     62 
     63 Table of Contents
     64 
     65    1.  Introduction ...............................................   3
     66    2.  Global database ............................................   3
     67       2.1  Servers ................................................   3
     68       2.2  Clients ................................................   4
     69          2.2.1  Users .............................................   4
     70          2.2.2  Services ..........................................   4
     71       2.3  Channels ...............................................   4
     72    3.  The IRC Server Specification ...............................   5
     73       3.1  Overview ...............................................   5
     74       3.2  Character codes ........................................   5
     75       3.3  Messages ...............................................   5
     76          3.3.1  Message format in Augmented BNF ...................   6
     77       3.4  Numeric replies ........................................   7
     78    4.  Message Details ............................................   7
     79       4.1  Connection Registration ................................   8
     80          4.1.1  Password message ..................................   8
     81          4.1.2  Server message ....................................   9
     82          4.1.3  Nick ..............................................  10
     83          4.1.4  Service message ...................................  11
     84          4.1.5  Quit ..............................................  12
     85          4.1.6  Server quit message ...............................  13
     86       4.2  Channel operations .....................................  14
     87          4.2.1  Join message ......................................  14
     88          4.2.2  Njoin message .....................................  15
     89          4.2.3  Mode message ......................................  16
     90    5.  Implementation details  ....................................  16
     91       5.1  Connection 'Liveness' ..................................  16
     92       5.2  Accepting a client to server connection ................  16
     93          5.2.1  Users .............................................  16
     94          5.2.2  Services ..........................................  17
     95       5.3  Establishing a server-server connection. ...............  17
     96          5.3.1  Link options ......................................  17
     97             5.3.1.1  Compressed server to server links ............  18
     98             5.3.1.2  Anti abuse protections .......................  18
     99          5.3.2  State information exchange when connecting ........  18
    100       5.4  Terminating server-client connections ..................  19
    101       5.5  Terminating server-server connections ..................  19
    102       5.6  Tracking nickname changes ..............................  19
    103       5.7  Tracking recently used nicknames .......................  20
    104       5.8  Flood control of clients ...............................  20
    105       5.9  Non-blocking lookups ...................................  21
    106          5.9.1  Hostname (DNS) lookups ............................  21
    107          5.9.2  Username (Ident) lookups ..........................  21
    108    6.  Current problems ...........................................  21
    109       6.1  Scalability ............................................  21
    110       6.2  Labels .................................................  22
    111 
    112 
    113 
    114 Kalt                         Informational                      [Page 2]
    115 
    116 RFC 2813          Internet Relay Chat: Server Protocol        April 2000
    117 
    118 
    119          6.2.1  Nicknames .........................................  22
    120          6.2.2  Channels ..........................................  22
    121          6.2.3  Servers ...........................................  22
    122       6.3  Algorithms .............................................  22
    123    7.  Security Considerations ....................................  23
    124       7.1  Authentication .........................................  23
    125       7.2  Integrity ..............................................  23
    126    8.  Current support and availability ...........................  24
    127    9.  Acknowledgements ...........................................  24
    128    10.  References ................................................  24
    129    11.  Author's Address ..........................................  25
    130    12. Full Copyright Statement ...................................  26
    131 
    132 1. Introduction
    133 
    134    This document is intended for people working on implementing an IRC
    135    server but will also be useful to anyone implementing an IRC service.
    136 
    137    Servers provide the three basic services required for realtime
    138    conferencing defined by the "Internet Relay Chat: Architecture"
    139    [IRC-ARCH]: client locator (via the client protocol [IRC-CLIENT]),
    140    message relaying (via the server protocol defined in this document)
    141    and channel hosting and management (following specific rules [IRC-
    142    CHAN]).
    143 
    144 2. Global database
    145 
    146    Although the IRC Protocol defines a fairly distributed model, each
    147    server maintains a "global state database" about the whole IRC
    148    network.  This database is, in theory, identical on all servers.
    149 
    150 2.1 Servers
    151 
    152    Servers are uniquely identified by their name which has a maximum
    153    length of sixty three (63) characters.  See the protocol grammar
    154    rules (section 3.3.1) for what may and may not be used in a server
    155    name.
    156 
    157    Each server is typically known by all other servers, however it is
    158    possible to define a "hostmask" to group servers together according
    159    to their name.  Inside the hostmasked area, all the servers have a
    160    name which matches the hostmask, and any other server with a name
    161    matching the hostmask SHALL NOT be connected to the IRC network
    162    outside the hostmasked area.  Servers which are outside the area have
    163    no knowledge of the individual servers present inside the area,
    164    instead they are presented with a virtual server which has the
    165    hostmask for name.
    166 
    167 
    168 
    169 
    170 Kalt                         Informational                      [Page 3]
    171 
    172 RFC 2813          Internet Relay Chat: Server Protocol        April 2000
    173 
    174 
    175 2.2 Clients
    176 
    177    For each client, all servers MUST have the following information: a
    178    netwide unique identifier (whose format depends on the type of
    179    client) and the server to which the client is connected.
    180 
    181 2.2.1 Users
    182 
    183    Each user is distinguished from other users by a unique nickname
    184    having a maximum length of nine (9) characters.  See the protocol
    185    grammar rules (section 3.3.1) for what may and may not be used in a
    186    nickname.  In addition to the nickname, all servers MUST have the
    187    following information about all users: the name of the host that the
    188    user is running on, the username of the user on that host, and the
    189    server to which the client is connected.
    190 
    191 2.2.2 Services
    192 
    193    Each service is distinguished from other services by a service name
    194    composed of a nickname and a server name.  The nickname has a maximum
    195    length of nine (9) characters.  See the protocol grammar rules
    196    (section 3.3.1) for what may and may not be used in a nickname.  The
    197    server name used to compose the service name is the name of the
    198    server to which the service is connected.  In addition to this
    199    service name all servers MUST know the service type.
    200 
    201    Services differ from users by the format of their identifier, but
    202    more importantly services and users don't have the same type of
    203    access to the server: services can request part or all of the global
    204    state information that a server maintains, but have a more restricted
    205    set of commands available to them (See "IRC Client Protocol" [IRC-
    206    CLIENT] for details on which) and are not allowed to join channels.
    207    Finally services are not usually subject to the "Flood control"
    208    mechanism described in section 5.8.
    209 
    210 2.3 Channels
    211 
    212    Alike services, channels have a scope [IRC-CHAN] and are not
    213    necessarily known to all servers.  When a channel existence is known
    214    to a server, the server MUST keep track of the channel members, as
    215    well as the channel modes.
    216 
    217 
    218 
    219 
    220 
    221 
    222 
    223 
    224 
    225 
    226 Kalt                         Informational                      [Page 4]
    227 
    228 RFC 2813          Internet Relay Chat: Server Protocol        April 2000
    229 
    230 
    231 3. The IRC Server Specification
    232 
    233 3.1 Overview
    234 
    235    The protocol as described herein is for use with server to server
    236    connections.  For client to server connections, see the IRC Client
    237    Protocol specification.
    238 
    239    There are, however, more restrictions on client connections (which
    240    are considered to be untrustworthy) than on server connections.
    241 
    242 3.2 Character codes
    243 
    244    No specific character set is specified. The protocol is based on a a
    245    set of codes which are composed of eight (8) bits, making up an
    246    octet.  Each message may be composed of any number of these octets;
    247    however, some octet values are used for control codes which act as
    248    message delimiters.
    249 
    250    Regardless of being an 8-bit protocol, the delimiters and keywords
    251    are such that protocol is mostly usable from US-ASCII terminal and a
    252    telnet connection.
    253 
    254    Because of IRC's Scandinavian origin, the characters {}|^ are
    255    considered to be the lower case equivalents of the characters []\~,
    256    respectively. This is a critical issue when determining the
    257    equivalence of two nicknames, or channel names.
    258 
    259 3.3 Messages
    260 
    261    Servers and clients send each other messages which may or may not
    262    generate a reply.  Most communication between servers do not generate
    263    any reply, as servers mostly perform routing tasks for the clients.
    264 
    265    Each IRC message may consist of up to three main parts: the prefix
    266    (OPTIONAL), the command, and the command parameters (maximum of
    267    fifteen (15)).  The prefix, command, and all parameters are separated
    268    by one ASCII space character (0x20) each.
    269 
    270    The presence of a prefix is indicated with a single leading ASCII
    271    colon character (':', 0x3b), which MUST be the first character of the
    272    message itself.  There MUST be NO gap (whitespace) between the colon
    273    and the prefix.  The prefix is used by servers to indicate the true
    274    origin of the message.  If the prefix is missing from the message, it
    275    is assumed to have originated from the connection from which it was
    276    received.  Clients SHOULD not use a prefix when sending a message
    277    from themselves; if they use one, the only valid prefix is the
    278    registered nickname associated with the client.
    279 
    280 
    281 
    282 Kalt                         Informational                      [Page 5]
    283 
    284 RFC 2813          Internet Relay Chat: Server Protocol        April 2000
    285 
    286 
    287    When a server receives a message, it MUST identify its source using
    288    the (eventually assumed) prefix.  If the prefix cannot be found in
    289    the server's internal database, it MUST be discarded, and if the
    290    prefix indicates the message comes from an (unknown) server, the link
    291    from which the message was received MUST be dropped.  Dropping a link
    292    in such circumstances is a little excessive but necessary to maintain
    293    the integrity of the network and to prevent future problems.  Another
    294    common error condition is that the prefix found in the server's
    295    internal database identifies a different source (typically a source
    296    registered from a different link than from which the message
    297    arrived).  If the message was received from a server link and the
    298    prefix identifies a client, a KILL message MUST be issued for the
    299    client and sent to all servers.  In other cases, the link from which
    300    the message arrived SHOULD be dropped for clients, and MUST be
    301    dropped for servers.  In all cases, the message MUST be discarded.
    302 
    303    The command MUST either be a valid IRC command or a three (3) digit
    304    number represented in ASCII text.
    305 
    306    IRC messages are always lines of characters terminated with a CR-LF
    307    (Carriage Return - Line Feed) pair, and these messages SHALL NOT
    308    exceed 512 characters in length, counting all characters including
    309    the trailing CR-LF. Thus, there are 510 characters maximum allowed
    310    for the command and its parameters.  There is no provision for
    311    continuation message lines.  See section 5 for more details about
    312    current implementations.
    313 
    314 3.3.1 Message format in Augmented BNF
    315 
    316    The protocol messages must be extracted from the contiguous stream of
    317    octets.  The current solution is to designate two characters, CR and
    318    LF, as message separators.  Empty messages are silently ignored,
    319    which permits use of the sequence CR-LF between messages without
    320    extra problems.
    321 
    322    The extracted message is parsed into the components <prefix>,
    323    <command> and list of parameters (<params>).
    324 
    325    The Augmented BNF representation for this is found in "IRC Client
    326    Protocol" [IRC-CLIENT].
    327 
    328    The extended prefix (["!" user "@" host ]) MUST NOT be used in server
    329    to server communications and is only intended for server to client
    330    messages in order to provide clients with more useful information
    331    about who a message is from without the need for additional queries.
    332 
    333 
    334 
    335 
    336 
    337 
    338 Kalt                         Informational                      [Page 6]
    339 
    340 RFC 2813          Internet Relay Chat: Server Protocol        April 2000
    341 
    342 
    343 3.4 Numeric replies
    344 
    345    Most of the messages sent to the server generate a reply of some
    346    sort.  The most common reply is the numeric reply, used for both
    347    errors and normal replies.  The numeric reply MUST be sent as one
    348    message consisting of the sender prefix, the three digit numeric, and
    349    the target of the reply.  A numeric reply is not allowed to originate
    350    from a client; any such messages received by a server are silently
    351    dropped. In all other respects, a numeric reply is just like a normal
    352    message, except that the keyword is made up of 3 numeric digits
    353    rather than a string of letters.  A list of different replies is
    354    supplied in "IRC Client Protocol" [IRC-CLIENT].
    355 
    356 4. Message Details
    357 
    358    All the messages recognized by the IRC server and client are
    359    described in the IRC Client Protocol specification.
    360 
    361    Where the reply ERR_NOSUCHSERVER is returned, it means that the
    362    target of the message could not be found.  The server MUST NOT send
    363    any other replies after this error for that command.
    364 
    365    The server to which a client is connected is required to parse the
    366    complete message, returning any appropriate errors.  If the server
    367    encounters a fatal error while parsing a message, an error MUST be
    368    sent back to the client and the parsing terminated.  A fatal error
    369    may follow from incorrect command, a destination which is otherwise
    370    unknown to the server (server, client or channel names fit this
    371    category), not enough parameters or incorrect privileges.
    372 
    373    If a full set of parameters is presented, then each MUST be checked
    374    for validity and appropriate responses sent back to the client.  In
    375    the case of messages which use parameter lists using the comma as an
    376    item separator, a reply MUST be sent for each item.
    377 
    378    In the examples below, some messages appear using the full format:
    379 
    380    :Name COMMAND parameter list
    381 
    382    Such examples represent a message from "Name" in transit between
    383    servers, where it is essential to include the name of the original
    384    sender of the message so remote servers may send back a reply along
    385    the correct path.
    386 
    387    The message details for client to server communication are described
    388    in the "IRC Client Protocol" [IRC-CLIENT].  Some sections in the
    389    following pages apply to some of these messages, they are additions
    390    to the message specifications which are only relevant to server to
    391 
    392 
    393 
    394 Kalt                         Informational                      [Page 7]
    395 
    396 RFC 2813          Internet Relay Chat: Server Protocol        April 2000
    397 
    398 
    399    server communication, or to the server implementation.  The messages
    400    which are introduced here are only used for server to server
    401    communication.
    402 
    403 4.1 Connection Registration
    404 
    405    The commands described here are used to register a connection with
    406    another IRC server.
    407 
    408 4.1.1 Password message
    409 
    410       Command: PASS
    411    Parameters: <password> <version> <flags> [<options>]
    412 
    413    The PASS command is used to set a 'connection password'.  The
    414    password MUST be set before any attempt to register the connection is
    415    made.  Currently this means that servers MUST send a PASS command
    416    before any SERVER command.  Only one (1) PASS command SHALL be
    417    accepted from a connection.
    418 
    419    The last three (3) parameters MUST be ignored if received from a
    420    client (e.g. a user or a service).  They are only relevant when
    421    received from a server.
    422 
    423    The <version> parameter is a string of at least four (4) characters,
    424    and up to fourteen (14) characters.  The first four (4) characters
    425    MUST be digits and indicate the protocol version known by the server
    426    issuing the message.  The protocol described by this document is
    427    version 2.10 which is encoded as "0210".  The remaining OPTIONAL
    428    characters are implementation dependent and should describe the
    429    software version number.
    430 
    431    The <flags> parameter is a string of up to one hundred (100)
    432    characters.  It is composed of two substrings separated by the
    433    character "|" (%x7C).  If present, the first substring MUST be the
    434    name of the implementation.  The reference implementation (See
    435    Section 8, "Current support and availability") uses the string "IRC".
    436    If a different implementation is written, which needs an identifier,
    437    then that identifier should be registered through publication of an
    438    RFC. The second substring is implementation dependent.  Both
    439    substrings are OPTIONAL, but the character "|" is REQUIRED.  The
    440    character "|" MUST NOT appear in either substring.
    441 
    442    Finally, the last parameter, <options>, is used for link options.
    443    The only options defined by the protocol are link compression (using
    444    the character "Z"), and an abuse protection flag (using the character
    445 
    446 
    447 
    448 
    449 
    450 Kalt                         Informational                      [Page 8]
    451 
    452 RFC 2813          Internet Relay Chat: Server Protocol        April 2000
    453 
    454 
    455    "P").  See sections 5.3.1.1 (Compressed server to server links) and
    456    5.3.1.2 (Anti abuse protections) respectively for more information on
    457    these options.
    458 
    459    Numeric Replies:
    460 
    461            ERR_NEEDMOREPARAMS              ERR_ALREADYREGISTRED
    462 
    463    Example:
    464 
    465         PASS moresecretpassword 0210010000 IRC|aBgH$ Z
    466 
    467 4.1.2 Server message
    468 
    469       Command: SERVER
    470    Parameters: <servername> <hopcount> <token> <info>
    471 
    472    The SERVER command is used to register a new server. A new connection
    473    introduces itself as a server to its peer.  This message is also used
    474    to pass server data over whole net.  When a new server is connected
    475    to net, information about it MUST be broadcasted to the whole
    476    network.
    477 
    478    The <info> parameter may contain space characters.
    479 
    480    <hopcount> is used to give all servers some internal information on
    481    how far away each server is.  Local peers have a value of 0, and each
    482    passed server increments the value.  With a full server list, it
    483    would be possible to construct a map of the entire server tree, but
    484    hostmasks prevent this from being done.
    485 
    486    The <token> parameter is an unsigned number used by servers as an
    487    identifier.  This identifier is subsequently used to reference a
    488    server in the NICK and SERVICE messages sent between servers.  Server
    489    tokens only have a meaning for the point-to-point peering they are
    490    used and MUST be unique for that connection.  They are not global.
    491 
    492    The SERVER message MUST only be accepted from either (a) a connection
    493    which is yet to be registered and is attempting to register as a
    494    server, or (b) an existing connection to another server, in which
    495    case the SERVER message is introducing a new server behind that
    496    server.
    497 
    498    Most errors that occur with the receipt of a SERVER command result in
    499    the connection being terminated by the destination host (target
    500    SERVER).  Because of the severity of such event, error replies are
    501    usually sent using the "ERROR" command rather than a numeric.
    502 
    503 
    504 
    505 
    506 Kalt                         Informational                      [Page 9]
    507 
    508 RFC 2813          Internet Relay Chat: Server Protocol        April 2000
    509 
    510 
    511    If a SERVER message is parsed and it attempts to introduce a server
    512    which is already known to the receiving server, the connection, from
    513    which that message arrived, MUST be closed (following the correct
    514    procedures), since a duplicate route to a server has been formed and
    515    the acyclic nature of the IRC tree breaks.  In some conditions, the
    516    connection from which the already known server has registered MAY be
    517    closed instead.  It should be noted that this kind of error can also
    518    be the result of a second running server, problem which cannot be
    519    fixed within the protocol and typically requires human intervention.
    520    This type of problem is particularly insidious, as it can quite
    521    easily result in part of the IRC network to be isolated, with one of
    522    the two servers connected to each partition therefore making it
    523    impossible for the two parts to unite.
    524 
    525    Numeric Replies:
    526 
    527            ERR_ALREADYREGISTRED
    528 
    529    Example:
    530 
    531    SERVER test.oulu.fi 1 1 :Experimental server ; New server
    532                                    test.oulu.fi introducing itself and
    533                                    attempting to register.
    534 
    535    :tolsun.oulu.fi SERVER csd.bu.edu 5 34 :BU Central Server ; Server
    536                                    tolsun.oulu.fi is our uplink for
    537                                    csd.bu.edu which is 5 hops away.  The
    538                                    token "34" will be used by
    539                                    tolsun.oulu.fi when introducing new
    540                                    users or services connected to
    541                                    csd.bu.edu.
    542 
    543 4.1.3 Nick
    544 
    545       Command: NICK
    546    Parameters: <nickname> <hopcount> <username> <host> <servertoken>
    547                <umode> <realname>
    548 
    549    This form of the NICK message MUST NOT be allowed from user
    550    connections. However, it MUST be used instead of the NICK/USER pair
    551    to notify other servers of new users joining the IRC network.
    552 
    553    This message is really the combination of three distinct messages:
    554    NICK, USER and MODE [IRC-CLIENT].
    555 
    556    The <hopcount> parameter is used by servers to indicate how far away
    557    a user is from its home server.  A local connection has a hopcount of
    558    0.  The hopcount value is incremented by each passed server.
    559 
    560 
    561 
    562 Kalt                         Informational                     [Page 10]
    563 
    564 RFC 2813          Internet Relay Chat: Server Protocol        April 2000
    565 
    566 
    567    The <servertoken> parameter replaces the <servername> parameter of
    568    the USER (See section 4.1.2 for more information on server tokens).
    569 
    570    Examples:
    571 
    572    NICK syrk 5 kalt millennium.stealth.net 34 +i :Christophe Kalt ; New
    573                                    user with nickname "syrk", username
    574                                    "kalt", connected from host
    575                                    "millennium.stealth.net" to server
    576                                    "34" ("csd.bu.edu" according to the
    577                                    previous example).
    578 
    579    :krys NICK syrk                 ; The other form of the NICK message,
    580                                    as defined in "IRC Client Protocol"
    581                                    [IRC-CLIENT] and used between
    582                                    servers: krys changed his nickname to
    583                                    syrk
    584 
    585 4.1.4 Service message
    586 
    587       Command: SERVICE
    588    Parameters: <servicename> <servertoken> <distribution> <type>
    589                 <hopcount> <info>
    590 
    591    The SERVICE command is used to introduce a new service.  This form of
    592    the SERVICE message SHOULD NOT be allowed from client (unregistered,
    593    or registered) connections.  However, it MUST be used between servers
    594    to notify other servers of new services joining the IRC network.
    595 
    596    The <servertoken> is used to identify the server to which the service
    597    is connected.  (See section 4.1.2 for more information on server
    598    tokens).
    599 
    600    The <hopcount> parameter is used by servers to indicate how far away
    601    a service is from its home server.  A local connection has a hopcount
    602    of 0.  The hopcount value is incremented by each passed server.
    603 
    604    The <distribution> parameter is used to specify the visibility of a
    605    service.  The service may only be known to servers which have a name
    606    matching the distribution.  For a matching server to have knowledge
    607    of the service, the network path between that server and the server
    608    to which the service is connected MUST be composed of servers whose
    609    names all match the mask.  Plain "*" is used when no restriction is
    610    wished.
    611 
    612    The <type> parameter is currently reserved for future usage.
    613 
    614 
    615 
    616 
    617 
    618 Kalt                         Informational                     [Page 11]
    619 
    620 RFC 2813          Internet Relay Chat: Server Protocol        April 2000
    621 
    622 
    623    Numeric Replies:
    624 
    625            ERR_ALREADYREGISTRED            ERR_NEEDMOREPARAMS
    626            ERR_ERRONEUSNICKNAME
    627            RPL_YOURESERVICE                RPL_YOURHOST
    628            RPL_MYINFO
    629 
    630    Example:
    631 
    632 SERVICE dict@irc.fr 9 *.fr 0 1 :French Dictionary r" registered on
    633                                    server "9" is being announced to
    634                                    another server.  This service will
    635                                    only be available on servers whose
    636                                    name matches "*.fr".
    637 
    638 4.1.5 Quit
    639 
    640       Command: QUIT
    641    Parameters: [<Quit Message>]
    642 
    643    A client session ends with a quit message.  The server MUST close the
    644    connection to a client which sends a QUIT message. If a "Quit
    645    Message" is given, this will be sent instead of the default message,
    646    the nickname or service name.
    647 
    648    When "netsplit" (See Section 4.1.6) occur, the "Quit Message" is
    649    composed of the names of two servers involved, separated by a space.
    650    The first name is that of the server which is still connected and the
    651    second name is either that of the server which has become
    652    disconnected or that of the server to which the leaving client was
    653    connected:
    654 
    655       <Quit Message> =  ":" servername SPACE servername
    656 
    657    Because the "Quit Message" has a special meaning for "netsplits",
    658    servers SHOULD NOT allow a client to use a <Quit Message> in the
    659    format described above.
    660 
    661    If, for some other reason, a client connection is closed without the
    662    client issuing a QUIT command (e.g. client dies and EOF occurs on
    663    socket), the server is REQUIRED to fill in the quit message with some
    664    sort of message reflecting the nature of the event which caused it to
    665    happen.  Typically, this is done by reporting a system specific
    666    error.
    667 
    668    Numeric Replies:
    669 
    670            None.
    671 
    672 
    673 
    674 Kalt                         Informational                     [Page 12]
    675 
    676 RFC 2813          Internet Relay Chat: Server Protocol        April 2000
    677 
    678 
    679    Examples:
    680 
    681    :WiZ QUIT :Gone to have lunch   ; Preferred message format.
    682 
    683 4.1.6 Server quit message
    684 
    685       Command: SQUIT
    686    Parameters: <server> <comment>
    687 
    688    The SQUIT message has two distinct uses.
    689 
    690    The first one (described in "Internet Relay Chat: Client Protocol"
    691    [IRC-CLIENT]) allows operators to break a local or remote server
    692    link.  This form of the message is also eventually used by servers to
    693    break a remote server link.
    694 
    695    The second use of this message is needed to inform other servers when
    696    a "network split" (also known as "netsplit") occurs, in other words
    697    to inform other servers about quitting or dead servers.  If a server
    698    wishes to break the connection to another server it MUST send a SQUIT
    699    message to the other server, using the name of the other server as
    700    the server parameter, which then closes its connection to the
    701    quitting server.
    702 
    703    The <comment> is filled in by servers which SHOULD place an error or
    704    similar message here.
    705 
    706    Both of the servers which are on either side of the connection being
    707    closed are REQUIRED to send out a SQUIT message (to all its other
    708    server connections) for all other servers which are considered to be
    709    behind that link.
    710 
    711    Similarly, a QUIT message MAY be sent to the other still connected
    712    servers on behalf of all clients behind that quitting link.  In
    713    addition to this, all channel members of a channel which lost a
    714    member due to the "split" MUST be sent a QUIT message.  Messages to
    715    channel members are generated by each client's local server.
    716 
    717    If a server connection is terminated prematurely (e.g., the server on
    718    the other end of the link died), the server which detects this
    719    disconnection is REQUIRED to inform the rest of the network that the
    720    connection has closed and fill in the comment field with something
    721    appropriate.
    722 
    723    When a client is removed as the result of a SQUIT message, the server
    724    SHOULD add the nickname to the list of temporarily unavailable
    725    nicknames in an attempt to prevent future nickname collisions. See
    726 
    727 
    728 
    729 
    730 Kalt                         Informational                     [Page 13]
    731 
    732 RFC 2813          Internet Relay Chat: Server Protocol        April 2000
    733 
    734 
    735    section 5.7 (Tracking recently used nicknames) for more information
    736    on this procedure.
    737 
    738    Numeric replies:
    739 
    740            ERR_NOPRIVILEGES                ERR_NOSUCHSERVER
    741            ERR_NEEDMOREPARAMS
    742 
    743    Example:
    744 
    745    SQUIT tolsun.oulu.fi :Bad Link ?  ; the server link tolson.oulu.fi
    746                                    has been terminated because of "Bad
    747                                    Link".
    748 
    749    :Trillian SQUIT cm22.eng.umd.edu :Server out of control ; message
    750                                    from Trillian to disconnect
    751                                    "cm22.eng.umd.edu" from the net
    752                                    because "Server out of control".
    753 
    754 4.2 Channel operations
    755 
    756    This group of messages is concerned with manipulating channels, their
    757    properties (channel modes), and their contents (typically users).  In
    758    implementing these, a number of race conditions are inevitable when
    759    users at opposing ends of a network send commands which will
    760    ultimately clash.  It is also REQUIRED that servers keep a nickname
    761    history to ensure that wherever a <nick> parameter is given, the
    762    server check its history in case it has recently been changed.
    763 
    764 4.2.1 Join message
    765 
    766       Command: JOIN
    767    Parameters: <channel>[ %x7 <modes> ]
    768                *( "," <channel>[ %x7 <modes> ] )
    769 
    770    The JOIN command is used by client to start listening a specific
    771    channel. Whether or not a client is allowed to join a channel is
    772    checked only by the local server the client is connected to; all
    773    other servers automatically add the user to the channel when the
    774    command is received from other servers.
    775 
    776    Optionally, the user status (channel modes 'O', 'o', and 'v') on the
    777    channel may be appended to the channel name using a control G (^G or
    778    ASCII 7) as separator.  Such data MUST be ignored if the message
    779    wasn't received from a server.  This format MUST NOT be sent to
    780    clients, it can only be used between servers and SHOULD be avoided.
    781 
    782 
    783 
    784 
    785 
    786 Kalt                         Informational                     [Page 14]
    787 
    788 RFC 2813          Internet Relay Chat: Server Protocol        April 2000
    789 
    790 
    791    The JOIN command MUST be broadcast to all servers so that each server
    792    knows where to find the users who are on the channel.  This allows
    793    optimal delivery of PRIVMSG and NOTICE messages to the channel.
    794 
    795    Numeric Replies:
    796 
    797            ERR_NEEDMOREPARAMS              ERR_BANNEDFROMCHAN
    798            ERR_INVITEONLYCHAN              ERR_BADCHANNELKEY
    799            ERR_CHANNELISFULL               ERR_BADCHANMASK
    800            ERR_NOSUCHCHANNEL               ERR_TOOMANYCHANNELS
    801            ERR_TOOMANYTARGETS              ERR_UNAVAILRESOURCE
    802            RPL_TOPIC
    803 
    804    Examples:
    805 
    806    :WiZ JOIN #Twilight_zone        ; JOIN message from WiZ
    807 
    808 4.2.2 Njoin message
    809 
    810       Command: NJOIN
    811    Parameters: <channel> [ "@@" / "@" ] [ "+" ] <nickname>
    812                          *( "," [ "@@" / "@" ] [ "+" ] <nickname> )
    813 
    814    The NJOIN message is used between servers only.  If such a message is
    815    received from a client, it MUST be ignored.  It is used when two
    816    servers connect to each other to exchange the list of channel members
    817    for each channel.
    818 
    819    Even though the same function can be performed by using a succession
    820    of JOIN, this message SHOULD be used instead as it is more efficient.
    821    The prefix "@@" indicates that the user is the "channel creator", the
    822    character "@" alone indicates a "channel operator", and the character
    823    '+' indicates that the user has the voice privilege.
    824 
    825    Numeric Replies:
    826 
    827            ERR_NEEDMOREPARAMS              ERR_NOSUCHCHANNEL
    828            ERR_ALREADYREGISTRED
    829 
    830    Examples:
    831 
    832    :ircd.stealth.net NJOIN #Twilight_zone :@WiZ,+syrk,avalon ; NJOIN
    833                                    message from ircd.stealth.net
    834                                    announcing users joining the
    835                                    #Twilight_zone channel: WiZ with
    836                                    channel operator status, syrk with
    837                                    voice privilege and avalon with no
    838                                    privilege.
    839 
    840 
    841 
    842 Kalt                         Informational                     [Page 15]
    843 
    844 RFC 2813          Internet Relay Chat: Server Protocol        April 2000
    845 
    846 
    847 4.2.3 Mode message
    848 
    849    The MODE message is a dual-purpose command in IRC.  It allows both
    850    usernames and channels to have their mode changed.
    851 
    852    When parsing MODE messages, it is RECOMMENDED that the entire message
    853    be parsed first, and then the changes which resulted passed on.
    854 
    855    It is REQUIRED that servers are able to change channel modes so that
    856    "channel creator" and "channel operators" may be created.
    857 
    858 5. Implementation details
    859 
    860    A the time of writing, the only current implementation of this
    861    protocol is the IRC server, version 2.10. Earlier versions may
    862    implement some or all of the commands described by this document with
    863    NOTICE messages replacing many of the numeric replies. Unfortunately,
    864    due to backward compatibility requirements, the implementation of
    865    some parts of this document varies with what is laid out.  One
    866    notable difference is:
    867 
    868         * recognition that any LF or CR anywhere in a message marks
    869           the end of that message (instead of requiring CR-LF);
    870 
    871    The rest of this section deals with issues that are mostly of
    872    importance to those who wish to implement a server but some parts
    873    also apply directly to clients as well.
    874 
    875 5.1 Connection 'Liveness'
    876 
    877    To detect when a connection has died or become unresponsive, the
    878    server MUST poll each of its connections.  The PING command (See "IRC
    879    Client Protocol" [IRC-CLIENT]) is used if the server doesn't get a
    880    response from its peer in a given amount of time.
    881 
    882    If a connection doesn't respond in time, its connection is closed
    883    using the appropriate procedures.
    884 
    885 5.2 Accepting a client to server connection
    886 
    887 5.2.1 Users
    888 
    889    When a server successfully registers a new user connection, it is
    890    REQUIRED to send to the user unambiguous messages stating: the user
    891    identifiers upon which it was registered (RPL_WELCOME), the server
    892    name and version (RPL_YOURHOST), the server birth information
    893    (RPL_CREATED), available user and channel modes (RPL_MYINFO), and it
    894    MAY send any introductory messages which may be deemed appropriate.
    895 
    896 
    897 
    898 Kalt                         Informational                     [Page 16]
    899 
    900 RFC 2813          Internet Relay Chat: Server Protocol        April 2000
    901 
    902 
    903    In particular the server SHALL send the current user/service/server
    904    count (as per the LUSER reply) and finally the MOTD (if any, as per
    905    the MOTD reply).
    906 
    907    After dealing with registration, the server MUST then send out to
    908    other servers the new user's nickname (NICK message), other
    909    information as supplied by itself (USER message) and as the server
    910    could discover (from DNS servers).  The server MUST NOT send this
    911    information out with a pair of NICK and USER messages as defined in
    912    "IRC Client Protocol" [IRC-CLIENT], but MUST instead take advantage
    913    of the extended NICK message defined in section 4.1.3.
    914 
    915 5.2.2 Services
    916 
    917    Upon successfully registering a new service connection, the server is
    918    subject to the same kind of REQUIREMENTS as for a user.  Services
    919    being somewhat different, only the following replies are sent:
    920    RPL_YOURESERVICE, RPL_YOURHOST, RPL_MYINFO.
    921 
    922    After dealing with this, the server MUST then send out to other
    923    servers (SERVICE message) the new service's nickname and other
    924    information as supplied by the service (SERVICE message) and as the
    925    server could discover (from DNS servers).
    926 
    927 5.3 Establishing a server-server connection.
    928 
    929    The process of establishing a server-to-server connection is fraught
    930    with danger since there are many possible areas where problems can
    931    occur - the least of which are race conditions.
    932 
    933    After a server has received a connection following by a PASS/SERVER
    934    pair which were recognized as being valid, the server SHOULD then
    935    reply with its own PASS/SERVER information for that connection as
    936    well as all of the other state information it knows about as
    937    described below.
    938 
    939    When the initiating server receives a PASS/SERVER pair, it too then
    940    checks that the server responding is authenticated properly before
    941    accepting the connection to be that server.
    942 
    943 5.3.1 Link options
    944 
    945    Server links are based on a common protocol (defined by this
    946    document) but a particular link MAY set specific options using the
    947    PASS message (See Section 4.1.1).
    948 
    949 
    950 
    951 
    952 
    953 
    954 Kalt                         Informational                     [Page 17]
    955 
    956 RFC 2813          Internet Relay Chat: Server Protocol        April 2000
    957 
    958 
    959 5.3.1.1 Compressed server to server links
    960 
    961    If a server wishes to establish a compressed link with its peer, it
    962    MUST set the 'Z' flag in the options parameter to the PASS message.
    963    If both servers request compression and both servers are able to
    964    initialize the two compressed streams, then the remainder of the
    965    communication is to be compressed.  If any server fails to initialize
    966    the stream, it will send an uncompressed ERROR message to its peer
    967    and close the connection.
    968 
    969    The data format used for the compression is described by RFC 1950
    970    [ZLIB], RFC 1951 [DEFLATE] and RFC 1952 [GZIP].
    971 
    972 5.3.1.2 Anti abuse protections
    973 
    974    Most servers implement various kinds of protections against possible
    975    abusive behaviours from non trusted parties (typically users).  On
    976    some networks, such protections are indispensable, on others they are
    977    superfluous.  To require that all servers implement and enable such
    978    features on a particular network, the 'P' flag is used when two
    979    servers connect.  If this flag is present, it means that the server
    980    protections are enabled, and that the server REQUIRES all its server
    981    links to enable them as well.
    982 
    983    Commonly found protections are described in sections 5.7 (Tracking
    984    recently used nicknames) and 5.8 (Flood control of clients).
    985 
    986 5.3.2 State information exchange when connecting
    987 
    988    The order of state information being exchanged between servers is
    989    essential.  The REQUIRED order is as follows:
    990 
    991            * all known servers;
    992 
    993            * all known client information;
    994 
    995            * all known channel information.
    996 
    997    Information regarding servers is sent via extra SERVER messages,
    998    client information with NICK and SERVICE messages and channels with
    999    NJOIN/MODE messages.
   1000 
   1001    NOTE: channel topics SHOULD NOT be exchanged here because the TOPIC
   1002    command overwrites any old topic information, so at best, the two
   1003    sides of the connection would exchange topics.
   1004 
   1005 
   1006 
   1007 
   1008 
   1009 
   1010 Kalt                         Informational                     [Page 18]
   1011 
   1012 RFC 2813          Internet Relay Chat: Server Protocol        April 2000
   1013 
   1014 
   1015    By passing the state information about servers first, any collisions
   1016    with servers that already exist occur before nickname collisions
   1017    caused by a second server introducing a particular nickname.  Due to
   1018    the IRC network only being able to exist as an acyclic graph, it may
   1019    be possible that the network has already reconnected in another
   1020    location.  In this event, the place where the server collision occurs
   1021    indicates where the net needs to split.
   1022 
   1023 5.4 Terminating server-client connections
   1024 
   1025    When a client connection unexpectedly closes, a QUIT message is
   1026    generated on behalf of the client by the server to which the client
   1027    was connected.  No other message is to be generated or used.
   1028 
   1029 5.5 Terminating server-server connections
   1030 
   1031    If a server-server connection is closed, either via a SQUIT command
   1032    or "natural" causes, the rest of the connected IRC network MUST have
   1033    its information updated by the server which detected the closure.
   1034    The terminating server then sends a list of SQUITs (one for each
   1035    server behind that connection).  (See Section 4.1.6 (SQUIT)).
   1036 
   1037 5.6 Tracking nickname changes
   1038 
   1039    All IRC servers are REQUIRED to keep a history of recent nickname
   1040    changes.  This is important to allow the server to have a chance of
   1041    keeping in touch of things when nick-change race conditions occur
   1042    with commands manipulating them.  Messages which MUST trace nick
   1043    changes are:
   1044 
   1045            * KILL (the nick being disconnected)
   1046 
   1047            * MODE (+/- o,v on channels)
   1048 
   1049            * KICK (the nick being removed from channel)
   1050 
   1051       No other commands need to check nick changes.
   1052 
   1053    In the above cases, the server is required to first check for the
   1054    existence of the nickname, then check its history to see who that
   1055    nick now belongs to (if anyone!).  This reduces the chances of race
   1056    conditions but they can still occur with the server ending up
   1057    affecting the wrong client.  When performing a change trace for an
   1058    above command it is RECOMMENDED that a time range be given and
   1059    entries which are too old ignored.
   1060 
   1061 
   1062 
   1063 
   1064 
   1065 
   1066 Kalt                         Informational                     [Page 19]
   1067 
   1068 RFC 2813          Internet Relay Chat: Server Protocol        April 2000
   1069 
   1070 
   1071    For a reasonable history, a server SHOULD be able to keep previous
   1072    nickname for every client it knows about if they all decided to
   1073    change.  This size is limited by other factors (such as memory, etc).
   1074 
   1075 5.7 Tracking recently used nicknames
   1076 
   1077    This mechanism is commonly known as "Nickname Delay", it has been
   1078    proven to significantly reduce the number of nickname collisions
   1079    resulting from "network splits"/reconnections as well as abuse.
   1080 
   1081    In addition of keeping track of nickname changes, servers SHOULD keep
   1082    track of nicknames which were recently used and were released as the
   1083    result of a "network split" or a KILL message.  These nicknames are
   1084    then unavailable to the server local clients and cannot be re-used
   1085    (even though they are not currently in use) for a certain period of
   1086    time.
   1087 
   1088    The duration for which a nickname remains unavailable SHOULD be set
   1089    considering many factors among which are the size (user wise) of the
   1090    IRC network, and the usual duration of "network splits".  It SHOULD
   1091    be uniform on all servers for a given IRC network.
   1092 
   1093 5.8 Flood control of clients
   1094 
   1095    With a large network of interconnected IRC servers, it is quite easy
   1096    for any single client attached to the network to supply a continuous
   1097    stream of messages that result in not only flooding the network, but
   1098    also degrading the level of service provided to others.  Rather than
   1099    require every 'victim' to provide their own protection, flood
   1100    protection was written into the server and is applied to all clients
   1101    except services.  The current algorithm is as follows:
   1102 
   1103    * check to see if client's `message timer' is less than current time
   1104      (set to be equal if it is);
   1105 
   1106    * read any data present from the client;
   1107 
   1108    * while the timer is less than ten (10) seconds ahead of the current
   1109      time, parse any present messages and penalize the client by two (2)
   1110      seconds for each message;
   1111 
   1112    * additional penalties MAY be used for specific commands which
   1113      generate a lot of traffic across the network.
   1114 
   1115    This in essence means that the client may send one (1) message every
   1116    two (2) seconds without being adversely affected.  Services MAY also
   1117    be subject to this mechanism.
   1118 
   1119 
   1120 
   1121 
   1122 Kalt                         Informational                     [Page 20]
   1123 
   1124 RFC 2813          Internet Relay Chat: Server Protocol        April 2000
   1125 
   1126 
   1127 5.9 Non-blocking lookups
   1128 
   1129    In a real-time environment, it is essential that a server process
   1130    does as little waiting as possible so that all the clients are
   1131    serviced fairly.  Obviously this requires non-blocking IO on all
   1132    network read/write operations.  For normal server connections, this
   1133    was not difficult, but there are other support operations that may
   1134    cause the server to block (such as disk reads).  Where possible, such
   1135    activity SHOULD be performed with a short timeout.
   1136 
   1137 5.9.1 Hostname (DNS) lookups
   1138 
   1139    Using the standard resolver libraries from Berkeley and others has
   1140    meant large delays in some cases where replies have timed out.  To
   1141    avoid this, a separate set of DNS routines were written for the
   1142    current implementation.  Routines were setup for non-blocking IO
   1143    operations with local cache, and then polled from within the main
   1144    server IO loop.
   1145 
   1146 5.9.2 Username (Ident) lookups
   1147 
   1148    Although there are numerous ident libraries (implementing the
   1149    "Identification Protocol" [IDENT]) for use and inclusion into other
   1150    programs, these caused problems since they operated in a synchronous
   1151    manner and resulted in frequent delays.  Again the solution was to
   1152    write a set of routines which would cooperate with the rest of the
   1153    server and work using non-blocking IO.
   1154 
   1155 6. Current problems
   1156 
   1157    There are a number of recognized problems with this protocol, all of
   1158    which are hoped to be solved sometime in the near future during its
   1159    rewrite.  Currently, work is underway to find working solutions to
   1160    these problems.
   1161 
   1162 6.1 Scalability
   1163 
   1164    It is widely recognized that this protocol does not scale
   1165    sufficiently well when used in a large arena.  The main problem comes
   1166    from the requirement that all servers know about all other servers
   1167    and clients and that information regarding them be updated as soon as
   1168    it changes.  It is also desirable to keep the number of servers low
   1169    so that the path length between any two points is kept minimal and
   1170    the spanning tree as strongly branched as possible.
   1171 
   1172 
   1173 
   1174 
   1175 
   1176 
   1177 
   1178 Kalt                         Informational                     [Page 21]
   1179 
   1180 RFC 2813          Internet Relay Chat: Server Protocol        April 2000
   1181 
   1182 
   1183 6.2 Labels
   1184 
   1185    The current IRC protocol has 4 types of labels: the nickname, the
   1186    channel name, the server name and the service name.  Each of the four
   1187    types has its own domain and no duplicates are allowed inside that
   1188    domain.  Currently, it is possible for users to pick the label for
   1189    any of the first three, resulting in collisions.  It is widely
   1190    recognized that this needs reworking, with a plan for unique names
   1191    for nicks that don't collide being desirable as well as a solution
   1192    allowing a cyclic tree.
   1193 
   1194 6.2.1 Nicknames
   1195 
   1196    The idea of the nickname on IRC is very convenient for users to use
   1197    when talking to each other outside of a channel, but there is only a
   1198    finite nickname space and being what they are, it's not uncommon for
   1199    several people to want to use the same nick.  If a nickname is chosen
   1200    by two people using this protocol, either one will not succeed or
   1201    both will be removed by use of KILL (See Section 3.7.1 of "IRC Client
   1202    Protocol" [IRC-CLIENT]).
   1203 
   1204 6.2.2 Channels
   1205 
   1206    The current channel layout requires that all servers know about all
   1207    channels, their inhabitants and properties.  Besides not scaling
   1208    well, the issue of privacy is also a concern.  A collision of
   1209    channels is treated as an inclusive event (people from both nets on
   1210    channel with common name are considered to be members of it) rather
   1211    than an exclusive one such as used to solve nickname collisions.
   1212 
   1213    This protocol defines "Safe Channels" which are very unlikely to be
   1214    the subject of a channel collision.  Other channel types are kept for
   1215    backward compatibility.
   1216 
   1217 6.2.3 Servers
   1218 
   1219    Although the number of servers is usually small relative to the
   1220    number of users and channels, they too are currently REQUIRED to be
   1221    known globally, either each one separately or hidden behind a mask.
   1222 
   1223 6.3 Algorithms
   1224 
   1225    In some places within the server code, it has not been possible to
   1226    avoid N^2 algorithms such as checking the channel list of a set of
   1227    clients.
   1228 
   1229 
   1230 
   1231 
   1232 
   1233 
   1234 Kalt                         Informational                     [Page 22]
   1235 
   1236 RFC 2813          Internet Relay Chat: Server Protocol        April 2000
   1237 
   1238 
   1239    In current server versions, there are only few database consistency
   1240    checks, most of the time each server assumes that a neighbouring
   1241    server is correct.  This opens the door to large problems if a
   1242    connecting server is buggy or otherwise tries to introduce
   1243    contradictions to the existing net.
   1244 
   1245    Currently, because of the lack of unique internal and global labels,
   1246    there are a multitude of race conditions that exist.  These race
   1247    conditions generally arise from the problem of it taking time for
   1248    messages to traverse and effect the IRC network.  Even by changing to
   1249    unique labels, there are problems with channel-related commands being
   1250    disrupted.
   1251 
   1252 7. Security Considerations
   1253 
   1254 7.1 Authentication
   1255 
   1256    Servers only have two means of authenticating incoming connections:
   1257    plain text password, and DNS lookups.  While these methods are weak
   1258    and widely recognized as unsafe, their combination has proven to be
   1259    sufficient in the past:
   1260 
   1261     * public networks typically allow user connections with only few
   1262       restrictions, without requiring accurate authentication.
   1263 
   1264     * private networks which operate in a controlled environment often
   1265       use home-grown authentication mechanisms not available on the
   1266       internet: reliable ident servers [IDENT], or other proprietary
   1267       mechanisms.
   1268 
   1269    The same comments apply to the authentication of IRC Operators.
   1270 
   1271    It should also be noted that while there has been no real demand over
   1272    the years for stronger authentication, and no real effort to provide
   1273    better means to safely authenticate users, the current protocol
   1274    offers enough to be able to easily plug-in external authentication
   1275    methods based on the information that a client can submit to the
   1276    server upon connection: nickname, username, password.
   1277 
   1278 7.2 Integrity
   1279 
   1280    Since the PASS and OPER messages of the IRC protocol are sent in
   1281    clear text, a stream layer encryption mechanism (like "The TLS
   1282    Protocol" [TLS]) could be used to protect these transactions.
   1283 
   1284 
   1285 
   1286 
   1287 
   1288 
   1289 
   1290 Kalt                         Informational                     [Page 23]
   1291 
   1292 RFC 2813          Internet Relay Chat: Server Protocol        April 2000
   1293 
   1294 
   1295 8. Current support and availability
   1296 
   1297       Mailing lists for IRC related discussion:
   1298         General discussion: ircd-users@irc.org
   1299         Protocol development: ircd-dev@irc.org
   1300 
   1301       Software implementations:
   1302         ftp://ftp.irc.org/irc/server
   1303         ftp://ftp.funet.fi/pub/unix/irc
   1304         ftp://coombs.anu.edu.au/pub/irc
   1305 
   1306       Newsgroup: alt.irc
   1307 
   1308 9. Acknowledgements
   1309 
   1310    Parts of this document were copied from the RFC 1459 [IRC] which
   1311    first formally documented the IRC Protocol.  It has also benefited
   1312    from many rounds of review and comments.  In particular, the
   1313    following people have made significant contributions to this
   1314    document:
   1315 
   1316    Matthew Green, Michael Neumayer, Volker Paulsen, Kurt Roeckx, Vesa
   1317    Ruokonen, Magnus Tjernstrom, Stefan Zehl.
   1318 
   1319 10. References
   1320 
   1321    [KEYWORDS]   Bradner, S., "Key words for use in RFCs to Indicate
   1322                 Requirement Levels", BCP 14, RFC 2119, March 1997.
   1323 
   1324    [ABNF]       Crocker, D. and P. Overell, "Augmented BNF for Syntax
   1325                 Specifications: ABNF", RFC 2234, November 1997.
   1326 
   1327    [IRC]        Oikarinen, J. and D. Reed, "Internet Relay Chat
   1328                 Protocol", RFC 1459, May 1993.
   1329 
   1330    [IRC-ARCH]   Kalt, C., "Internet Relay Chat: Architecture", RFC 2810,
   1331                 April 2000.
   1332 
   1333    [IRC-CLIENT] Kalt, C., "Internet Relay Chat: Client Protocol", RFC
   1334                 2812, April 2000.
   1335 
   1336 
   1337    [IRC-CHAN]   Kalt, C., "Internet Relay Chat: Channel Management", RFC
   1338                 2811, April 2000.
   1339 
   1340    [ZLIB]       Deutsch, P. and J-L. Gailly, "ZLIB Compressed Data
   1341                 Format Specification version 3.3", RFC 1950, May 1996.
   1342 
   1343 
   1344 
   1345 
   1346 Kalt                         Informational                     [Page 24]
   1347 
   1348 RFC 2813          Internet Relay Chat: Server Protocol        April 2000
   1349 
   1350 
   1351    [DEFLATE]    Deutsch, P., "DEFLATE Compressed Data Format
   1352                 Specification version 1.3", RFC 1951, May 1996.
   1353 
   1354    [GZIP]       Deutsch, P., "GZIP file format specification version
   1355                 4.3", RFC 1952, May 1996.
   1356 
   1357    [IDENT]      St. Johns, M., "The Identification Protocol", RFC 1413,
   1358                 February 1993.
   1359 
   1360    [TLS]        Dierks, T. and C. Allen, "The TLS Protocol", RFC 2246,
   1361                 January 1999.
   1362 
   1363 11. Author's Address
   1364 
   1365    Christophe Kalt
   1366    99 Teaneck Rd, Apt #117
   1367    Ridgefield Park, NJ 07660
   1368    USA
   1369 
   1370    EMail: kalt@stealth.net
   1371 
   1372 
   1373 
   1374 
   1375 
   1376 
   1377 
   1378 
   1379 
   1380 
   1381 
   1382 
   1383 
   1384 
   1385 
   1386 
   1387 
   1388 
   1389 
   1390 
   1391 
   1392 
   1393 
   1394 
   1395 
   1396 
   1397 
   1398 
   1399 
   1400 
   1401 
   1402 Kalt                         Informational                     [Page 25]
   1403 
   1404 RFC 2813          Internet Relay Chat: Server Protocol        April 2000
   1405 
   1406 
   1407 12.  Full Copyright Statement
   1408 
   1409    Copyright (C) The Internet Society (2000).  All Rights Reserved.
   1410 
   1411    This document and translations of it may be copied and furnished to
   1412    others, and derivative works that comment on or otherwise explain it
   1413    or assist in its implementation may be prepared, copied, published
   1414    and distributed, in whole or in part, without restriction of any
   1415    kind, provided that the above copyright notice and this paragraph are
   1416    included on all such copies and derivative works.  However, this
   1417    document itself may not be modified in any way, such as by removing
   1418    the copyright notice or references to the Internet Society or other
   1419    Internet organizations, except as needed for the purpose of
   1420    developing Internet standards in which case the procedures for
   1421    copyrights defined in the Internet Standards process must be
   1422    followed, or as required to translate it into languages other than
   1423    English.
   1424 
   1425    The limited permissions granted above are perpetual and will not be
   1426    revoked by the Internet Society or its successors or assigns.
   1427 
   1428    This document and the information contained herein is provided on an
   1429    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   1430    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   1431    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   1432    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   1433    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
   1434 
   1435 Acknowledgement
   1436 
   1437    Funding for the RFC Editor function is currently provided by the
   1438    Internet Society.
   1439 
   1440 
   1441 
   1442 
   1443 
   1444 
   1445 
   1446 
   1447 
   1448 
   1449 
   1450 
   1451 
   1452 
   1453 
   1454 
   1455 
   1456 
   1457 
   1458 Kalt                         Informational                     [Page 26]
   1459