Network Working Group                                            C. Kalt
Request for Comments: 2811                                    April 2000
Updates: 1459
Category: Informational

Internet Relay Chat: チャネル管理

IRC

RFC 1459 (Internet Relay Chat Protocol)
RFC 2810 (Internet Relay Chat: Architecture)
RFC 2811 (Internet Relay Chat: Channel Management)
RFC 2812 (Internet Relay Chat: Client Protocol)
RFC 2813 (Internet Relay Chat: Server Protocol)
RFC 7194 (Default Port for Internet Relay Chat (IRC) via TLS/SSL)

本メモの位置づけ

このメモは、インターネットコミュニティーのための情報を提供するものです。このメモは、いかなる種類のインターネット標準も規定するものではありません。このメモの配布は無制限です。

概要

IRC（Internet Relay Chat）プロトコルの最大の特徴は、チャネルと呼ばれるフォーラムでユーザをグループ化し、複数のユーザが一緒にコミュニケーションする手段を提供することです。

もともとチャネルは一種類しかなかったが、時代とともにニーズに応え、あるいは実験的に新しいタイプのチャネルが登場してきました。

この文書では、チャネルとその特性およびプロパティが IRC サーバによってどのように管理されるかを規定します。

1. 序説

この文書は、IRC サーバがどのようにチャネルを管理するかについて詳細に定義しており、IRC サーバの実装に取り組んでいる人々にとってほとんど有益なものでしょう。

ここで定義された概念は IRC の重要な部分ですが、クライアントを実装する上で必須でないことに変わりはありません。トレンドは、より複雑で "インテリジェント" なクライアントへと向かっているようで、チャネルの内部構造を知ることを利用して、よりフレンドリーなインターフェースをユーザに提供できるようになっていますが、シンプルなクライアントは、このドキュメントを読まなくても実装することが可能です。

ここで定義された概念の多くは、IRC アーキテクチャ [IRC-ARCH] を念頭において設計され、ほとんどがこの文脈で意味をなすものです。しかし、他の多くのものは、会議システムのためのフォーラムを提供するために、他のアーキテクチャに適用することができます。

最後に、IRC ユーザは、以下の章、特に 2. チャネル特性と 4. チャネルモードのいくつかに興味を持つかもしれないことに留意してください。

2. チャネルの特性

チャネルは、そのチャネルに宛てられたメッセージをすべて受信する、1人または複数のユーザからなる名前付きグループです。チャネルは、その名前、プロパティ、現在のメンバによって特徴付けられます。

2.1 名前空間

チャネル名は、最大50文字の文字列（&、#、+、! で始まる文字）です。チャネル名は大文字と小文字を区別しません。

ただし、最初の文字が &、#、+、! のいずれかであること（以下、"チャネル接頭辞" と呼びます）。チャネル名の唯一の制約は、スペース（）、コントロール G（^G または ASCII 7）、カンマ（,はプロトコルではリストアイテムのセパレータとして使用されます）を含んではならないことです。また、コロン（:）はチャネルマスクのデリミタとして使用されます。チャネル名の正確な文法は "IRC サーバプロトコル" [IRC-SERVER] で定義されています。

異なる接頭辞を使用することで、チャネル名に対して4つの異なる名前空間が効果的に作成されます。これは、一般的な名前空間に関するプロトコルの制限のために重要です。この制限の詳細については、6.1 ラベルを参照してください。

2.2 チャネルスコープ

チャネルの実体は、IRC ネットワーク上の1つまたは複数のサーバによって知られています。ユーザは、そのユーザが直接接続しているサーバが知っているチャネルのみメンバになることができます。特定のチャネルの存在を知っているサーバのリストは、チャネルに宛てられたメッセージがすべてのチャネルメンバに送信されるために、IRC ネットワークの連続した部分でなければなりません。

接頭辞に & を持つチャネルは、作成されたサーバのローカルチャネルです。

その他のチャネルは、チャネルマスクに応じて、ネットワークに接続されている1台以上のサーバに知られています。

