 |
|
CowCulture 2811 IRC - Internet Relay Chat: Channel Management
|
 Status of this Memo [166 B] 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 [70 B] Copyright (C) The Internet Society (2000). All Rights Reserved.
__
Abstract [490 B] 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 uniq __
Table of Contents [3.74 KB]
1. Introduction [967 B] This document defines in detail on how channels are managed by the
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 __
2. Channel Characteristics [191 B] 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 [944 B] 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
'&', __
2.2 Channel Scope [1.23 KB] 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 __
2.3 Channel Properties [364 B] 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 __
2.4 Privileged Channel Members [536 B] 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 __
2.4.1 Channel Operators [549 B] 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 __
2.4.2 Channel Creator [588 B] 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 cr __
3. Channel lifetime [208 B] 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 [1.44 KB] 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 cha __
3.2 Safe Channels [1.75 KB] 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) __
4. Channel Modes [1.17 KB] 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 f __
4.1 Member Status [124 B] 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 [219 B] 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 [80 B] The mode 'o' is used to toggle the operator status of a channel
member.
__
4.1.3 Voice Privilege [196 B] 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 [101 B] The modes in this category are used to define properties which
affects how channels operate.
__
4.2.1 Anonymous Flag [1.11 KB] 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 " __
4.2.2 Invite Only Flag [315 B] 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 "IR __
4.2.3 Moderated Channel Flag [242 B] 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 [134 B] 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 [506 B] 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 __
4.2.6 Private and Secret Channels [1.19 KB] 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 the __
4.2.7 Server Reop Flag [578 B] 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 exte __
4.2.8 Topic [102 B] The channel flag 't' is used to restrict the usage of the TOPIC
command to channel operators.
__
4.2.9 User Limit [294 B] 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 __
4.2.10 Channel Key [226 B] 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
__
4.3 Channel Access Control [436 B] 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 numbe __
4.3.1 Channel Ban and Exception [614 B] 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 __
4.3.2 Channel Invitation [226 B] 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 [298 B] 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 m __
5.1 Tracking Recently Used Channels [1.18 KB] 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 SHOU __
5.2 Safe Channels [269 B] 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 ar __
5.2.1 Channel Identifier [472 B] 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:
__
5.2.2 Channel Delay [447 B] 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 member __
5.2.3 Abuse Window [795 B] 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, __
5.2.4 Preserving Sanity In The Name Space [427 B] 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 di __
5.2.5 Server Reop Mechanism [2.21 KB] 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 __
6. Current problems [407 B] 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" __
6.1 Labels [416 B] 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 use __
6.1.1 Channel Delay [357 B] 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 obviousl __
6.1.2 Safe Channels [361 B] "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 t __
6.2 Mode Propagation Delays [775 B] 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 __
6.3 Collisions And Channel Modes [1.03 KB] 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, mea __
6.4 Resource Exhaustion [612 B] 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 __
7. Security Considerations [1 B]
7.1 Access Control [780 B] 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 authenticat __
7.2 Channel Privacy [432 B] Because channel collisions are treated as inclusive events (See
Section 6.3), it is possible for users to join a channel overriding
individuals to "take over" channels by "illegitimately" gaining
channel operator statu __
7.3 Anonymity [538 B] 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". Thi __
8. Current support and availability [312 B] 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
__
9. Acknowledgements [384 B] 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 contri __
10. References [611 B] [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 __
11. Author's Address [105 B] Christophe Kalt
99 Teaneck Rd, Apt #117
Ridgefield Park, NJ 07660
EMail: kalt@stealth.net
__
12. Full Copyright Statement [1.43 KB] 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 __
Acknowledgement [91 B] Funding for the RFC Editor function is currently provided by the
Internet Society.
__
|
Gogloom.com - Loading
- Please, wait
Search Examples: