kunt

golang IRC bot
git clone git://git.2f30.org/kunt
Log | Files | Refs | LICENSE

rfc2811.txt (40788B)


      1 
      2 
      3 
      4 
      5 
      6 
      7 Network Working Group                                            C. Kalt
      8 Request for Comments: 2811                                    April 2000
      9 Updates: 1459
     10 Category: Informational
     11 
     12 
     13                 Internet Relay Chat: Channel Management
     14 
     15 Status of this Memo
     16 
     17    This memo provides information for the Internet community.  It does
     18    not specify an Internet standard of any kind.  Distribution of this
     19    memo is unlimited.
     20 
     21 Copyright Notice
     22 
     23    Copyright (C) The Internet Society (2000).  All Rights Reserved.
     24 
     25 Abstract
     26 
     27    One of the most notable characteristics of the IRC (Internet Relay
     28    Chat) protocol is to allow for users to be grouped in forums, called
     29    channels, providing a mean for multiple users to communicate
     30    together.
     31 
     32    There was originally a unique type of channels, but with the years,
     33    new types appeared either as a response to a need, or for
     34    experimental purposes.
     35 
     36    This document specifies how channels, their characteristics and
     37    properties are managed by IRC servers.
     38 
     39 Table of Contents
     40 
     41    1.  Introduction ...............................................   2
     42    2.  Channel Characteristics ....................................   3
     43       2.1  Namespace ..............................................   3
     44       2.2  Channel Scope ..........................................   3
     45       2.3  Channel Properties .....................................   4
     46       2.4  Privileged Channel Members .............................   4
     47          2.4.1  Channel Operators .................................   5
     48          2.4.2  Channel Creator ...................................   5
     49    3.  Channel lifetime ...........................................   5
     50       3.1  Standard channels ......................................   5
     51       3.2  Safe Channels ..........................................   6
     52    4.  Channel Modes ..............................................   7
     53       4.1  Member Status ..........................................   7
     54          4.1.1  "Channel Creator" Status ..........................   7
     55 
     56 
     57 
     58 Kalt                         Informational                      [Page 1]
     59 
     60 RFC 2811        Internet Relay Chat: Channel Management       April 2000
     61 
     62 
     63          4.1.2  Channel Operator Status ...........................   8
     64          4.1.3  Voice Privilege ...................................   8
     65       4.2  Channel Flags ..........................................   8
     66          4.2.1  Anonymous Flag ....................................   8
     67          4.2.2  Invite Only Flag ..................................   8
     68          4.2.3  Moderated Channel Flag ............................   9
     69          4.2.4  No Messages To Channel From Clients On The Outside    9
     70          4.2.5  Quiet Channel .....................................   9
     71          4.2.6  Private and Secret Channels .......................   9
     72          4.2.7  Server Reop Flag ..................................  10
     73          4.2.8  Topic .............................................  10
     74          4.2.9  User Limit ........................................  10
     75          4.2.10  Channel Key ......................................  10
     76       4.3  Channel Access Control .................................  10
     77          4.3.1  Channel Ban and Exception .........................  11
     78          4.3.2  Channel Invitation ................................  11
     79    5.  Current Implementations ....................................  11
     80       5.1  Tracking Recently Used Channels ........................  11
     81       5.2  Safe Channels ..........................................  12
     82          5.2.1  Channel Identifier ................................  12
     83          5.2.2  Channel Delay .....................................  12
     84          5.2.3  Abuse Window ......................................  13
     85          5.2.4  Preserving Sanity In The Name Space ...............  13
     86          5.2.5  Server Reop Mechanism .............................  13
     87    6.  Current problems ...........................................  14
     88       6.1  Labels .................................................  14
     89          6.1.1  Channel Delay .....................................  14
     90          6.1.2  Safe Channels .....................................  15
     91       6.2  Mode Propagation Delays ................................  15
     92       6.3  Collisions And Channel Modes ...........................  15
     93       6.4  Resource Exhaustion ....................................  16
     94    7.  Security Considerations ....................................  16
     95       7.1  Access Control .........................................  16
     96       7.2  Channel Privacy ........................................  16
     97       7.3 Anonymity ...............................................  17
     98    8.  Current support and availability ...........................  17
     99    9.  Acknowledgements ...........................................  17
    100    10. References ................................................   18
    101    11. Author's Address ..........................................   18
    102    12. Full Copyright Statement ...................................  19
    103 
    104 1. Introduction
    105 
    106    This document defines in detail on how channels are managed by the
    107    IRC servers and will be mostly useful to people working on
    108    implementing an IRC server.
    109 
    110 
    111 
    112 
    113 
    114 Kalt                         Informational                      [Page 2]
    115 
    116 RFC 2811        Internet Relay Chat: Channel Management       April 2000
    117 
    118 
    119    While the concepts defined here are an important part of IRC, they
    120    remain non essential for implementing clients.  While the trend seems
    121    to be towards more and more complex and "intelligent" clients which
    122    are able to take advantage of knowing the internal workings of
    123    channels to provide the users with a more friendly interface, simple
    124    clients can be implemented without reading this document.
    125 
    126    Many of the concepts defined here were designed with the IRC
    127    architecture [IRC-ARCH] in mind and mostly make sense in this
    128    context.  However, many others could be applied to other
    129    architectures in order to provide forums for a conferencing system.
    130 
    131    Finally, it is to be noted that IRC users may find some of the
    132    following sections of interest, in particular sections 2 (Channel
    133    Characteristics) and 4 (Channel Modes).
    134 
    135 2. Channel Characteristics
    136 
    137    A channel is a named group of one or more users which will all
    138    receive messages addressed to that channel.  A channel is
    139    characterized by its name, properties and current members.
    140 
    141 2.1 Namespace
    142 
    143    Channels names are strings (beginning with a '&', '#', '+' or '!'
    144    character) of length up to fifty (50) characters.  Channel names are
    145    case insensitive.
    146 
    147    Apart from the the requirement that the first character being either
    148    '&', '#', '+' or '!' (hereafter called "channel prefix"). The only
    149    restriction on a channel name is that it SHALL NOT contain any spaces
    150    (' '), a control G (^G or ASCII 7), a comma (',' which is used as a
    151    list item separator by the protocol).  Also, a colon (':') is used as
    152    a delimiter for the channel mask.  The exact syntax of a channel name
    153    is defined in "IRC Server Protocol" [IRC-SERVER].
    154 
    155    The use of different prefixes effectively creates four (4) distinct
    156    namespaces for channel names.  This is important because of the
    157    protocol limitations regarding namespaces (in general).  See section
    158    6.1 (Labels) for more details on these limitations.
    159 
    160 2.2 Channel Scope
    161 
    162    A channel entity is known by one or more servers on the IRC network.
    163    A user can only become member of a channel known by the server to
    164    which the user is directly connected.  The list of servers which know
    165 
    166 
    167 
    168 
    169 
    170 Kalt                         Informational                      [Page 3]
    171 
    172 RFC 2811        Internet Relay Chat: Channel Management       April 2000
    173 
    174 
    175    of the existence of a particular channel MUST be a contiguous part of
    176    the IRC network, in order for the messages addressed to the channel
    177    to be sent to all the channel members.
    178 
    179    Channels with '&' as prefix are local to the server where they are
    180    created.
    181 
    182    Other channels are known to one (1) or more servers that are
    183    connected to the network, depending on the channel mask:
    184 
    185       If there is no channel mask, then the channel is known to all
    186       the servers.
    187 
    188       If there is a channel mask, then the channel MUST only be known
    189       to servers which has a local user on the channel, and to its
    190       neighbours if the mask matches both the local and neighbouring
    191       server names.  Since other servers have absolutely no knowledge of
    192       the existence of such a channel, the area formed by the servers
    193       having a name matching the mask has to be contiguous for the
    194       channel to be known by all these servers.  Channel masks are best
    195       used in conjunction with server hostmasking [IRC-SERVER].
    196 
    197 2.3 Channel Properties
    198 
    199    Each channel has its own properties, which are defined by channel
    200    modes.  Channel modes can be manipulated by the channel members.  The
    201    modes affect the way servers manage the channels.
    202 
    203    Channels with '+' as prefix do not support channel modes.  This means
    204    that all the modes are unset, with the exception of the 't' channel
    205    flag which is set.
    206 
    207 2.4 Privileged Channel Members
    208 
    209    In order for the channel members to keep some control over a channel,
    210    and some kind of sanity, some channel members are privileged.  Only
    211    these members are allowed to perform the following actions on the
    212    channel:
    213 
    214         INVITE  - Invite a client to an invite-only channel (mode +i)
    215         KICK    - Eject a client from the channel
    216         MODE    - Change the channel's mode, as well as
    217                   members' privileges
    218         PRIVMSG - Sending messages to the channel (mode +n, +m, +v)
    219         TOPIC   - Change the channel topic in a mode +t channel
    220 
    221 
    222 
    223 
    224 
    225 
    226 Kalt                         Informational                      [Page 4]
    227 
    228 RFC 2811        Internet Relay Chat: Channel Management       April 2000
    229 
    230 
    231 2.4.1 Channel Operators
    232 
    233    The channel operators (also referred to as a "chop" or "chanop") on a
    234    given channel are considered to 'own' that channel.  Ownership of a
    235    channel is shared among channel operators.
    236 
    237    Channel operators are identified by the '@' symbol next to their
    238    nickname whenever it is associated with a channel (i.e., replies to
    239    the NAMES, WHO and WHOIS commands).
    240 
    241    Since channels starting with the character '+' as prefix do not
    242    support channel modes, no member can therefore have the status of
    243    channel operator.
    244 
    245 2.4.2 Channel Creator
    246 
    247    A user who creates a channel with the character '!' as prefix is
    248    identified as the "channel creator".  Upon creation of the channel,
    249    this user is also given channel operator status.
    250 
    251    In recognition of this status, the channel creators are endowed with
    252    the ability to toggle certain modes of the channel which channel
    253    operators may not manipulate.
    254 
    255    A "channel creator" can be distinguished from a channel operator by
    256    issuing the proper MODE command.  See the "IRC Client Protocol"
    257    [IRC-CLIENT] for more information on this topic.
    258 
    259 3. Channel lifetime
    260 
    261    In regard to the lifetime of a channel, there are typically two
    262    groups of channels: standard channels which prefix is either '&', '#'
    263    or '+', and "safe channels" which prefix is '!'.
    264 
    265 3.1 Standard channels
    266 
    267    These channels are created implicitly when the first user joins it,
    268    and cease to exist when the last user leaves it.  While the channel
    269    exists, any client can reference the channel using the name of the
    270    channel.
    271 
    272    The user creating a channel automatically becomes channel operator
    273    with the notable exception of channels which name is prefixed by the
    274    character '+', see section 4 (Channel modes).  See section 2.4.1
    275    (Channel Operators) for more details on this title.
    276 
    277 
    278 
    279 
    280 
    281 
    282 Kalt                         Informational                      [Page 5]
    283 
    284 RFC 2811        Internet Relay Chat: Channel Management       April 2000
    285 
    286 
    287    In order to avoid the creation of duplicate channels (typically when
    288    the IRC network becomes disjoint because of a split between two
    289    servers), channel names SHOULD NOT be allowed to be reused by a user
    290    if a channel operator (See Section 2.4.1 (Channel Operators)) has
    291    recently left the channel because of a network split.  If this
    292    happens, the channel name is temporarily unavailable.  The duration
    293    while a channel remains unavailable should be tuned on a per IRC
    294    network basis.  It is important to note that this prevents local
    295    users from creating a channel using the same name, but does not
    296    prevent the channel to be recreated by a remote user. The latter
    297    typically happens when the IRC network rejoins.  Obviously, this
    298    mechanism only makes sense for channels which name begins with the
    299    character '#', but MAY be used for channels which name begins with
    300    the character '+'.  This mechanism is commonly known as "Channel
    301    Delay".
    302 
    303 3.2 Safe Channels
    304 
    305    Unlike other channels, "safe channels" are not implicitly created.  A
    306    user wishing to create such a channel MUST request the creation by
    307    sending a special JOIN command to the server in which the channel
    308    identifier (then unknown) is replaced by the character '!'.  The
    309    creation process for this type of channel is strictly controlled.
    310    The user only chooses part of the channel name (known as the channel
    311    "short name"), the server automatically prepends the user provided
    312    name with a channel identifier consisting of five (5) characters.
    313    The channel name resulting from the combination of these two elements
    314    is unique, making the channel safe from abuses based on network
    315    splits.
    316 
    317    The user who creates such a channel automatically becomes "channel
    318    creator".  See section 2.4.2 (Channel Creator) for more details on
    319    this title.
    320 
    321    A server MUST NOT allow the creation of a new channel if another
    322    channel with the same short name exists; or if another channel with
    323    the same short name existed recently AND any of its member(s) left
    324    because of a network split.  Such channel ceases to exist after last
    325    user leaves AND no other member recently left the channel because of
    326    a network split.
    327 
    328    Unlike the mechanism described in section 5.2.2 (Channel Delay), in
    329    this case, channel names do not become unavailable: these channels
    330    may continue to exist after the last user left.  Only the user
    331    creating the channel becomes "channel creator", users joining an
    332    existing empty channel do not automatically become "channel creator"
    333    nor "channel operator".
    334 
    335 
    336 
    337 
    338 Kalt                         Informational                      [Page 6]
    339 
    340 RFC 2811        Internet Relay Chat: Channel Management       April 2000
    341 
    342 
    343    To ensure the uniqueness of the channel names, the channel identifier
    344    created by the server MUST follow specific rules.  For more details
    345    on this, see section 5.2.1 (Channel Identifier).
    346 
    347 4. Channel Modes
    348 
    349    The various modes available for channels are as follows:
    350 
    351         O - give "channel creator" status;
    352         o - give/take channel operator privilege;
    353         v - give/take the voice privilege;
    354 
    355         a - toggle the anonymous channel flag;
    356         i - toggle the invite-only channel flag;
    357         m - toggle the moderated channel;
    358         n - toggle the no messages to channel from clients on the
    359             outside;
    360         q - toggle the quiet channel flag;
    361         p - toggle the private channel flag;
    362         s - toggle the secret channel flag;
    363         r - toggle the server reop channel flag;
    364         t - toggle the topic settable by channel operator only flag;
    365 
    366         k - set/remove the channel key (password);
    367         l - set/remove the user limit to channel;
    368 
    369         b - set/remove ban mask to keep users out;
    370         e - set/remove an exception mask to override a ban mask;
    371         I - set/remove an invitation mask to automatically override
    372             the invite-only flag;
    373 
    374    Unless mentioned otherwise below, all these modes can be manipulated
    375    by "channel operators" by using the MODE command defined in "IRC
    376    Client Protocol" [IRC-CLIENT].
    377 
    378 4.1 Member Status
    379 
    380    The modes in this category take a channel member nickname as argument
    381    and affect the privileges given to this user.
    382 
    383 4.1.1 "Channel Creator" Status
    384 
    385    The mode 'O' is only used in conjunction with "safe channels" and
    386    SHALL NOT be manipulated by users.  Servers use it to give the user
    387    creating the channel the status of "channel creator".
    388 
    389 
    390 
    391 
    392 
    393 
    394 Kalt                         Informational                      [Page 7]
    395 
    396 RFC 2811        Internet Relay Chat: Channel Management       April 2000
    397 
    398 
    399 4.1.2 Channel Operator Status
    400 
    401    The mode 'o' is used to toggle the operator status of a channel
    402    member.
    403 
    404 4.1.3 Voice Privilege
    405 
    406    The mode 'v' is used to give and take voice privilege to/from a
    407    channel member.  Users with this privilege can talk on moderated
    408    channels.  (See section 4.2.3 (Moderated Channel Flag).
    409 
    410 4.2 Channel Flags
    411 
    412    The modes in this category are used to define properties which
    413    affects how channels operate.
    414 
    415 4.2.1 Anonymous Flag
    416 
    417    The channel flag 'a' defines an anonymous channel.  This means that
    418    when a message sent to the channel is sent by the server to users,
    419    and the origin is a user, then it MUST be masked.  To mask the
    420    message, the origin is changed to "anonymous!anonymous@anonymous."
    421    (e.g., a user with the nickname "anonymous", the username "anonymous"
    422    and from a host called "anonymous.").  Because of this, servers MUST
    423    forbid users from using the nickname "anonymous".  Servers MUST also
    424    NOT send QUIT messages for users leaving such channels to the other
    425    channel members but generate a PART message instead.
    426 
    427    On channels with the character '&' as prefix, this flag MAY be
    428    toggled by channel operators, but on channels with the character '!'
    429    as prefix, this flag can be set (but SHALL NOT be unset) by the
    430    "channel creator" only.  This flag MUST NOT be made available on
    431    other types of channels.
    432 
    433    Replies to the WHOIS, WHO and NAMES commands MUST NOT reveal the
    434    presence of other users on channels for which the anonymous flag is
    435    set.
    436 
    437 4.2.2 Invite Only Flag
    438 
    439    When the channel flag 'i' is set, new members are only accepted if
    440    their mask matches Invite-list (See section 4.3.2) or they have been
    441    invited by a channel operator.  This flag also restricts the usage of
    442    the INVITE command (See "IRC Client Protocol" [IRC-CLIENT]) to
    443    channel operators.
    444 
    445 
    446 
    447 
    448 
    449 
    450 Kalt                         Informational                      [Page 8]
    451 
    452 RFC 2811        Internet Relay Chat: Channel Management       April 2000
    453 
    454 
    455 4.2.3 Moderated Channel Flag
    456 
    457    The channel flag 'm' is used to control who may speak on a channel.
    458    When it is set, only channel operators, and members who have been
    459    given the voice privilege may send messages to the channel.
    460 
    461       This flag only affects users.
    462 
    463 4.2.4 No Messages To Channel From Clients On The Outside
    464 
    465    When the channel flag 'n' is set, only channel members MAY send
    466    messages to the channel.
    467 
    468       This flag only affects users.
    469 
    470 4.2.5 Quiet Channel
    471 
    472    The channel flag 'q' is for use by servers only.  When set, it
    473    restricts the type of data sent to users about the channel
    474    operations: other user joins, parts and nick changes are not sent.
    475    From a user's point of view, the channel contains only one user.
    476 
    477    This is typically used to create special local channels on which the
    478    server sends notices related to its operations.  This was used as a
    479    more efficient and flexible way to replace the user mode 's' defined
    480    in RFC 1459 [IRC].
    481 
    482 4.2.6 Private and Secret Channels
    483 
    484    The channel flag 'p' is used to mark a channel "private" and the
    485    channel flag 's' to mark a channel "secret".  Both properties are
    486    similar and conceal the existence of the channel from other users.
    487 
    488    This means that there is no way of getting this channel's name from
    489    the server without being a member.  In other words, these channels
    490    MUST be omitted from replies to queries like the WHOIS command.
    491 
    492    When a channel is "secret", in addition to the restriction above, the
    493    server will act as if the channel does not exist for queries like the
    494    TOPIC, LIST, NAMES commands.  Note that there is one exception to
    495    this rule: servers will correctly reply to the MODE command.
    496    Finally, secret channels are not accounted for in the reply to the
    497    LUSERS command (See "Internet Relay Chat: Client Protocol" [IRC-
    498    CLIENT]) when the <mask> parameter is specified.
    499 
    500 
    501 
    502 
    503 
    504 
    505 
    506 Kalt                         Informational                      [Page 9]
    507 
    508 RFC 2811        Internet Relay Chat: Channel Management       April 2000
    509 
    510 
    511    The channel flags 'p' and 's' MUST NOT both be set at the same time.
    512    If a MODE message originating from a server sets the flag 'p' and the
    513    flag 's' is already set for the channel, the change is silently
    514    ignored.  This should only happen during a split healing phase
    515    (mentioned in the "IRC Server Protocol" document [IRC-SERVER]).
    516 
    517 4.2.7 Server Reop Flag
    518 
    519    The channel flag 'r' is only available on channels which name begins
    520    with the character '!' and MAY only be toggled by the "channel
    521    creator".
    522 
    523    This flag is used to prevent a channel from having no channel
    524    operator for an extended period of time.  When this flag is set, any
    525    channel that has lost all its channel operators for longer than the
    526    "reop delay" period triggers a mechanism in servers to reop some or
    527    all of the channel inhabitants.  This mechanism is described more in
    528    detail in section 5.2.4 (Channel Reop Mechanism).
    529 
    530 4.2.8 Topic
    531 
    532    The channel flag 't' is used to restrict the usage of the TOPIC
    533    command to channel operators.
    534 
    535 4.2.9 User Limit
    536 
    537    A user limit may be set on channels by using the channel flag 'l'.
    538    When the limit is reached, servers MUST forbid their local users to
    539    join the channel.
    540 
    541    The value of the limit MUST only be made available to the channel
    542    members in the reply sent by the server to a MODE query.
    543 
    544 4.2.10 Channel Key
    545 
    546    When a channel key is set (by using the mode 'k'), servers MUST
    547    reject their local users request to join the channel unless this key
    548    is given.
    549 
    550    The channel key MUST only be made visible to the channel members in
    551    the reply sent by the server to a MODE query.
    552 
    553 4.3 Channel Access Control
    554 
    555    The last category of modes is used to control access to the channel,
    556    they take a mask as argument.
    557 
    558 
    559 
    560 
    561 
    562 Kalt                         Informational                     [Page 10]
    563 
    564 RFC 2811        Internet Relay Chat: Channel Management       April 2000
    565 
    566 
    567    In order to reduce the size of the global database for control access
    568    modes set for channels, servers MAY put a maximum limit on the number
    569    of such modes set for a particular channel.  If such restriction is
    570    imposed, it MUST only affect user requests.  The limit SHOULD be
    571    homogeneous on a per IRC network basis.
    572 
    573 4.3.1 Channel Ban and Exception
    574 
    575    When a user requests to join a channel, his local server checks if
    576    the user's address matches any of the ban masks set for the channel.
    577    If a match is found, the user request is denied unless the address
    578    also matches an exception mask set for the channel.
    579 
    580    Servers MUST NOT allow a channel member who is banned from the
    581    channel to speak on the channel, unless this member is a channel
    582    operator or has voice privilege. (See Section 4.1.3 (Voice
    583    Privilege)).
    584 
    585    A user who is banned from a channel and who carries an invitation
    586    sent by a channel operator is allowed to join the channel.
    587 
    588 4.3.2 Channel Invitation
    589 
    590    For channels which have the invite-only flag set (See Section 4.2.2
    591    (Invite Only Flag)), users whose address matches an invitation mask
    592    set for the channel are allowed to join the channel without any
    593    invitation.
    594 
    595 5. Current Implementations
    596 
    597    The only current implementation of these rules as part of the IRC
    598    protocol is the IRC server, version 2.10.
    599 
    600    The rest of this section deals with issues that are mostly of
    601    importance to those who wish to implement a server but some parts may
    602    also be of interest for client writers.
    603 
    604 5.1 Tracking Recently Used Channels
    605 
    606    This mechanism is commonly known as "Channel Delay" and generally
    607    only applies to channels which names is prefixed with the character
    608    '#' (See Section 3.1 "Standard channels").
    609 
    610    When a network split occurs, servers SHOULD keep track of which
    611    channels lost a "channel operator" as the result of the break.  These
    612    channels are then in a special state which lasts for a certain period
    613    of time.  In this particular state, the channels cannot cease to
    614 
    615 
    616 
    617 
    618 Kalt                         Informational                     [Page 11]
    619 
    620 RFC 2811        Internet Relay Chat: Channel Management       April 2000
    621 
    622 
    623    exist.  If all the channel members leave the channel, the channel
    624    becomes unavailable: the server local clients cannot join the channel
    625    as long as it is empty.
    626 
    627    Once a channel is unavailable, it will become available again either
    628    because a remote user has joined the channel (most likely because the
    629    network is healing), or because the delay period has expired (in
    630    which case the channel ceases to exist and may be re-created).
    631 
    632    The duration for which a channel death is delayed SHOULD be set
    633    considering many factors among which are the size (user wise) of the
    634    IRC network, and the usual duration of network splits.  It SHOULD be
    635    uniform on all servers for a given IRC network.
    636 
    637 5.2 Safe Channels
    638 
    639    This document introduces the notion of "safe channels".  These
    640    channels have a name prefixed with the character '!' and great effort
    641    is made to avoid collisions in this name space.  Collisions are not
    642    impossible, however they are very unlikely.
    643 
    644 5.2.1 Channel Identifier
    645 
    646    The channel identifier is a function of the time.  The current time
    647    (as defined under UNIX by the number of seconds elapsed since
    648    00:00:00 GMT, January 1, 1970) is converted in a string of five (5)
    649    characters using the following base:
    650    "ABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890" (each character has a decimal
    651    value starting from 0 for 'A' to 35 for '0').
    652 
    653    The channel identifier therefore has a periodicity of 36^5 seconds
    654    (about 700 days).
    655 
    656 5.2.2 Channel Delay
    657 
    658    These channels MUST be subject to the "channel delay" mechanism
    659    described in section 5.1 (Channel Delay).  However, the mechanism is
    660    slightly adapted to fit better.
    661 
    662    Servers MUST keep track of all such channels which lose members as
    663    the result of a network split, no matter whether the user is a
    664    "channel operator" or not.
    665 
    666    However, these channels do NOT ever become unavailable, it is always
    667    possible to join them even when they are empty.
    668 
    669 
    670 
    671 
    672 
    673 
    674 Kalt                         Informational                     [Page 12]
    675 
    676 RFC 2811        Internet Relay Chat: Channel Management       April 2000
    677 
    678 
    679 5.2.3 Abuse Window
    680 
    681    Because the periodicity is so long, attacks on a particular channel
    682    (name) may only occur once in a very long while.  However, with luck
    683    and patience, it is still possible for a user to cause a channel
    684    collision.  In order to avoid this, servers MUST "look in the future"
    685    and keep a list of channel names which identifier is about to be used
    686    (in the coming few days for example). Such list should remain small,
    687    not be a burden for servers to maintain and be used to avoid channel
    688    collisions by preventing the re-creation of such channel for a longer
    689    period of time than channel delay does.
    690 
    691    Eventually a server MAY choose to extend this procedure to forbid
    692    creation of channels with the same shortname only (then ignoring the
    693    channel identifier).
    694 
    695 5.2.4 Preserving Sanity In The Name Space
    696 
    697    The combination of the mechanisms described in sections 5.2.2 and
    698    5.2.3 makes it quite difficult for a user to create a channel
    699    collision. However, another type of abuse consists of creating many
    700    channels having the same shortname, but different identifiers.  To
    701    prevent this from happening, servers MUST forbid the creation of a
    702    new channel which has the same shortname of a channel currently
    703    existing.
    704 
    705 5.2.5 Server Reop Mechanism
    706 
    707    When a channel has been opless for longer than the "reop delay"
    708    period and has the channel flag 'r' set (See Section 4.2.7 (Server
    709    Reop Flag)), IRC servers are responsible for giving the channel
    710    operator status randomly to some of the members.
    711 
    712    The exact logic used for this mechanism by the current implementation
    713    is described below.  Servers MAY use a different logic, but that it
    714    is strongly RECOMMENDED that all servers use the same logic on a
    715    particular IRC network to maintain coherence as well as fairness.
    716    For the same reason, the "reop delay" SHOULD be uniform on all
    717    servers for a given IRC network.  As for the "channel delay", the
    718    value of the "reop delay" SHOULD be set considering many factors
    719    among which are the size (user wise) of the IRC network, and the
    720    usual duration of network splits.
    721 
    722    a) the reop mechanism is triggered after a random time following the
    723       expiration of the "reop delay".  This should limit the eventuality
    724       of the mechanism being triggered at the same time (for the same
    725       channel) on two separate servers.
    726 
    727 
    728 
    729 
    730 Kalt                         Informational                     [Page 13]
    731 
    732 RFC 2811        Internet Relay Chat: Channel Management       April 2000
    733 
    734 
    735    b) If the channel is small (five (5) users or less), and the "channel
    736       delay" for this channel has expired,
    737         Then reop all channel members if at least one member is local to
    738         the server.
    739 
    740    c) If the channel is small (five (5) users or less), and the "channel
    741       delay" for this channel has expired, and the "reop delay" has
    742       expired for longer than its value,
    743         Then reop all channel members.
    744 
    745    d) For other cases, reop at most one member on the channel, based on
    746       some method build into the server. If you don't reop a member, the
    747       method should be such that another server will probably op
    748       someone. The method SHOULD be the same over the whole network. A
    749       good heuristic could be just random reop.
    750       (The current implementation actually tries to choose a member
    751       local to the server who has not been idle for too long, eventually
    752       postponing action, therefore letting other servers have a chance
    753       to find a "not too idle" member.  This is over complicated due to
    754       the fact that servers only know the "idle" time of their local
    755       users)
    756 
    757 6. Current problems
    758 
    759    There are a number of recognized problems with the way IRC channels
    760    are managed.  Some of these can be directly attributed to the rules
    761    defined in this document, while others are the result of the
    762    underlying "IRC Server Protocol" [IRC-SERVER].  Although derived from
    763    RFC 1459 [IRC], this document introduces several novelties in an
    764    attempt to solve some of the known problems.
    765 
    766 6.1 Labels
    767 
    768    This document defines one of the many labels used by the IRC
    769    protocol.  Although there are several distinct namespaces (based on
    770    the channel name prefix), duplicates inside each of these are not
    771    allowed.  Currently, it is possible for users on different servers to
    772    pick the label which may result in collisions (with the exception of
    773    channels known to only one server where they can be averted).
    774 
    775 6.1.1 Channel Delay
    776 
    777    The channel delay mechanism described in section 5.1 (Tracking
    778    Recently Used Channels) and used for channels prefixed with the
    779    character '#' is a simple attempt at preventing collisions from
    780    happening.  Experience has shown that, under normal circumstances, it
    781 
    782 
    783 
    784 
    785 
    786 Kalt                         Informational                     [Page 14]
    787 
    788 RFC 2811        Internet Relay Chat: Channel Management       April 2000
    789 
    790 
    791    is very efficient; however, it obviously has severe limitations
    792    keeping it from being an adequate solution to the problem discussed
    793    here.
    794 
    795 6.1.2 Safe Channels
    796 
    797    "Safe channels" described in section 3.2 (Safe Channels) are a better
    798    way to prevent collisions from happening as it prevents users from
    799    having total control over the label they choose.  The obvious
    800    drawback for such labels is that they are not user friendly.
    801    However, it is fairly trivial for a client program to improve on
    802    this.
    803 
    804 6.2 Mode Propagation Delays
    805 
    806    Because of network delays induced by the network, and because each
    807    server on the path is REQUIRED to check the validity of mode changes
    808    (e.g., user exists and has the right privileges), it is not unusual
    809    for a MODE message to only affect part of the network, often creating
    810    a discrepancy between servers on the current state of a channel.
    811 
    812    While this may seem easy to fix (by having only the original server
    813    check the validity of mode changes), it was decided not to do so for
    814    various reasons.  One concern is that servers cannot trust each
    815    other, and that a misbehaving servers can easily be detected.  This
    816    way of doing so also stops wave effects on channels which are out of
    817    synch when mode changes are issued from different directions.
    818 
    819 6.3 Collisions And Channel Modes
    820 
    821    The "Internet Relay Chat: Server Protocol" document [IRC-SERVER]
    822    describes how channel data is exchanged when two servers connect to
    823    each other.  Channel collisions (either legitimate or not) are
    824    treated as inclusive events, meaning that the resulting channel has
    825    for members all the users who are members of the channel on either
    826    server prior to the connection.
    827 
    828    Similarly, each server sends the channel modes to the other one.
    829    Therefore, each server also receives these channel modes.  There are
    830    three types of modes for a given channel: flags, masks, and data.
    831    The first two types are easy to deal with as they are either set or
    832    unset.  If such a mode is set on one server, it MUST be set on the
    833    other server as a result of the connection.
    834 
    835 
    836 
    837 
    838 
    839 
    840 
    841 
    842 Kalt                         Informational                     [Page 15]
    843 
    844 RFC 2811        Internet Relay Chat: Channel Management       April 2000
    845 
    846 
    847    As topics are not sent as part of this exchange, they are not a
    848    problem.  However, channel modes 'l' and 'k' are exchanged, and if
    849    they are set on both servers prior to the connection, there is no
    850    mechanism to decide which of the two values takes precedence.  It is
    851    left up to the users to fix the resulting discrepancy.
    852 
    853 6.4 Resource Exhaustion
    854 
    855    The mode based on masks defined in section 4.3 make the IRC servers
    856    (and network) vulnerable to a simple abuse of the system: a single
    857    channel operator can set as many different masks as possible on a
    858    particular channel.  This can easily cause the server to waste
    859    memory, as well as network bandwidth (since the info is propagated to
    860    other servers).  For this reason it is RECOMMENDED that a limit be
    861    put on the number of such masks per channels as mentioned in section
    862    4.3.
    863 
    864    Moreover, more complex mechanisms MAY be used to avoid having
    865    redundant masks set for the same channel.
    866 
    867 7. Security Considerations
    868 
    869 7.1 Access Control
    870 
    871    One of the main ways to control access to a channel is to use masks
    872    which are based on the username and hostname of the user connections.
    873    This mechanism can only be efficient and safe if the IRC servers have
    874    an accurate way of authenticating user connections, and if users
    875    cannot easily get around it.  While it is in theory possible to
    876    implement such a strict authentication mechanism, most IRC networks
    877    (especially public networks) do not have anything like this in place
    878    and provide little guaranty about the accuracy of the username and
    879    hostname for a particular client connection.
    880 
    881    Another way to control access is to use a channel key, but since this
    882    key is sent in plaintext, it is vulnerable to traditional man in the
    883    middle attacks.
    884 
    885 7.2 Channel Privacy
    886 
    887    Because channel collisions are treated as inclusive events (See
    888    Section 6.3), it is possible for users to join a channel overriding
    889    its access control settings.  This method has long been used by
    890    individuals to "take over" channels by "illegitimately" gaining
    891    channel operator status on the channel.  The same method can be used
    892    to find out the exact list of members of a channel, as well as to
    893    eventually receive some of the messages sent to the channel.
    894 
    895 
    896 
    897 
    898 Kalt                         Informational                     [Page 16]
    899 
    900 RFC 2811        Internet Relay Chat: Channel Management       April 2000
    901 
    902 
    903 7.3 Anonymity
    904 
    905    The anonymous channel flag (See Section 4.2.1) can be used to render
    906    all users on such channel "anonymous" by presenting all messages to
    907    the channel as originating from a pseudo user which nickname is
    908    "anonymous".  This is done at the client-server level, and no
    909    anonymity is provided at the server-server level.
    910 
    911    It should be obvious to readers, that the level of anonymity offered
    912    is quite poor and insecure, and that clients SHOULD display strong
    913    warnings for users joining such channels.
    914 
    915 8. Current support and availability
    916 
    917      Mailing lists for IRC related discussion:
    918        General discussion: ircd-users@irc.org
    919        Protocol development: ircd-dev@irc.org
    920 
    921      Software implementations:
    922        ftp://ftp.irc.org/irc/server
    923        ftp://ftp.funet.fi/pub/unix/irc
    924        ftp://coombs.anu.edu.au/pub/irc
    925 
    926      Newsgroup: alt.irc
    927 
    928 9. Acknowledgements
    929 
    930    Parts of this document were copied from the RFC 1459 [IRC] which
    931    first formally documented the IRC Protocol.  It has also benefited
    932    from many rounds of review and comments.  In particular, the
    933    following people have made significant contributions to this
    934    document:
    935 
    936    Matthew Green, Michael Neumayer, Volker Paulsen, Kurt Roeckx, Vesa
    937    Ruokonen, Magnus Tjernstrom, Stefan Zehl.
    938 
    939 
    940 
    941 
    942 
    943 
    944 
    945 
    946 
    947 
    948 
    949 
    950 
    951 
    952 
    953 
    954 Kalt                         Informational                     [Page 17]
    955 
    956 RFC 2811        Internet Relay Chat: Channel Management       April 2000
    957 
    958 
    959 10. References
    960 
    961    [KEYWORDS]   Bradner, S., "Key words for use in RFCs to Indicate
    962                 Requirement Levels", BCP 14, RFC 2119, March 1997.
    963 
    964    [IRC]        Oikarinen, J. and D. Reed, "Internet Relay Chat
    965                 Protocol", RFC 1459, May 1993.
    966 
    967    [IRC-ARCH]   Kalt, C., "Internet Relay Chat: Architecture", RFC 2810,
    968                 April 2000.
    969 
    970    [IRC-CLIENT] Kalt, C., "Internet Relay Chat: Client Protocol", RFC
    971                 2812, April 2000.
    972 
    973    [IRC-SERVER] Kalt, C., "Internet Relay Chat: Server Protocol", RFC
    974                 2813, April 2000.
    975 
    976 11. Author's Address
    977 
    978    Christophe Kalt
    979    99 Teaneck Rd, Apt #117
    980    Ridgefield Park, NJ 07660
    981    USA
    982 
    983    EMail: kalt@stealth.net
    984 
    985 
    986 
    987 
    988 
    989 
    990 
    991 
    992 
    993 
    994 
    995 
    996 
    997 
    998 
    999 
   1000 
   1001 
   1002 
   1003 
   1004 
   1005 
   1006 
   1007 
   1008 
   1009 
   1010 Kalt                         Informational                     [Page 18]
   1011 
   1012 RFC 2811        Internet Relay Chat: Channel Management       April 2000
   1013 
   1014 
   1015 12.  Full Copyright Statement
   1016 
   1017    Copyright (C) The Internet Society (2000).  All Rights Reserved.
   1018 
   1019    This document and translations of it may be copied and furnished to
   1020    others, and derivative works that comment on or otherwise explain it
   1021    or assist in its implementation may be prepared, copied, published
   1022    and distributed, in whole or in part, without restriction of any
   1023    kind, provided that the above copyright notice and this paragraph are
   1024    included on all such copies and derivative works.  However, this
   1025    document itself may not be modified in any way, such as by removing
   1026    the copyright notice or references to the Internet Society or other
   1027    Internet organizations, except as needed for the purpose of
   1028    developing Internet standards in which case the procedures for
   1029    copyrights defined in the Internet Standards process must be
   1030    followed, or as required to translate it into languages other than
   1031    English.
   1032 
   1033    The limited permissions granted above are perpetual and will not be
   1034    revoked by the Internet Society or its successors or assigns.
   1035 
   1036    This document and the information contained herein is provided on an
   1037    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   1038    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   1039    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   1040    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   1041    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
   1042 
   1043 Acknowledgement
   1044 
   1045    Funding for the RFC Editor function is currently provided by the
   1046    Internet Society.
   1047 
   1048 
   1049 
   1050 
   1051 
   1052 
   1053 
   1054 
   1055 
   1056 
   1057 
   1058 
   1059 
   1060 
   1061 
   1062 
   1063 
   1064 
   1065 
   1066 Kalt                         Informational                     [Page 19]
   1067