チャネルマスクがない場合、チャネルはすべてのサーバに知られています。
チャネルマスクがある場合、チャネルは、そのチャネルにローカルユーザを持つサーバにのみ知られなければなりません。また、マスクがローカルおよび近隣のサーバ名の両方に一致する場合は、その近隣サーバにのみ知られなければなりません。他のサーバはこのようなチャネルの存在を全く知らないので、マスクに一致する名前を持つサーバが形成する領域は、これらすべてのサーバにチャネルが知られるように連続でなければなりません。チャネルマスクはサーバのホストマスク [IRC-SERVER] と組み合わせて使用するのが最も効果的です。

2.3 チャネルプロパティ

各チャネルは独自のプロパティを持ち、それはチャネルモードによって定義されます。チャネルモードは、チャネルのメンバが操作することができます。モードは、サーバがチャネルを管理する方法に影響を与えます。

接頭辞に + を持つチャネルは、チャネルモードをサポートしていません。つまり、t チャネルフラグが設定されていることを除いて、すべてのモードが未設定であることを意味します。

2.4 特権的なチャネルメンバ

チャネルメンバがチャネルをコントロールし、ある種の健全性を保つために、一部のチャネルメンバには特権が与えられます。これらのメンバのみが、チャネル上で以下のアクションを実行することを許可されます。

INVITE  - クライアントを招待制のチャネルに招待する（モード +i）
KICK    - クライアントをチャネルから退出させる
MODE    - チャネルのモードを変更し、メンバの権限も変更する
PRIVMSG - チャネルにメッセージを送る（モード +n, +m, +v）
TOPIC   - Change the channel topic in a mode +t channel
TOPIC   - モード +t のチャネルでチャネルのトピックを変更する

2.4.1 チャネルオペレータ

あるチャネルのチャネルオペレータ（"チョップ" または "チャノップ" とも呼ばれる）は、そのチャネルを "所有" しているとみなされます。チャネルの所有権はチャネルオペレータの間で共有されます。

チャネルオペレータは、そのニックネームがチャネルに関連づけられた場合（NAMES、WHO、WHOIS コマンドへの返信など）、ニックネームの横に @ マークが表示され識別されます。

接頭辞に + を持つチャネルはチャネルモードをサポートしないため、チャネルオペレータのステータスを持つメンバは存在しません。

2.4.2 チャネル作成者

接頭辞に ! を付けてチャネルを作成したユーザは、"チャネル作成者" として識別されます。また、チャネルを作成した時点で、このユーザはチャネルオペレータのステータスを与えられます。

そのため、チャネル作成者には、チャネルオペレータが操作できないチャネルの特定のモードを切り替える能力が与えられています。

"チャネル作成者" は、適切な MODE コマンドを発行することで、チャネルオペレータと区別することができます。このトピックに関する詳細な情報は、"IRC クライアントプロトコル" [IRC-CLIENT] を参照してください。

3. チャネルの寿命

チャネルの寿命に関しては、一般的に2つのグループがあります：接頭辞が &、#、+ のいずれかの標準チャネルと、接頭辞が ! の "安全なチャネル" です。

3.1 標準チャネル

これらのチャネルは、最初のユーザが参加したときに暗黙的に作成され、最後のユーザが退出したときに存在しなくなります。チャネルが存在する間は、どのクライアントもチャネル名を使用してチャネルを参照することができます。

チャネルを作成したユーザは自動的にチャネルオペレータになりますが、チャネル名の前に + が付くチャネルは例外です（4. チャネルモードを参照）。このタイトルの詳細については、2.4.1チャネルオペレータを参照してください。

重複したチャネルが作成されるのを避けるため（典型的には2つのサーバ間で分割されたために IRC ネットワークが不連続になった場合）、チャネルオペレータ（2.4.1 チャネルオペレータを参照）がネットワークの分割によって最近チャネルから離れた場合は、チャネル名をユーザが再利用することを許可してはいけません。この場合，チャネル名は一時的に利用できなくなります。チャネルが利用できない状態にある期間は、IRC ネットワークごとに設定する必要があります。これはローカルユーザが同じ名前のチャネルを作成することを防ぎますが、リモートユーザがチャネルを再作成することは防げないことに注意することが重要です。後者は通常、IRC ネットワークが再接続されたときに起こります。明らかに、このメカニズムは名前が # で始まるチャネルにのみ意味がありますが、名前が + で始まるチャネルにも使用することができます。このメカニズムは一般的に "Channel Delay" として知られています。

