[要約] RFC 2811は、インターネットリレーチャット（IRC）のチャンネル管理に関する仕様です。このRFCの目的は、IRCチャンネルの作成、管理、および制御に関するガイドラインを提供することです。
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.
Copyright（c）The Internet Society（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（インターネットリレーチャット）プロトコルの最も注目すべき特性の1つは、ユーザーをチャネルと呼ばれるフォーラムでグループ化できるようにし、複数のユーザーが一緒に通信する平均を提供することです。
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文字までの文字列です。チャネル名はケースの鈍感です。
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ネットワーク上の1つ以上のサーバーで知られています。ユーザーは、ユーザーが直接接続されているサーバーによって既知のチャネルのメンバーにのみなります。知っているサーバーのリスト
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サーバー]と組み合わせて使用するのが最適です。
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.
'' as prefixを持つチャネルは、チャネルモードをサポートしません。これは、設定された「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.
特定のチャネル上のチャネル演算子（「チョップ」または「チャノップ」とも呼ばれる）は、そのチャネル「独自」と見なされます。チャネルの所有権は、チャネルオペレーター間で共有されます。
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.
Prefixとしての文字 ''から始まるチャネルはチャネルモードをサポートしていないため、メンバーはチャネル演算子のステータスを持つことはできません。
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.
「チャネル作成者」は、適切なモードコマンドを発行することにより、チャネルオペレーターと区別できます。このトピックの詳細については、「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 '!'.
チャネルの寿命に関しては、通常、チャネルには2つのグループがあります。プレフィックスが「＆」、「＃」、「 '」のいずれかの標準チャネルと、プレフィックスが「！」です。
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".
重複したチャネルの作成を回避するために（通常、2つのサーバー間の分割によりIRCネットワークがばらばらになる場合）、チャネルオペレーターの場合、チャネル名をユーザーが再利用することはできません（セクション2.4.1（チャネルを参照）オペレーター））は、ネットワーク分割のために最近チャネルを離れました。これが発生した場合、チャネル名は一時的に利用できません。チャネルが利用できないままの期間は、IRC Networkベースで調整する必要があります。これにより、ローカルユーザーが同じ名前を使用してチャネルを作成することを防ぐことができますが、リモートユーザーによってチャネルが再現されることを妨げないことに注意することが重要です。後者は通常、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.
他のチャネルとは異なり、「セーフチャネル」は暗黙的に作成されていません。このようなチャネルを作成したいユーザーは、チャネル識別子（当時不明）が文字「！」に置き換えられるサーバーに特別な結合コマンドを送信して、作成を要求する必要があります。このタイプのチャネルの作成プロセスは厳密に制御されます。ユーザーはチャンネル名の一部（チャネル「ショート名」と呼ばれる）のみを選択し、サーバーは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]で定義されたモードコマンドを使用して、「チャネル演算子」によって操作できます。
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」は、匿名チャネルを定義します。これは、チャネルに送信されたメッセージがサーバーからユーザーに送信され、Originがユーザーである場合、マスクする必要があることを意味します。メッセージをマスクするために、原点は「Anonymous！Anonymous@Anonymous」に変更されます。（たとえば、ニックネーム「匿名」、ユーザー名「匿名」、「匿名」と呼ばれるホストからのユーザー。）。このため、サーバーはユーザーがニックネーム「匿名」を使用することを禁止する必要があります。また、サーバーは、そのようなチャネルを他のチャネルメンバーに残しているユーザーにQUITメッセージを送信しないでください。代わりにパーツメッセージを生成する必要があります。
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、名前のコマンドへの返信は、匿名フラグが設定されているチャネル上の他のユーザーの存在を明らかにしてはなりません。
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を参照）、またはチャネルオペレーターによって招待されました。このフラグは、招待コマンドの使用（「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」は、サーバーのみで使用されます。設定すると、チャネル操作についてユーザーに送信されるデータのタイプを制限します。他のユーザーが参加し、部品とニックの変更は送信されません。ユーザーの観点から、チャンネルには1人のユーザーのみが含まれています。
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.
上記の制限に加えて、チャネルが「秘密」である場合、サーバーは、トピック、リスト、名前コマンドなどのクエリに対してチャネルが存在しないかのように動作します。このルールには1つの例外があることに注意してください。サーバーはモードコマンドに正しく返信します。最後に、<mask>パラメーターが指定されている場合、secretチャネルは、Lusersコマンドへの返信（「インターネットリレーチャット：クライアントプロトコル」[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).
このフラグは、チャネルが長期間チャネルオペレーターを持たないのを防ぐために使用されます。このフラグが設定されると、すべてのチャネルオペレーターを「再び遅延」期間よりも長く紛失したチャネルは、サーバーのメカニズムをトリガーして、チャネルの住民の一部またはすべてを再度操作します。このメカニズムについては、セクション5.2.4（チャネル再開メカニズム）で詳しく説明します。
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.
制限の値は、サーバーがモードクエリに送信した返信で、チャネルメンバーが利用できるようにする必要があります。
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.
ユーザーがチャネルへの参加を要求すると、彼のローカルサーバーは、ユーザーのアドレスがチャンネルに設定された禁止マスクのいずれかに一致するかどうかを確認します。一致が見つかった場合、アドレスがチャネルの例外マスクセットも一致しない限り、ユーザー要求は拒否されます。
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.
Inviteのみのフラグセット（セクション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').
チャネル識別子は時間の関数です。1970年1月1日、00:00:00 gmt以降に経過した秒数でUnixの下で定義されているように）は、「Abcdefghijklmnopqrstuvwxyz1234567890」を使用して、5人の文字列で変換されます。「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.
周期性は非常に長いため、特定のチャネル（名前）への攻撃は非常に長い間1回しか発生しません。ただし、運と忍耐力があれば、ユーザーがチャンネルの衝突を引き起こすことは依然として可能です。これを回避するために、サーバーは「将来的に見て」、識別子が使用されようとしているチャネル名のリストを保持する必要があります（たとえば、今後数日で）。このようなリストは、サーバーが維持する負担ではなく、チャネルの遅延よりも長期間そのようなチャネルの再作成を防ぐことにより、チャネルの衝突を避けるために使用するために使用されるべきではありません。
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.
チャネルが「再び遅延」期間よりも長くオープレスであり、チャンネルフラグ「R」セット（セクション4.2.7（サーバーリップフラグ）を参照）を持っている場合、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ネットワーク上で同じロジックを使用して、コヒーレンスと公平性を維持することを強くお勧めします。同じ理由で、「再び遅延」は、特定のIRCネットワークのすべてのサーバーで均一でなければなりません。「チャネル遅延」に関しては、「再び遅延」の値を設定する必要があります。その中の多くの要因が、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) 再びメカニズムは、「再び遅延」の有効期限に続いてランダムな時間の後にトリガーされます。これにより、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人以下）、このチャネルの「チャネル遅延」が期限切れになった場合、少なくとも1人のメンバーがサーバーのローカルである場合、すべてのチャネルメンバーを再度操作します。
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人以下）、このチャネルの「チャネル遅延」が期限切れになり、「再び遅延」がその値よりも長く期限切れになってから、すべてのチャネルメンバーを再度操作する場合。
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) 他のケースについては、サーバーに何らかの方法を構築する方法に基づいて、チャネル上の最大1人のメンバーを再開します。メンバーを再開しない場合、メソッドはおそらく他のサーバーが誰かをOPするようにする必要があります。この方法は、ネットワーク全体で同じでなければなりません。優れたヒューリスティックは、ただランダムな再開かもしれません。（現在の実装は、実際にはあまりにも長くアイドル状態ではないサーバーにローカルのメンバーを選択しようとします。サーバーがローカルユーザーの「アイドル」時間のみを知っているという事実）
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つを定義します。いくつかの異なる名前空間（チャネル名のプレフィックスに基づく）がありますが、これらのそれぞれ内部の複製は許可されていません。現在、さまざまなサーバーのユーザーがラベルを選択する可能性があり、衝突につながる可能性のある（回避できる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
セクション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.
これは簡単に修正できるように思えるかもしれませんが（元のサーバーのみがモード変更の有効性を確認することで）、さまざまな理由でそうしないことが決定されました。懸念の1つは、サーバーがお互いを信頼できず、誤動作サーバーを簡単に検出できることです。この方法では、モード変更が異なる方向から発行されたときに同期しないチャネルへの波の影響も停止します。
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 Relay Chat：Server Protocol」ドキュメント[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」が交換され、接続の前に両方のサーバーに設定されている場合、2つの値のどれが優先されるかを決定するメカニズムはありません。結果として生じる不一致を修正するためにユーザーに任されます。
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.
チャネルへのアクセスを制御する主な方法の1つは、ユーザー接続のユーザー名とホスト名に基づいたマスクを使用することです。このメカニズムは、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
Newsgroup: alt.irc
NewsGroup：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.
マシュー・グリーン、マイケル・ノイマイヤー、ヴォルカー・ポールセン、カート・ロックズ、ヴェサ・ルーコネン、マグナス・ツェーンストロム、ステファン・ゼール。
[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 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
Christophe Kalt 99 Teaneck Rd、Apt＃117 Ridgefield Park、NJ 07660 USA
EMail: kalt@stealth.net
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。