Network Working Group C. Kalt
Request for Comments: 2811 April 2000
Updates: 1459
Category: Informational
Network Working Group C. Kalt
Request for Comments: 2811 April 2000
Updates: 1459
Category: Informational
Internet Relay Chat: Channel Management
Internet中继聊天：频道管理
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.
版权所有（C）互联网协会（2000年）。版权所有。
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.
IRC（Internet中继聊天）协议最显著的特点之一是允许用户在论坛中分组，称为频道，为多个用户提供一种共同通信的方式。
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.
本文档指定IRC服务器如何管理通道及其特性和属性。
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
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
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
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
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.
本文档详细定义了IRC服务器如何管理通道，对致力于实现IRC服务器的人员非常有用。
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.
虽然这里定义的概念是IRC的重要组成部分，但它们对于实现客户机仍然不是必需的。虽然趋势似乎是越来越复杂和“智能”的客户端，它们能够利用了解通道的内部工作原理为用户提供更友好的界面，但简单的客户端可以在不阅读本文档的情况下实现。
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.
这里定义的许多概念都是在考虑IRC体系结构[IRC-ARCH]的情况下设计的，并且在这种情况下基本上是有意义的。然而，许多其他架构可以应用于其他架构，以便为会议系统提供论坛。
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).
最后，需要注意的是，IRC用户可以找到以下感兴趣的部分，特别是第2部分（信道特性）和第4部分（信道模式）。
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.
通道是一个由一个或多个用户组成的命名组，所有用户都将接收发往该通道的消息。通道以其名称、属性和当前成员为特征。
Channels names are strings (beginning with a '&', '#', '+' or '!' character) of length up to fifty (50) characters. Channel names are case insensitive.
频道名称是长度不超过五十（50）个字符的字符串（以'&'、'#'、'+'或'！'字符开头）。通道名称不区分大小写。
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].
除了要求第一个字符为“&”、“#”、“+”或“！”之外（以下称为“信道前缀”）。通道名称的唯一限制是，它不应包含任何空格（“”）、控件G（^G或ASCII 7）、逗号（“，”，协议将其用作列表项分隔符）。此外，冒号（“：”）用作通道掩码的分隔符。频道名称的确切语法在“IRC服务器协议”[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.
使用不同的前缀可以有效地为通道名称创建四（4）个不同的名称空间。这一点很重要，因为有关名称空间的协议限制（通常）。有关这些限制的更多详细信息，请参见第6.1节（标签）。
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
IRC网络上的一个或多个服务器知道通道实体。用户只能成为该用户直接连接到的服务器已知的通道的成员。知道的服务器列表
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.
特定信道的存在必须是IRC网络的一个连续部分，以便发送到该信道的消息到所有信道成员。
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:
连接到网络的一（1）个或多个服务器知道其他通道，具体取决于通道掩码：
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].
如果存在通道掩码，则只有在通道上有本地用户的服务器才能知道该通道，如果掩码与本地和相邻服务器名称都匹配，则其邻居也只能知道该通道。由于其他服务器完全不知道此类通道的存在，因此由具有与掩码匹配的名称的服务器形成的区域必须是连续的，以便所有这些服务器都知道该通道。通道掩码最好与服务器主机掩码[IRC-server]结合使用。
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.
前缀为“+”的通道不支持通道模式。这意味着除设置的“t”通道标志外，所有模式均未设置。
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
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
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.
给定频道上的频道运营商（也称为“chop”或“chanop”）被视为“拥有”该频道。频道的所有权在频道运营商之间共享。
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).
当通道操作员与通道关联时（即回复名称、WHO和WHOIS命令），其昵称旁边的“@”符号将识别通道操作员。
Since channels starting with the character '+' as prefix do not support channel modes, no member can therefore have the status of channel operator.
由于以字符“+”开头的通道不支持通道模式，因此任何成员都不能具有通道操作员的状态。
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.
使用字符“！”创建频道的用户as前缀被标识为“频道创建者”。创建频道后，该用户还将获得频道操作员状态。
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.
通过发出适当的模式命令，可以将“频道创建者”与频道操作员区分开来。有关此主题的更多信息，请参阅“IRC客户端协议”[IRC-Client]。
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 '!'.
关于通道的寿命，通常有两组通道：前缀为“&”、“#”或“+”的标准通道和前缀为“！”的“安全通道”。
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.
创建频道的用户自动成为频道操作员，但频道名称前缀为“+”的明显例外，请参见第4节（频道模式）。有关此标题的更多详细信息，请参见第2.4.1节（频道运营商）。
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".
为了避免创建重复通道（通常当IRC网络因两台服务器之间的拆分而变得不相交时），如果通道运营商（见第2.4.1节（通道运营商））最近因网络拆分而离开通道，则用户不应允许重新使用通道名称。如果发生这种情况，通道名称将暂时不可用。频道不可用的持续时间应根据每个IRC网络进行调整。请务必注意，这会阻止本地用户使用相同的名称创建通道，但不会阻止远程用户重新创建通道。后者通常在IRC网络重新连接时发生。显然，此机制仅适用于名称以字符“#”开头的频道，但也可用于名称以字符“+”开头的频道。这种机制通常被称为“信道延迟”。
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.
与其他通道不同，“安全通道”不是隐式创建的。希望创建此类频道的用户必须通过向服务器发送特殊的JOIN命令来请求创建，在该服务器中，频道标识符（当时未知）被替换为字符“！”。此类通道的创建过程受到严格控制。用户仅选择频道名称的一部分（称为频道“短名称”），服务器会自动在用户提供的名称前加上由五（5）个字符组成的频道标识符。由这两个元素组合而成的频道名称是唯一的，使该频道免受基于网络拆分的滥用。
The user who creates such a channel automatically becomes "channel creator". See section 2.4.2 (Channel Creator) for more details on this title.
创建此类频道的用户将自动成为“频道创建者”。有关此标题的更多详细信息，请参见第2.4.2节（频道创建者）。
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".
与第5.2.2节（信道延迟）中描述的机制不同，在这种情况下，信道名称不会变得不可用：在最后一个用户离开后，这些信道可能会继续存在。只有创建频道的用户才成为“频道创建者”，加入现有空频道的用户不会自动成为“频道创建者”或“频道运营商”。
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).
为确保通道名称的唯一性，服务器创建的通道标识符必须遵循特定规则。有关这方面的更多详细信息，请参阅第5.2.1节（通道标识符）。
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;
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;
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;
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;
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].
除非下文另有说明，否则所有这些模式均可由“通道操作员”通过使用“IRC客户端协议”[IRC-Client]中定义的MODE命令进行操作。
The modes in this category take a channel member nickname as argument and affect the privileges given to this user.
此类别中的模式将频道成员昵称作为参数，并影响授予此用户的权限。
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".
模式“O”仅与“安全通道”一起使用，用户不得操纵。服务器使用它为创建频道的用户提供“频道创建者”的状态。
The mode 'o' is used to toggle the operator status of a channel member.
模式“o”用于切换通道成员的操作员状态。
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).
模式“v”用于向频道成员授予或从频道成员获取语音权限。具有此权限的用户可以在主持的频道上讲话。（见第4.2.3节（慢化通道标志）。
The modes in this category are used to define properties which affects how channels operate.
此类别中的模式用于定义影响通道运行方式的特性。
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.
通道标志“a”定义匿名通道。这意味着，当发送到通道的消息由服务器发送给用户，并且源是用户时，必须对其进行屏蔽。要屏蔽邮件，源代码将更改为“匿名！anonymous@anonymous.“（例如，昵称为“anonymous”、用户名为“anonymous”且来自名为“anonymous”的主机的用户。）。因此，服务器必须禁止用户使用昵称“匿名”。服务器也不能为离开此类通道的用户向其他通道成员发送退出消息，而是生成部分消息。
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.
对WHOIS、WHO和NAMES命令的答复不得显示设置了匿名标志的频道上存在其他用户。
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.
设置频道标志“i”时，仅当新成员的掩码与邀请列表匹配（见第4.3.2节）或已被频道运营商邀请时，才接受新成员。此标志还限制频道操作员使用INVITE命令（请参阅“IRC客户端协议”[IRC-Client]）。
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.
频道标志“m”用于控制谁可以在频道上讲话。设置后，只有频道运营商和获得语音权限的成员才能向频道发送消息。
This flag only affects users.
此标志仅影响用户。
When the channel flag 'n' is set, only channel members MAY send messages to the channel.
设置通道标志“n”时，只有通道成员可以向通道发送消息。
This flag only affects users.
此标志仅影响用户。
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.
通道标志“q”仅供服务器使用。设置后，它将限制发送给用户的有关通道操作的数据类型：不发送其他用户连接、部件和尼克更改。从用户的角度来看，频道只包含一个用户。
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].
这通常用于创建特殊的本地通道，服务器在该通道上发送与其操作相关的通知。这被用作一种更有效、更灵活的方式来取代RFC 1459[IRC]中定义的用户模式。
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.
通道标志“p”用于标记通道“专用”，通道标志“s”用于标记通道“机密”。这两个属性相似，对其他用户隐藏通道的存在。
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.
这意味着如果不是成员，就无法从服务器获取此频道的名称。换句话说，这些通道必须从WHOIS命令之类的查询回复中省略。
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.
当通道为“机密”时，除了上述限制外，服务器还将在主题、列表、名称命令等查询中充当通道不存在的角色。请注意，此规则有一个例外：服务器将正确响应MODE命令。最后，当指定<mask>参数时，在对LUSERS命令的回复中不考虑秘密通道（请参阅“Internet中继聊天：客户端协议”[IRC-Client]）。
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]).
通道标志“p”和“s”不能同时设置。如果源于服务器的模式消息设置了标志“p”，并且已经为通道设置了标志“s”，则更改将被静默忽略。这只应发生在分割修复阶段（在“IRC服务器协议”文档[IRC-Server]中提到）。
The channel flag 'r' is only available on channels which name begins with the character '!' and MAY only be toggled by the "channel creator".
频道标志“r”仅在名称以字符“！”开头的频道上可用并且只能由“频道创建者”进行切换。
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).
此标志用于防止通道在较长时间内没有通道操作员。设置此标志时，任何丢失其所有通道运算符的通道超过“reop delay”（reop延迟）时间都会触发服务器中的机制，以reop部分或全部通道居民。第5.2.4节（通道Reop机制）对该机制进行了更详细的描述。
The channel flag 't' is used to restrict the usage of the TOPIC command to channel operators.
通道标志“t”用于限制通道操作员使用TOPIC命令。
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.
可以使用通道标志“l”在通道上设置用户限制。当达到限制时，服务器必须禁止其本地用户加入通道。
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.
在服务器发送给模式查询的回复中，限制值必须仅对通道成员可用。
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.
设置频道密钥（通过使用模式“k”）时，服务器必须拒绝其本地用户加入频道的请求，除非提供了此密钥。
The channel key MUST only be made visible to the channel members in the reply sent by the server to a MODE query.
在服务器发送给模式查询的回复中，通道密钥必须仅对通道成员可见。
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 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.
为了减小为通道设置的控制访问模式的全局数据库的大小，服务器可以对为特定通道设置的此类模式的数量设置最大限制。如果施加此类限制，则只能影响用户请求。每个IRC网络的限值应相同。
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.
当用户请求加入某个频道时，其本地服务器会检查该用户的地址是否与为该频道设置的任何ban掩码匹配。如果找到匹配项，则拒绝用户请求，除非地址也与通道的异常掩码集匹配。
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)).
服务器不得允许被禁止进入频道的频道成员在频道上讲话，除非该成员是频道运营商或具有语音权限。（见第4.1.3节（语音权限））。
A user who is banned from a channel and who carries an invitation sent by a channel operator is allowed to join the channel.
被禁止进入频道并携带频道运营商发送的邀请的用户可以加入频道。
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.
对于设置了仅邀请标志的频道（请参见第4.2.2节（仅邀请标志）），其地址与频道的邀请掩码设置匹配的用户可以在没有任何邀请的情况下加入频道。
The only current implementation of these rules as part of the IRC protocol is the IRC server, version 2.10.
作为IRC协议一部分的这些规则的当前唯一实现是IRC服务器，版本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.
本节的其余部分将讨论对那些希望实现服务器的人来说最重要的问题，但客户机编写人员可能也会对某些部分感兴趣。
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").
这种机制通常称为“信道延迟”，通常仅适用于名称前缀为字符“#”的信道（参见第3.1节“标准信道”）。
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
当发生网络拆分时，服务器应跟踪哪些频道因中断而失去了“频道运营商”。然后，这些通道处于一种特殊状态，持续一段时间。在此特定状态下，通道不能停止运行
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.
设置信道死亡延迟的持续时间时，应考虑许多因素，其中包括IRC网络的大小（用户方面）和通常的网络分裂持续时间。对于给定的IRC网络，它在所有服务器上都应该是统一的。
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.
本文件介绍了“安全通道”的概念。这些频道的名称前缀为字符“！”为了避免在这个名称空间中发生冲突，我们付出了巨大的努力。碰撞并非不可能，但可能性很小。
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').
通道标识符是时间的函数。当前时间（在UNIX下定义为自1970年1月1日格林尼治标准时间00:00:00以来经过的秒数）转换为五（5）个字符的字符串，使用以下基数：“ABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890”（每个字符的十进制值从“a”的0到“0”的35）。
The channel identifier therefore has a periodicity of 36^5 seconds (about 700 days).
因此，通道标识符的周期为36^5秒（约700天）。
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.
这些通道必须遵守第5.1节（通道延迟）中所述的“通道延迟”机制。但是，该机构稍微进行了调整，以更好地适应。
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.
但是，这些频道不会变得不可用，即使它们是空的，也始终可以加入它们。
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).
最终，服务器可能会选择扩展此过程，以禁止仅创建具有相同短名称的频道（然后忽略频道标识符）。
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.2节和第5.2.3节中描述的机制组合使得用户很难创建通道冲突。然而，另一种类型的滥用包括创建具有相同短名称但不同标识符的多个频道。为了防止这种情况发生，服务器必须禁止创建与当前存在的频道同名的新频道。
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.
当通道的opless时间超过“reop延迟”时间并且设置了通道标志“r”（参见第4.2.7节（服务器reop标志）），IRC服务器负责将通道操作员状态随机提供给一些成员。
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.
下面描述当前实现用于此机制的确切逻辑。服务器可能使用不同的逻辑，但强烈建议所有服务器在特定IRC网络上使用相同的逻辑，以保持一致性和公平性。出于同样的原因，“reop延迟”在给定IRC网络的所有服务器上应该是一致的。至于“信道延迟”，设置“reop延迟”的值时应考虑许多因素，其中包括IRC网络的大小（用户方面）和通常的网络分裂持续时间。
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.
a) reop机制在“reop延迟”到期后的随机时间后触发。这应该限制在两个单独的服务器上同时（针对同一通道）触发机制的可能性。
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.
b) 如果通道较小（五（5）个用户或更少），且此通道的“通道延迟”已过期，则如果至少有一个成员是服务器本地的，则重新操作所有通道成员。
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.
c) 如果信道很小（五（5）个用户或更少），且该信道的“信道延迟”已过期，且“reop延迟”已过期超过其值，则reop所有信道成员。
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)
d) 对于其他情况，根据服务器中内置的某些方法，reop最多只能在通道上处理一个成员。如果您没有重新操作成员，那么该方法应该是另一台服务器可能会对某人进行操作。整个网络上的方法应相同。一个好的启发式可能只是随机的reop。（当前的实现实际上试图选择一个本地成员，该成员在服务器上没有空闲太久，最终推迟了操作，因此让其他服务器有机会找到一个“不太空闲”的成员。由于服务器只知道其本地用户的“空闲”时间，这太复杂了）
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.
IRC通道的管理方式存在许多公认的问题。其中一些可以直接归因于本文档中定义的规则，而另一些则是基础“IRC服务器协议”[IRC-Server]的结果。虽然源于RFC1459[IRC]，但本文介绍了一些新颖之处，试图解决一些已知问题。
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).
本文档定义了IRC协议使用的众多标签之一。尽管有几个不同的名称空间（基于通道名称前缀），但每个名称空间中都不允许重复。目前，不同服务器上的用户可以选择可能导致冲突的标签（只有一台服务器知道的通道除外，可以避免这些通道）。
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
第5.1节（跟踪最近使用的通道）中描述的通道延迟机制，用于前缀为“#”的通道，是防止发生冲突的简单尝试。经验表明，在正常情况下
is very efficient; however, it obviously has severe limitations keeping it from being an adequate solution to the problem discussed here.
效率很高,；然而，它显然有严重的局限性，无法充分解决这里讨论的问题。
"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.
第3.2节（安全通道）中描述的“安全通道”是防止发生冲突的更好方法，因为它防止用户完全控制他们选择的标签。这种标签的明显缺点是不便于用户使用。然而，客户机程序在这方面进行改进是相当简单的。
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.
虽然这似乎很容易修复（通过仅让原始服务器检查模式更改的有效性），但出于各种原因，决定不这样做。一个问题是，服务器之间不能相互信任，并且很容易检测到行为不正常的服务器。这样做的方式还可以阻止当从不同方向发出模式更改时，通道上不同步的波浪效应。
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.
“Internet中继聊天：服务器协议”文档[IRC-Server]描述了两台服务器相互连接时如何交换通道数据。通道冲突（合法或不合法）被视为包含事件，这意味着在连接之前，结果通道的成员是任何一台服务器上的通道成员的所有用户。
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.
类似地，每台服务器将通道模式发送给另一台服务器。因此，每个服务器也接收这些通道模式。给定通道有三种模式：标志、掩码和数据。前两种类型很容易处理，因为它们要么是设置的，要么是未设置的。如果在一台服务器上设置了此模式，则连接后必须在另一台服务器上设置此模式。
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.
由于主题不是作为交换的一部分发送的，因此它们不是问题。但是，通道模式“l”和“k”是交换的，如果在连接之前在两台服务器上都设置了它们，则没有机制来决定这两个值中哪一个优先。由用户自行解决由此产生的差异。
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.
基于第4.3节中定义的掩码的模式使IRC服务器（和网络）容易受到系统简单滥用的影响：单个通道操作员可以在特定通道上设置尽可能多的不同掩码。这很容易导致服务器浪费内存和网络带宽（因为信息会传播到其他服务器）。因此，建议对第4.3节中提到的每个通道的屏蔽数量进行限制。
Moreover, more complex mechanisms MAY be used to avoid having redundant masks set for the same channel.
此外，可以使用更复杂的机制来避免为同一信道设置冗余掩码。
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.
控制通道访问的主要方法之一是使用基于用户连接的用户名和主机名的掩码。只有当IRC服务器具有准确的用户连接身份验证方法，并且用户无法轻松绕过此方法时，此机制才能有效且安全。虽然理论上可以实现这样一种严格的身份验证机制，但大多数IRC网络（尤其是公共网络）都没有类似的机制，并且对于特定客户端连接的用户名和主机名的准确性几乎没有保证。
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.
控制访问的另一种方法是使用信道密钥，但是由于该密钥是明文发送的，所以它容易受到传统的中间人攻击。
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.
由于通道冲突被视为包含性事件（参见第6.3节），因此用户可以加入覆盖其访问控制设置的通道。长期以来，这种方法一直被个人使用，通过“非法”获得频道运营商的地位来“接管”频道。同样的方法也可以用于查找通道成员的确切列表，以及最终接收发送到通道的一些消息。
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.
匿名通道标志（见第4.2.1节）可用于通过向通道显示来自昵称为“匿名”的伪用户的所有消息，使该通道上的所有用户成为“匿名”用户。这是在客户机-服务器级别完成的，在服务器级别不提供匿名性。
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.
读者应该清楚地看到，所提供的匿名性水平非常差，而且不安全，客户应该向加入此类渠道的用户发出强烈警告。
Mailing lists for IRC related discussion:
General discussion: ircd-users@irc.org
Protocol development: ircd-dev@irc.org
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
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
新闻组：alt.irc
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:
本文件的部分内容是从RFC 1459[IRC]中复制的，该文件首先正式记录了IRC协议。它还受益于多轮审查和评论。特别是，以下人员对本文件做出了重大贡献：
Matthew Green, Michael Neumayer, Volker Paulsen, Kurt Roeckx, Vesa Ruokonen, Magnus Tjernstrom, Stefan Zehl.
马修·格林、迈克尔·纽梅尔、沃尔克·保尔森、库尔特·罗克斯、维萨·鲁科宁、马格纳斯·特杰恩斯特罗姆、斯特凡·泽尔。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[关键词]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[IRC] Oikarinen, J. and D. Reed, "Internet Relay Chat Protocol", RFC 1459, May 1993.
[IRC]Oikarinen，J.和D.Reed，“互联网中继聊天协议”，RFC 1459，1993年5月。
[IRC-ARCH] Kalt, C., "Internet Relay Chat: Architecture", RFC 2810, April 2000.
[IRC-ARCH]Kalt，C.，“互联网中继聊天：架构”，RFC 28102000年4月。
[IRC-CLIENT] Kalt, C., "Internet Relay Chat: Client Protocol", RFC 2812, April 2000.
[IRC-CLIENT]Kalt，C.，“互联网中继聊天：客户端协议”，RFC28122000年4月。
[IRC-SERVER] Kalt, C., "Internet Relay Chat: Server Protocol", RFC 2813, April 2000.
[IRC-SERVER]Kalt，C.，“互联网中继聊天：服务器协议”，RFC 28132000年4月。
Christophe Kalt 99 Teaneck Rd, Apt #117 Ridgefield Park, NJ 07660 USA
克里斯托夫·卡尔特美国新泽西州里奇菲尔德公园117号公寓蒂内克路99号，邮编：07660
EMail: kalt@stealth.net
EMail: kalt@stealth.net
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
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.
RFC编辑功能的资金目前由互联网协会提供。