3.2 安全なチャネル

他のチャネルとは異なり、"安全なチャネル" は暗黙のうちに作成されることはありません。このようなチャネルを作成したいユーザは、サーバに特別な JOIN コマンドを送信して作成を要求しなければなりません。このとき、チャネル識別子（当時は不明）は文字 ! に置き換えられます。このタイプのチャネルの作成プロセスは厳密に制御されます。ユーザはチャネル名の一部（チャネルの "ショートネーム" と呼ばれる）を選択するだけで、サーバは自動的にユーザが提供した名前の前に5文字からなるチャネル識別子を付けます。この2つの要素の組み合わせによるチャネル名は一意であり、ネットワークの分割に基づく悪用からチャネルを安全に守ることができます。

このようなチャネルを作成したユーザは、自動的に "チャネル作成者" となります。この称号の詳細については、2.4.2 チャネル作成者を参照してください。

サーバは、同じ短縮名を持つ別のチャネルが存在する場合、または同じ短縮名を持つ別のチャネルが最近存在し、そのメンバのいずれかがネットワークの分裂によって離脱した場合、新規チャネルの作成を許可してはなりません。このようなチャネルは、最後のユーザが退出し、ネットワークの分裂によって他のメンバがそのチャネルから退出しなくなった時点で存在しなくなります。

5.2.2 チャネル遅延で説明したメカニズムとは異なり、この場合、チャネル名は利用できなくなるわけではなく、最後のユーザが退出した後もこれらのチャネルは存在し続ける可能性があります。チャネルを作成したユーザのみが "チャネル作成者" となり、既存の空のチャネルに参加したユーザは自動的に "チャネル作成者" にも "チャネルオペレータ" にもなれません。

チャネル名の一意性を確保するため、サーバが作成するチャネル識別子は特定のルールに従わなければなりません。この詳細については、5.2.1 チャネル識別子を参照してください。

4. チャネルモード

チャネルに用意されている各種モードは以下の通りです。

O - "チャネル作成者" のステータスを与える。
o - チャネルオペレータの権限を与える/取る。
v - 音声の特権を与える/取る。

a - 匿名チャネルフラグを切り替える。
i - 招待専用チャネルフラグを切り替える。
m - モデレートされたチャネルを切り替える。
n - 外部のクライアントからチャネルへのメッセージの受信禁止を切り替える。
q - クワイエットチャネルフラグを切り替える。
p - プライベートチャネルフラグを切り替える。
s - シークレットチャネルフラグを切り替える。
r - サーバ再開チャネルフラグを切り替える。
t - チャネルオペレータだけが設定可能なトピックフラグを切り替える。

k - チャネルキー（パスワード）を設定／解除する。
l - チャネルに対するユーザ制限を設定/解除する。

b - ユーザを締め出すための禁止マスクを設定/解除する。
e - 禁止マスクを上書きするための例外マスクを設定/削除する。
I - 招待専用フラグを自動的に上書きする招待マスクを設定/削除する。

以下に特に断りがない限り、これらのモードは "IRC クライアントプロトコル" [IRC-CLIENT] で定義されている MODE コマンドを使用することで "チャネルオペレータ" が操作することができる。

4.1 メンバステータス

このカテゴリのモードは、チャネルメンバのニックネームを引数として取り、このユーザに与えられた特権に影響を与えます。

4.1.1 "チャネル作成者" ステータス

モード O は "安全なチャネル" でのみ使用され、ユーザによって操作されてはなりません。サーバは、チャネルを作成するユーザに "チャネル作成者" のステータスを与えるために使用します。

4.1.2 チャネルオペレータステータス

モード o は、チャネルメンバのオペレータのステータスを切り替えるために使用します。

4.1.3 音声特権

モード v は、チャネルメンバへ音声権限を与えたり、取ったりするために使用します。この特権を持つユーザは、モデレートされたチャネルで会話することができます。（4.2.3 モデレートされたチャネルフラグを参照してください。）

4.2 チャネルフラグ

