Internet delayed conversation: Channel Management (rfc2811-Internet Relay Chat: client Protocol)

Delayed Internet conversation: Channel Management
(Rfc2811-Internet Relay Chat: client Protocol)
Status of this memo
This Memorandum provides information to internet groups. It does not set any Internet standards and can be released without restrictions.
Copyright Notice
Copyright (c) the Internet Society (2000). All rights reserved.
Summary
One of the most striking features of the IRC protocol is that it allows users to group by Forum, called a channel,
It provides a way for multiple users to communicate with each other.
This document details the channels, their features, and attributes managed by the IRC server.
1. Introduction 2
2. Channel Feature 2
2.1 namespace 2
2.2 channel range 3
2.3 channel attribute 3
2.4 privileged channel user 3
3. Channel survival 4
3.1 Standard Channel 4
3.2 Security Channel 4
4. channel mode 5
4.1 member identity 5
4.2 channel flag 6
4.3 Channel Access Control 7
5. Current implementation 8
5.1 track recently used channels 8
5.2 Security Channel 8
6. Current problem 10
6.1 logo 10
6.2 status propagation latency 10
6.3 conflict and channel status 11
6.4 Resource Depletion 11
7. security considerations 11
7.1 Access Control 11
7.2 channel secrets 12
7.3 anonymous 12
8. Current support and Access Channels 12
9. Thanks 12
10. References 12
11. Author address 13

