summaryrefslogtreecommitdiff
path: root/vendor/github.com/fluffle/goirc/doc/rfc2811.txt
diff options
context:
space:
mode:
Diffstat (limited to 'vendor/github.com/fluffle/goirc/doc/rfc2811.txt')
-rw-r--r--vendor/github.com/fluffle/goirc/doc/rfc2811.txt1067
1 files changed, 1067 insertions, 0 deletions
diff --git a/vendor/github.com/fluffle/goirc/doc/rfc2811.txt b/vendor/github.com/fluffle/goirc/doc/rfc2811.txt
new file mode 100644
index 0000000..7c2c4ea
--- /dev/null
+++ b/vendor/github.com/fluffle/goirc/doc/rfc2811.txt
@@ -0,0 +1,1067 @@
+
+
+
+
+
+
+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
+
+
+
+Kalt Informational [Page 1]
+
+RFC 2811 Internet Relay Chat: Channel Management April 2000
+
+
+ 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.
+
+
+
+
+
+Kalt Informational [Page 2]
+
+RFC 2811 Internet Relay Chat: Channel Management April 2000
+
+
+ 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
+
+
+
+
+
+Kalt Informational [Page 3]
+
+RFC 2811 Internet Relay Chat: Channel Management April 2000
+
+
+ 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
+
+
+
+
+
+
+Kalt Informational [Page 4]
+
+RFC 2811 Internet Relay Chat: Channel Management April 2000
+
+
+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.
+
+
+
+
+
+
+Kalt Informational [Page 5]
+
+RFC 2811 Internet Relay Chat: Channel Management April 2000
+
+
+ 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".
+
+
+
+
+Kalt Informational [Page 6]
+
+RFC 2811 Internet Relay Chat: Channel Management April 2000
+
+
+ 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".
+
+
+
+
+
+
+Kalt Informational [Page 7]
+
+RFC 2811 Internet Relay Chat: Channel Management April 2000
+
+
+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.
+
+
+
+
+
+
+Kalt Informational [Page 8]
+
+RFC 2811 Internet Relay Chat: Channel Management April 2000
+
+
+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.
+
+
+
+
+
+
+
+Kalt Informational [Page 9]
+
+RFC 2811 Internet Relay Chat: Channel Management April 2000
+
+
+ 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.
+
+
+
+
+
+Kalt Informational [Page 10]
+
+RFC 2811 Internet Relay Chat: Channel Management April 2000
+
+
+ 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
+
+
+
+
+Kalt Informational [Page 11]
+
+RFC 2811 Internet Relay Chat: Channel Management April 2000
+
+
+ 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.
+
+
+
+
+
+
+Kalt Informational [Page 12]
+
+RFC 2811 Internet Relay Chat: Channel Management April 2000
+
+
+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.
+
+
+
+
+Kalt Informational [Page 13]
+
+RFC 2811 Internet Relay Chat: Channel Management April 2000
+
+
+ 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
+
+
+
+
+
+Kalt Informational [Page 14]
+
+RFC 2811 Internet Relay Chat: Channel Management April 2000
+
+
+ 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.
+
+
+
+
+
+
+
+
+Kalt Informational [Page 15]
+
+RFC 2811 Internet Relay Chat: Channel Management April 2000
+
+
+ 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.
+
+
+
+
+Kalt Informational [Page 16]
+
+RFC 2811 Internet Relay Chat: Channel Management April 2000
+
+
+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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kalt Informational [Page 17]
+
+RFC 2811 Internet Relay Chat: Channel Management April 2000
+
+
+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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kalt Informational [Page 18]
+
+RFC 2811 Internet Relay Chat: Channel Management April 2000
+
+
+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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kalt Informational [Page 19]
+