このカテゴリのモードは、チャネルの動作に影響を与えるプロパティを定義するために使用されます。

4.2.1 匿名フラグ

チャネルフラグ a は匿名チャネルを定義します。これは、このチャネルに送信されたメッセージがサーバからユーザに送信され、その送信元がユーザである場合、そのメッセージをマスクする必要があることを意味します。メッセージをマスクするために、オリジンは anonymous!anonymous@anonymous に変更されます。（例: ニックネーム anonymous、ユーザ名 anonymous、ホスト名 anonymous のユーザ）に変更します。このため、サーバはユーザが anonymous というニックネームを使用することを禁止しなければなりません。また、このようなチャネルから退出するユーザに対して、サーバは他のチャネルメンバに QUIT メッセージを送らず、代わりにパートメッセージを生成しなければなりません。

文字 & を接頭辞に持つチャネルでは、このフラグはチャネルオペレータが切り替えることができますが、文字 ! を接頭辞に持つチャネルでは、このフラグは "チャネル作成者" のみが設定できます（ただし解除してはなりません）。このフラグは、他の種類のチャネルで利用可能であってはなりません。

WHOIS、WHO、および NAMES コマンドへの返信では、匿名フラグが設定されているチャネルに他のユーザが存在することを明らかにしてはなりません。

4.2.2 招待専用フラグ

チャネルフラグ i が設定されている場合、新しいメンバはそのマスクが Invite-list（章 4.3.2 参照) に一致するか、チャネルオペレータによって招待された場合のみ受け入れられます。このフラグは INVITE コマンド（"IRC クライアントプロトコル" [IRC-CLIENT] 参照）の使用もチャネルオペレータに制限しています。

4.2.3 モデレートチャネルフラグ

チャネルフラグ m は、チャネルで発言できる人を制御するために使用されます。このフラグが設定されている場合、チャネルオペレータと音声権限を与えられたメンバのみがチャネルにメッセージを送信することができます。

このフラグは、ユーザにのみ影響します。

4.2.4 外部のクライアントからチャネルへのメッセージ禁止

チャネルフラグ n が設定されている場合、チャネルメンバのみがチャネルにメッセージを送信することができます。

このフラグは、ユーザにのみ影響します。

4.2.5 Quiet チャネル

チャネルフラグ q は、サーバのみが使用します。このフラグを設定すると、チャネルの操作に関して、ユーザに送信されるデータの種類が制限されます。他のユーザの参加、パート、ニックネームの変更などは送信されません。ユーザから見ると、チャネルにはユーザが一人しかいません。

これは通常、サーバがその操作に関連する通知を送信する特別なローカルチャネルを作成するために使用されます。これは、RFC 1459 [IRC] で定義されているユーザモード s を置き換え、より効率的で柔軟な方法として使用されます。

4.2.6 プライベート・シークレットチャネル

チャネルフラグ p はチャネルを "プライベート" に、チャネルフラグ s はチャネルを "シークレット" にマークするために使用されます。どちらの性質も同様であり、他のユーザからチャネルの存在を隠すことができます。

これは、メンバでない限り、サーバからこのチャネルの名前を取得する方法がないことを意味します。言い換えれば、これらのチャネルは WHOIS コマンドなどのクエリに対する応答から除外する必要があります。

チャネルが "シークレット" の場合、上記の制限に加えて、TOPIC、LIST、NAMES コマンドなどの問い合わせに対して、そのチャネルが存在しないかのように振る舞います。このルールには1つの例外があることに注意してください：サーバは MODE コマンドには正しく応答します。最後に、mask パラメータが指定されている場合、LUSERS コマンド（"Internet Relay Chat: クライアントプロトコル" [IRC-CLIENT] を参照）に対する応答では、シークレットチャネルは考慮されません。

チャネルフラグ p と s は同時に設定してはなりません。サーバから発信された MODE メッセージがフラグ p を設定し、そのチャネルにすでにフラグ s が設定されていた場合、その変更は静かに無視されます。これはスプリットヒーリングフェーズ（"IRC サーバプロトコル" 文書 [IRC-SERVER] で述べられています）中にのみ発生するはずです。

