Network Working Group C. Kalt
Request for Comments: 2811 April 2000
Updates: 1459
Category: Informational
Internet Relay Chat: Channel Management
Status of this Memo
このメモの位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（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（インターネットリレーチャット）プロトコルの最も顕著な特徴の一つは、ユーザーが複数のユーザーが互いに通信するための平均値を提供する、フォーラムと呼ばれるチャネルにグループ化することを可能にすることです。
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
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.
チャネルは、すべてそのチャネルに宛てたメッセージを受信する1人以上のユーザの名前付きグループです。チャネルは、その名称、特性および現在のメンバーによって特徴付けられます。
Channels names are strings (beginning with a '&', '#', '+' or '!' character) of length up to fifty (50) characters. Channel names are case insensitive.
チャンネル名は、50（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 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ネットワーク上の1つ以上のサーバによって知られています。ユーザは、ユーザが直接接続されたサーバによって知られているチャンネルのメンバーになることができます。メッセージは、すべてのチャネルメンバーに送信するチャネルに対処するために、特定のチャネルの存在を知っているサーバーのリストが順番に、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つ（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].
チャネルマスクがあればマスクは地元や近隣のサーバー名の両方に一致する場合、そのチャネルは、チャネル上のローカルユーザーを持っているサーバーへ、そしてその隣に知らなければなりません。他のサーバは、そのようなチャネルの存在を全く知識を持たないので、マスクと一致する名前を持つサーバによって形成される領域は、全てのこれらのサーバによって知られるようにチャネルのための連続しなければなりません。チャンネルマスクは、最適なサーバのhostmasking [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
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.
所与のチャネル上に（また、「チョップ」または「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).
それは、チャネルに関連付けられているときはいつでもチャネルのオペレータは、そのニックネームの横に「@」記号によって識別される（すなわち、名前、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.
キャラクターとのチャネルを作成したユーザー「！」接頭辞として「チャンネルクリエータ」として識別されます。チャネルの作成時に、このユーザーは、チャンネルオペレータのステータスを与えられています。
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.
「チャネルの作成者は、」適切なMODEコマンドを発行することにより、チャンネルオペレータと区別することができます。このトピックの詳細については、「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つのサーバー間のスプリットでばらばらになったとき）の作成を避けるために、チャンネル名はチャンネルオペレータが（セクション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つの文字からなるチャンネル識別子とユーザ提供名を付加します。この2つの要素の組合せから生じるチャンネル名は、ネットワーク分割に基づく人権侵害から安全なチャネルを作る、ユニークです。
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;
a - toggle the anonymous channel flag;
i - toggle the invite-only channel flag;
m - toggle the moderated channel;
n - toggle the no messages to channel from clients on the
outside;
q - toggle the quiet channel flag;
p - toggle the private channel flag;
s - toggle the secret channel flag;
r - toggle the server reop channel flag;
t - toggle the topic settable by channel operator only flag;
k - set/remove the channel key (password);
l - set/remove the user limit to channel;
b - set/remove ban mask to keep users out;
e - set/remove an exception mask to override a ban mask;
I - set/remove an invitation mask to automatically override
the invite-only flag;
Unless mentioned otherwise below, all these modes can be manipulated by "channel operators" by using the MODE command defined in "IRC Client Protocol" [IRC-CLIENT].
そうでなければ下記のない限り、すべてのこれらのモードは、「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.
チャンネルフラグが '匿名チャネルを画定します。これは、チャネルに送信されたメッセージがユーザーにサーバーによって送信され、起源がユーザーである場合は、それがマスクされなければならないことを意味しています。メッセージをマスクするには、起源に変更され、「匿名！匿名@匿名の。」 （例えば、ニックネーム「匿名」、ユーザ名「匿名」と呼ばれるホストから「匿名」を持つユーザ）。このため、サーバーは、ニックネームは「匿名」を使用してからユーザーを禁止しなければなりません。サーバーは、ユーザーが他のチャネルのメンバーに、このようなチャンネルを残すために、メッセージをQUIT送信しないが、代わりにPARTメッセージを発生させなければなりません。
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への回答、および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.
「私は」チャンネルフラグが設定されている場合は、新しいメンバーはマスク一致が招待リストを場合（セクション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]で定義されたユーザモード「s」を交換するより効率的かつ柔軟な方法として使用しました。
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.
チャンネルは、上記の制限に加えて、「秘密」である場合には、チャネルがTOPICようなクエリ、LIST、NAMESコマンドには存在しないかのように、サーバが動作します。この規則には例外があることに注意してください：サーバが正しくMODEコマンドに返信させていただきます。最後に、秘密のチャネルが（参照「インターネットリレーチャット：クライアントプロトコル」[IRC-CLIENT]）LUSERSコマンドへの応答には計上されていない<マスク>パラメータが指定されています。
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」は、両方を同時に設定してはいけません。サーバから発信MODEメッセージはフラグ「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遅延」期間よりも長く、そのすべてのチャネルの演算子を失ったすべてのチャネルは、チャネル住民の一部または全部をREOPするサーバ内のメカニズムをトリガします。このメカニズムは、セクション5.2.4（チャンネルREOP機構）においてより詳細に記載されています。
The channel flag 't' is used to restrict the usage of the TOPIC command to channel operators.
チャンネルフラグ「t」は、チャネルオペレータにトピックコマンドの使用を制限するために使用されます。
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.
限界の値は、MODEクエリにサーバーによって送信された応答でチャネルメンバーに利用可能にしなければなりません。
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.
チャンネルキーはMODEクエリにサーバーから送信された応答のチャネルメンバーに見えるようにしなければなりません。
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.
ユーザー要求がチャンネルに参加したとき、彼のローカルサーバーのチェックはユーザーのアドレスは、チャンネルに設定禁止マスクのいずれかに一致する場合。一致が見つかった場合はアドレスもチャネルの例外マスクセットと一致しない限り、ユーザの要求は拒否されます。
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').
チャンネル識別子は、時間の関数です。 「ABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890」（各文字があります。現在の時刻は（00:00:00 GMT、1970年1月1日からの経過秒数でUNIXの下で定義される）以下のベースを使用して5（5）文字の文字列に変換され、 「0」）35に「A」を0から始まる小数値。
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.
チャンネルが（4.2.7（サーバーREOPフラグ）を参照してください）「REOP遅延」期間よりも長くoplessされていると設定されたチャネルフラグは「r」がありました場合には、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遅延」の有効期限以下のランダムな時間の後にトリガされます。これは、2台の別個のサーバー上（同じチャネル用）が同時にトリガされる機構の不測の事態を制限すべきです。
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（5）ユーザー以下）に小さく、このチャネルの「チャネル遅延」が満了した場合は、すべてのチャネルメンバーをREOP。
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（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最大1人のメンバーは、サーバーに組み込みます。あなたはメンバーをREOPない場合は、この方法は、別のサーバーはおそらくOP誰かするようなものでなければなりません。この方法は、ネットワーク全体にわたり同じである必要があります。良いヒューリスティックは、単にランダム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]の結果である一方、これらのいくつかは、直接、この文書で定義されたルールに起因することができます。 RFC 1459 [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プロトコルで使用される多くのラベルの1つを定義します。 （チャンネル名プレフィックスに基づいて）いくつかの異なる名前空間が存在するが、これらの各内部重複は許可されません。異なるサーバー上のユーザーが（彼らは回避することができる唯一つのサーバに知られているチャンネルを除く）の衝突をもたらすことができるラベルを選択するために、現在、それが可能です。
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 is very efficient; however, it obviously has severe limitations keeping it from being an adequate solution to the problem discussed here.
セクション5.1（トラッキング最近使用されるチャネル）に記載され、「＃」文字が付いチャネルに使用されるチャネル遅延機構が起きてからの衝突を防止するに簡単試みです。経験は、通常の状況下で、それは非常に効率的であることが示されています。しかし、それは明らかにここで議論し、問題への適切な解決策であることから、それを維持する厳しい制限があります。
"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.
そのためネットワークによって誘導されたネットワーク遅延の、パス上の各サーバーは、モード変更（例えば、ユーザーが権利権限を存在している）の有効性を確認するために必要とされるため、MODEメッセージのみの部分に影響を与えるようにするために、それは珍しいことではありませんネットワークは、多くの場合、チャネルの現在の状態のサーバ間の不一致を作成します。
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.
「インターネットリレーチャット：サーバプロトコル」ドキュメント[IRC-SERVER]は2台のサーバーが相互に接続したときにチャネルデータを交換する方法について説明します。 （正当かどうかのどちらか）チャンネルの衝突は、得られたチャネルは会員接続する前に、いずれかのサーバ上のチャンネルのメンバーであるすべてのユーザーのために持っていることを意味し、包括的なイベントとして扱われます。
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.
同様に、各サーバは、他のいずれかのチャネルモードを送信します。したがって、各サーバは、これらのチャネルモードを受信します。フラグ、マスク、およびデータ：各チャネルのモードの3つのタイプがあります。最初の2つのタイプは、彼らがいずれかの設定または設定解除されているように対処するのは簡単です。そのようなモードは、1台のサーバー上で設定されている場合は、接続の結果として、他のサーバ上で設定しなければなりません。
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
Software implementations: ftp://ftp.irc.org/irc/server ftp://ftp.funet.fi/pub/unix/irc ftp://coombs.anu.edu.au/pub/irc
ソフトウェアの実装：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:
この文書の部分は、第一正式IRCプロトコルを文書RFC 1459 [IRC]からコピーされました。また、レビューやコメントの多くのラウンドの恩恵を受けています。具体的には、以下の人々は、このドキュメントへの重要な貢献をしました。
Matthew Green, Michael Neumayer, Volker Paulsen, Kurt Roeckx, Vesa Ruokonen, Magnus Tjernstrom, Stefan Zehl.
マシュー・グリーン、ミヒャエル・ノイマイアー、フォルカー・ポールセン、クルトRoeckx、のVesa Ruokonen、マグナスTjernström、ステファンZehl。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[キーワード]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[IRC] Oikarinen, J. and D. Reed, "Internet Relay Chat Protocol", RFC 1459, May 1993.
[IRC] Oikarinen、J.とD.リード、 "インターネットリレーチャットプロトコル"、RFC 1459、1993年5月。
[IRC-ARCH] Kalt, C., "Internet Relay Chat: Architecture", RFC 2810, April 2000.
[IRC-ARCH] Kalt、C.、 "インターネットリレーチャット：アーキテクチャ"、RFC 2810、2000年4月。
[IRC-CLIENT] Kalt, C., "Internet Relay Chat: Client Protocol", RFC 2812, April 2000.
[IRC-CLIENT] Kalt、C.、 "インターネットリレーチャット：クライアントプロトコル"、RFC 2812、2000年4月。
[IRC-SERVER] Kalt, C., "Internet Relay Chat: Server Protocol", RFC 2813, April 2000.
[IRC-SERVER] Kalt、C.、 "インターネットリレーチャット：サーバプロトコル"、RFC 2813、2000年4月。
Christophe Kalt 99 Teaneck Rd, Apt #117 Ridgefield Park, NJ 07660 USA
クリストフKalt 99ティーネックRdを、アプト＃117リッジフィールドパーク、ニュージャージー州07660米国
EMail: kalt@stealth.net
メールアドレス：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 Editor機能のための基金は現在、インターネット協会によって提供されます。