As per Relevance of the word channels, we have this rfc below:
Network Working Group C.
Request for Comments: 2811 April 2000
Updates: 1459
Category:
Internet Relay Chat: Channel
Status of this
This memo provides information for the Internet community. It
not specify an Internet standard of any kind. Distribution of
memo is unlimited
Copyright
Copyright (C) The Internet Society (2000). All Rights Reserved
One of the most notable characteristics of the IRC (Internet
Chat) protocol is to allow for users to be grouped in forums,
channels, providing a mean for multiple users to
together
There was originally a unique type of channels, but with the years
new types appeared either as a response to a need, or
experimental purposes
This document specifies how channels, their characteristics
properties are managed by IRC servers
Table of
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.
This document defines in detail on how channels are managed by
IRC servers and will be mostly useful to people working
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,
remain non essential for implementing clients. While the trend
to be towards more and more complex and "intelligent" clients
are able to take advantage of knowing the internal workings
channels to provide the users with a more friendly interface,
clients can be implemented without reading this document
Many of the concepts defined here were designed with the
architecture [IRC-ARCH] in mind and mostly make sense in
context. However, many others could be applied to
architectures in order to provide forums for a conferencing system
Finally, it is to be noted that IRC users may find some of
following sections of interest, in particular sections 2 (
Characteristics) and 4 (Channel Modes).
2. Channel
A channel is a named group of one or more users which will
receive messages addressed to that channel. A channel
characterized by its name, properties and current members
2.1
Channels names are strings (beginning with a '&', '#', '+' or '!'
character) of length up to fifty (50) characters. Channel names
case insensitive
Apart from the the requirement that the first character being
'&', '#', '+' or '!' (hereafter called "channel prefix"). The
restriction on a channel name is that it SHALL NOT contain any
(' '), a control G (^G or ASCII 7), a comma (',' which is used as
list item separator by the protocol). Also, a colon (':') is used
a delimiter for the channel mask. The exact syntax of a channel
is defined in "IRC Server Protocol" [IRC-SERVER].
The use of different prefixes effectively creates four (4)
namespaces for channel names. This is important because of
protocol limitations regarding namespaces (in general). See
6.1 (Labels) for more details on these limitations
2.2 Channel
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
which the user is directly connected. The list of servers which
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
the IRC network, in order for the messages addressed to the
to be sent to all the channel members
Channels with '&' as prefix are local to the server where they
created
Other channels are known to one (1) or more servers that
connected to the network, depending on the channel mask
If there is no channel mask, then the channel is known to
the servers
If there is a channel mask, then the channel MUST only be
to servers which has a local user on the channel, and to
neighbours if the mask matches both the local and
server names. Since other servers have absolutely no knowledge
the existence of such a channel, the area formed by the
having a name matching the mask has to be contiguous for
channel to be known by all these servers. Channel masks are
used in conjunction with server hostmasking [IRC-SERVER].
2.3 Channel
Each channel has its own properties, which are defined by
modes. Channel modes can be manipulated by the channel members.
modes affect the way servers manage the channels
Channels with '+' as prefix do not support channel modes. This
that all the modes are unset, with the exception of the 't'
flag which is set
2.4 Privileged Channel
In order for the channel members to keep some control over a channel
and some kind of sanity, some channel members are privileged.
these members are allowed to perform the following actions on
channel
INVITE - Invite a client to an invite-only channel (mode +i
KICK - Eject a client from the
MODE - Change the channel's mode, as well
members'
PRIVMSG - Sending messages to the channel (mode +n, +m, +v
TOPIC - Change the channel topic in a mode +t
Kalt Informational [Page 4]
RFC 2811 Internet Relay Chat: Channel Management April 2000
2.4.1 Channel
The channel operators (also referred to as a "chop" or "chanop") on
given channel are considered to 'own' that channel. Ownership of
channel is shared among channel operators
Channel operators are identified by the '@' symbol next to
nickname whenever it is associated with a channel (i.e., replies
the NAMES, WHO and WHOIS commands).
Since channels starting with the character '+' as prefix do
support channel modes, no member can therefore have the status
channel operator
2.4.2 Channel
A user who creates a channel with the character '!' as prefix
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
the ability to toggle certain modes of the channel which
operators may not manipulate
A "channel creator" can be distinguished from a channel operator
issuing the proper MODE command. See the "IRC Client Protocol
[IRC-CLIENT] for more information on this topic
3. Channel
In regard to the lifetime of a channel, there are typically
groups of channels: standard channels which prefix is either '&', '#'
or '+', and "safe channels" which prefix is '!'.
3.1 Standard
These channels are created implicitly when the first user joins it
and cease to exist when the last user leaves it. While the
exists, any client can reference the channel using the name of
channel
The user creating a channel automatically becomes channel
with the notable exception of channels which name is prefixed by
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
the IRC network becomes disjoint because of a split between
servers), channel names SHOULD NOT be allowed to be reused by a
if a channel operator (See Section 2.4.1 (Channel Operators))
recently left the channel because of a network split. If
happens, the channel name is temporarily unavailable. The
while a channel remains unavailable should be tuned on a per
network basis. It is important to note that this prevents
users from creating a channel using the same name, but does
prevent the channel to be recreated by a remote user. The
typically happens when the IRC network rejoins. Obviously,
mechanism only makes sense for channels which name begins with
character '#', but MAY be used for channels which name begins
the character '+'. This mechanism is commonly known as "
Delay".
3.2 Safe
Unlike other channels, "safe channels" are not implicitly created.
user wishing to create such a channel MUST request the creation
sending a special JOIN command to the server in which the
identifier (then unknown) is replaced by the character '!'.
creation process for this type of channel is strictly controlled
The user only chooses part of the channel name (known as the
"short name"), the server automatically prepends the user
name with a channel identifier consisting of five (5) characters
The channel name resulting from the combination of these two
is unique, making the channel safe from abuses based on
splits
The user who creates such a channel automatically becomes "
creator". See section 2.4.2 (Channel Creator) for more details
this title
A server MUST NOT allow the creation of a new channel if
channel with the same short name exists; or if another channel
the same short name existed recently AND any of its member(s)
because of a network split. Such channel ceases to exist after
user leaves AND no other member recently left the channel because
a network split
Unlike the mechanism described in section 5.2.2 (Channel Delay),
this case, channel names do not become unavailable: these
may continue to exist after the last user left. Only the
creating the channel becomes "channel creator", users joining
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
created by the server MUST follow specific rules. For more
on this, see section 5.2.1 (Channel Identifier).
4. Channel
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
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
the invite-only flag
Unless mentioned otherwise below, all these modes can be
by "channel operators" by using the MODE command defined in "
Client Protocol" [IRC-CLIENT].
4.1 Member
The modes in this category take a channel member nickname as
and affect the privileges given to this user
4.1.1 "Channel Creator"
The mode 'O' is only used in conjunction with "safe channels"
SHALL NOT be manipulated by users. Servers use it to give the
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
The mode 'o' is used to toggle the operator status of a
member
4.1.3 Voice
The mode 'v' is used to give and take voice privilege to/from
channel member. Users with this privilege can talk on
channels. (See section 4.2.3 (Moderated Channel Flag).
4.2 Channel
The modes in this category are used to define properties
affects how channels operate
4.2.1 Anonymous
The channel flag 'a' defines an anonymous channel. This means
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
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
forbid users from using the nickname "anonymous". Servers MUST
NOT send QUIT messages for users leaving such channels to the
channel members but generate a PART message instead
On channels with the character '&' as prefix, this flag MAY
toggled by channel operators, but on channels with the character '!'
as prefix, this flag can be set (but SHALL NOT be unset) by
"channel creator" only. This flag MUST NOT be made available
other types of channels
Replies to the WHOIS, WHO and NAMES commands MUST NOT reveal
presence of other users on channels for which the anonymous flag
set
4.2.2 Invite Only
When the channel flag 'i' is set, new members are only accepted
their mask matches Invite-list (See section 4.3.2) or they have
invited by a channel operator. This flag also restricts the usage
the INVITE command (See "IRC Client Protocol" [IRC-CLIENT])
channel operators
Kalt Informational [Page 8]
RFC 2811 Internet Relay Chat: Channel Management April 2000
4.2.3 Moderated Channel
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
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
When the channel flag 'n' is set, only channel members MAY
messages to the channel
This flag only affects users
4.2.5 Quiet
The channel flag 'q' is for use by servers only. When set,
restricts the type of data sent to users about the
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
server sends notices related to its operations. This was used as
more efficient and flexible way to replace the user mode 's'
in RFC 1459 [IRC].
4.2.6 Private and Secret
The channel flag 'p' is used to mark a channel "private" and
channel flag 's' to mark a channel "secret". Both properties
similar and conceal the existence of the channel from other users
This means that there is no way of getting this channel's name
the server without being a member. In other words, these
MUST be omitted from replies to queries like the WHOIS command
When a channel is "secret", in addition to the restriction above,
server will act as if the channel does not exist for queries like
TOPIC, LIST, NAMES commands. Note that there is one exception
this rule: servers will correctly reply to the MODE command
Finally, secret channels are not accounted for in the reply to
LUSERS command (See "Internet Relay Chat: Client Protocol" [IRC
CLIENT]) when the 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
flag 's' is already set for the channel, the change is
ignored. This should only happen during a split healing
(mentioned in the "IRC Server Protocol" document [IRC-SERVER]).
4.2.7 Server Reop
The channel flag 'r' is only available on channels which name
with the character '!' and MAY only be toggled by the "
creator".
This flag is used to prevent a channel from having no
operator for an extended period of time. When this flag is set,
channel that has lost all its channel operators for longer than
"reop delay" period triggers a mechanism in servers to reop some
all of the channel inhabitants. This mechanism is described more
detail in section 5.2.4 (Channel Reop Mechanism).
4.2.8
The channel flag 't' is used to restrict the usage of the
command to channel operators
4.2.9 User
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
join the channel
The value of the limit MUST only be made available to the
members in the reply sent by the server to a MODE query
4.2.10 Channel
When a channel key is set (by using the mode 'k'), servers
reject their local users request to join the channel unless this
is given
The channel key MUST only be made visible to the channel members
the reply sent by the server to a MODE query
4.3 Channel Access
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
modes set for channels, servers MAY put a maximum limit on the
of such modes set for a particular channel. If such restriction
imposed, it MUST only affect user requests. The limit SHOULD
homogeneous on a per IRC network basis
4.3.1 Channel Ban and
When a user requests to join a channel, his local server checks
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
also matches an exception mask set for the channel
Servers MUST NOT allow a channel member who is banned from
channel to speak on the channel, unless this member is a
operator or has voice privilege. (See Section 4.1.3 (
Privilege)).
A user who is banned from a channel and who carries an
sent by a channel operator is allowed to join the channel
4.3.2 Channel
For channels which have the invite-only flag set (See Section 4.2.2
(Invite Only Flag)), users whose address matches an invitation
set for the channel are allowed to join the channel without
invitation
5. Current
The only current implementation of these rules as part of the
protocol is the IRC server, version 2.10.
The rest of this section deals with issues that are mostly
importance to those who wish to implement a server but some parts
also be of interest for client writers
5.1 Tracking Recently Used
This mechanism is commonly known as "Channel Delay" and
only applies to channels which names is prefixed with the
'#' (See Section 3.1 "Standard channels").
When a network split occurs, servers SHOULD keep track of
channels lost a "channel operator" as the result of the break.
channels are then in a special state which lasts for a certain
of time. In this particular state, the channels cannot cease
Kalt Informational [Page 11]
RFC 2811 Internet Relay Chat: Channel Management April 2000
exist. If all the channel members leave the channel, the
becomes unavailable: the server local clients cannot join the
as long as it is empty
Once a channel is unavailable, it will become available again
because a remote user has joined the channel (most likely because
network is healing), or because the delay period has expired (
which case the channel ceases to exist and may be re-created).
The duration for which a channel death is delayed SHOULD be
considering many factors among which are the size (user wise) of
IRC network, and the usual duration of network splits. It SHOULD
uniform on all servers for a given IRC network
5.2 Safe
This document introduces the notion of "safe channels".
channels have a name prefixed with the character '!' and great
is made to avoid collisions in this name space. Collisions are
impossible, however they are very unlikely
5.2.1 Channel
The channel identifier is a function of the time. The current
(as defined under UNIX by the number of seconds elapsed
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
value starting from 0 for 'A' to 35 for '0').
The channel identifier therefore has a periodicity of 36^5
(about 700 days).
5.2.2 Channel
These channels MUST be subject to the "channel delay"
described in section 5.1 (Channel Delay). However, the mechanism
slightly adapted to fit better
Servers MUST keep track of all such channels which lose members
the result of a network split, no matter whether the user is
"channel operator" or not
However, these channels do NOT ever become unavailable, it is
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
Because the periodicity is so long, attacks on a particular
(name) may only occur once in a very long while. However, with
and patience, it is still possible for a user to cause a
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
(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
collisions by preventing the re-creation of such channel for a
period of time than channel delay does
Eventually a server MAY choose to extend this procedure to
creation of channels with the same shortname only (then ignoring
channel identifier).
5.2.4 Preserving Sanity In The Name
The combination of the mechanisms described in sections 5.2.2
5.2.3 makes it quite difficult for a user to create a
collision. However, another type of abuse consists of creating
channels having the same shortname, but different identifiers.
prevent this from happening, servers MUST forbid the creation of
new channel which has the same shortname of a channel
existing
5.2.5 Server Reop
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 (
Reop Flag)), IRC servers are responsible for giving the
operator status randomly to some of the members
The exact logic used for this mechanism by the current
is described below. Servers MAY use a different logic, but that
is strongly RECOMMENDED that all servers use the same logic on
particular IRC network to maintain coherence as well as fairness
For the same reason, the "reop delay" SHOULD be uniform on
servers for a given IRC network. As for the "channel delay",
value of the "reop delay" SHOULD be set considering many
among which are the size (user wise) of the IRC network, and
usual duration of network splits
a) the reop mechanism is triggered after a random time following
expiration of the "reop delay". This should limit the
of the mechanism being triggered at the same time (for the
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 "
delay" for this channel has expired
Then reop all channel members if at least one member is local
the server
c) If the channel is small (five (5) users or less), and the "
delay" for this channel has expired, and the "reop delay"
expired for longer than its value
Then reop all channel members
d) For other cases, reop at most one member on the channel, based
some method build into the server. If you don't reop a member,
method should be such that another server will probably
someone. The method SHOULD be the same over the whole network.
good heuristic could be just random reop
(The current implementation actually tries to choose a
local to the server who has not been idle for too long,
postponing action, therefore letting other servers have a
to find a "not too idle" member. This is over complicated due
the fact that servers only know the "idle" time of their
users
6. Current
There are a number of recognized problems with the way IRC
are managed. Some of these can be directly attributed to the
defined in this document, while others are the result of
underlying "IRC Server Protocol" [IRC-SERVER]. Although derived
RFC 1459 [IRC], this document introduces several novelties in
attempt to solve some of the known problems
6.1
This document defines one of the many labels used by the
protocol. Although there are several distinct namespaces (based
the channel name prefix), duplicates inside each of these are
allowed. Currently, it is possible for users on different servers
pick the label which may result in collisions (with the exception
channels known to only one server where they can be averted).
6.1.1 Channel
The channel delay mechanism described in section 5.1 (
Recently Used Channels) and used for channels prefixed with
character '#' is a simple attempt at preventing collisions
happening. Experience has shown that, under normal circumstances,
Kalt Informational [Page 14]
RFC 2811 Internet Relay Chat: Channel Management April 2000
is very efficient; however, it obviously has severe
keeping it from being an adequate solution to the problem
here
6.1.2 Safe
"Safe channels" described in section 3.2 (Safe Channels) are a
way to prevent collisions from happening as it prevents users
having total control over the label they choose. The
drawback for such labels is that they are not user friendly
However, it is fairly trivial for a client program to improve
this
6.2 Mode Propagation
Because of network delays induced by the network, and because
server on the path is REQUIRED to check the validity of mode
(e.g., user exists and has the right privileges), it is not
for a MODE message to only affect part of the network, often
a discrepancy between servers on the current state of a channel
While this may seem easy to fix (by having only the original
check the validity of mode changes), it was decided not to do so
various reasons. One concern is that servers cannot trust
other, and that a misbehaving servers can easily be detected.
way of doing so also stops wave effects on channels which are out
synch when mode changes are issued from different directions
6.3 Collisions And Channel
The "Internet Relay Chat: Server Protocol" document [IRC-SERVER
describes how channel data is exchanged when two servers connect
each other. Channel collisions (either legitimate or not)
treated as inclusive events, meaning that the resulting channel
for members all the users who are members of the channel on
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
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
unset. If such a mode is set on one server, it MUST be set on
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
problem. However, channel modes 'l' and 'k' are exchanged, and
they are set on both servers prior to the connection, there is
mechanism to decide which of the two values takes precedence. It
left up to the users to fix the resulting discrepancy
6.4 Resource
The mode based on masks defined in section 4.3 make the IRC
(and network) vulnerable to a simple abuse of the system: a
channel operator can set as many different masks as possible on
particular channel. This can easily cause the server to
memory, as well as network bandwidth (since the info is propagated
other servers). For this reason it is RECOMMENDED that a limit
put on the number of such masks per channels as mentioned in
4.3.
Moreover, more complex mechanisms MAY be used to avoid
redundant masks set for the same channel
7. Security
7.1 Access
One of the main ways to control access to a channel is to use
which are based on the username and hostname of the user connections
This mechanism can only be efficient and safe if the IRC servers
an accurate way of authenticating user connections, and if
cannot easily get around it. While it is in theory possible
implement such a strict authentication mechanism, most IRC
(especially public networks) do not have anything like this in
and provide little guaranty about the accuracy of the username
hostname for a particular client connection
Another way to control access is to use a channel key, but since
key is sent in plaintext, it is vulnerable to traditional man in
middle attacks
7.2 Channel
Because channel collisions are treated as inclusive events (
Section 6.3), it is possible for users to join a channel
its access control settings. This method has long been used
individuals to "take over" channels by "illegitimately"
channel operator status on the channel. The same method can be
to find out the exact list of members of a channel, as well as
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
The anonymous channel flag (See Section 4.2.1) can be used to
all users on such channel "anonymous" by presenting all messages
the channel as originating from a pseudo user which nickname
"anonymous". This is done at the client-server level, and
anonymity is provided at the server-server level
It should be obvious to readers, that the level of anonymity
is quite poor and insecure, and that clients SHOULD display
warnings for users joining such channels
8. Current support and
Mailing lists for IRC related discussion
General discussion: ircd-users@irc.
Protocol development: ircd-dev@irc.
Software implementations
ftp://ftp.irc.org/irc/
ftp://ftp.funet.fi/pub/unix/
ftp://coombs.anu.edu.au/pub/
Newsgroup: alt.
9.
Parts of this document were copied from the RFC 1459 [IRC]
first formally documented the IRC Protocol. It has also
from many rounds of review and comments. In particular,
following people have made significant contributions to
document
Matthew Green, Michael Neumayer, Volker Paulsen, Kurt Roeckx,
Ruokonen, Magnus Tjernstrom, Stefan Zehl
Kalt Informational [Page 17]
RFC 2811 Internet Relay Chat: Channel Management April 2000
10.
[KEYWORDS] Bradner, S., "Key words for use in RFCs to
Requirement Levels", BCP 14, RFC 2119, March 1997.
[IRC] Oikarinen, J. and D. Reed, "Internet Relay
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",
2812, April 2000.
[IRC-SERVER] Kalt, C., "Internet Relay Chat: Server Protocol",
2813, April 2000.
11. Author's
Christophe
99 Teaneck Rd, Apt #117
Ridgefield Park, NJ 07660
EMail: kalt@stealth.
Kalt Informational [Page 18]
RFC 2811 Internet Relay Chat: Channel Management April 2000
12. Full Copyright
Copyright (C) The Internet Society (2000). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Funding for the RFC Editor function is currently provided by
Internet Society
Kalt Informational [Page 19]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