4.2.7 サーバ再開フラグ

チャネルフラグ r は、名前が ! で始まるチャネルにのみ有効で、"チャネル作成者" によってのみ切り替えられます。

このフラグは、チャネルオペレータがいない状態が長時間続くことを防ぐために使用されます。このフラグが設定されると、"reop delay" 期間よりも長い間、すべてのチャネルオペレータを失ったチャネルは、一部またはすべてのチャネル住民を再開するためのサーバ内のメカニズムをトリガします。このメカニズムについては、5.2.4 チャネル再開のメカニズムでより詳細に説明します。

4.2.8 トピック

チャネルフラグ t は、TOPIC コマンドの使用をチャネルオペレータに限定するために使用します。

4.2.9 ユーザ制限

チャネルフラグ l を使用することで、チャネルにユーザ数の上限を設定することができます。この制限に達した場合、サーバはそのローカルユーザがそのチャネルに参加することを禁止しなければなりません。

制限の値は、サーバが MODE クエリに対して送信する応答においてのみ、チャネルメンバに公開されなければなりません。

4.2.10 チャネルキー

チャネルキーが設定された場合（モード k を使用）、サーバはこのキーが与えられない限り、ローカルユーザのチャネル参加要求を拒否しなければなりません。

チャネルキーは，MODE クエリに対するサーバからの応答においてのみ，チャネルメンバに見えるようにしなければなりません。

4.3 チャネルアクセス制御

最後のカテゴリのモードは，チャネルへのアクセスを制御するために使用され，引数としてマスクを取ります。

チャネルに設定される制御アクセスモードのグローバルデータベースのサイズを縮小するために、サーバは特定のチャネルに設定されるそのモードの数に最大限の制限を設けることができます。そのような制限が課される場合、それはユーザのリクエストにのみ影響するものでなければなりません。制限は IRC ネットワークごとに均質であるべきです。

4.3.1 チャネル禁止と例外

ユーザがチャネルへの参加を要求すると、そのユーザのローカルサーバは、ユーザのアドレスがチャネルに設定されている禁止マスクのいずれかに一致するかどうかをチェックします。一致した場合、そのアドレスがチャネルに設定された例外マスクにも一致しない限り、ユーザのリクエストは拒否されます。

サーバは、チャネルから追放されたチャネルメンバがチャネルオペレータであるか、音声権限を持っていない限り、そのチャネルでの発言を許可してはなりません。（4.1.3 音声特権を参照。）

チャネルから追放されたユーザが、チャネル運営者から送られた招待状を携帯している場合、チャネルへの参加が許可されます。

4.3.2 チャネル招待

招待専用フラグが設定されているチャネル（4.2.2 招待専用フラグ参照）では、そのチャネルに設定されている招待マスクにアドレスが一致するユーザは、招待なしでチャネルに参加することができます。

5. 現在の実装

これらのルールを IRC プロトコルの一部として現在実装しているのは、IRC サーバ、バージョン 2.10 のみです。

この章の残りの部分は、主にサーバを実装しようとする人にとって重要な問題を扱っていますが、いくつかの部分はクライアントを書く人にとっても興味深いものでしょう。

5.1 最近使ったチャネルの追跡

このメカニズムは一般に "チャネル遅延" と呼ばれ、一般に名前の前に # が付くチャネルにのみ適用されます（3.1 標準チャネル参照）。

ネットワークの分割が発生した場合、サーバは分割の結果、どのチャネルが "チャネルオペレータ" を失ったかを追跡する必要があります。これらのチャネルは、ある期間、特別な状態になります。この特別な状態では、チャネルは存在しなくなることはありません。すべてのチャネルメンバがチャネルを離れると、チャネルは利用できなくなります。チャネルが空である限り、サーバ・ローカル・クライアントはチャネルに参加することができません。

一度利用できなくなったチャネルは、リモートユーザがチャネルに参加した場合（ネットワークが回復している場合が多い）、または遅延時間が経過した場合に再び利用可能になり、その場合チャネルは存在しなくなりますが、再作成される可能性があります。

