text:
                RFC 2813 - Internet Relay Chat: Server Protocol

     ----------------------------------------------------------------------

 Network Working Group                                           C. Kalt
 Request for Comments: 2813                                   April 2000
 Updates: 1459
 Category: Informational

                   Internet Relay Chat: Server Protocol

 Status of this Memo

    This memo provides information for the Internet community.  It does
    not specify an Internet standard of any kind.  Distribution of this
    memo is unlimited.

 Copyright Notice

    Copyright (C) The Internet Society (2000).  All Rights Reserved.

 Abstract

    While based on the client-server model, the IRC (Internet Relay Chat)
    protocol allows servers to connect to each other effectively forming
    a network.

    This document defines the protocol used by servers to talk to each
    other.  It was originally a superset of the client protocol but has
    evolved differently.

    First formally documented in May 1993 as part of RFC 1459 [IRC], most
    of the changes brought since then can be found in this document as
    development was focused on making the protocol scale better.  Better
    scalability has allowed existing world-wide networks to keep growing
    and reach sizes which defy the old specification.

 Table of Contents

    1.  Introduction ...............................................   3
    2.  Global database ............................................   3
       2.1  Servers ................................................   3
       2.2  Clients ................................................   4
          2.2.1  Users .............................................   4
          2.2.2  Services ..........................................   4
       2.3  Channels ...............................................   4
    3.  The IRC Server Specification ...............................   5
       3.1  Overview ...............................................   5
       3.2  Character codes ........................................   5
       3.3  Messages ...............................................   5
          3.3.1  Message format in Augmented BNF ...................   6
       3.4  Numeric replies ........................................   7
    4.  Message Details ............................................   7
       4.1  Connection Registration ................................   8
          4.1.1  Password message ..................................   8
          4.1.2  Server message ....................................   9
          4.1.3  Nick ..............................................  10
          4.1.4  Service message ...................................  11
          4.1.5  Quit ..............................................  12
          4.1.6  Server quit message ...............................  13
       4.2  Channel operations .....................................  14
          4.2.1  Join message ......................................  14
          4.2.2  Njoin message .....................................  15
          4.2.3  Mode message ......................................  16
    5.  Implementation details  ....................................  16
       5.1  Connection 'Liveness' ..................................  16
       5.2  Accepting a client to server connection ................  16
          5.2.1  Users .............................................  16
          5.2.2  Services ..........................................  17
       5.3  Establishing a server-server connection. ...............  17
          5.3.1  Link options ......................................  17
             5.3.1.1  Compressed server to server links ............  18
             5.3.1.2  Anti abuse protections .......................  18
          5.3.2  State information exchange when connecting ........  18
       5.4  Terminating server-client connections ..................  19
       5.5  Terminating server-server connections ..................  19
       5.6  Tracking nickname changes ..............................  19
       5.7  Tracking recently used nicknames .......................  20
       5.8  Flood control of clients ...............................  20
       5.9  Non-blocking lookups ...................................  21
          5.9.1  Hostname (DNS) lookups ............................  21
          5.9.2  Username (Ident) lookups ..........................  21
    6.  Current problems ...........................................  21
       6.1  Scalability ............................................  21
       6.2  Labels .................................................  22
          6.2.1  Nicknames .........................................  22
          6.2.2  Channels ..........................................  22
          6.2.3  Servers ...........................................  22
       6.3  Algorithms .............................................  22
    7.  Security Considerations ....................................  23
       7.1  Authentication .........................................  23
       7.2  Integrity ..............................................  23
    8.  Current support and availability ...........................  24
    9.  Acknowledgements ...........................................  24
    10.  References ................................................  24
    11.  Author's Address ..........................................  25
    12. Full Copyright Statement ...................................  26

 1. Introduction

    This document is intended for people working on implementing an IRC
    server but will also be useful to anyone implementing an IRC service.

    Servers provide the three basic services required for realtime
    conferencing defined by the "Internet Relay Chat: Architecture"
    [IRC-ARCH]: client locator (via the client protocol [IRC-CLIENT]),
    message relaying (via the server protocol defined in this document)
    and channel hosting and management (following specific rules [IRC-
    CHAN]).

 2. Global database

    Although the IRC Protocol defines a fairly distributed model, each
    server maintains a "global state database" about the whole IRC
    network.  This database is, in theory, identical on all servers.

 2.1 Servers

    Servers are uniquely identified by their name which has a maximum
    length of sixty three (63) characters.  See the protocol grammar
    rules (section 3.3.1) for what may and may not be used in a server
    name.

    Each server is typically known by all other servers, however it is
    possible to define a "hostmask" to group servers together according
    to their name.  Inside the hostmasked area, all the servers have a
    name which matches the hostmask, and any other server with a name
    matching the hostmask SHALL NOT be connected to the IRC network
    outside the hostmasked area.  Servers which are outside the area have
    no knowledge of the individual servers present inside the area,
    instead they are presented with a virtual server which has the
    hostmask for name.

 2.2 Clients

    For each client, all servers MUST have the following information: a
    netwide unique identifier (whose format depends on the type of
    client) and the server to which the client is connected.

 2.2.1 Users

    Each user is distinguished from other users by a unique nickname
    having a maximum length of nine (9) characters.  See the protocol
    grammar rules (section 3.3.1) for what may and may not be used in a
    nickname.  In addition to the nickname, all servers MUST have the
    following information about all users: the name of the host that the
    user is running on, the username of the user on that host, and the
    server to which the client is connected.

 2.2.2 Services

    Each service is distinguished from other services by a service name
    composed of a nickname and a server name.  The nickname has a maximum
    length of nine (9) characters.  See the protocol grammar rules
    (section 3.3.1) for what may and may not be used in a nickname.  The
    server name used to compose the service name is the name of the
    server to which the service is connected.  In addition to this
    service name all servers MUST know the service type.

    Services differ from users by the format of their identifier, but
    more importantly services and users don't have the same type of
    access to the server: services can request part or all of the global
    state information that a server maintains, but have a more restricted
    set of commands available to them (See "IRC Client Protocol" [IRC-
    CLIENT] for details on which) and are not allowed to join channels.
    Finally services are not usually subject to the "Flood control"
    mechanism described in section 5.8.

 2.3 Channels

    Alike services, channels have a scope [IRC-CHAN] and are not
    necessarily known to all servers.  When a channel existence is known
    to a server, the server MUST keep track of the channel members, as
    well as the channel modes.

 3. The IRC Server Specification

 3.1 Overview

    The protocol as described herein is for use with server to server
    connections.  For client to server connections, see the IRC Client
    Protocol specification.

    There are, however, more restrictions on client connections (which
    are considered to be untrustworthy) than on server connections.

 3.2 Character codes

    No specific character set is specified. The protocol is based on a a
    set of codes which are composed of eight (8) bits, making up an
    octet.  Each message may be composed of any number of these octets;
    however, some octet values are used for control codes which act as
    message delimiters.

    Regardless of being an 8-bit protocol, the delimiters and keywords
    are such that protocol is mostly usable from US-ASCII terminal and a
    telnet connection.

    Because of IRC's Scandinavian origin, the characters {}|^ are
    considered to be the lower case equivalents of the characters []\~,
    respectively. This is a critical issue when determining the
    equivalence of two nicknames, or channel names.

 3.3 Messages

    Servers and clients send each other messages which may or may not
    generate a reply.  Most communication between servers do not generate
    any reply, as servers mostly perform routing tasks for the clients.

    Each IRC message may consist of up to three main parts: the prefix
    (OPTIONAL), the command, and the command parameters (maximum of
    fifteen (15)).  The prefix, command, and all parameters are separated
    by one ASCII space character (0x20) each.

    The presence of a prefix is indicated with a single leading ASCII
    colon character (':', 0x3b), which MUST be the first character of the
    message itself.  There MUST be NO gap (whitespace) between the colon
    and the prefix.  The prefix is used by servers to indicate the true
    origin of the message.  If the prefix is missing from the message, it
    is assumed to have originated from the connection from which it was
    received.  Clients SHOULD not use a prefix when sending a message
    from themselves; if they use one, the only valid prefix is the
    registered nickname associated with the client.

    When a server receives a message, it MUST identify its source using
    the (eventually assumed) prefix.  If the prefix cannot be found in
    the server's internal database, it MUST be discarded, and if the
    prefix indicates the message comes from an (unknown) server, the link
    from which the message was received MUST be dropped.  Dropping a link
    in such circumstances is a little excessive but necessary to maintain
    the integrity of the network and to prevent future problems.  Another
    common error condition is that the prefix found in the server's
    internal database identifies a different source (typically a source
    registered from a different link than from which the message
    arrived).  If the message was received from a server link and the
    prefix identifies a client, a KILL message MUST be issued for the
    client and sent to all servers.  In other cases, the link from which
    the message arrived SHOULD be dropped for clients, and MUST be
    dropped for servers.  In all cases, the message MUST be discarded.

    The command MUST either be a valid IRC command or a three (3) digit
    number represented in ASCII text.

    IRC messages are always lines of characters terminated with a CR-LF
    (Carriage Return - Line Feed) pair, and these messages SHALL NOT
    exceed 512 characters in length, counting all characters including
    the trailing CR-LF. Thus, there are 510 characters maximum allowed
    for the command and its parameters.  There is no provision for
    continuation message lines.  See section 5 for more details about
    current implementations.

 3.3.1 Message format in Augmented BNF

    The protocol messages must be extracted from the contiguous stream of
    octets.  The current solution is to designate two characters, CR and
    LF, as message separators.  Empty messages are silently ignored,
    which permits use of the sequence CR-LF between messages without
    extra problems.

    The extracted message is parsed into the components <prefix>,
    <command> and list of parameters (<params>).

    The Augmented BNF representation for this is found in "IRC Client
    Protocol" [IRC-CLIENT].

    The extended prefix (["!" user "@" host ]) MUST NOT be used in server
    to server communications and is only intended for server to client
    messages in order to provide clients with more useful information
    about who a message is from without the need for additional queries.

 3.4 Numeric replies

    Most of the messages sent to the server generate a reply of some
    sort.  The most common reply is the numeric reply, used for both
    errors and normal replies.  The numeric reply MUST be sent as one
    message consisting of the sender prefix, the three digit numeric, and
    the target of the reply.  A numeric reply is not allowed to originate
    from a client; any such messages received by a server are silently
    dropped. In all other respects, a numeric reply is just like a normal
    message, except that the keyword is made up of 3 numeric digits
    rather than a string of letters.  A list of different replies is
    supplied in "IRC Client Protocol" [IRC-CLIENT].

 4. Message Details

    All the messages recognized by the IRC server and client are
    described in the IRC Client Protocol specification.

    Where the reply ERR_NOSUCHSERVER is returned, it means that the
    target of the message could not be found.  The server MUST NOT send
    any other replies after this error for that command.

    The server to which a client is connected is required to parse the
    complete message, returning any appropriate errors.  If the server
    encounters a fatal error while parsing a message, an error MUST be
    sent back to the client and the parsing terminated.  A fatal error
    may follow from incorrect command, a destination which is otherwise
    unknown to the server (server, client or channel names fit this
    category), not enough parameters or incorrect privileges.

    If a full set of parameters is presented, then each MUST be checked
    for validity and appropriate responses sent back to the client.  In
    the case of messages which use parameter lists using the comma as an
    item separator, a reply MUST be sent for each item.

    In the examples below, some messages appear using the full format:

    :Name COMMAND parameter list

    Such examples represent a message from "Name" in transit between
    servers, where it is essential to include the name of the original
    sender of the message so remote servers may send back a reply along
    the correct path.

    The message details for client to server communication are described
    in the "IRC Client Protocol" [IRC-CLIENT].  Some sections in the
    following pages apply to some of these messages, they are additions
    to the message specifications which are only relevant to server to

    server communication, or to the server implementation.  The messages
    which are introduced here are only used for server to server
    communication.

 4.1 Connection Registration

    The commands described here are used to register a connection with
    another IRC server.

 4.1.1 Password message

       Command: PASS
    Parameters: <password> <version> <flags> [<options>]

    The PASS command is used to set a 'connection password'.  The
    password MUST be set before any attempt to register the connection is
    made.  Currently this means that servers MUST send a PASS command
    before any SERVER command.  Only one (1) PASS command SHALL be
    accepted from a connection.

    The last three (3) parameters MUST be ignored if received from a
    client (e.g. a user or a service).  They are only relevant when
    received from a server.

    The <version> parameter is a string of at least four (4) characters,
    and up to fourteen (14) characters.  The first four (4) characters
    MUST be digits and indicate the protocol version known by the server
    issuing the message.  The protocol described by this document is
    version 2.10 which is encoded as "0210".  The remaining OPTIONAL
    characters are implementation dependent and should describe the
    software version number.

    The <flags> parameter is a string of up to one hundred (100)
    characters.  It is composed of two substrings separated by the
    character "|" (%x7C).  If present, the first substring MUST be the
    name of the implementation.  The reference implementation (See
    Section 8, "Current support and availability") uses the string "IRC".
    If a different implementation is written, which needs an identifier,
    then that identifier should be registered through publication of an
    RFC. The second substring is implementation dependent.  Both
    substrings are OPTIONAL, but the character "|" is REQUIRED.  The
    character "|" MUST NOT appear in either substring.

    Finally, the last parameter, <options>, is used for link options.
    The only options defined by the protocol are link compression (using
    the character "Z"), and an abuse protection flag (using the character

    "P").  See sections 5.3.1.1 (Compressed server to server links) and
    5.3.1.2 (Anti abuse protections) respectively for more information on
    these options.

    Numeric Replies:

            ERR_NEEDMOREPARAMS              ERR_ALREADYREGISTRED

    Example:

         PASS moresecretpassword 0210010000 IRC|aBgH$ Z

 4.1.2 Server message

       Command: SERVER
    Parameters: <servername> <hopcount> <token> <info>

    The SERVER command is used to register a new server. A new connection
    introduces itself as a server to its peer.  This message is also used
    to pass server data over whole net.  When a new server is connected
    to net, information about it MUST be broadcasted to the whole
    network.

    The <info> parameter may contain space characters.

    <hopcount> is used to give all servers some internal information on
    how far away each server is.  Local peers have a value of 0, and each
    passed server increments the value.  With a full server list, it
    would be possible to construct a map of the entire server tree, but
    hostmasks prevent this from being done.

    The <token> parameter is an unsigned number used by servers as an
    identifier.  This identifier is subsequently used to reference a
    server in the NICK and SERVICE messages sent between servers.  Server
    tokens only have a meaning for the point-to-point peering they are
    used and MUST be unique for that connection.  They are not global.

    The SERVER message MUST only be accepted from either (a) a connection
    which is yet to be registered and is attempting to register as a
    server, or (b) an existing connection to another server, in which
    case the SERVER message is introducing a new server behind that
    server.

    Most errors that occur with the receipt of a SERVER command result in
    the connection being terminated by the destination host (target
    SERVER).  Because of the severity of such event, error replies are
    usually sent using the "ERROR" command rather than a numeric.

    If a SERVER message is parsed and it attempts to introduce a server
    which is already known to the receiving server, the connection, from
    which that message arrived, MUST be closed (following the correct
    procedures), since a duplicate route to a server has been formed and
    the acyclic nature of the IRC tree breaks.  In some conditions, the
    connection from which the already known server has registered MAY be
    closed instead.  It should be noted that this kind of error can also
    be the result of a second running server, problem which cannot be
    fixed within the protocol and typically requires human intervention.
    This type of problem is particularly insidious, as it can quite
    easily result in part of the IRC network to be isolated, with one of
    the two servers connected to each partition therefore making it
    impossible for the two parts to unite.

    Numeric Replies:

            ERR_ALREADYREGISTRED

    Example:

    SERVER test.oulu.fi 1 1 :Experimental server ; New server
                                    test.oulu.fi introducing itself and
                                    attempting to register.

    :tolsun.oulu.fi SERVER csd.bu.edu 5 34 :BU Central Server ; Server
                                    tolsun.oulu.fi is our uplink for
                                    csd.bu.edu which is 5 hops away.  The
                                    token "34" will be used by
                                    tolsun.oulu.fi when introducing new
                                    users or services connected to
                                    csd.bu.edu.

 4.1.3 Nick

       Command: NICK
    Parameters: <nickname> <hopcount> <username> <host> <servertoken>
                <umode> <realname>

    This form of the NICK message MUST NOT be allowed from user
    connections. However, it MUST be used instead of the NICK/USER pair
    to notify other servers of new users joining the IRC network.

    This message is really the combination of three distinct messages:
    NICK, USER and MODE [IRC-CLIENT].

    The <hopcount> parameter is used by servers to indicate how far away
    a user is from its home server.  A local connection has a hopcount of
    0.  The hopcount value is incremented by each passed server.

    The <servertoken> parameter replaces the <servername> parameter of
    the USER (See section 4.1.2 for more information on server tokens).

    Examples:

    NICK syrk 5 kalt millennium.stealth.net 34 +i :Christophe Kalt ; New
                                    user with nickname "syrk", username
                                    "kalt", connected from host
                                    "millennium.stealth.net" to server
                                    "34" ("csd.bu.edu" according to the
                                    previous example).

    :krys NICK syrk                 ; The other form of the NICK message,
                                    as defined in "IRC Client Protocol"
                                    [IRC-CLIENT] and used between
                                    servers: krys changed his nickname to
                                    syrk

 4.1.4 Service message

       Command: SERVICE
    Parameters: <servicename> <servertoken> <distribution> <type>
                 <hopcount> <info>

    The SERVICE command is used to introduce a new service.  This form of
    the SERVICE message SHOULD NOT be allowed from client (unregistered,
    or registered) connections.  However, it MUST be used between servers
    to notify other servers of new services joining the IRC network.

    The <servertoken> is used to identify the server to which the service
    is connected.  (See section 4.1.2 for more information on server
    tokens).

    The <hopcount> parameter is used by servers to indicate how far away
    a service is from its home server.  A local connection has a hopcount
    of 0.  The hopcount value is incremented by each passed server.

    The <distribution> parameter is used to specify the visibility of a
    service.  The service may only be known to servers which have a name
    matching the distribution.  For a matching server to have knowledge
    of the service, the network path between that server and the server
    to which the service is connected MUST be composed of servers whose
    names all match the mask.  Plain "*" is used when no restriction is
    wished.

    The <type> parameter is currently reserved for future usage.

    Numeric Replies:

            ERR_ALREADYREGISTRED            ERR_NEEDMOREPARAMS
            ERR_ERRONEUSNICKNAME
            RPL_YOURESERVICE                RPL_YOURHOST
            RPL_MYINFO

    Example:

 SERVICE dict@irc.fr 9 *.fr 0 1 :French Dictionary r" registered on
                                    server "9" is being announced to
                                    another server.  This service will
                                    only be available on servers whose
                                    name matches "*.fr".

 4.1.5 Quit

       Command: QUIT
    Parameters: [<Quit Message>]

    A client session ends with a quit message.  The server MUST close the
    connection to a client which sends a QUIT message. If a "Quit
    Message" is given, this will be sent instead of the default message,
    the nickname or service name.

    When "netsplit" (See Section 4.1.6) occur, the "Quit Message" is
    composed of the names of two servers involved, separated by a space.
    The first name is that of the server which is still connected and the
    second name is either that of the server which has become
    disconnected or that of the server to which the leaving client was
    connected:

       <Quit Message> =  ":" servername SPACE servername

    Because the "Quit Message" has a special meaning for "netsplits",
    servers SHOULD NOT allow a client to use a <Quit Message> in the
    format described above.

    If, for some other reason, a client connection is closed without the
    client issuing a QUIT command (e.g. client dies and EOF occurs on
    socket), the server is REQUIRED to fill in the quit message with some
    sort of message reflecting the nature of the event which caused it to
    happen.  Typically, this is done by reporting a system specific
    error.

    Numeric Replies:

            None.

    Examples:

    :WiZ QUIT :Gone to have lunch   ; Preferred message format.

 4.1.6 Server quit message

       Command: SQUIT
    Parameters: <server> <comment>

    The SQUIT message has two distinct uses.

    The first one (described in "Internet Relay Chat: Client Protocol"
    [IRC-CLIENT]) allows operators to break a local or remote server
    link.  This form of the message is also eventually used by servers to
    break a remote server link.

    The second use of this message is needed to inform other servers when
    a "network split" (also known as "netsplit") occurs, in other words
    to inform other servers about quitting or dead servers.  If a server
    wishes to break the connection to another server it MUST send a SQUIT
    message to the other server, using the name of the other server as
    the server parameter, which then closes its connection to the
    quitting server.

    The <comment> is filled in by servers which SHOULD place an error or
    similar message here.

    Both of the servers which are on either side of the connection being
    closed are REQUIRED to send out a SQUIT message (to all its other
    server connections) for all other servers which are considered to be
    behind that link.

    Similarly, a QUIT message MAY be sent to the other still connected
    servers on behalf of all clients behind that quitting link.  In
    addition to this, all channel members of a channel which lost a
    member due to the "split" MUST be sent a QUIT message.  Messages to
    channel members are generated by each client's local server.

    If a server connection is terminated prematurely (e.g., the server on
    the other end of the link died), the server which detects this
    disconnection is REQUIRED to inform the rest of the network that the
    connection has closed and fill in the comment field with something
    appropriate.

    When a client is removed as the result of a SQUIT message, the server
    SHOULD add the nickname to the list of temporarily unavailable
    nicknames in an attempt to prevent future nickname collisions. See

    section 5.7 (Tracking recently used nicknames) for more information
    on this procedure.

    Numeric replies:

            ERR_NOPRIVILEGES                ERR_NOSUCHSERVER
            ERR_NEEDMOREPARAMS

    Example:

    SQUIT tolsun.oulu.fi :Bad Link ?  ; the server link tolson.oulu.fi
                                    has been terminated because of "Bad
                                    Link".

    :Trillian SQUIT cm22.eng.umd.edu :Server out of control ; message
                                    from Trillian to disconnect
                                    "cm22.eng.umd.edu" from the net
                                    because "Server out of control".

 4.2 Channel operations

    This group of messages is concerned with manipulating channels, their
    properties (channel modes), and their contents (typically users).  In
    implementing these, a number of race conditions are inevitable when
    users at opposing ends of a network send commands which will
    ultimately clash.  It is also REQUIRED that servers keep a nickname
    history to ensure that wherever a <nick> parameter is given, the
    server check its history in case it has recently been changed.

 4.2.1 Join message

       Command: JOIN
    Parameters: <channel>[ %x7 <modes> ]
                *( "," <channel>[ %x7 <modes> ] )

    The JOIN command is used by client to start listening a specific
    channel. Whether or not a client is allowed to join a channel is
    checked only by the local server the client is connected to; all
    other servers automatically add the user to the channel when the
    command is received from other servers.

    Optionally, the user status (channel modes 'O', 'o', and 'v') on the
    channel may be appended to the channel name using a control G (^G or
    ASCII 7) as separator.  Such data MUST be ignored if the message
    wasn't received from a server.  This format MUST NOT be sent to
    clients, it can only be used between servers and SHOULD be avoided.

    The JOIN command MUST be broadcast to all servers so that each server
    knows where to find the users who are on the channel.  This allows
    optimal delivery of PRIVMSG and NOTICE messages to the channel.

    Numeric Replies:

            ERR_NEEDMOREPARAMS              ERR_BANNEDFROMCHAN
            ERR_INVITEONLYCHAN              ERR_BADCHANNELKEY
            ERR_CHANNELISFULL               ERR_BADCHANMASK
            ERR_NOSUCHCHANNEL               ERR_TOOMANYCHANNELS
            ERR_TOOMANYTARGETS              ERR_UNAVAILRESOURCE
            RPL_TOPIC

    Examples:

    :WiZ JOIN #Twilight_zone        ; JOIN message from WiZ

 4.2.2 Njoin message

       Command: NJOIN
    Parameters: <channel> [ "@@" / "@" ] [ "+" ] <nickname>
                          *( "," [ "@@" / "@" ] [ "+" ] <nickname> )

    The NJOIN message is used between servers only.  If such a message is
    received from a client, it MUST be ignored.  It is used when two
    servers connect to each other to exchange the list of channel members
    for each channel.

    Even though the same function can be performed by using a succession
    of JOIN, this message SHOULD be used instead as it is more efficient.
    The prefix "@@" indicates that the user is the "channel creator", the
    character "@" alone indicates a "channel operator", and the character
    '+' indicates that the user has the voice privilege.

    Numeric Replies:

            ERR_NEEDMOREPARAMS              ERR_NOSUCHCHANNEL
            ERR_ALREADYREGISTRED

    Examples:

    :ircd.stealth.net NJOIN #Twilight_zone :@WiZ,+syrk,avalon ; NJOIN
                                    message from ircd.stealth.net
                                    announcing users joining the
                                    #Twilight_zone channel: WiZ with
                                    channel operator status, syrk with
                                    voice privilege and avalon with no
                                    privilege.

 4.2.3 Mode message

    The MODE message is a dual-purpose command in IRC.  It allows both
    usernames and channels to have their mode changed.

    When parsing MODE messages, it is RECOMMENDED that the entire message
    be parsed first, and then the changes which resulted passed on.

    It is REQUIRED that servers are able to change channel modes so that
    "channel creator" and "channel operators" may be created.

 5. Implementation details

    A the time of writing, the only current implementation of this
    protocol is the IRC server, version 2.10. Earlier versions may
    implement some or all of the commands described by this document with
    NOTICE messages replacing many of the numeric replies. Unfortunately,
    due to backward compatibility requirements, the implementation of
    some parts of this document varies with what is laid out.  One
    notable difference is:

         * recognition that any LF or CR anywhere in a message marks
           the end of that message (instead of requiring CR-LF);

    The rest of this section deals with issues that are mostly of
    importance to those who wish to implement a server but some parts
    also apply directly to clients as well.

 5.1 Connection 'Liveness'

    To detect when a connection has died or become unresponsive, the
    server MUST poll each of its connections.  The PING command (See "IRC
    Client Protocol" [IRC-CLIENT]) is used if the server doesn't get a
    response from its peer in a given amount of time.

    If a connection doesn't respond in time, its connection is closed
    using the appropriate procedures.

 5.2 Accepting a client to server connection

 5.2.1 Users

    When a server successfully registers a new user connection, it is
    REQUIRED to send to the user unambiguous messages stating: the user
    identifiers upon which it was registered (RPL_WELCOME), the server
    name and version (RPL_YOURHOST), the server birth information
    (RPL_CREATED), available user and channel modes (RPL_MYINFO), and it
    MAY send any introductory messages which may be deemed appropriate.

    In particular the server SHALL send the current user/service/server
    count (as per the LUSER reply) and finally the MOTD (if any, as per
    the MOTD reply).

    After dealing with registration, the server MUST then send out to
    other servers the new user's nickname (NICK message), other
    information as supplied by itself (USER message) and as the server
    could discover (from DNS servers).  The server MUST NOT send this
    information out with a pair of NICK and USER messages as defined in
    "IRC Client Protocol" [IRC-CLIENT], but MUST instead take advantage
    of the extended NICK message defined in section 4.1.3.

 5.2.2 Services

    Upon successfully registering a new service connection, the server is
    subject to the same kind of REQUIREMENTS as for a user.  Services
    being somewhat different, only the following replies are sent:
    RPL_YOURESERVICE, RPL_YOURHOST, RPL_MYINFO.

    After dealing with this, the server MUST then send out to other
    servers (SERVICE message) the new service's nickname and other
    information as supplied by the service (SERVICE message) and as the
    server could discover (from DNS servers).

 5.3 Establishing a server-server connection.

    The process of establishing a server-to-server connection is fraught
    with danger since there are many possible areas where problems can
    occur - the least of which are race conditions.

    After a server has received a connection following by a PASS/SERVER
    pair which were recognized as being valid, the server SHOULD then
    reply with its own PASS/SERVER information for that connection as
    well as all of the other state information it knows about as
    described below.

    When the initiating server receives a PASS/SERVER pair, it too then
    checks that the server responding is authenticated properly before
    accepting the connection to be that server.

 5.3.1 Link options

    Server links are based on a common protocol (defined by this
    document) but a particular link MAY set specific options using the
    PASS message (See Section 4.1.1).

 5.3.1.1 Compressed server to server links

    If a server wishes to establish a compressed link with its peer, it
    MUST set the 'Z' flag in the options parameter to the PASS message.
    If both servers request compression and both servers are able to
    initialize the two compressed streams, then the remainder of the
    communication is to be compressed.  If any server fails to initialize
    the stream, it will send an uncompressed ERROR message to its peer
    and close the connection.

    The data format used for the compression is described by RFC 1950
    [ZLIB], RFC 1951 [DEFLATE] and RFC 1952 [GZIP].

 5.3.1.2 Anti abuse protections

    Most servers implement various kinds of protections against possible
    abusive behaviours from non trusted parties (typically users).  On
    some networks, such protections are indispensable, on others they are
    superfluous.  To require that all servers implement and enable such
    features on a particular network, the 'P' flag is used when two
    servers connect.  If this flag is present, it means that the server
    protections are enabled, and that the server REQUIRES all its server
    links to enable them as well.

    Commonly found protections are described in sections 5.7 (Tracking
    recently used nicknames) and 5.8 (Flood control of clients).

 5.3.2 State information exchange when connecting

    The order of state information being exchanged between servers is
    essential.  The REQUIRED order is as follows:

            * all known servers;

            * all known client information;

            * all known channel information.

    Information regarding servers is sent via extra SERVER messages,
    client information with NICK and SERVICE messages and channels with
    NJOIN/MODE messages.

    NOTE: channel topics SHOULD NOT be exchanged here because the TOPIC
    command overwrites any old topic information, so at best, the two
    sides of the connection would exchange topics.

    By passing the state information about servers first, any collisions
    with servers that already exist occur before nickname collisions
    caused by a second server introducing a particular nickname.  Due to
    the IRC network only being able to exist as an acyclic graph, it may
    be possible that the network has already reconnected in another
    location.  In this event, the place where the server collision occurs
    indicates where the net needs to split.

 5.4 Terminating server-client connections

    When a client connection unexpectedly closes, a QUIT message is
    generated on behalf of the client by the server to which the client
    was connected.  No other message is to be generated or used.

 5.5 Terminating server-server connections

    If a server-server connection is closed, either via a SQUIT command
    or "natural" causes, the rest of the connected IRC network MUST have
    its information updated by the server which detected the closure.
    The terminating server then sends a list of SQUITs (one for each
    server behind that connection).  (See Section 4.1.6 (SQUIT)).

 5.6 Tracking nickname changes

    All IRC servers are REQUIRED to keep a history of recent nickname
    changes.  This is important to allow the server to have a chance of
    keeping in touch of things when nick-change race conditions occur
    with commands manipulating them.  Messages which MUST trace nick
    changes are:

            * KILL (the nick being disconnected)

            * MODE (+/- o,v on channels)

            * KICK (the nick being removed from channel)

       No other commands need to check nick changes.

    In the above cases, the server is required to first check for the
    existence of the nickname, then check its history to see who that
    nick now belongs to (if anyone!).  This reduces the chances of race
    conditions but they can still occur with the server ending up
    affecting the wrong client.  When performing a change trace for an
    above command it is RECOMMENDED that a time range be given and
    entries which are too old ignored.

    For a reasonable history, a server SHOULD be able to keep previous
    nickname for every client it knows about if they all decided to
    change.  This size is limited by other factors (such as memory, etc).

 5.7 Tracking recently used nicknames

    This mechanism is commonly known as "Nickname Delay", it has been
    proven to significantly reduce the number of nickname collisions
    resulting from "network splits"/reconnections as well as abuse.

    In addition of keeping track of nickname changes, servers SHOULD keep
    track of nicknames which were recently used and were released as the
    result of a "network split" or a KILL message.  These nicknames are
    then unavailable to the server local clients and cannot be re-used
    (even though they are not currently in use) for a certain period of
    time.

    The duration for which a nickname remains unavailable SHOULD be set
    considering many factors among which are the size (user wise) of the
    IRC network, and the usual duration of "network splits".  It SHOULD
    be uniform on all servers for a given IRC network.

 5.8 Flood control of clients

    With a large network of interconnected IRC servers, it is quite easy
    for any single client attached to the network to supply a continuous
    stream of messages that result in not only flooding the network, but
    also degrading the level of service provided to others.  Rather than
    require every 'victim' to provide their own protection, flood
    protection was written into the server and is applied to all clients
    except services.  The current algorithm is as follows:

    * check to see if client's `message timer' is less than current time
      (set to be equal if it is);

    * read any data present from the client;

    * while the timer is less than ten (10) seconds ahead of the current
      time, parse any present messages and penalize the client by two (2)
      seconds for each message;

    * additional penalties MAY be used for specific commands which
      generate a lot of traffic across the network.

    This in essence means that the client may send one (1) message every
    two (2) seconds without being adversely affected.  Services MAY also
    be subject to this mechanism.

 5.9 Non-blocking lookups

    In a real-time environment, it is essential that a server process
    does as little waiting as possible so that all the clients are
    serviced fairly.  Obviously this requires non-blocking IO on all
    network read/write operations.  For normal server connections, this
    was not difficult, but there are other support operations that may
    cause the server to block (such as disk reads).  Where possible, such
    activity SHOULD be performed with a short timeout.

 5.9.1 Hostname (DNS) lookups

    Using the standard resolver libraries from Berkeley and others has
    meant large delays in some cases where replies have timed out.  To
    avoid this, a separate set of DNS routines were written for the
    current implementation.  Routines were setup for non-blocking IO
    operations with local cache, and then polled from within the main
    server IO loop.

 5.9.2 Username (Ident) lookups

    Although there are numerous ident libraries (implementing the
    "Identification Protocol" [IDENT]) for use and inclusion into other
    programs, these caused problems since they operated in a synchronous
    manner and resulted in frequent delays.  Again the solution was to
    write a set of routines which would cooperate with the rest of the
    server and work using non-blocking IO.

 6. Current problems

    There are a number of recognized problems with this protocol, all of
    which are hoped to be solved sometime in the near future during its
    rewrite.  Currently, work is underway to find working solutions to
    these problems.

 6.1 Scalability

    It is widely recognized that this protocol does not scale
    sufficiently well when used in a large arena.  The main problem comes
    from the requirement that all servers know about all other servers
    and clients and that information regarding them be updated as soon as
    it changes.  It is also desirable to keep the number of servers low
    so that the path length between any two points is kept minimal and
    the spanning tree as strongly branched as possible.

 6.2 Labels

    The current IRC protocol has 4 types of labels: the nickname, the
    channel name, the server name and the service name.  Each of the four
    types has its own domain and no duplicates are allowed inside that
    domain.  Currently, it is possible for users to pick the label for
    any of the first three, resulting in collisions.  It is widely
    recognized that this needs reworking, with a plan for unique names
    for nicks that don't collide being desirable as well as a solution
    allowing a cyclic tree.

 6.2.1 Nicknames

    The idea of the nickname on IRC is very convenient for users to use
    when talking to each other outside of a channel, but there is only a
    finite nickname space and being what they are, it's not uncommon for
    several people to want to use the same nick.  If a nickname is chosen
    by two people using this protocol, either one will not succeed or
    both will be removed by use of KILL (See Section 3.7.1 of "IRC Client
    Protocol" [IRC-CLIENT]).

 6.2.2 Channels

    The current channel layout requires that all servers know about all
    channels, their inhabitants and properties.  Besides not scaling
    well, the issue of privacy is also a concern.  A collision of
    channels is treated as an inclusive event (people from both nets on
    channel with common name are considered to be members of it) rather
    than an exclusive one such as used to solve nickname collisions.

    This protocol defines "Safe Channels" which are very unlikely to be
    the subject of a channel collision.  Other channel types are kept for
    backward compatibility.

 6.2.3 Servers

    Although the number of servers is usually small relative to the
    number of users and channels, they too are currently REQUIRED to be
    known globally, either each one separately or hidden behind a mask.

 6.3 Algorithms

    In some places within the server code, it has not been possible to
    avoid N^2 algorithms such as checking the channel list of a set of
    clients.

    In current server versions, there are only few database consistency
    checks, most of the time each server assumes that a neighbouring
    server is correct.  This opens the door to large problems if a
    connecting server is buggy or otherwise tries to introduce
    contradictions to the existing net.

    Currently, because of the lack of unique internal and global labels,
    there are a multitude of race conditions that exist.  These race
    conditions generally arise from the problem of it taking time for
    messages to traverse and effect the IRC network.  Even by changing to
    unique labels, there are problems with channel-related commands being
    disrupted.

 7. Security Considerations

 7.1 Authentication

    Servers only have two means of authenticating incoming connections:
    plain text password, and DNS lookups.  While these methods are weak
    and widely recognized as unsafe, their combination has proven to be
    sufficient in the past:

     * public networks typically allow user connections with only few
       restrictions, without requiring accurate authentication.

     * private networks which operate in a controlled environment often
       use home-grown authentication mechanisms not available on the
       internet: reliable ident servers [IDENT], or other proprietary
       mechanisms.

    The same comments apply to the authentication of IRC Operators.

    It should also be noted that while there has been no real demand over
    the years for stronger authentication, and no real effort to provide
    better means to safely authenticate users, the current protocol
    offers enough to be able to easily plug-in external authentication
    methods based on the information that a client can submit to the
    server upon connection: nickname, username, password.

 7.2 Integrity

    Since the PASS and OPER messages of the IRC protocol are sent in
    clear text, a stream layer encryption mechanism (like "The TLS
    Protocol" [TLS]) could be used to protect these transactions.

 8. Current support and availability

       Mailing lists for IRC related discussion:
         General discussion: ircd-users@irc.org
         Protocol development: ircd-dev@irc.org

       Software implementations:
         ftp://ftp.irc.org/irc/server
         ftp://ftp.funet.fi/pub/unix/irc
         ftp://coombs.anu.edu.au/pub/irc

       Newsgroup: alt.irc

 9. Acknowledgements

    Parts of this document were copied from the RFC 1459 [IRC] which
    first formally documented the IRC Protocol.  It has also benefited
    from many rounds of review and comments.  In particular, the
    following people have made significant contributions to this
    document:

    Matthew Green, Michael Neumayer, Volker Paulsen, Kurt Roeckx, Vesa
    Ruokonen, Magnus Tjernstrom, Stefan Zehl.

 10. References

    [KEYWORDS]   Bradner, S., "Key words for use in RFCs to Indicate
                 Requirement Levels", BCP 14, RFC 2119, March 1997.

    [ABNF]       Crocker, D. and P. Overell, "Augmented BNF for Syntax
                 Specifications: ABNF", RFC 2234, November 1997.

    [IRC]        Oikarinen, J. and D. Reed, "Internet Relay Chat
                 Protocol", RFC 1459, May 1993.

    [IRC-ARCH]   Kalt, C., "Internet Relay Chat: Architecture", RFC 2810,
                 April 2000.

    [IRC-CLIENT] Kalt, C., "Internet Relay Chat: Client Protocol", RFC
                 2812, April 2000.

    [IRC-CHAN]   Kalt, C., "Internet Relay Chat: Channel Management", RFC
                 2811, April 2000.

    [ZLIB]       Deutsch, P. and J-L. Gailly, "ZLIB Compressed Data
                 Format Specification version 3.3", RFC 1950, May 1996.

    [DEFLATE]    Deutsch, P., "DEFLATE Compressed Data Format
                 Specification version 1.3", RFC 1951, May 1996.

    [GZIP]       Deutsch, P., "GZIP file format specification version
                 4.3", RFC 1952, May 1996.

    [IDENT]      St. Johns, M., "The Identification Protocol", RFC 1413,
                 February 1993.

    [TLS]        Dierks, T. and C. Allen, "The TLS Protocol", RFC 2246,
                 January 1999.

 11. Author's Address

    Christophe Kalt
    99 Teaneck Rd, Apt #117
    Ridgefield Park, NJ 07660
    USA

    EMail: kalt@stealth.net

 12.  Full Copyright Statement

    Copyright (C) The Internet Society (2000).  All Rights Reserved.

    This document and translations of it may be copied and furnished to
    others, and derivative works that comment on or otherwise explain it
    or assist in its implementation may be prepared, copied, published
    and distributed, in whole or in part, without restriction of any
    kind, provided that the above copyright notice and this paragraph are
    included on all such copies and derivative works.  However, this
    document itself may not be modified in any way, such as by removing
    the copyright notice or references to the Internet Society or other
    Internet organizations, except as needed for the purpose of
    developing Internet standards in which case the procedures for
    copyrights defined in the Internet Standards process must be
    followed, or as required to translate it into languages other than
    English.

    The limited permissions granted above are perpetual and will not be
    revoked by the Internet Society or its successors or assigns.

    This document and the information contained herein is provided on an
    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

 Acknowledgement

    Funding for the RFC Editor function is currently provided by the
    Internet Society.


text:
                               RFC 2811 (RFC2811)

                       Internet RFC/STD/FYI/BCP Archives

    [ RFC Index | RFC Search | Usenet FAQs | Web FAQs | Documents | Cities ]

                Alternate Formats: rfc2811.txt | rfc2811.txt.pdf

               RFC 2811 - Internet Relay Chat: Channel Management

     ----------------------------------------------------------------------

 Network Working Group                                            C. Kalt
 Request for Comments: 2811                                    April 2000
 Updates: 1459
 Category: Informational

                 Internet Relay Chat: Channel Management

 Status of this Memo

    This memo provides information for the Internet community.  It does
    not specify an Internet standard of any kind.  Distribution of this
    memo is unlimited.

 Copyright Notice

    Copyright (C) The Internet Society (2000).  All Rights Reserved.

 Abstract

    One of the most notable characteristics of the IRC (Internet Relay
    Chat) protocol is to allow for users to be grouped in forums, called
    channels, providing a mean for multiple users to communicate
    together.

    There was originally a unique type of channels, but with the years,
    new types appeared either as a response to a need, or for
    experimental purposes.

    This document specifies how channels, their characteristics and
    properties are managed by IRC servers.

 Table of Contents

    1.  Introduction ...............................................   2
    2.  Channel Characteristics ....................................   3
       2.1  Namespace ..............................................   3
       2.2  Channel Scope ..........................................   3
       2.3  Channel Properties .....................................   4
       2.4  Privileged Channel Members .............................   4
          2.4.1  Channel Operators .................................   5
          2.4.2  Channel Creator ...................................   5
    3.  Channel lifetime ...........................................   5
       3.1  Standard channels ......................................   5
       3.2  Safe Channels ..........................................   6
    4.  Channel Modes ..............................................   7
       4.1  Member Status ..........................................   7
          4.1.1  "Channel Creator" Status ..........................   7

          4.1.2  Channel Operator Status ...........................   8
          4.1.3  Voice Privilege ...................................   8
       4.2  Channel Flags ..........................................   8
          4.2.1  Anonymous Flag ....................................   8
          4.2.2  Invite Only Flag ..................................   8
          4.2.3  Moderated Channel Flag ............................   9
          4.2.4  No Messages To Channel From Clients On The Outside    9
          4.2.5  Quiet Channel .....................................   9
          4.2.6  Private and Secret Channels .......................   9
          4.2.7  Server Reop Flag ..................................  10
          4.2.8  Topic .............................................  10
          4.2.9  User Limit ........................................  10
          4.2.10  Channel Key ......................................  10
       4.3  Channel Access Control .................................  10
          4.3.1  Channel Ban and Exception .........................  11
          4.3.2  Channel Invitation ................................  11
    5.  Current Implementations ....................................  11
       5.1  Tracking Recently Used Channels ........................  11
       5.2  Safe Channels ..........................................  12
          5.2.1  Channel Identifier ................................  12
          5.2.2  Channel Delay .....................................  12
          5.2.3  Abuse Window ......................................  13
          5.2.4  Preserving Sanity In The Name Space ...............  13
          5.2.5  Server Reop Mechanism .............................  13
    6.  Current problems ...........................................  14
       6.1  Labels .................................................  14
          6.1.1  Channel Delay .....................................  14
          6.1.2  Safe Channels .....................................  15
       6.2  Mode Propagation Delays ................................  15
       6.3  Collisions And Channel Modes ...........................  15
       6.4  Resource Exhaustion ....................................  16
    7.  Security Considerations ....................................  16
       7.1  Access Control .........................................  16
       7.2  Channel Privacy ........................................  16
       7.3 Anonymity ...............................................  17
    8.  Current support and availability ...........................  17
    9.  Acknowledgements ...........................................  17
    10. References ................................................   18
    11. Author's Address ..........................................   18
    12. Full Copyright Statement ...................................  19

 1. Introduction

    This document defines in detail on how channels are managed by the
    IRC servers and will be mostly useful to people working on
    implementing an IRC server.

    While the concepts defined here are an important part of IRC, they
    remain non essential for implementing clients.  While the trend seems
    to be towards more and more complex and "intelligent" clients which
    are able to take advantage of knowing the internal workings of
    channels to provide the users with a more friendly interface, simple
    clients can be implemented without reading this document.

    Many of the concepts defined here were designed with the IRC
    architecture [IRC-ARCH] in mind and mostly make sense in this
    context.  However, many others could be applied to other
    architectures in order to provide forums for a conferencing system.

    Finally, it is to be noted that IRC users may find some of the
    following sections of interest, in particular sections 2 (Channel
    Characteristics) and 4 (Channel Modes).

 2. Channel Characteristics

    A channel is a named group of one or more users which will all
    receive messages addressed to that channel.  A channel is
    characterized by its name, properties and current members.

 2.1 Namespace

    Channels names are strings (beginning with a '&', '#', '+' or '!'
    character) of length up to fifty (50) characters.  Channel names are
    case insensitive.

    Apart from the the requirement that the first character being either
    '&', '#', '+' or '!' (hereafter called "channel prefix"). The only
    restriction on a channel name is that it SHALL NOT contain any spaces
    (' '), a control G (^G or ASCII 7), a comma (',' which is used as a
    list item separator by the protocol).  Also, a colon (':') is used as
    a delimiter for the channel mask.  The exact syntax of a channel name
    is defined in "IRC Server Protocol" [IRC-SERVER].

    The use of different prefixes effectively creates four (4) distinct
    namespaces for channel names.  This is important because of the
    protocol limitations regarding namespaces (in general).  See section
    6.1 (Labels) for more details on these limitations.

 2.2 Channel Scope

    A channel entity is known by one or more servers on the IRC network.
    A user can only become member of a channel known by the server to
    which the user is directly connected.  The list of servers which know

    of the existence of a particular channel MUST be a contiguous part of
    the IRC network, in order for the messages addressed to the channel
    to be sent to all the channel members.

    Channels with '&' as prefix are local to the server where they are
    created.

    Other channels are known to one (1) or more servers that are
    connected to the network, depending on the channel mask:

       If there is no channel mask, then the channel is known to all
       the servers.

       If there is a channel mask, then the channel MUST only be known
       to servers which has a local user on the channel, and to its
       neighbours if the mask matches both the local and neighbouring
       server names.  Since other servers have absolutely no knowledge of
       the existence of such a channel, the area formed by the servers
       having a name matching the mask has to be contiguous for the
       channel to be known by all these servers.  Channel masks are best
       used in conjunction with server hostmasking [IRC-SERVER].

 2.3 Channel Properties

    Each channel has its own properties, which are defined by channel
    modes.  Channel modes can be manipulated by the channel members.  The
    modes affect the way servers manage the channels.

    Channels with '+' as prefix do not support channel modes.  This means
    that all the modes are unset, with the exception of the 't' channel
    flag which is set.

 2.4 Privileged Channel Members

    In order for the channel members to keep some control over a channel,
    and some kind of sanity, some channel members are privileged.  Only
    these members are allowed to perform the following actions on the
    channel:

         INVITE  - Invite a client to an invite-only channel (mode +i)
         KICK    - Eject a client from the channel
         MODE    - Change the channel's mode, as well as
                   members' privileges
         PRIVMSG - Sending messages to the channel (mode +n, +m, +v)
         TOPIC   - Change the channel topic in a mode +t channel

 2.4.1 Channel Operators

    The channel operators (also referred to as a "chop" or "chanop") on a
    given channel are considered to 'own' that channel.  Ownership of a
    channel is shared among channel operators.

    Channel operators are identified by the '@' symbol next to their
    nickname whenever it is associated with a channel (i.e., replies to
    the NAMES, WHO and WHOIS commands).

    Since channels starting with the character '+' as prefix do not
    support channel modes, no member can therefore have the status of
    channel operator.

 2.4.2 Channel Creator

    A user who creates a channel with the character '!' as prefix is
    identified as the "channel creator".  Upon creation of the channel,
    this user is also given channel operator status.

    In recognition of this status, the channel creators are endowed with
    the ability to toggle certain modes of the channel which channel
    operators may not manipulate.

    A "channel creator" can be distinguished from a channel operator by
    issuing the proper MODE command.  See the "IRC Client Protocol"
    [IRC-CLIENT] for more information on this topic.

 3. Channel lifetime

    In regard to the lifetime of a channel, there are typically two
    groups of channels: standard channels which prefix is either '&', '#'
    or '+', and "safe channels" which prefix is '!'.

 3.1 Standard channels

    These channels are created implicitly when the first user joins it,
    and cease to exist when the last user leaves it.  While the channel
    exists, any client can reference the channel using the name of the
    channel.

    The user creating a channel automatically becomes channel operator
    with the notable exception of channels which name is prefixed by the
    character '+', see section 4 (Channel modes).  See section 2.4.1
    (Channel Operators) for more details on this title.

    In order to avoid the creation of duplicate channels (typically when
    the IRC network becomes disjoint because of a split between two
    servers), channel names SHOULD NOT be allowed to be reused by a user
    if a channel operator (See Section 2.4.1 (Channel Operators)) has
    recently left the channel because of a network split.  If this
    happens, the channel name is temporarily unavailable.  The duration
    while a channel remains unavailable should be tuned on a per IRC
    network basis.  It is important to note that this prevents local
    users from creating a channel using the same name, but does not
    prevent the channel to be recreated by a remote user. The latter
    typically happens when the IRC network rejoins.  Obviously, this
    mechanism only makes sense for channels which name begins with the
    character '#', but MAY be used for channels which name begins with
    the character '+'.  This mechanism is commonly known as "Channel
    Delay".

 3.2 Safe Channels

    Unlike other channels, "safe channels" are not implicitly created.  A
    user wishing to create such a channel MUST request the creation by
    sending a special JOIN command to the server in which the channel
    identifier (then unknown) is replaced by the character '!'.  The
    creation process for this type of channel is strictly controlled.
    The user only chooses part of the channel name (known as the channel
    "short name"), the server automatically prepends the user provided
    name with a channel identifier consisting of five (5) characters.
    The channel name resulting from the combination of these two elements
    is unique, making the channel safe from abuses based on network
    splits.

    The user who creates such a channel automatically becomes "channel
    creator".  See section 2.4.2 (Channel Creator) for more details on
    this title.

    A server MUST NOT allow the creation of a new channel if another
    channel with the same short name exists; or if another channel with
    the same short name existed recently AND any of its member(s) left
    because of a network split.  Such channel ceases to exist after last
    user leaves AND no other member recently left the channel because of
    a network split.

    Unlike the mechanism described in section 5.2.2 (Channel Delay), in
    this case, channel names do not become unavailable: these channels
    may continue to exist after the last user left.  Only the user
    creating the channel becomes "channel creator", users joining an
    existing empty channel do not automatically become "channel creator"
    nor "channel operator".

    To ensure the uniqueness of the channel names, the channel identifier
    created by the server MUST follow specific rules.  For more details
    on this, see section 5.2.1 (Channel Identifier).

 4. Channel Modes

    The various modes available for channels are as follows:

         O - give "channel creator" status;
         o - give/take channel operator privilege;
         v - give/take the voice privilege;

         a - toggle the anonymous channel flag;
         i - toggle the invite-only channel flag;
         m - toggle the moderated channel;
         n - toggle the no messages to channel from clients on the
             outside;
         q - toggle the quiet channel flag;
         p - toggle the private channel flag;
         s - toggle the secret channel flag;
         r - toggle the server reop channel flag;
         t - toggle the topic settable by channel operator only flag;

         k - set/remove the channel key (password);
         l - set/remove the user limit to channel;

         b - set/remove ban mask to keep users out;
         e - set/remove an exception mask to override a ban mask;
         I - set/remove an invitation mask to automatically override
             the invite-only flag;

    Unless mentioned otherwise below, all these modes can be manipulated
    by "channel operators" by using the MODE command defined in "IRC
    Client Protocol" [IRC-CLIENT].

 4.1 Member Status

    The modes in this category take a channel member nickname as argument
    and affect the privileges given to this user.

 4.1.1 "Channel Creator" Status

    The mode 'O' is only used in conjunction with "safe channels" and
    SHALL NOT be manipulated by users.  Servers use it to give the user
    creating the channel the status of "channel creator".

 4.1.2 Channel Operator Status

    The mode 'o' is used to toggle the operator status of a channel
    member.

 4.1.3 Voice Privilege

    The mode 'v' is used to give and take voice privilege to/from a
    channel member.  Users with this privilege can talk on moderated
    channels.  (See section 4.2.3 (Moderated Channel Flag).

 4.2 Channel Flags

    The modes in this category are used to define properties which
    affects how channels operate.

 4.2.1 Anonymous Flag

    The channel flag 'a' defines an anonymous channel.  This means that
    when a message sent to the channel is sent by the server to users,
    and the origin is a user, then it MUST be masked.  To mask the
    message, the origin is changed to "anonymous!anonymous@anonymous."
    (e.g., a user with the nickname "anonymous", the username "anonymous"
    and from a host called "anonymous.").  Because of this, servers MUST
    forbid users from using the nickname "anonymous".  Servers MUST also
    NOT send QUIT messages for users leaving such channels to the other
    channel members but generate a PART message instead.

    On channels with the character '&' as prefix, this flag MAY be
    toggled by channel operators, but on channels with the character '!'
    as prefix, this flag can be set (but SHALL NOT be unset) by the
    "channel creator" only.  This flag MUST NOT be made available on
    other types of channels.

    Replies to the WHOIS, WHO and NAMES commands MUST NOT reveal the
    presence of other users on channels for which the anonymous flag is
    set.

 4.2.2 Invite Only Flag

    When the channel flag 'i' is set, new members are only accepted if
    their mask matches Invite-list (See section 4.3.2) or they have been
    invited by a channel operator.  This flag also restricts the usage of
    the INVITE command (See "IRC Client Protocol" [IRC-CLIENT]) to
    channel operators.

 4.2.3 Moderated Channel Flag

    The channel flag 'm' is used to control who may speak on a channel.
    When it is set, only channel operators, and members who have been
    given the voice privilege may send messages to the channel.

       This flag only affects users.

 4.2.4 No Messages To Channel From Clients On The Outside

    When the channel flag 'n' is set, only channel members MAY send
    messages to the channel.

       This flag only affects users.

 4.2.5 Quiet Channel

    The channel flag 'q' is for use by servers only.  When set, it
    restricts the type of data sent to users about the channel
    operations: other user joins, parts and nick changes are not sent.
    From a user's point of view, the channel contains only one user.

    This is typically used to create special local channels on which the
    server sends notices related to its operations.  This was used as a
    more efficient and flexible way to replace the user mode 's' defined
    in RFC 1459 [IRC].

 4.2.6 Private and Secret Channels

    The channel flag 'p' is used to mark a channel "private" and the
    channel flag 's' to mark a channel "secret".  Both properties are
    similar and conceal the existence of the channel from other users.

    This means that there is no way of getting this channel's name from
    the server without being a member.  In other words, these channels
    MUST be omitted from replies to queries like the WHOIS command.

    When a channel is "secret", in addition to the restriction above, the
    server will act as if the channel does not exist for queries like the
    TOPIC, LIST, NAMES commands.  Note that there is one exception to
    this rule: servers will correctly reply to the MODE command.
    Finally, secret channels are not accounted for in the reply to the
    LUSERS command (See "Internet Relay Chat: Client Protocol" [IRC-
    CLIENT]) when the <mask> parameter is specified.

    The channel flags 'p' and 's' MUST NOT both be set at the same time.
    If a MODE message originating from a server sets the flag 'p' and the
    flag 's' is already set for the channel, the change is silently
    ignored.  This should only happen during a split healing phase
    (mentioned in the "IRC Server Protocol" document [IRC-SERVER]).

 4.2.7 Server Reop Flag

    The channel flag 'r' is only available on channels which name begins
    with the character '!' and MAY only be toggled by the "channel
    creator".

    This flag is used to prevent a channel from having no channel
    operator for an extended period of time.  When this flag is set, any
    channel that has lost all its channel operators for longer than the
    "reop delay" period triggers a mechanism in servers to reop some or
    all of the channel inhabitants.  This mechanism is described more in
    detail in section 5.2.4 (Channel Reop Mechanism).

 4.2.8 Topic

    The channel flag 't' is used to restrict the usage of the TOPIC
    command to channel operators.

 4.2.9 User Limit

    A user limit may be set on channels by using the channel flag 'l'.
    When the limit is reached, servers MUST forbid their local users to
    join the channel.

    The value of the limit MUST only be made available to the channel
    members in the reply sent by the server to a MODE query.

 4.2.10 Channel Key

    When a channel key is set (by using the mode 'k'), servers MUST
    reject their local users request to join the channel unless this key
    is given.

    The channel key MUST only be made visible to the channel members in
    the reply sent by the server to a MODE query.

 4.3 Channel Access Control

    The last category of modes is used to control access to the channel,
    they take a mask as argument.

    In order to reduce the size of the global database for control access
    modes set for channels, servers MAY put a maximum limit on the number
    of such modes set for a particular channel.  If such restriction is
    imposed, it MUST only affect user requests.  The limit SHOULD be
    homogeneous on a per IRC network basis.

 4.3.1 Channel Ban and Exception

    When a user requests to join a channel, his local server checks if
    the user's address matches any of the ban masks set for the channel.
    If a match is found, the user request is denied unless the address
    also matches an exception mask set for the channel.

    Servers MUST NOT allow a channel member who is banned from the
    channel to speak on the channel, unless this member is a channel
    operator or has voice privilege. (See Section 4.1.3 (Voice
    Privilege)).

    A user who is banned from a channel and who carries an invitation
    sent by a channel operator is allowed to join the channel.

 4.3.2 Channel Invitation

    For channels which have the invite-only flag set (See Section 4.2.2
    (Invite Only Flag)), users whose address matches an invitation mask
    set for the channel are allowed to join the channel without any
    invitation.

 5. Current Implementations

    The only current implementation of these rules as part of the IRC
    protocol is the IRC server, version 2.10.

    The rest of this section deals with issues that are mostly of
    importance to those who wish to implement a server but some parts may
    also be of interest for client writers.

 5.1 Tracking Recently Used Channels

    This mechanism is commonly known as "Channel Delay" and generally
    only applies to channels which names is prefixed with the character
    '#' (See Section 3.1 "Standard channels").

    When a network split occurs, servers SHOULD keep track of which
    channels lost a "channel operator" as the result of the break.  These
    channels are then in a special state which lasts for a certain period
    of time.  In this particular state, the channels cannot cease to

    exist.  If all the channel members leave the channel, the channel
    becomes unavailable: the server local clients cannot join the channel
    as long as it is empty.

    Once a channel is unavailable, it will become available again either
    because a remote user has joined the channel (most likely because the
    network is healing), or because the delay period has expired (in
    which case the channel ceases to exist and may be re-created).

    The duration for which a channel death is delayed SHOULD be set
    considering many factors among which are the size (user wise) of the
    IRC network, and the usual duration of network splits.  It SHOULD be
    uniform on all servers for a given IRC network.

 5.2 Safe Channels

    This document introduces the notion of "safe channels".  These
    channels have a name prefixed with the character '!' and great effort
    is made to avoid collisions in this name space.  Collisions are not
    impossible, however they are very unlikely.

 5.2.1 Channel Identifier

    The channel identifier is a function of the time.  The current time
    (as defined under UNIX by the number of seconds elapsed since
    00:00:00 GMT, January 1, 1970) is converted in a string of five (5)
    characters using the following base:
    "ABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890" (each character has a decimal
    value starting from 0 for 'A' to 35 for '0').

    The channel identifier therefore has a periodicity of 36^5 seconds
    (about 700 days).

 5.2.2 Channel Delay

    These channels MUST be subject to the "channel delay" mechanism
    described in section 5.1 (Channel Delay).  However, the mechanism is
    slightly adapted to fit better.

    Servers MUST keep track of all such channels which lose members as
    the result of a network split, no matter whether the user is a
    "channel operator" or not.

    However, these channels do NOT ever become unavailable, it is always
    possible to join them even when they are empty.

 5.2.3 Abuse Window

    Because the periodicity is so long, attacks on a particular channel
    (name) may only occur once in a very long while.  However, with luck
    and patience, it is still possible for a user to cause a channel
    collision.  In order to avoid this, servers MUST "look in the future"
    and keep a list of channel names which identifier is about to be used
    (in the coming few days for example). Such list should remain small,
    not be a burden for servers to maintain and be used to avoid channel
    collisions by preventing the re-creation of such channel for a longer
    period of time than channel delay does.

    Eventually a server MAY choose to extend this procedure to forbid
    creation of channels with the same shortname only (then ignoring the
    channel identifier).

 5.2.4 Preserving Sanity In The Name Space

    The combination of the mechanisms described in sections 5.2.2 and
    5.2.3 makes it quite difficult for a user to create a channel
    collision. However, another type of abuse consists of creating many
    channels having the same shortname, but different identifiers.  To
    prevent this from happening, servers MUST forbid the creation of a
    new channel which has the same shortname of a channel currently
    existing.

 5.2.5 Server Reop Mechanism

    When a channel has been opless for longer than the "reop delay"
    period and has the channel flag 'r' set (See Section 4.2.7 (Server
    Reop Flag)), IRC servers are responsible for giving the channel
    operator status randomly to some of the members.

    The exact logic used for this mechanism by the current implementation
    is described below.  Servers MAY use a different logic, but that it
    is strongly RECOMMENDED that all servers use the same logic on a
    particular IRC network to maintain coherence as well as fairness.
    For the same reason, the "reop delay" SHOULD be uniform on all
    servers for a given IRC network.  As for the "channel delay", the
    value of the "reop delay" SHOULD be set considering many factors
    among which are the size (user wise) of the IRC network, and the
    usual duration of network splits.

    a) the reop mechanism is triggered after a random time following the
       expiration of the "reop delay".  This should limit the eventuality
       of the mechanism being triggered at the same time (for the same
       channel) on two separate servers.

    b) If the channel is small (five (5) users or less), and the "channel
       delay" for this channel has expired,
         Then reop all channel members if at least one member is local to
         the server.

    c) If the channel is small (five (5) users or less), and the "channel
       delay" for this channel has expired, and the "reop delay" has
       expired for longer than its value,
         Then reop all channel members.

    d) For other cases, reop at most one member on the channel, based on
       some method build into the server. If you don't reop a member, the
       method should be such that another server will probably op
       someone. The method SHOULD be the same over the whole network. A
       good heuristic could be just random reop.
       (The current implementation actually tries to choose a member
       local to the server who has not been idle for too long, eventually
       postponing action, therefore letting other servers have a chance
       to find a "not too idle" member.  This is over complicated due to
       the fact that servers only know the "idle" time of their local
       users)

 6. Current problems

    There are a number of recognized problems with the way IRC channels
    are managed.  Some of these can be directly attributed to the rules
    defined in this document, while others are the result of the
    underlying "IRC Server Protocol" [IRC-SERVER].  Although derived from
    RFC 1459 [IRC], this document introduces several novelties in an
    attempt to solve some of the known problems.

 6.1 Labels

    This document defines one of the many labels used by the IRC
    protocol.  Although there are several distinct namespaces (based on
    the channel name prefix), duplicates inside each of these are not
    allowed.  Currently, it is possible for users on different servers to
    pick the label which may result in collisions (with the exception of
    channels known to only one server where they can be averted).

 6.1.1 Channel Delay

    The channel delay mechanism described in section 5.1 (Tracking
    Recently Used Channels) and used for channels prefixed with the
    character '#' is a simple attempt at preventing collisions from
    happening.  Experience has shown that, under normal circumstances, it

    is very efficient; however, it obviously has severe limitations
    keeping it from being an adequate solution to the problem discussed
    here.

 6.1.2 Safe Channels

    "Safe channels" described in section 3.2 (Safe Channels) are a better
    way to prevent collisions from happening as it prevents users from
    having total control over the label they choose.  The obvious
    drawback for such labels is that they are not user friendly.
    However, it is fairly trivial for a client program to improve on
    this.

 6.2 Mode Propagation Delays

    Because of network delays induced by the network, and because each
    server on the path is REQUIRED to check the validity of mode changes
    (e.g., user exists and has the right privileges), it is not unusual
    for a MODE message to only affect part of the network, often creating
    a discrepancy between servers on the current state of a channel.

    While this may seem easy to fix (by having only the original server
    check the validity of mode changes), it was decided not to do so for
    various reasons.  One concern is that servers cannot trust each
    other, and that a misbehaving servers can easily be detected.  This
    way of doing so also stops wave effects on channels which are out of
    synch when mode changes are issued from different directions.

 6.3 Collisions And Channel Modes

    The "Internet Relay Chat: Server Protocol" document [IRC-SERVER]
    describes how channel data is exchanged when two servers connect to
    each other.  Channel collisions (either legitimate or not) are
    treated as inclusive events, meaning that the resulting channel has
    for members all the users who are members of the channel on either
    server prior to the connection.

    Similarly, each server sends the channel modes to the other one.
    Therefore, each server also receives these channel modes.  There are
    three types of modes for a given channel: flags, masks, and data.
    The first two types are easy to deal with as they are either set or
    unset.  If such a mode is set on one server, it MUST be set on the
    other server as a result of the connection.

    As topics are not sent as part of this exchange, they are not a
    problem.  However, channel modes 'l' and 'k' are exchanged, and if
    they are set on both servers prior to the connection, there is no
    mechanism to decide which of the two values takes precedence.  It is
    left up to the users to fix the resulting discrepancy.

 6.4 Resource Exhaustion

    The mode based on masks defined in section 4.3 make the IRC servers
    (and network) vulnerable to a simple abuse of the system: a single
    channel operator can set as many different masks as possible on a
    particular channel.  This can easily cause the server to waste
    memory, as well as network bandwidth (since the info is propagated to
    other servers).  For this reason it is RECOMMENDED that a limit be
    put on the number of such masks per channels as mentioned in section
    4.3.

    Moreover, more complex mechanisms MAY be used to avoid having
    redundant masks set for the same channel.

 7. Security Considerations

 7.1 Access Control

    One of the main ways to control access to a channel is to use masks
    which are based on the username and hostname of the user connections.
    This mechanism can only be efficient and safe if the IRC servers have
    an accurate way of authenticating user connections, and if users
    cannot easily get around it.  While it is in theory possible to
    implement such a strict authentication mechanism, most IRC networks
    (especially public networks) do not have anything like this in place
    and provide little guaranty about the accuracy of the username and
    hostname for a particular client connection.

    Another way to control access is to use a channel key, but since this
    key is sent in plaintext, it is vulnerable to traditional man in the
    middle attacks.

 7.2 Channel Privacy

    Because channel collisions are treated as inclusive events (See
    Section 6.3), it is possible for users to join a channel overriding
    its access control settings.  This method has long been used by
    individuals to "take over" channels by "illegitimately" gaining
    channel operator status on the channel.  The same method can be used
    to find out the exact list of members of a channel, as well as to
    eventually receive some of the messages sent to the channel.

 7.3 Anonymity

    The anonymous channel flag (See Section 4.2.1) can be used to render
    all users on such channel "anonymous" by presenting all messages to
    the channel as originating from a pseudo user which nickname is
    "anonymous".  This is done at the client-server level, and no
    anonymity is provided at the server-server level.

    It should be obvious to readers, that the level of anonymity offered
    is quite poor and insecure, and that clients SHOULD display strong
    warnings for users joining such channels.

 8. Current support and availability

      Mailing lists for IRC related discussion:
        General discussion: ircd-users@irc.org
        Protocol development: ircd-dev@irc.org

      Software implementations:
        ftp://ftp.irc.org/irc/server
        ftp://ftp.funet.fi/pub/unix/irc
        ftp://coombs.anu.edu.au/pub/irc

      Newsgroup: alt.irc

 9. Acknowledgements

    Parts of this document were copied from the RFC 1459 [IRC] which
    first formally documented the IRC Protocol.  It has also benefited
    from many rounds of review and comments.  In particular, the
    following people have made significant contributions to this
    document:

    Matthew Green, Michael Neumayer, Volker Paulsen, Kurt Roeckx, Vesa
    Ruokonen, Magnus Tjernstrom, Stefan Zehl.

 10. References

    [KEYWORDS]   Bradner, S., "Key words for use in RFCs to Indicate
                 Requirement Levels", BCP 14, RFC 2119, March 1997.

    [IRC]        Oikarinen, J. and D. Reed, "Internet Relay Chat
                 Protocol", RFC 1459, May 1993.

    [IRC-ARCH]   Kalt, C., "Internet Relay Chat: Architecture", RFC 2810,
                 April 2000.

    [IRC-CLIENT] Kalt, C., "Internet Relay Chat: Client Protocol", RFC
                 2812, April 2000.

    [IRC-SERVER] Kalt, C., "Internet Relay Chat: Server Protocol", RFC
                 2813, April 2000.

 11. Author's Address

    Christophe Kalt
    99 Teaneck Rd, Apt #117
    Ridgefield Park, NJ 07660
    USA

    EMail: kalt@stealth.net

 12.  Full Copyright Statement

    Copyright (C) The Internet Society (2000).  All Rights Reserved.

    This document and translations of it may be copied and furnished to
    others, and derivative works that comment on or otherwise explain it
    or assist in its implementation may be prepared, copied, published
    and distributed, in whole or in part, without restriction of any
    kind, provided that the above copyright notice and this paragraph are
    included on all such copies and derivative works.  However, this
    document itself may not be modified in any way, such as by removing
    the copyright notice or references to the Internet Society or other
    Internet organizations, except as needed for the purpose of
    developing Internet standards in which case the procedures for
    copyrights defined in the Internet Standards process must be
    followed, or as required to translate it into languages other than
    English.

    The limited permissions granted above are perpetual and will not be
    revoked by the Internet Society or its successors or assigns.

    This document and the information contained herein is provided on an
    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

 Acknowledgement

    Funding for the RFC Editor function is currently provided by the
    Internet Society.

Previous: RFC 2810 - Internet Relay        Next: RFC 2812 - Internet Relay Chat:
Chat: Architecture                                               Client Protocol

     ----------------------------------------------------------------------

    [ RFC Index | RFC Search | Usenet FAQs | Web FAQs | Documents | Cities ]

repo_name: rmmh/skybot

repo_language: Python