1. Introduction
This document details how the channel is defined by the IRC server.
Especially useful.
Although the concepts defined here are an important part of IRC, they are not necessary for client implementation.
Although the client is becoming more and more complex and "smart", it can take advantage of the internal work of the channel to provide users with a more
Friendly interface, but simple clients can achieve this without reading this document.
Many of the concepts defined here are limited by the IRC architecture [IRC-ARCH] in the mind, and most
It makes sense only in this environment. However, many other concepts can be applied to other architectures so that
The discussion system provides forum sites.
Finally, the IRC user may find the following useful parts, especially the second and fourth parts (channel features ).
Part (channel status ).
2. channel features
A channel is a name group composed of one or more users. All members in the group receive messages sent to this channel.
It is marked by its name, attribute, and current member.
2.1 namespace
Channel name (by a '&', '#', '+' or '! ') Can contain up to 50 characters. Channel
The name is case sensitive.
Except the first character, it must be '&', '#', '+', or '! '(Later called "channel prefix ")
Outer. The only restriction on the channel name is that it cannot contain any space (''), control Letter g (^ g or ASCII 7 ),
Comma (',' is used as the delimiter of the list item ). Also, the colon (':') is used as the separator of the channel mask.
The exact channel name syntax is defined in "IRC server protocol" [IRC-server.
The use of different prefixes effectively creates four namespaces for Channel names. This is important because of the limitations of this Protocol.
It is related to namespace (in general ). See section 6.1 (FLAG) for more details about limitations.
2.2 channel range
A channel entity is known to one or more servers on the IRC network. Only servers directly connected to users
You can only join a channel that you know. It is known that a series of servers in a specific channel must be on the IRC network.
A adjacent part, so that messages sent to this channel can be sent to all channel members.
Channels prefixed with '&' are local for the servers that create them.
Other channels are known to one or more servers connected to the network, depending on the channel mask:
If there is no channel mask, the channel will be known to all servers.
If there is a channel mask, this channel is only known to servers that have local users connected to the channel. If
The mask matches the local name and the name of the adjacent server, so it is also known to the neighboring server. Because other services
The server does not have any information about the existence of such a channel. If the channel is to be known to all servers
The regions of servers with names that match the mask must be adjacent to the channel. The channel mask is best for Servers
Host mask [IRC-SERVER] used together.
2.3 channel attributes
Each channel has its own channel state-defined attributes. The channel mode can be used by channel members. Module
Server Management channel.
A channel prefixed with '+' does not support the channel mode. This means that all the modes are not set.
Specifies the 'T' channel flag.
2.4 privileged channel Users
Some channel members are granted privileges to maintain certain control and order over the Channel. Only
These members are allowed to perform the following operations on the channel:
Invite-invite a customer to an invite-only channel (mode + I)
Kick-evicted a customer from the Channel
Mode-change the channel mode or the privileges of members
PRIVMSG-send messages to the channel (mode + N, + M + V)
Topic-change the channel topic in a channel with the mode of + T
2.4.1 channel Administrator
The channel Administrator (also known as "chop" or "chanop") on a given channel is considered to have this channel.
Channel ownership is shared by the channel administrator.
No matter when it is related to the channel, the channel administrator is marked by the '@' symbol adjacent to its name (
For example, answer names, WHO, and whois commands ).
Because the channel prefixed with the character '+' does not support the channel mode, no member has the channel administrator status.
2.4.2 channel creator
The user who creates a channel is called the channel creator '! 'Prefix as its flag. Once created
This user is also granted the channel administrator status.
To identify this status, the channel creator is granted the ability to lock the channel status, which is not available to the channel Administrator
.
By sending the appropriate mode command, you can differentiate the 'Channel creators 'and channel administrators. See "IRC client
Protocol "[IRC-CLIENT] for more information in this regard.
3. Channel survival
There are two typical channels related to the channel life: Standard channel, whose prefix is not '&''#'
It is '+' and the security channel. Its prefix is '! '.
3.1 Standard Channel
When a local user joins these channels, they are created secretly, and the last user stops to survive when they exit. But channel survival
Any customer can reference this channel by channel name.
The user who creates the channel automatically becomes the channel administrator, except for the channel whose prefix is '+', see Section 4
Path mode ). For more information about this topic, see Section 2.4.1.
To avoid creating two identical channels (especially when the IRC network is disconnected from the two servers ),
The channel name cannot be used by users when the channel administrator leaves due to network disconnection. If this happens,
The channel name is temporarily unavailable. Channel downtime should be adjusted based on each IRC network
. It should be emphasized that this can prevent the creation of another channel with the same name, but it cannot prevent Remote use
User to recreate the channel. The latter is particularly prone to re-connection in the IRC network. Obviously, this mechanism knowledge and
It is a channel whose name starts with '#', but may also be used by a channel whose name starts with '+. This mechanism
It is generally referred to as 'Channel latencies '.
3.2 Security Channel
Unlike other channels, "security channels" are not created in secret. Users who want to create such channels must
The server sends a special join command to apply for creation. The channel identifier in the server (then unknown)
Bycharacter '! . The creation of such channels is strictly controlled. The user selects only some channel names (called channels)
The server automatically adds the first five channel identifiers to the user's name. These two elements are combined
The channel name is unique, so that the channel will not be abused due to network disconnection.
The user who creates such a channel automatically becomes the 'Channel creator '. See section 2.4.2 (Channel creator) to obtain
More information about this topic.
If the short name of the new channel is the same as that of another existing channel
And its members are disconnected from the network. Therefore, the server prohibits the creation of such a channel.
This type of channel stops survival after the last member leaves and no other member has recently left due to network disconnection.
Different from the mechanism described in section 5.2.2 (Channel latency), the channel name does not become unavailable in this case:
These channels may survive after the last member leaves. Only the user who creates the channel can become the channel creator ",
If a user with an empty channel does not automatically become the channel creator or the channel administrator ".
To ensure the uniqueness of channel names, channel identifiers created by the server must follow certain rules. More details
Section, see Section 5.2.1 (Channel identifier ).
4. Channel Mode
The channels can obtain the following modes:
0-assign the channel creator status;
O-grant/revoke the "channel administrator" privilege;
V-grant/revoke the privilege to speak;
A-change the anonymous channel flag;
I-converted invite-only channel flag;
Whether the M-conversion adjusts the channel
N-conversion allows external customers to send messages to the Channel
Q-convert the quiet channel flag;
P-converted private channel flag
S-conversion Secret channel flag
R-conversion server reop channel flag
T-switch whether the topic can be set only by the channel Administrator
K-set/Delete the channel key (password );
L-set/delete channel User restrictions
B-set/Delete the ban mask so that users cannot access
E-set/Delete the exception mask to overwrite the ban mask;
I-set/Delete the invitation mask to overwrite the invite-only flag;
Unless otherwise stated below, all these statuses can be used by the channel Administrator through the mode command.
The command is defined in IRC client Protocol [IRC-CLIENT.
4.1 member identity
In this field, the pattern uses the nickname of the channel member as a parameter and affects the privileges granted to the member.
4.1.1 "channel creator" Identity
The '0' mode is used only with the "Secure Channel" and cannot be used by users. The server uses it
ID of the user "channel creator" who creates the channel.
4.1.2 channel administrator status
Mode 'O' is used to change the Administrator identity of a channel member.
4.1.3 privilege to speak
The 'V' mode is used to give the channel member the privilege to speak and revoke the privilege from the member. Has this feature
The authorized user can talk on the adjusted channel. (See section 4.2.3 (moderated channel flag ).
4.2 channel flag
The pattern in this field is used to define the attributes that affect channel management.
4.2.1 anonymous flag
The channel flag 'A' defines an anonymous channel. This means that when a message sent to the channel is
When the server sends a message to a user and it comes from the user, it will be blocked. The source is changed to block messages
To "Anonymous! Anonymous @ anonymous. "(that is, an alias is" anonymous "and the user name is
"Anonymous" users, from hosts called "anonymous ). In this case, the server must disable aliases.
For "anonymous" users. The server cannot send quit to members of other channels for users to leave such channels,
Instead, a part message is generated.
On the channel prefixed with the '&' character, this flag may be converted by the channel administrator, but it is in the character '! 'Before
On the decorated channel, this flag can only be set by the 'Channel creators '(but cannot be set ). This flag is of another type
.
The reply to the WHOIS, WHO, and names commands on the channel that has been set with the anonymous flag cannot indicate other
User.
4.2.2 invite only flag
When the channel flag 'I' is set, new members only need to match their mask with the invitation list (see section 4.3.2
Or they have been invited by the channel administrator. This flag also limits the use of the invite command for the channel administrator.
(See IRC client Protocol [IRC-CLIENT].
4.2.3 channel adjusted flag
The channel flag 'M' is used to control who can speak on the channel. When it is set, only the channel administrator, and
A member authorized to speak can send messages to other channels.
This flag only affects users.
4.2.4 non-channel customers are not allowed to send messages to the Channel
When the channel flag 'n' is set, only channel members can send messages to the channel.
This flag only affects users.
4.2.5 quiet passage
The channel flag 'q' is only used by the server. When set, it limits the data about channel Operations sent to users.
Type: other users join, leave, and important changes are not sent. From the user's point of view, the channel only contains one
User.
This is often used to create a special local channel in which the server sends notifications related to its operations. It acts as
A more efficient and flexible method can be used to replace the user State defined in RFC 1459 [IRC '.
4.2.6 private and secret channels
The channel flag 'P' is used to indicate that a channel is private, and the channel flag 's' is used to indicate that a channel is secret.
Password. The two are similar in nature. They all hide the existence of the channel from other users.
This means there is no way to get the channel name from the server if it is not enough. In other words, the WHOIS command
The answer to the question must be omitted.
When a channel is 'secret ', in addition to the above restrictions, the query for topics, lists, and names commands,
The server must behave like a channel does not exist. The preceding rule has only one exception: the server correctly replies to the mode.
Command. Finally, when the <mask> parameter is specified, the private channel is not responsible for replying to the lusers command (see "Internet Relay
Chat: client Protocol [IRC-CLIENT]).
The channel flag 'p' and 's' cannot be set at the same time. If the 'p' flag is set for the server mode message and the channel has been
After setting 's', this change will be ignored quietly. This can only happen during the disconnection recovery period. (In "irc
Server Protocol ).
4.2.7 server reop flag
The channel flag 'R' is only available for channels whose names start with 'S', and may only be available for the 'Channel
To convert.
This flag is used to prevent a channel from being in a State without a channel administrator for a long time. When this flag is set, any loss of it
All channels whose administrators are longer than 'reop latencies 'will trigger a mechanism in the pushing server.
Some or all users are reset as administrators. This mechanism is described in more detail in section 5.2.4 (Channel reop mechanism ).
4.2.8 topic
The channel flag 't' is used to restrict the use of the channel administrator topic command.
4.2.9 User restrictions
You can use the channel flag 'l' to set a User restriction on the channel. When the limit is reached, the server must
Prohibit local users from joining the channel.
The limit value can be obtained from the server's reply to the mode query.
4.3 Channel Access Control
The last domain of the status is used to control channel access. They use a mask as a parameter.
To reduce the size of the entire database that controls the access status set for the channel, the server may add
The upper limit. If you want to add this restriction, it must only affect user requests. This restriction applies to each IRC
The network should be similar.
4.3.1 channel bans and exceptions
When a user requests to join a channel, its local server checks whether the user's address and any ban on the channel mask
The request is rejected if the address matches the channel's exception mask.
The server does not allow members prohibited by the channel to speak on the channel, unless the sub-member is the channel administrator or privileged to speak. (Parameter
See section 4.1.3 (speaker privilege )).
The user prohibited by the channel. If it has an invitation from the channel administrator, it is allowed to join the channel.
4.3.2 channel invitation
For those channels set with the invite-only flag, any user, as long as its address and channel invitation mask
If they match, they are allowed to join the channel, even if they are not invited.
5. Current implementation
Currently, the only implementation of these rules as part of the IRC protocol is the IRC server version 2.10.
This part of other content involves things that are especially important to those who want to implement the server, but there are also some parts
It is useful to client program authors.
5.1 track recently used Channels
This mechanism is generally called "channel latency" and is usually used for the channel with the prefix '#' (see section 3.1
("Standard channel ").
When a network disconnection occurs, the server must track which channels have lost a 'Channel Postmaster 'due to the disconnection '. This
Some channels are then in a special State and continue for a period of time. In this special status, the channel cannot be stopped.
To survive. If all the channel members leave, the channel becomes inaccessible: as long as it is empty, the local customer
Users cannot join.
Once a channel is not available, when a remote user joins the channel (most likely because the network is being restored) or delays
When the period expires (in this case, the channel stops and may be re-created), it will become available. Channel death push
There are many factors to consider when setting a delay, including the size of the IRC network and the duration of the network disconnection. Pair
For a given IRC network, the time should be the same on all servers.
5.2 Security Channel
This document introduces the concept of "Secure Channel. These channels are prefixed with characters '! ', And do your best to avoid
Conflicts in the namespace are not allowed. Conflicts are not impossible, but generally do not occur.
5.2.1 channel identifier
Channel identifier is a function of time. The current time is converted to a string of five characters
"Abcdefghijklmnopqrstuvwxyz1234567890" as the base (each character has a ten
Hexadecimal value, 'A' corresponds to 0 to '0' corresponds to 35 ).
Therefore, the channel identifier cycle is 36 ^ 5 seconds (about 700 days)
5.2.2 channel delay
These channels must follow the channel delay mechanism described in section 5.1. However, this mechanism is slightly modified.
To run better.
The server must track the channels that lose members due to network disconnection, regardless of whether the lost user is a 'Channel Postmaster '.
However, these channels are never accessible, even if they are empty.
5.2.3 abuse window
Because the cycle is so long, it takes a long time to attack a specific channel. However, if
If you are lucky and patient, the user may still cause channel conflicts. The server must
In the long run, maintain a list of channel names. The identifiers of these names will be used in the future (for example
Days ). Such a list should maintain a small scale and should not be a burden for servers to maintain. These lists are used in
Avoid re-creation of the same channel for a period longer than the channel delay.
The last server program may choose to expand this program to prohibit the creation of channels with the same short name (and then ignore
Channel identifier ).
5.2.4 keep the name space normal
The combination of 5.2.2 and 5.2.3 described mechanisms makes it difficult for users to conflict with the channel. However
Another form of abuse is to create many channels with the same short name but different identifiers. To prevent
If the short name of the channel is the same as that of the existing channel, the server must disable the channel creation.
5.2.5 server reop Mechanism
When the opening time of a channel is longer than the 'reop latencies 'and the channel is set with the 'R' flag (see
4.2.7 (server reop mark), the IRC server has the responsibility to randomly assign the channel administrator status to some Members.
The following describes the logic used for this mechanism in the current implementation. The server may use different logic, but it is strongly
We recommend that all servers on an IRC network use the same logic to ensure consistency and fairness. Phase-based
For the same reason, for a given IRC network, the value of "reop latency" should be consistent across all hosts. Same
Similar to channel latency, many factors should also be taken into account when setting the reop latency value, including the size of the IRC network
The duration of a network disconnection.
A) The reop mechanism expires after the "reop delay" period and is triggered after a random period of time. In this way, this mechanism can be restricted in
The possibility of simultaneous triggering on two separated servers.
B) if the channel size is small (five or fewer users) and the channel's "channel delay" has expired,
If at least one member is local to the server, the Administrator is reset for all users.
C) if the channel size is small (five or fewer users), and the channel's "channel delay" has expired
Full, "reop delay" has expired. Then, the Administrator is reset for all users.
D) In other cases, at most one member of the channel is reset to the Administrator, based on the built-in server method.
If you do not reset a member to the Administrator, the built-in method should be that another server may
The user is set as the administrator. This method should be the same across the network. A good heuristic method is
Reset the administrator.
(The current implementation is actually trying to select a local member of the server. If this member is not idle for too long
So that other servers have the opportunity to find a member that is not too idle. This is too complex
Miscellaneous, because the server only knows the idle time of the local user)
6. Current Problems
Some problems with IRC channel management have been identified. There are some rules that can be directly attributed to the definition in this document.
The other is the result of the underlying "IRC server protocol. Although it comes from RFC 1459 [IRC], this document
Try to propose some new methods to solve some known problems.
6.1 flag
This document defines one of the many logos used by the IRC protocol. Although there are many different namespaces
Channel name prefix), but they cannot be reused internally. Currently, users on different servers may use the same
The identifier that can cause a conflict (except for a channel that only one server knows, which can prevent a conflict ).
6.1.1 channel delay
Part 1 describes the channel delay mechanism used by the channel whose prefix is '#' (tracking the channel delay mechanism that has been used recently
Channel) is a simple attempt to prevent conflicts. Experience shows that it is very effective in general; however
Obviously, it has many limitations so that it cannot solve the problems discussed here.
6.1.2 Security Channel
The "Security Channel" described in section 3.2 (Security Channel) is a good way to prevent conflicts, because
It prevents users from having full control over the logo they select. The obvious disadvantage of this sign is that they are unfriendly to users. However
Yes. It is quite tedious to improve the client.
6.2 status propagation delay
The latency caused by the network and the correctness of the status changes required by each server (for example, the user has
And has the appropriate privileges). Sometimes, a State information only affects some networks, and the information about the channel status on the server is often used.
There is a difference.
Although this problem seems easy to correct (by checking the source server for the correctness of the status change), there are various reasons
It is up to you to decide not to do so. One worry is that the servers cannot trust each other, so that the servers with errors are easy to detect.
This prevents the channel from being greatly affected by the state information not synchronized from all directions.
6.3 conflict and channel status
The Internet Relay Chat: Server protocol document [IRC-SERVER] describes when two servers are connected
How data is exchanged. Channel conflicts (whether reasonable or unreasonable) are considered internal events, meaning
The participating channels give priority to channel members.
Similarly, each server sends the channel status to other servers. Therefore, each server also receives these channels
Status. There are three modes for a given channel: Flag, mask, and data. The first two are easy to handle because they either
Set or not. If this mode is set on the server, it must be in another service due to the connection.
Also set.
Because topics are not sent as part of the exchange, they are not a problem. However, the channel modes 'l' and 'K'
If they are set on both servers before the connection, there is no mechanism to determine the two values.
That takes priority. Leave it to the user to adjust the resulting differences.
6.4 Resource Depletion
Part 1 defines a mask-based model that makes it easy for IRC servers (and networks) to abuse the system rashly: 1
Channel administrators can set as many masks as possible on a channel. This can easily cause the server to waste memory.
And network bandwidth (because the information is transmitted to other servers ). For this reason, we recommend that you
Limit the number of masks that can be set for each channel.
In addition, there may be more complex mechanisms to avoid additional masks for the same channel.
7. security considerations
7.1 Access Control
One of the most important ways to control access to the channel is to use a mask, which is based on the user name connected to the user.
And host name. Only the IRC server has a precise method to identify user connections, and the user cannot easily escape
This mechanism is efficient and secure only when such authentication is avoided. Although theoretically it is possible to implement such a strict identification Machine
But most IRC networks (especially public networks) do not have such mechanisms and
The accuracy of the user name and host name is rarely guaranteed.
Another way to control access is to use the channel key. However, because the key is sent in plain text
It is vulnerable to attacks.
7.2 channel secrets
Because channel conflicts are considered as internal events (see section 6.3), users may go beyond the access control settings.
Add a channel. This method has been used by individuals for a long time to "control" the channel by illegally obtaining the channel administrator status.
The same method can be used to find the precise member list of the channel and receive many messages sent to the channel.
7.3 Anonymous
The anonymous channel flag (see section 4.2.1) can be used to present "anonymous" to all users on such channels.
The method is to make all messages sent to this channel come from a fake user named "anonymous. This is in the customer
The user-server level does not provide anonymity at the server-server level.
It should be obvious to the reader that the level provided anonymously is very low and insecure, and the customer program should add such
The channel user provides a severe warning.
8. Current support and access channels
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. Thanks
Parts of this document were copied from the RFC 1459 [IRC] Which
First formally authorized ented the IRC protocol. It has also benefited
From role rounds of review and comments. In particle,
Following people have made significant contributions to this
Document:

Matthew green, Michael norayer, Volker Paulsen, Kurt roeckx, VESA
Ruokonen, Magnus tjernstrom, Stefan zehl.
10. References
[Keywords] bradner, S., "key words for use in rfcs to indicate
Requirement Levels ", BCP 14, RFC 2119, March 1997.
[IRC] oikarinen, J. and D. Reed, "Internet Relay Chat
Protocol ", RFC 1459, May 1993.
[IRC-ARCH] kalt, C., "Internet Relay Chat: Architecture", RFC 2810,
Else l 2000.
[IRC-CLIENT] kalt, C., "Internet Relay Chat: client protocol", RFC
2812, 10000l 2000.
[IRC-SERVER] kalt, C., "Internet Relay Chat: Server Protocol", RFC
2813, 10000l 2000.
11. Author's address
Christophe kalt
99 Teaneck Rd, Apt #117
Ridgefield Park, NJ 07660
USA

Email: kalt@stealth.net

RFC2811-Internet relay chat: client Protocol Internet delayed conversation: Channel Management