チャネルの死を遅延させる期間は、IRC ネットワークのサイズ（ユーザ数）や、ネットワークの分割の通常の期間など、多くの要因を考慮して設定する必要があります。これは、ある IRC ネットワークのすべてのサーバで統一されるべきです。

5.2 安全なチャネル

本書では，"安全なチャネル" という概念を導入しています。これらのチャネルは ! という文字を先頭につけた名前を持ち、この名前空間での衝突を避けるために多大な努力が払われています。衝突は不可能ではありませんが、非常に起こりにくいです。

5.2.1 チャネル識別子

チャネル識別子は、時刻の関数です。現在時刻（UNIX では 1970 年 1 月 1 日 00:00:00 GMT からの経過秒数で定義）は、以下の基数を用いて 5 文字の文字列に変換されます。ABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890（各文字は 0 から始まる 10 進数値で、A は 0、0 は 35 です。）

したがって、チャネル識別子の周期は \(36^5\) 秒（約700日）です。

5.2.2 チャネル遅延

これらのチャネルには、5.1項（チャネル遅延）で説明した "チャネル遅延" の仕組みが必要です。ただし、この仕組みはより適合するように若干アレンジされています。

サーバは、ユーザが "チャネルオペレータ" であるかどうかにかかわらず、ネットワークの分割によってメンバを失ったそのようなチャネルをすべて記録しておかなければなりません。

ただし、これらのチャネルが使えなくなることはなく、空チャネルであっても常に参加することが可能です。

5.2.3 Abuse Window

周期性が長いため、特定のチャネル（名前）に対する攻撃は、非常に長い時間に一度しか発生しない可能性があります。しかし、運と忍耐力があれば、ユーザがチャネル衝突を起こすことは可能です。これを避けるために、サーバは "未来を見る" 必要があり、識別子が使用されようとしているチャネル名のリストを保持する必要があります（たとえば、今後数日間に使用される）。このようなリストは小さく、サーバにとって維持の負担にならないものであるべきで、チャネルの遅延よりも長い期間、そのようなチャネルの再作成を防止することによって、チャネル衝突を回避するために使用されます。

最終的には、この手順を拡張して、同じショートネームだけを持つチャネルの作成を禁止する（その場合、チャネル識別子は無視される）ことになるかもしれません。

5.2.4 ネームスペースの健全性確保

5.2.2 節と 5.2.3 節で説明したメカニズムを組み合わせることで、ユーザがチャネルの衝突を起こすことはかなり難しくなっています。しかし、別のタイプの不正使用は、同じショートネームを持つが異なる識別子を持つ多数のチャネルを作成することです。これを防ぐために、サーバは現在存在するチャネルと同じショートネームを持つ新しいチャネルの作成を禁止しなければなりません。

5.2.5 サーバ再稼働の仕組み

チャネルが "再開遅延" 期間よりも長く無人となり、チャネルフラグ r が設定されている場合（4.2.7 サーバ再開フラグ参照）、IRC サーバはチャネルオペレータ状態を一部のメンバにランダムに与える責任を負います。

現在の実装でこのメカニズムに使用されている正確なロジックを以下に説明します。サーバは異なるロジックを使用することができますが、一貫性と公平性を維持するために、特定の IRC ネットワーク上ですべてのサーバが同じロジックを使用することが強く推奨されています。同じ理由で、"reop delay" は特定の IRC ネットワークのすべてのサーバで均一であるべきです。"チャネル遅延" については、IRC ネットワークの規模（ユーザ数）、ネットワークの分割の頻度など、様々な要素を考慮して "再開遅延" の値を設定する必要があります。

a) 再稼働メカニズムは、"再稼働遅延" の満了後、ランダムな時間の後にトリガーされます。これは、メカニズムが2つの別々のサーバで同時に（同じチャネルで）トリガーされる可能性を制限するはずです。

b) チャネルが小規模（5ユーザ以下）で、このチャネルの "チャネル遅延" が終了した場合、少なくとも1つのメンバがサーバにローカルであれば、すべてのチャネルメンバを再オープンします。

c) チャネルが小規模（5ユーザ以下）で、このチャネルの "チャネル遅延" が期限切れで、"再開遅延" の値より長い時間が経過した場合、すべてのチャネルメンバを再開させます。

