RFC2811 日本語訳
2811 Internet Relay Chat: Channel Management. C. Kalt. April 2000. (Format: TXT=40788 bytes) (Updates RFC1459) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group C. Kalt Request for Comments: 2811 April 2000 Updates: 1459 Category: Informational
Kaltがコメントのために要求するワーキンググループC.をネットワークでつないでください: 2811 2000年4月は以下をアップデートします。 1459年のカテゴリ: 情報
Internet Relay Chat: Channel Management
インターネットリレーチャット: チャンネル管理
Status of this Memo
この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)インターネット協会(2000)。 All rights reserved。
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(インターネットRelay Chat)プロトコルの最も注目に値する特性の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
1. 序論… 2 2. チャンネルの特性… 3 2.1名前空間… 3 2.2は範囲にチャネルを開設します… 3 2.3は特性を向けます… 4 2.4 特権があるチャンネルメンバー… 4 2.4 .1 オペレータはチャネルを開設します… 5 2.4 .2は創造者を向けます… 5 3. チャンネル、生涯… 5 3.1 標準のチャンネル… 5 3.2金庫は精神を集中します… 6 4. チャンネルモード… 7 4.1 メンバー状態… 7 4.1 .1 「チャンネル創造者」状態… 7
Kalt Informational [Page 1] RFC 2811 Internet Relay Chat: Channel Management April 2000
Kaltの情報[1ページ]のRFC2811インターネットリレーチャット: チャンネル管理2000年4月
4.1.2 Channel Operator Status ........................... 8
4.1.3 Voice Privilege ................................... 8
4.2 Channel Flags .......................................... 8
4.2.1 Anonymous Flag .................................... 8
4.2.2 Invite Only Flag .................................. 8
4.2.3 Moderated Channel Flag ............................ 9
4.2.4 No Messages To Channel From Clients On The Outside 9
4.2.5 Quiet Channel ..................................... 9
4.2.6 Private and Secret Channels ....................... 9
4.2.7 Server Reop Flag .................................. 10
4.2.8 Topic ............................................. 10
4.2.9 User Limit ........................................ 10
4.2.10 Channel Key ...................................... 10
4.3 Channel Access Control ................................. 10
4.3.1 Channel Ban and Exception ......................... 11
4.3.2 Channel Invitation ................................ 11
5. Current Implementations .................................... 11
5.1 Tracking Recently Used Channels ........................ 11
5.2 Safe Channels .......................................... 12
5.2.1 Channel Identifier ................................ 12
5.2.2 Channel Delay ..................................... 12
5.2.3 Abuse Window ...................................... 13
5.2.4 Preserving Sanity In The Name Space ............... 13
5.2.5 Server Reop Mechanism ............................. 13
6. Current problems ........................................... 14
6.1 Labels ................................................. 14
6.1.1 Channel Delay ..................................... 14
6.1.2 Safe Channels ..................................... 15
6.2 Mode Propagation Delays ................................ 15
6.3 Collisions And Channel Modes ........................... 15
6.4 Resource Exhaustion .................................... 16
7. Security Considerations .................................... 16
7.1 Access Control ......................................... 16
7.2 Channel Privacy ........................................ 16
7.3 Anonymity ............................................... 17
8. Current support and availability ........................... 17
9. Acknowledgements ........................................... 17
10. References ................................................ 18
11. Author's Address .......................................... 18
12. Full Copyright Statement ................................... 19
4.1.2 チャンネルオペレータ状態… 8 4.1 .3 特権を声に出してください… 8 4.2チャンネルは弛みます… 8 4.2 .1の匿名の旗… 8 4.2 .2 旗だけを招待してください… 8 4.2 .3はチャンネル旗を加減しました… 9 4.2 .4 外部9でクライアントから精神を集中するために、.5が落ち着ける4.2が向けられるというメッセージがありません… 9 4.2 .6 個人的で秘密のチャンネル… 9 4.2 .7 サーバReopは弛みます… 10 4.2 .8話題… 10 4.2 .9ユーザ限界… 10 4.2 .10 主要な状態で、精神を集中してください… 10 4.3はアクセスコントロールを向けます… 10 4.3 .1は禁止令と例外を向けます… 11 4.3 .2は招待を向けます… 11 5. 現在の実装… 11 5.1 最近追跡するのはチャンネルを使用しました… 11 5.2金庫は精神を集中します… 12 5.2 .1は識別子を向けます… 12 5.2 .2は遅れを向けます… 12 5.2 .3 窓を誤用してください… 13 5.2 .4 名前スペースに正気を保存します… 13 5.2 .5サーバReopメカニズム… 13 6. 現在の問題… 14 6.1 ラベルします。 14 6.1 .1は遅れを向けます… 14 6.1 .2金庫は精神を集中します… 15 6.2 モード伝播は延着します… 15 6.3回の衝突とチャンネルモード… 15 6.4 リソース疲労困憊… 16 7. セキュリティ問題… 16 7.1 コントロールにアクセスしてください… 16 7.2はプライバシーを向けます… 16 7.3匿名… 17 8. 現在のサポートと有用性… 17 9. 承認… 17 10. 参照… 18 11. 作者のアドレス… 18 12. 完全な著作権宣言文… 19
1. Introduction
1. 序論
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サーバによってどう管理されるかに関して詳細に定義して、ほとんど人々の働きの役に立ちます。
Kalt Informational [Page 2] RFC 2811 Internet Relay Chat: Channel Management April 2000
Kaltの情報[2ページ]のRFC2811インターネットリレーチャット: チャンネル管理2000年4月
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(チャンネルCharacteristics)と4(チャンネルModes)で。
2. Channel Characteristics
2. チャネル特性
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人以上のユーザの命名されたグループです。 チャンネルは名前、特性、および現在のメンバーによって描写されます。
2.1 Namespace
2.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].
'要件は別として最初のキャラクタ存在'&'、その'#''+'!'(今後「チャンネル接頭語」と呼ばれます)。 チャンネル名における唯一の制限がそれである、それ、SHALL NOTがどんな空間も含んでいる、('、'、)、コントロールG(^GかASCII7)、コンマ、(''どれがリスト項目分離符としてプロトコルによって使用されるか、)、' コロン、も(':'、)、デリミタとして、チャンネル・マスクのために、使用されます。 チャンネル名の正確な構文は「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つの(4)の異なった名前空間を作成します。 これはプロトコル制限のために(一般に)の名前空間に関して重要です。 これらの制限に関するその他の詳細に関してセクション6.1(ラベル)を見てください。
2.2 Channel Scope
2.2 チャンネル範囲
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つ以上のサーバによって知られています。 ユーザはユーザが直接接続されるサーバによって知られていたチャンネルのメンバーになることができるだけです。 知っているサーバのリスト
Kalt Informational [Page 3] RFC 2811 Internet Relay Chat: Channel Management April 2000
Kaltの情報[3ページ]のRFC2811インターネットリレーチャット: チャンネル管理2000年4月
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(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]に関連してチャンネル・マスクを使用するのは最も良いです。
2.3 Channel Properties
2.3 チャンネルの特性
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.
接頭語としての'+'があるチャンネルはチャンネルにモードをサポートしません。 'これが、すべてのモードがunsetであることを意味する、'設定されるチャンネル旗でない。
2.4 Privileged Channel Members
2.4 特権があるチャンネルメンバー
In order for the channel members to keep some control over a channel, and some kind of sanity, some channel members are privileged. Only these members are allowed to perform the following actions on the channel:
チャンネルメンバーがチャンネルの何らかのコントロール、およびある種の正気を保つように、何人かのチャンネルメンバーが特権があります。 これらのメンバーだけがチャンネルへの以下の動作を実行できます:
INVITE - Invite a client to an invite-only channel (mode +i)
KICK - Eject a client from the channel
MODE - Change the channel's mode, as well as
members' privileges
PRIVMSG - Sending messages to the channel (mode +n, +m, +v)
TOPIC - Change the channel topic in a mode +t channel
INVITE--招待だけチャンネル(モード+i)KICKにクライアントを招待してください--チャンネルMODEからクライアントを追放してください--チャンネル(+ モード+n、+ m、v)TOPICにメッセージを送って、チャンネルのモード、およびメンバーの特権PRIVMSGを変えてください--モード+tチャンネルでチャンネル話題を変えてください。
Kalt Informational [Page 4] RFC 2811 Internet Relay Chat: Channel Management April 2000
Kaltの情報[4ページ]のRFC2811インターネットリレーチャット: チャンネル管理2000年4月
2.4.1 Channel Operators
2.4.1 チャンネルオペレータ
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).
チャンネルオペレータは彼らのあだ名の横でそれがチャンネル(すなわち、NAMES、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.
接頭語としてキャラクタ'+'から始まるチャンネルがチャンネルにモードをサポートしないので、したがって、どんなメンバーもチャンネルオペレータの状態を持つことができません。
2.4.2 Channel Creator
2.4.2 チャンネル創造者
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]を見てください。
3. Channel lifetime
3. 生涯を向けます。
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つのグループが通常あります: 規格は'+ 'それの接頭語が'!'であるどの接頭語が'&'であるか、そして、'#'か「安全なチャンネル」にチャネルを開設します。
3.1 Standard channels
3.1 標準のチャンネル
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(チャンネルOperators)を見てください。
Kalt Informational [Page 5] RFC 2811 Internet Relay Chat: Channel Management April 2000
Kaltの情報[5ページ]のRFC2811インターネットリレーチャット: チャンネル管理2000年4月
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つのサーバの間の分裂でばらばらになる)の作成を避けるためにSHOULD NOTを命名します。チャンネルオペレータ(セクション2.4.1(チャンネルOperators)を見る)が最近ネットワークによるチャンネルを分けられたままにしたなら、ユーザは再利用させられてください。 これが起こるなら、チャンネル名は一時入手できません。 チャンネルが入手できないままで残っている間、持続時間はIRCネットワーク基礎あたりのaで調整されるべきです。 これが地元のユーザがチャンネルを創造するのを同じ名前を使用することで防ぎますが、リモート・ユーザーによって休養させられるようにチャンネルは防がないことに注意するのが重要です。 IRCネットワークが再び加わると、後者は通常起こります。 明らかに、このメカニズムだけを名前がキャラクタ'#'で始めるチャンネルのために理解できますが、名前がキャラクタ'+'で始めるチャンネルに使用してもよいです。 このメカニズムは「チャンネル遅れ」として一般的に知られています。
3.2 Safe Channels
3.2 安全なチャンネル
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(5)キャラクタから成るチャンネル識別子の名前を供給したprependsです。 これらの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(チャンネルDelay)で説明されたメカニズムと異なって、この場合、チャンネル名は入手できなくなりません: 最後のユーザがいなくなった後にこれらのチャンネルは存続するかもしれません。 チャンネルを創造するユーザは「チャンネルクリエイター」になるだけです、ユーザが存在に加わって。空のチャンネルは、自動的に「チャンネルクリエイター」になって、「オペレータを向けません」。
Kalt Informational [Page 6] RFC 2811 Internet Relay Chat: Channel Management April 2000
Kaltの情報[6ページ]のRFC2811インターネットリレーチャット: チャンネル管理2000年4月
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(チャンネルIdentifier)を見てください。
4. Channel Modes
4. チャンネルモード
The various modes available for channels are as follows:
チャンネルに利用可能な様々なモードは以下の通りです:
O - give "channel creator" status;
o - give/take channel operator privilege;
v - give/take the voice privilege;
O--「チャンネルクリエイター」に状態を与えてください。 o - チャンネルオペレータ特権を与えるか、または取ってください。 v--声の特権を与えるか、または取ってください。
a - toggle the anonymous channel flag;
i - toggle the invite-only channel flag;
m - toggle the moderated channel;
n - toggle the no messages to channel from clients on the
outside;
q - toggle the quiet channel flag;
p - toggle the private channel flag;
s - toggle the secret channel flag;
r - toggle the server reop channel flag;
t - toggle the topic settable by channel operator only flag;
a--匿名のチャンネル旗を切り換えてください。 i--招待だけチャンネル旗を切り換えてください。 m--加減されたチャンネルを切り換えてください。 ノー、が外部でクライアントから精神を集中するために通信させるn--トグル。 q--静かなチャンネル旗を切り換えてください。 p--個人的なチャンネル旗を切り換えてください。 s--秘密のチャンネル旗を切り換えてください。 r--サーバreopチャンネル旗を切り換えてください。 t--チャンネルオペレータによる「舗装用敷石-可能」が旗を揚げさせるだけである話題を切り換えてください。
k - set/remove the channel key (password);
l - set/remove the user limit to channel;
k--チャンネルキー(パスワード)を設定するか、または取り外してください。 l--精神を集中するためにユーザ限界を設定するか、または取り除いてください。
b - set/remove ban mask to keep users out;
e - set/remove an exception mask to override a ban mask;
I - set/remove an invitation mask to automatically override
the invite-only flag;
b--禁止令マスクを設定するか、または取り除いて、ユーザを避けてください。 e--例外マスクを設定するか、または取り除いて、禁止令マスクをくつがえしてください。 私--招待マスクを設定するか、または取り除いて、自動的に招待だけ旗をくつがえしてください。
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コマンドを使用することによって、これらのすべてのモードを操ることができます。
4.1 Member Status
4.1 会員の地位
The modes in this category take a channel member nickname as argument and affect the privileges given to this user.
このカテゴリにおけるモードは、議論としてチャンネルメンバーあだ名をみなして、このユーザに与えられた特権に影響します。
4.1.1 "Channel Creator" Status
4.1.1 「チャンネル創造者」状態
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'は「安全なチャンネル」とSHALL NOTに関連して使用されるだけです。ユーザによって操られます。 サーバは、チャンネルのために「チャンネルクリエイター」の状態を作成するユーザに与えるのにそれを使用します。
Kalt Informational [Page 7] RFC 2811 Internet Relay Chat: Channel Management April 2000
Kaltの情報[7ページ]のRFC2811インターネットリレーチャット: チャンネル管理2000年4月
4.1.2 Channel Operator Status
4.1.2 チャンネルオペレータ状態
The mode 'o' is used to toggle the operator status of a channel member.
モード'o'は、チャンネルメンバーのオペレータ状態を切り換えるのに使用されます。
4.1.3 Voice Privilege
4.1.3 声の特権
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(Channel Flagを加減する)を見てください。
4.2 Channel Flags
4.2 チャンネル旗
The modes in this category are used to define properties which affects how channels operate.
このカテゴリにおけるモードは、特性を定義するのに使用されます(チャンネルがどう働いているかに影響します)。
4.2.1 Anonymous Flag
4.2.1 匿名の旗
The channel flag 'a' defines an anonymous channel. This means that when a message sent to the channel is sent by the server to users, and the origin is a user, then it MUST be masked. To mask the message, the origin is changed to "anonymous!anonymous@anonymous." (e.g., a user with the nickname "anonymous", the username "anonymous" and from a host called "anonymous."). Because of this, servers MUST forbid users from using the nickname "anonymous". Servers MUST also NOT send QUIT messages for users leaving such channels to the other channel members but generate a PART message instead.
チャンネル旗の'a'は匿名のチャンネルを定義します。 これは、次に、サーバでチャンネルに送られたメッセージをユーザに送って、発生源がユーザであるときにそれが仮面であるに違いないことを意味します。 メッセージにマスクをかけるために、発生源は" anonymous!anonymous@anonymous "に変わります。 (例えば、「匿名」というユーザ名と「匿名である」と呼ばれるホストからの「匿名」のあだ名をもっているユーザ。) これのために、サーバはあだ名を使用するのによる「匿名」のユーザを禁じなければなりません。 サーバは、また、もう片方へのそのようなチャンネルをチャンネルメンバーに残すユーザのためにメッセージを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.
接頭語、この旗としての'&'がそうするキャラクタを伴うチャンネルに関して、チャンネルオペレータによって切り換えられますが、接頭語、この旗を設定できるように(SHALL NOTはunsetにそうです)キャラクタ'!'があるチャンネルの上に「チャンネルクリエイター」だけによって切り換えられてください。 この旗を他のタイプのチャンネルで利用可能にしてはいけません。
Replies to the WHOIS, WHO and NAMES commands MUST NOT reveal the presence of other users on channels for which the anonymous flag is set.
WHOIS、WHO、およびNAMESコマンドに関する回答は匿名の旗が設定されるチャンネルで他のユーザの存在を明らかにしてはいけません。
4.2.2 Invite Only Flag
4.2.2 旗だけを招待してください。
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'を設定するとき、彼らのマスクがInvite-リストに合っているか(セクション4.3.2を見てください)、またはチャンネルオペレータが彼らを招待した場合にだけ、新しいメンバーを受け入れます。 また、この旗はINVITEコマンド(「IRCクライアントプロトコル」[IRC-CLIENT]を見る)の用法をチャンネルオペレータに制限します。
Kalt Informational [Page 8] RFC 2811 Internet Relay Chat: Channel Management April 2000
Kaltの情報[8ページ]のRFC2811インターネットリレーチャット: チャンネル管理2000年4月
4.2.3 Moderated Channel Flag
4.2.3 加減されたチャンネル旗
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.
'チャンネル旗、'だれがチャンネルについて演説するかもしれないかを制御するために、使用されます。 それは設定されます、とオペレータが向けるだけであり、声の特権が与えられているメンバーがメッセージをチャンネルに送るとき。
This flag only affects users.
この旗はユーザに影響するだけです。
4.2.4 No Messages To Channel From Clients On The Outside
4.2.4 外部でクライアントから精神を集中するメッセージがありません。
When the channel flag 'n' is set, only channel members MAY send messages to the channel.
''チャンネルであるときには弛んでください、そして、セット、メンバーがメッセージを送るかもしれない唯一のチャンネルはチャンネルですか?
This flag only affects users.
この旗はユーザに影響するだけです。
4.2.5 Quiet Channel
4.2.5 静かなチャンネル
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].
これは、サーバが操作に関連する通知を送る特別な市内回線を創造するのに通常使用されます。 ユーザ・モード's'を置き換えるより効率的でフレキシブルな方法がRFC1459で[IRC]を定義したとき、これは使用されました。
4.2.6 Private and Secret Channels
4.2.6 個人的で秘密のチャンネル
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コマンド。 この規則への1つの例外があることに注意してください: サーバは正しくMODEコマンドに答えるでしょう。 <マスク>パラメタが指定されるとき、最終的に、秘密のチャンネルは回答でLUSERSコマンド(「インターネットリレーチャット: クライアントプロトコル」[IRC- CLIENT]を見る)の原因にならされません。
Kalt Informational [Page 9] RFC 2811 Internet Relay Chat: Channel Management April 2000
Kaltの情報[9ページ]のRFC2811インターネットリレーチャット: チャンネル管理2000年4月
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]では、言及される)を癒す分裂の間、起こるだけであるべきです。
4.2.7 Server Reop Flag
4.2.7 サーバReopは弛みます。
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 Mechanism)で、より詳細に説明されます。
4.2.8 Topic
4.2.8 話題
The channel flag 't' is used to restrict the usage of the TOPIC command to channel operators.
'チャンネル旗、'TOPICコマンドの用法をチャンネルオペレータに制限するために、使用されます。
4.2.9 User Limit
4.2.9 ユーザ限界
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質問に送られた回答で限界の値をチャンネルメンバーにとって利用可能にするだけでよいです。
4.2.10 Channel Key
4.2.10 チャンネルキー
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質問に送られた回答でチャンネルキーをチャンネルメンバーにとって目に見えるようにするだけでよいです。
4.3 Channel Access Control
4.3 チャンネルアクセス制御装置
The last category of modes is used to control access to the channel, they take a mask as argument.
モードの最後のカテゴリはチャンネルへのアクセスを制御するのに使用されて、それらは議論としてマスクをみなします。
Kalt Informational [Page 10] RFC 2811 Internet Relay Chat: Channel Management April 2000
Kaltの情報[10ページ]のRFC2811インターネットリレーチャット: チャンネル管理2000年4月
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.
アクセス・モードがチャンネルに設定するコントロールのためのグローバルなデータベースのサイズを減少させるために、サーバは特定のチャンネルに設定されたそのようなモードの数に最大の限界を置くかもしれません。 そのような制限が課されるなら、それはユーザ要求に影響するだけでよいです。 SHOULDを制限してください。IRCネットワーク基礎あたりのaで均質であってください。
4.3.1 Channel Ban and Exception
4.3.1 チャンネル禁止令と例外
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.
チャンネルから禁止されて、チャンネルオペレータによって送られた招待状を運ぶユーザはチャンネルに加わることができます。
4.3.2 Channel Invitation
4.3.2 チャンネル招待
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を見てください(Only Flagを招待してください))チャンネルにおいて、招待マスクがアドレス一致をチャンネルに設定したユーザは少しも招待なしでチャンネルに加わることができます。
5. Current Implementations
5. 現在の実装
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.
このセクションの残りはほとんどサーバを実装したがっている人に重要な問題に対処しますが、また、いくつかの部品もクライアント作家に関しておもしろいかもしれません。
5.1 Tracking Recently Used Channels
5.1 最近追跡するのはチャンネルを使用しました。
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
ネットワーク分裂が現れると、チャンネルが中断の結果として「チャンネルオペレータ」を失ったサーバSHOULDは動向をおさえます。 これらのチャンネルがそして、ある期間の間に続く特別な状態にあります。 この特定の状態では、チャンネルは、やめることができません。
Kalt Informational [Page 11] RFC 2811 Internet Relay Chat: Channel Management April 2000
Kaltの情報[11ページ]のRFC2811インターネットリレーチャット: チャンネル管理2000年4月
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.
セット考慮が多かったならチャンネル死が遅れたSHOULDである持続時間はどれがIRCネットワークのサイズ(ユーザ賢明な)と、ネットワークの普通の持続時間であるかの中で股割りを因数分解します。 それ、SHOULD、すべてのサーバで与えられたIRCネットワークに一定であってください。
5.2 Safe Channels
5.2 安全なチャンネル
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.
このドキュメントは「安全なチャンネル」の概念を紹介します。 これらのチャンネルはキャラクタ'!'と共に名前を前に置かせています、そして、すばらしい取り組みはこの名前スペースで衝突を避けさせられます。 衝突が不可能でない、しかしながら、彼らは非常にありそうもないです。
5.2.1 Channel Identifier
5.2.1 チャンネル識別子
The channel identifier is a function of the time. The current time (as defined under UNIX by the number of seconds elapsed since 00:00:00 GMT, January 1, 1970) is converted in a string of five (5) characters using the following base: "ABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890" (each character has a decimal value starting from 0 for 'A' to 35 for '0').
チャンネル識別子は現代の関数です。 現在の時間(定義されるように、秒数に従ったUNIXの下では、グリニッジ標準時0時0分0秒、1970年1月1日は以来、経過していた)は一連の5(5)キャラクタで以下のベースを使用することで変換されます: "ABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890"(各キャラクタには、'''0のための35'のために0から始めるデシマル値があります)。
The channel identifier therefore has a periodicity of 36^5 seconds (about 700 days).
したがって、チャンネル識別子には、36^5秒(およそ700日間)の周期性があります。
5.2.2 Channel Delay
5.2.2 チャンネル遅れ
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(チャンネルDelay)で説明された「チャンネル遅れ」メカニズムを受けることがあるに違いありません。 しかしながら、メカニズムは、より一層合うようにわずかに適合させられます。
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.
彼らが空であるときにさえ、しかしながら、これらのチャンネルは入手できなくならないで、彼らを接合するのはいつも可能です。
Kalt Informational [Page 12] RFC 2811 Internet Relay Chat: Channel Management April 2000
Kaltの情報[12ページ]のRFC2811インターネットリレーチャット: チャンネル管理2000年4月
5.2.3 Abuse Window
5.2.3 乱用ウィンドウ
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).
結局、サーバは、同じshortnameだけでチャンネルの作成を禁じるためにこの手順を広げるのを選ぶかもしれません(次に、チャンネル識別子を無視して)。
5.2.4 Preserving Sanity In The Name Space
5.2.4 名前スペースに正気を保存すること。
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と.3がそれをする5.2について説明しました。 しかしながら、別のタイプの乱用は同じshortnameを持っている多くのチャンネルを作成して、異なった識別子を作成するのから成ります。 これが起こるのを防ぐために、サーバはチャンネルの同じshortnameを現在存在させる新しいチャンネルの作成を禁じなければなりません。
5.2.5 Server Reop Mechanism
5.2.5 サーバReopメカニズム
When a channel has been opless for longer than the "reop delay" period and has the channel flag 'r' set (See Section 4.2.7 (Server Reop Flag)), IRC servers are responsible for giving the channel operator status randomly to some of the members.
チャンネルが「reop遅れ」より長い期間のためのoplessであり、チャンネル旗'r'を設定させるとき(セクション4.2.7(サーバReop Flag)を見てください)、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ネットワークの同じ論理を使用するRECOMMENDEDが公正と同様に一貫性を維持するということでなかったなら、サーバは異なった論理を使用するかもしれません。 「reop遅れ」SHOULD、同じくらいに関して、推論してください。すべてのサーバで与えられたIRCネットワークに一定であってください。 「チャンネルは延着します」、値。「reop遅れ」SHOULDではどれが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つの別々のサーバで引き起こされるメカニズムの不測の事態を制限するべきです。
Kalt Informational [Page 13] RFC 2811 Internet Relay Chat: Channel Management April 2000
Kaltの情報[13ページ]のRFC2811インターネットリレーチャット: チャンネル管理2000年4月
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)ユーザか以下)このチャンネルのための「チャンネル遅れ」には、少なくとも1人のメンバーがサーバに地元であるなら、満期のThen 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遅れ」は値(Then reopオール・チャンネルのメンバー)より長い間、期限が切れています。
d) For other cases, reop at most one member on the channel, based on
some method build into the server. If you don't reop a member, the
method should be such that another server will probably op
someone. The method SHOULD be the same over the whole network. A
good heuristic could be just random reop.
(The current implementation actually tries to choose a member
local to the server who has not been idle for too long, eventually
postponing action, therefore letting other servers have a chance
to find a "not too idle" member. This is over complicated due to
the fact that servers only know the "idle" time of their local
users)
d) 何らかのメソッドに基づいて、サーバに建ててください。他のケースのために、reopに、別のサーバは、高々チャンネルの上のあるメンバー、あなたがメンバーをreopしないなら、メソッドがそのようなものであるべきであるので、たぶんオプアートにだれかを望んでいます。 メソッドSHOULD、全体のネットワークの上で同じであってください。 良いヒューリスティックはただ無作為のreopであるかもしれません。 (現在の実装は実際に長い間活動していなさ過ぎたというわけではないサーバへの地元のメンバーを選ぼうとします、結局動作を延期して、したがって、他のサーバに「活動していません過ぎるというわけではない」メンバーを見つける機会を持たせます。 複雑な支払われるべきものの上にサーバが地元のユーザの「活動していません、な」時間を知っているだけであるという事実にはこれがある、)
6. Current problems
6. 現在の問題
There are a number of recognized problems with the way IRC channels are managed. Some of these can be directly attributed to the rules defined in this document, while others are the result of the underlying "IRC Server Protocol" [IRC-SERVER]. Although derived from RFC 1459 [IRC], this document introduces several novelties in an attempt to solve some of the known problems.
IRCチャンネルが管理される方法に関する多くの認識された問題があります。 直接これらの或るものを本書では定義された規則の結果と考えることができます、他のものは基本的さ結果「IRCサーバプロトコル」[IRC-SERVER]ですが。 RFC1459[IRC]から派生しますが、このドキュメントは既知の問題のいくつかを解決する試みにおける数個の新案商品を導入します。
6.1 Labels
6.1 ラベル
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つのサーバだけに知られているチャンネルを除いた)をもたらすかもしれないラベルを選ぶのは、可能です。
6.1.1 Channel Delay
6.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(追跡Recently Used Channels)で説明されて、キャラクタ'#'で前に置かれたチャンネルに使用されるチャンネル遅れメカニズムは簡単な試みです。 経験が平常な時の下にそれを示した、それ
Kalt Informational [Page 14] RFC 2811 Internet Relay Chat: Channel Management April 2000
Kaltの情報[14ページ]のRFC2811インターネットリレーチャット: チャンネル管理2000年4月
is very efficient; however, it obviously has severe limitations keeping it from being an adequate solution to the problem discussed here.
非常に効率的です。 しかしながら、それには、明らかに、それが適切な解決法であることをここで議論した問題に妨げる厳しい制限があります。
6.1.2 Safe Channels
6.1.2 安全なチャンネル
"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(安全なChannels)で説明された「安全なチャンネル」はユーザには彼らが選ぶラベルの総コントロールがあるのを防ぐとき衝突が起こるのを防ぐのにおいて、よりふさわしい方法です。 そのようなラベルのための明らかな欠点はそれらがユーザフレンドリーでないということです。 しかしながら、クライアントプログラムがこれを改良するのは、かなり些細です。
6.2 Mode Propagation Delays
6.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.
ネットワークによって引き起こされたネットワーク遅延のため経路の各サーバがモード変更の正当性をチェックするREQUIRED(例えば、ユーザは、存在していて、正しい特権を持っている)であるので、ネットワークの一部に影響するだけである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.
これが修理するのが(オリジナルのサーバだけにモード変更の正当性をチェックさせることによって)簡単に見えているかもしれない間、それは様々な理由でそうしないように決められました。 1回の関心はサーバが互いを信じることができないで、容易にふらちな事するサーバは検出できるということです。 また、そうするこの方法はモード変更が異なった方向から発行されるとき同時性から脱しているチャンネルへの波の効果を止めます。
6.3 Collisions And Channel Modes
6.3回の衝突とチャンネルモード
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つのタイプは、彼らがセットかunsetのどちらかであるので、対処しやすいです。 そのようなモードが1つのサーバに設定されるなら、接続の結果、もう片方のサーバにそれを設定しなければなりません。
Kalt Informational [Page 15] RFC 2811 Internet Relay Chat: Channel Management April 2000
Kaltの情報[15ページ]のRFC2811インターネットリレーチャット: チャンネル管理2000年4月
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つの値に優先する決めるメカニズムが全くありません。 それは結果として起こる食い違いを修正するのがユーザに任せられます。
6.4 Resource Exhaustion
6.4 リソース疲労困憊
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で言及されるような1チャンネルあたりのマスクの数に置かれるのは、RECOMMENDEDです。
Moreover, more complex mechanisms MAY be used to avoid having redundant masks set for the same channel.
そのうえ、より複雑なメカニズムは、余分なマスクを同じチャンネルに設定させるのを避けるのに使用されるかもしれません。
7. Security Considerations
7. セキュリティ問題
7.1 Access Control
7.1 アクセスコントロール
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.
アクセスを制御する別の方法がチャンネルキーを使用することですが、平文でこのキーを送るので、伝統的な男性にとって、それは中央攻撃で被害を受け易いです。
7.2 Channel Privacy
7.2 チャンネルプライバシー
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を見てください)、ユーザがアクセス制御設定をくつがえしているチャンネルに加わるのは、可能です。 このメソッドは、チャンネルの「不合理に」獲得しているチャンネルオペレータ状態のそばでチャンネルを「持って行くこと」に長い間、個人によって使用されています。 チャンネルのメンバーの正確なリストを見つけて、結局チャンネルに送られたメッセージのいくつかを受けるのに同じメソッドを使用できます。
Kalt Informational [Page 16] RFC 2811 Internet Relay Chat: Channel Management April 2000
Kaltの情報[16ページ]のRFC2811インターネットリレーチャット: チャンネル管理2000年4月
7.3 Anonymity
7.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.
読者にとって、それが明白であるべきである、提供された匿名のレベルがかなり貧しくて、不安定であり、クライアントSHOULDがそのようなものに加わるユーザのために強い警告を表示するのが精神を集中します。
8. Current support and availability
8. 現在のサポートと有用性
Mailing lists for IRC related discussion:
General discussion: ircd-users@irc.org
Protocol development: ircd-dev@irc.org
IRCのためのメーリングリストは議論を関係づけました: 一般議論: ircd-users@irc.org プロトコル開発: 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
Newsgroup: alt.irc
9. Acknowledgements
9. 承認
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プロトコルを記録したRFC1459[IRC]からコピーされました。 また、それはレビューとコメントの多くのラウンドの利益を得ました。 以下の人々はこのドキュメントへの重要な貢献を特に、しました:
Matthew Green, Michael Neumayer, Volker Paulsen, Kurt Roeckx, Vesa Ruokonen, Magnus Tjernstrom, Stefan Zehl.
マシュー・グリーン、マイケル・ノイマイアー、ボルカー・ポールセン、カートRoeckx、Vesa Ruokonen、マグヌスTjernstrom、ステファンZehl。
Kalt Informational [Page 17] RFC 2811 Internet Relay Chat: Channel Management April 2000
Kaltの情報[17ページ]のRFC2811インターネットリレーチャット: チャンネル管理2000年4月
10. References
10. 参照
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[KEYWORDS]ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[IRC] Oikarinen, J. and D. Reed, "Internet Relay Chat
Protocol", RFC 1459, May 1993.
[IRC] Oikarinen、J.、およびD.リード(「インターネットリレーチャットプロトコル」、RFC1459)は1993がそうするかもしれません。
[IRC-ARCH] Kalt, C., "Internet Relay Chat: Architecture", RFC 2810,
April 2000.
[IRC-アーチ]Kalt、C.、「インターネットリレーチャット:」 「アーキテクチャ」、RFC2810、2000年4月。
[IRC-CLIENT] Kalt, C., "Internet Relay Chat: Client Protocol", RFC
2812, April 2000.
[IRC-クライアント]Kalt、C.、「インターネットリレーチャット:」 「クライアントプロトコル」、RFC2812、2000年4月。
[IRC-SERVER] Kalt, C., "Internet Relay Chat: Server Protocol", RFC
2813, April 2000.
[IRC-サーバ]Kalt、C.、「インターネットリレーチャット:」 「サーバプロトコル」、RFC2813、2000年4月。
11. Author's Address
11. 作者のアドレス
Christophe Kalt 99 Teaneck Rd, Apt #117 Ridgefield Park, NJ 07660 USA
クリストフKalt99ティーネック、しやすい#117リッジフィールド・パーク、ニュージャージー07660第米国
EMail: kalt@stealth.net
メール: kalt@stealth.net
Kalt Informational [Page 18] RFC 2811 Internet Relay Chat: Channel Management April 2000
Kaltの情報[18ページ]のRFC2811インターネットリレーチャット: チャンネル管理2000年4月
12. Full Copyright Statement
12. 完全な著作権宣言文
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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機能のための基金は現在、インターネット協会によって提供されます。
Kalt Informational [Page 19]
Kalt情報です。[19ページ]
一覧
スポンサーリンク