d) その他の場合は、サーバに組み込まれた何らかの方法に基づいて、チャネル上の最大1人のメンバを再開させます。もし、メンバを再開しないのであれば、その方法は、他のサーバがおそらく誰かを再開するようなものでなければなりません。この方法は、ネットワーク全体で同じであるべきです。良いヒューリスティックは、単なるランダムな再開かもしれません。（現在の実装では、実際にサーバのローカルであまり長くアイドル状態になっていないメンバを選ぼうとし、最終的には行動を先延ばしにして、他のサーバに "あまりアイドル状態になっていない" メンバを見つける機会を与えています。これは、サーバがローカルユーザの "アイドル" 時間しか知らないため、複雑になりすぎています。）

6. 現在の問題

IRC チャネルの管理方法には、いくつかの問題があると認識されています。これらのうちのいくつかは、この文書で定義された規則に直接起因するものであり、他のものは基礎となる "IRC サーバプロトコル" [IRC-SERVER] に起因するものであります。RFC 1459 [IRC] から派生したものではありますが、この文書では、既知の問題のいくつかを解決するために、いくつかの新規性を導入しています。

6.1 ラベル

この文書では、IRC プロトコルで使用される多くのラベルのうちの 1 つを定義しています。（チャネル名の接頭辞に基づく）いくつかの明確な名前空間がありますが、それぞれの内部で重複することは許されません。現在、異なるサーバのユーザがラベルを選択することが可能であり、衝突を引き起こす可能性があります（ただし、1つのサーバにしか知られていないチャネルは例外で、衝突を回避することができます）。

6.1.1 チャネル遅延

5. 1 最近使ったチャネルの追跡で説明した、文字 # を接頭辞に持つチャネルに使用されるチャネル遅延メカニズムは、衝突の発生を防ぐための単純な試みです。経験上、通常の状況下では非常に効率的であることが分かっています。しかし、ここで議論する問題に対する適切な解決策とはならないような厳しい制限があることは明らかです。

6.1.2 安全なチャネル

3.2 安全なチャネルで説明する "安全なチャネル" は、ユーザが選択したラベルを完全に制御することを防ぐため、衝突が起こらないようにするためのより良い方法です。このようなラベルの明らかな欠点は、ユーザフレンドリーでないことです。しかし、クライアントプログラムがこれを改善するのはかなり些細なことです。

6.2 モード伝搬遅延

ネットワークによって引き起こされるネットワーク遅延や、経路上の各サーバがモード変更の有効性（ユーザが存在し、正しい権限を持っているかなど）を確認する必要があるため、MODE メッセージがネットワークの一部にしか影響しないことは珍しくなく、チャネルの現在の状態についてサーバ間で不一致が生じることもよくあります。

これは、元のサーバだけがモード変更の妥当性をチェックすることで簡単に解決できそうですが、様々な理由からそうしないことにしました。1つは、サーバが互いに信頼できず、誤動作しているサーバが簡単に検出されることが懸念されることです。また、この方法だと、異なる方向からモード変更を行ったときに、同期していないチャネルに波が立つのを防ぐこともできます。

6.3 衝突とチャネルモード

"Internet Relay Chat: サーバプロトコル" ドキュメント [IRC-SERVER] は、2つのサーバが互いに接続したときに、どのようにチャネルデータを交換するかを説明しています。チャネルの衝突は（正当なものであろうとなかろうと）包含的なイベントとして扱われ、結果として生じるチャネルは、接続前にいずれかのサーバでチャネルのメンバであったすべてのユーザをメンバとして持つことを意味します。

同様に、各サーバはチャネルモードを他のサーバに送信します。したがって、各サーバはこれらのチャネルモードも受信します。あるチャネルのモードには、フラグ、マスク、データという3つのタイプがあります。最初の2つのタイプは、設定するかしないかのどちらかであるため、簡単に扱うことができます。このようなモードが一方のサーバで設定されている場合、接続の結果、もう一方のサーバでも設定されなければなりません。

トピックはこの交換の一部として送信されないので、問題はありません。しかし、チャネルモード l と k は交換され、接続前に両サーバで設定されていた場合、どちらの値が優先されるかを決めるメカニズムはありません。結果として生じる不一致を修正するのは、ユーザに任されています。

6.4 リソースの枯渇

4.3 節で定義されたマスクに基づくモードは、IRC サーバ（とネットワーク）をシステムの単純な悪用に対して脆弱にします：一人のチャネルオペレータが、特定のチャネルにできるだけ多くの異なるマスクを設定することができます。これはサーバがメモリとネットワークの帯域を浪費する原因になりえます（情報が他のサーバに伝搬されるからです）。このため、4.3 節で述べたように、チャネルごとのマスクの数に制限を設けることが推奨されます。

さらに、同じチャネルに冗長なマスクが設定されないように、より複雑なメカニズムを使用することもできます。

7. セキュリティへの配慮

7.1 アクセス制御

チャネルへのアクセスを制御する主な方法のひとつは、ユーザ接続のユーザ名とホスト名をもとにしたマスクを使用することです。このメカニズムは、IRC サーバがユーザの接続を認証する正確な方法を持っていて、ユーザが簡単にそれを回避できない場合にのみ、効率的で安全なものとなりえます。理論的にはこのような厳密な認証機構を実装することは可能ですが、ほとんどの IRC ネットワーク（特に公共のネットワーク）ではこのようなものはなく、特定のクライアント接続のためのユーザ名とホスト名の正確さについてはほとんど保証されていません。

また、アクセス制御の方法として、チャネルキーを使用する方法もありますが、このキーは平文で送信されるため、従来の中間者攻撃に対して脆弱です。

7.2 チャネルプライバシー

チャネルの衝突は包括的なイベントとして扱われるため（6.3 節参照）、ユーザがアクセス制御設定を上書きしてチャネルに参加することが可能です。この方法は、チャネルでチャネルオペレータの地位を "不正に" 獲得し、チャネルを "乗っ取る" 個人によって長い間使用されてきました。同じ方法で、チャネルの正確なメンバリストを見つけることができますし、最終的にはチャネルに送信されたメッセージの一部を受信することもできます。

7.3 匿名性

匿名チャネルフラグ（4.2.1 節を参照）を使用すると、チャネルへのすべてのメッセージはニックネームが anonymous である疑似ユーザから発信されていると表示され、そのチャネルのすべてのユーザは anonymous となります。これはクライアント・サーバレベルで行われ、サーバ・サーバレベルでは匿名性は提供されません。

読者には、提供される匿名性のレベルが非常に低く、安全でないことは明らかであり、クライアントがそのようなチャネルに参加するユーザに対して強い警告を表示する必要があります。

8. 現在のサポートと可用性

IRC 関連の議論を行うためのメーリングリスト：

General discussion: ircd-users@irc.org
Protocol development: ircd-dev@irc.org

ソフトウェアの実装：

ftp://ftp.irc.org/irc/server
ftp://ftp.funet.fi/pub/unix/irc
ftp://coombs.anu.edu.au/pub/irc

Newsgroup: alt.irc

9. 謝辞

この文書の一部は、IRC プロトコルを最初に正式に文書化した RFC 1459 [IRC] からコピーされたものです。また、多くのレビューとコメントから恩恵を受けています。特に、以下の方々がこの文書に大きな貢献をされました。

Matthew Green, Michael Neumayer, Volker Paulsen, Kurt Roeckx, Vesa Ruokonen, Magnus Tjernstrom, Stefan Zehl.

10. 参考

[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[IRC] Oikarinen, J. and D. Reed, "Internet Relay Chat Protocol", RFC 1459, May 1993.

[IRC-ARCH] Kalt, C., "Internet Relay Chat: Architecture", RFC 2810, April 2000.

[IRC-CLIENT] Kalt, C., "Internet Relay Chat: Client Protocol", RFC 2812, April 2000.

[IRC-SERVER] Kalt, C., "Internet Relay Chat: Server Protocol", RFC 2813, April 2000.

11. Author's Address

Christophe Kalt 99 Teaneck Rd, Apt #117 Ridgefield Park, NJ 07660 USA

EMail: kalt@stealth.net

12. Full Copyright Statement

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 2811 チャネル管理

Internet Relay Chat: チャネル管理