ネットワーキンググループ C. Kalt Request for Comments: 2811 2000年4月 1459のアップデート カテゴリ: インフォメーション インターネットリレーチャット:チャンネルの取り扱い この文章について この文章は、インターネットコミュニティのための情報を提供します。インターネ ットの基準を定義するものではありません。この文章の配布に制限はありません。 コピーライト Copyright (C) The Internet Society (2000). All Rights Reserved. 概要 ユーザがフォーラムの中でチャンネルと呼ばれるグループを作れることは、 IRC(Internet Relay Chat)プロトコルの目立った特徴のひとつです。チャンネルによ って、複数のユーザがいっしょにコミュニケーションすることができます。 もともとはチャンネルは一つのタイプしかありませんでしたが、時がたってニーズ や経験から新しいタイプが出てきました。 この文書ではチャンネル自体やその特性、プロパティがIRCサーバによってどのよ うに管理されるかを定義します。 目次 * 1 導入 * 2 チャンネルの特性 o 2.1 ネームスペース o 2.2 チャンネルスコープ o 2.3 チャンネルのプロパティ o 2.4 特権をもつチャンネルメンバー + 2.2.1 チャンネルオペレータ + 2.2.2 チャンネルクリエータ * 3 チャンネルの寿命 o 3.1 スタンダードチャンネル o 3.2 セーフチャンネル * 4 チャンネルモード o 4.1 メンバーステータス + 4.1.1 "チャンネルクリエータ"ステータス + 4.1.2 チャンネルオペレータステータス + 4.1.3 Voice Privilege o 4.2 チャンネルフラグ + 4.2.1 匿名フラグ + 4.2.2 招待のみフラグ + 4.2.3 モデレートチャンネルフラグ + 4.2.4 チャンネル外クライアントからのメッセージ遮断 + 4.2.5 クワイエットチャンネル + 4.2.6 プライベート・シークレットチャンネル + 4.2.7 サーバReopフラグ + 4.2.8 トピック + 4.2.9 ユーザ数の限界 + 4.2.10 チャンネルキー o 4.3 チャンネルアクセスコントロール + 4.3.1 チャンネル禁止と例外 + 4.3.2 チャンネル招待 * 5 現在の実装 o 5.1 最近使われたチャンネルの記録 o 5.2 セーフチャンネル + 5.2.1 チャンネル識別子 + 5.2.2 チャンネル遅延 + 5.2.3 Abuse Window + 5.2.4 ネームスペースの平穏維持 + 5.2.5 サーバReopメカニズム * 6 現状の問題点 o 6.1 ラベル + 6.1.1 チャンネル遅延 + 6.1.2 セーフチャンネル o 6.2 モード伝達遅延 o 6.3 衝突とチャンネルモード o 6.4 リソースの枯渇 * 7 セキュリティについての配慮 o 7.1 アクセスコントロール o 7.2 チャンネルのプライバシー o 7.3 匿名性 * 8 現在のサポートおよび入手先 * 9 謝辞 * 10 リファレンス * 11 筆者の連絡先 * 12 コピーライトの完全記述 1. 導入 この文書はIRCサーバによってどのようにチャンネルが管理されるかの詳細を定義 します。IRCサーバにIRCプロトコルを実装しようとしている人にとって有用だと思わ れます。 ここに定義されるコンセプトはIRCの重要な部分ですが、クライアントへの実装の ためには重要なことではありません。クライアントプログラムの最近の傾向として は、ユーザにもっとフレンドリーなインターフェースを与えるためにチャンネルの内 部動作を知ることができる、ますます複雑で「インテリジェントな」ものに向かって いるようですが、シンプルなクライアントはこの文書を読まなくても作れます。 ここに定義されるコンセプトの多くは、IRC architecture [IRC-ARCH]を年頭にお いてデザインされており、ほぼこの背景において意味をなします。しかし、会話シス テムのためのフォーラムを作るための多くのほかの構造に適用できます。 最後に、IRCユーザは後続の章、とくに第2章(チャンネルの特徴)及び第4章(チャン ネルモード)に興味を持つかもしれないということを強調しておきます。 2. チャンネルの特徴 チャンネルとは、そのチャンネル向けに送られたメッセージを受け取る一人以上の ユーザからなる、名前を付けられたグループです。チャンネルは名前、プロパティ、 現在のメンバーで特徴付けられます。 2.1 ネームスペース チャンネルの名前は50文字以内の文字列です('&'や'#'、'+' 、'!'で始まりま す)。チャンネルの名前はケースセンシティブではありません(英文字の大文字と小文 字は区別されません)。 先頭の文字が'&'か'#'か'+'か'!'(以降"チャンネルプレフィックス"と呼びます)で あること以外には、スペース(' ')やコントロールG(^GもしくはASCII 7)、コンマ (','このプロトコルではリストアイテムセパレータとして使われます)を含んでは 「いけない」というのがチャンネルネームの唯一の制限です。また、コロン(':')は チャンネルマスクの制限を外すものとして使われます。チャンネルネームの文法の詳 細は"IRC Server Protocol" [IRC-SERVER]で定義されています。 異なるプレフィックスを使うと、チャンネルネームのために4つの違ったネームス ペースを効果的に作ることができます。これは重要なことです。ネームスペースによ るプロトコルの限界が(一般的に)あるからです。この制限についての詳細は、6.1(ラ ベル)を見てください。 2.2 チャンネルスコープ チャンネルの存在は、IRCネットワーク上の1つ以上のサーバに認識されています。 ユーザは自分が直接つながっているサーバに認識されているチャンネルのメンバーに しかなれません。特定のチャンネルを認識しているサーバのリストはIRCネットワー ク上の隣接している部分で「なくてはなりません」。そのチャンネル宛てのメッセー ジをチャンネルメンバーすべてに送るためです。 '&'のプレフィックスで始まるチャンネルは、それらが作られたサーバローカルの ものです。 ほかのチャンネルはチャンネルマスクによって、ネットワークに接続されている1 つ以上のサーバに認識されます。 チャンネルマスクが無かったら、このチャンネルはすべてのサーバに認識さ れます。 チャンネルマスクがあれば、そのチャンネルはそのチャンネルにいるユーザ をローカルユーザとして持つサーバにのみ、またローカル及び隣接しているサ ーバ名にマスクがマッチしている場合には、そのサーバと隣接するサーバにの み、認識され「なければなりません」。ほかのサーバはそのようなチャンネル の存在についてまったく認識していないので、マスクに合致する名前をもつサ ーバによって作られるエリアは、これらのサーバすべてに認識されるチャンネ ルに隣接していなくてはならないのです。チャンネルマスクはサーバホストマ スキング[IRC-SERVER]との組み合わせでもっともよく使われます。 2.3 チャンネルのプロパティ 一つ一つのチャンネルは、各々チャンネルモードによって定義されるプロパティを 持っています。チャンネルモードはチャンネルメンバーが操作できます。モードはサ ーバのチャンネル管理方法に関係します。 プレフィックスとして'+'がついているチャンネルは、チャンネルモードをサポー トしません。つまり、チャンネルフラグ't' を除いてすべてのモードがセットされま せん。 2.4 特権をもつチャンネルメンバー チャンネルメンバーがチャンネルをコントロールできるようにするため、またチャ ンネルの健全性のため、何人かのチャンネルメンバーが特権を与えられます。これら のメンバーのみが次のアクションをチャンネルに対して行えます: INVITE - 招待のみ(invite-only)チャンネル(モード +i)にクライアントを招待 (invite)する KICK - クライアントをチャンネルから追い出す MODE - チャンネルのモードを変えたり、メンバーの特権を変えたりする PRIVMSG - チャンネルにメッセージを送る(モード +n, +m, +v) TOPIC - +tモードのチャンネルでチャンネルトピックを変える 2.4.1 チャンネルオペレータ 権限を与えられたチャンネル上のチャンネルオペレータ("chop"とか"chanop"と呼 ばれることもあります)がそのチャンネルを「所有」するとみなされます。チャンネ ルの所有はチャンネルオペレータたちでシェアされています。 チャンネルオペレータは、チャンネルに関係した表示(たとえば、NAMES、WHO、 WHOISといったコマンドへのリプライなど)ではいかなる場合も'@'マークがニックネ ームの後ろについていることで見分けられます。 '+'のプレフィックスで始まっているチャンネルはチャンネルモードをサポートし ないので、どのメンバーもチャンネルオペレータにはなれません。 2.4.2 チャンネルクリエータ '!'をプレフィックスにしたチャンネルを作るユーザは、"チャンネルクリエータ" として認識されます。チャンネルを作る際、このユーザはチャンネルオペレータの権 限も与えられます。 この権限の認識の際、チャンネルクリエータは、チャンネルオペレータが操作でき ないいくつかのチャンネルモードをトグルする能力を与えられます。 "チャンネルクリエータ"は正しいモードコマンドを流すことによってチャンネルオ ペレータと区別されます。この点については"IRC Client Protocol" [IRC-CLIENT]に より多くの情報があります。 3. チャンネルの寿命 チャンネルの寿命については、通常2つのチャンネルのグループがあります。プレ フィックスが'&'、'#'、'+'であるスタンダードチャンネルと、プレフィックスが'!' である"セーフチャンネル"です。 3.1 スタンダードチャンネル これらのチャンネルは、最初のユーザが入ったときに暗黙のうちに作られ、最後の ユーザが出て行ったときに消滅します。チャンネルが存在する間は、どんなクライア ントもチャンネルの名前をつかってそのチャンネルを見つけることができます。 '+'がプレフィックスになっている名前のチャンネルでは、チャンネルを作ったユ ーザは、4(チャンネルモード)の注目すべき例外を除いて、自動的にチャンネルオペ レータになります。このことに関する詳細は、2.4.1(チャンネルオペレータ)を参照 してください。 複製チャンネルができるのを避けるために(通常二つのサーバの接続が切れてしま ってIRCネットワークが分断したとき起こる)、 チャンネルオペレータ(2.4.1(チャン ネルオペレータ)参照)がネットワークの分断のためチャンネルを離れたときに、チャ ンネルの名前がユーザによって使いまわされることは「許されません」。もしこうな った場合、チャンネルの名前は一時的に使えなくなります。チャンネルが使えない時 間は、一つ一つのIRCネットワークの基準に応じて調整されるべきです。重要なの は、ローカルユーザが同じ名前でチャンネルを作ることはできませんが、リモートユ ーザがチャンネルを作り直すことは妨げない、という点です。後者は通常、IRCネッ トワークが再接続したときに起こります。明らかに、このメカニズムは名前が'#'で 始まるチャンネルにのみ意味がありますが、名前が'+'で始まるチャンネルにも使わ れる「かもしれません」。このメカニズムは一般に"チャンネル遅延"として知られて います。 3.2 セーフチャンネル ほかのチャンネルと違い、"セーフチャンネル"は暗黙のうちには作られません。こ のようなチャンネルを作ろうとしているユーザは、チャンネル識別子(そのときはア ンノウンになっています)を'!'というキャラクタに置き換える特別なJOINコマンドを サーバに送ってチャンネル作成をリクエストし「なくてはなりません」。このタイプ のチャンネルの作成プロセスは、厳密にコントロールされています。 ユーザは単にチャンネルの名前の一部(チャンネル「ショート」ネームとして知ら れています)を選び、サーバは5文字からなるチャンネル識別子をユーザから与えられ た名前の前に自動的につけます。 この二つの要素の組み合わせからできたチャンネルの名前はユニークで、ネットワ ークの分断によるチャンネルの誤用からチャンネルを守ります。 このようなチャンネルを作ったユーザは、自動的に"チャンネルクリエータ"になり ます。詳細は2.4.2(チャンネルクリエータ)を見てください。 サーバは、おなじショートネームのチャンネルがある場合、もしくはおなじショー トネームのチャンネルが最近あり、「かつ」、そこにいたメンバーがネットワークの 分断のせいでいなくなった場合には、新しいチャンネルの作成を許しては「いけませ ん」。最後のユーザが抜けたあとで、「かつ」、ほかのメンバーが最近チャンネルネ ットワークの分断のためにそのチャンネルを抜けていなければ、このようなチャンネ ルは消えます。 5.2.2(チャンネル遅延)に述べるメカニズムと違い、このケースでは、チャンネル の名前は使えないようにはなりません。これらのチャンネルは最後のユーザが抜けた あとでも存在し続けることができます。チャンネルを作ったユーザだけが"チャンネ ルクリエータ"となり、空のチャンネルにあとで入ったユーザは自動的には"チャンネ ルクリエータ"にも"チャンネルオペレータ"にもなりません。 チャンネルの名前のユニーク性を確実にするため、サーバによって作られるチャン ネル識別子はルールに従ってつけられ「なくてはなりません」。詳しくは5.2.1 (チ ャンネル識別子)を見てください。 4. チャンネルモード チャンネルに使えるさまざまなモードは以下のとおりです。 O - "チャンネルクリエータ"の権限を付与 o - チャンネルオペレータの特権を付与/剥奪 v - ボイス特権を付与/剥奪 a - 匿名チャンネルフラグをトグル i - 招待のみチャンネルフラグをトグル m - モデレートチャンネルをトグル n - チャンネル外クライアントからのメッセージ遮断をトグル q - クワイエットチャンネルフラグをトグル p - プライベートチャンネルフラグをトグル s - シークレットチャンネルフラグをトグル r - サーバreopチャンネルフラグをトグル t - トピック変更をチャンネルオペレータのみに限定するかをトグル k - チャンネルキー(パスワード)の設定／解除 l - チャンネルのユーザ数制限の設定／解除 b - ユーザをシャットアウトする禁止(ban)マスクの設定／解除 e - 禁止マスクに優先する例外マスクの設定／解除 I - 自動的に招待のみフラグに優先する招待マスクの設定／解除 以下、特筆しない限り、これらすべてのモードは"チャンネルオペレータ"が、"IRC Client Protocol" [IRC-CLIENT]で定義されているモードコマンドをつかって操作で きます。 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メッセージをほかのチャンネルメンバーに送っては「だめ」です。かわりにPART メッセージを送らなくてはなりません。 プレフィックスが'&'のチャンネル上では、このフラグはチャンネルオペレータに よってトグルされる「可能性があります」が、プレフィックスが'!'のチャンネルで は、このフラグは"チャンネルクリエータ"によってのみ設定され得ます(しかし解除 は「され得ません」)。このフラグはほかのタイプのチャンネルでは使えては「いけ ません」。 WHOIS、WHO、NAMESコマンドへのリプライは、匿名フラグが設定されているチャン ネルのほかのユーザの存在を表しては「いけません」。 4.2.2 招待のみフラグ チャンネルフラグ'i'が設定されていたら、新しいメンバーはマスクが招待リスト (4.3.2参照)にマッチしているか、チャンネルオペレータに招待(invite)された場合 のみ、そのチャンネルに入れます。このフラグはまた、チャンネルオペレータへの INVITEコマンド("IRC Client Protocol" [IRC-CLIENT]参照)の使用制限も行います。 4.2.3 モデレートチャンネルフラグ 'm'というチャンネルフラグは、チャンネル上で誰が発言してよいかコントロール します。これが設定されている場合、チャンネルオペレータと、ボイス特権を与えら れているメンバーだけがメッセージをチャンネルに送ることができます。 このフラグはユーザにのみ関係あります。 4.2.4 チャンネル外クライアントからのメッセージ遮断 'n'というチャンネルフラグが設定してあると、チャンネルメンバーだけがそのチ ャンネルにメッセージをおくることが「できます」。 このフラグはユーザにのみ関係あります。 4.2.5 クワイエットチャンネル 'q'というチャンネルフラグはサーバのみが使えます。セットされると、ユーザに 送られるチャンネルオペレーションに関するある種のデータを制限します。ほかのユ ーザが入ってきたり、出て行ったり、ニックネームを変えたりしたということが送ら れません。ユーザの視点で見ると、チャンネルには一人のユーザしかいないように見 えます。 これは通常、サーバがオペレーションに関する注意を送る特別なローカルチャンネ ルを作るときに使われます。これはRFC 1459 [IRC]で定義されていた's'というユー ザモードをより効果的でフレキシブルにしたものです。 4.2.6 プライベート及びシークレットチャンネル 'p'というチャンネルフラグはチャンネルを"プライベート(private)"であることを 示すために、また's'というチャンネルフラグはチャンネルが"シークレット (secret)"であることを示すために使われます。どちらのプロパティも似ていて、ほ かのユーザからチャンネルが見えないようにします。 つまり、メンバーにならないとこのチャンネルの名前をサーバから取ることができ ないということです。ほかの言い方をすれば、これらのチャンネルはWHOISコマンド のようなクエリーに対しての返答をしなくてよいようになって「いなくてはなりませ ん」。 あるチャンネルが"シークレット"である場合、上記の制限に加えて、サーバは TOPIC、LIST、NAMESといったコマンドに対してこのチャンネルが存在しないかのよう に動作します。ただし一つだけこのルールに例外があります。サーバはMODEコマンド に対しては正しくリプライします。 最後に、<マスク>パラメータが設定されている場合には、シークレットチャンネル はLUSERSコマンド("Internet Relay Chat: Client Protocol" [IRC-CLIENT]を参照の こと)に対するリプライにおいて明らかにされません。 'p'、's'というチャンネルフラグは、同時にセットされては「いけません」。サーバ から出た'p'フラグと's'フラグをセットするMODEメッセージがすでにチャンネルにセ ットされていれば、変更は明示されずに無視されます。このことは分断を直す段階 ("IRC Server Protocol" document [IRC-SERVER]に述べられています)でのみ起こる でしょう。 4.2.7 サーバReopフラグ 'r'というチャンネルフラグは、'!'で始まる名前のチャンネルでのみ使えて、"チ ャンネルクリエータ"のみがトグル「でき」ます。 このフラグはチャンネルが長い時間チャンネルオペレータなしの状態になっている のを防ぐために使われます。このフラグが設定されると、"reop遅延"期間よりも長く チャンネルオペレータが一人もいない状態になっているチャンネルがあると、チャン ネルにいる人の一部か全員をreopするサーバのメカニズムが動きます。このメカニズ ムは5.2.4(Channel Reop Mechanism・・・とかいてあるけど、その番号のところには 違うことがかいてある！)に、より詳しく述べられています。 4.2.8 トピック 't'というチャンネルフラグは、チャンネルオペレータのTOPICコマンドの使用を制 限します。 4.2.9 ユーザ数の限界 'l'というチャンネルフラグを使えば、チャンネル上のユーザ数の制限ができま す。 制限いっぱいになってしまうと、サーバは自分のローカルユーザがそのチャン ネルに入るのを禁止し「なくてはなりません」。 制限値は、モードクエリーにサーバから送られるリプライでチャンネルメンバーに だけ使えるように「しなくてはなりません」。 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ではGMTで1970年1月1日の 00:00:00からたった秒数で定義されています)が以下のようなベースを使った5文字の 文字列にコンバートされます:"ABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890" (各々の文 字は、'A'が0から始まって'0'が35の10進数の値を持っています)。 というわけで、チャンネル識別子は36^5秒(約700日)の周期を持っています。 5.2.2 チャンネル遅延 これらのチャンネルは5.1(チャンネル遅延)で書かれている"チャンネル遅延"メカ ニズムに従わ「なくてはなりません」。しかしながら、このメカニズムはよりよく現 状にあうように、ちょっと変化させられています。 サーバは、ネットワークの分断の結果ユーザを失ったすべてのチャンネルの記録を 保持し「なくてはなりません」。失われたユーザが"チャンネルオペレータ"であるか どうかは問いません。 しかし、これらのチャンネルは使用不可にはなり「ません」。空っぽの場合でも入 ることができます。 5.2.3 Abuse Windowウィンドウ乱用？ 周期が長いため、一つのチャンネル(の名前)へのアタックは大変長い期間のうちに 一回しか起こり得ません。それでも、運がよかったり辛抱強かったりすれば、ユーザ がチャンネルの衝突を起こすことは可能ではあります。それをさけるために、サーバ は"未来を見"て、識別子がもうすぐ使うであろう(たとえば未来数日分の)チャンネル ネームのリストを保持し「なくてはなりません」。そのようなリストはサーバにとっ て重荷にならないように小さく保たれ、チャンネル遅延よりも長い期間そのようなチ ャンネルの作り直しをしないことで、チャンネルの衝突を避けるために使われます。 場合によっては、サーバがこの手続きを拡張して、おなじショートネームだけの (チャンネル識別子を無視した)チャンネルの作成を禁止するという選択をするという こともできます。 5.2.4 ネームスペースの平穏維持 5.2.2と5.2.3で述べられているメカニズムの組み合わせで、ユーザがチャンネルの 衝突を起こす恐れは大変小さくなります。しかし、おなじショートネームだけど識別 子が違うたくさんのチャンネルを作ることによるほかのタイプのabuseがあります。 こういうことが起こらないように、サーバは現在あるチャンネルとおなじショートネ ームの新しいチャンネルの作成を禁止し「なくてはなりません」。 5.2.5 サーバReopメカニズム チャンネルが"reop遅延"期間よりも長い時間オペレータ不在(opless)で、しかも 'r'チャンネルフラグ(4.2.7 (サーバReopフラグ)参照)が設定されている場合、IRCサ ーバはランダムなメンバーにチャンネルオペレータステータスを与える必要がありま す。 現在の実装でこのメカニズムに使われているロジックそのものは以下のとおりで す。サーバはほかのロジックを使っても「かまいません」。しかし、一貫性と公正さ を保持するため、一つのIRCネットワークの中ではすべてのサーバがおなじロジック を使うことが強く「推奨されます」。 おなじ理由で、"reop遅延"も一つのIRCネットワーク内のすべてのサーバで単一で ある「べき」です。"チャンネル遅延"と同様、"reop遅延"の値はIRCネットワークの サイズ(ユーザに関する)や、通常のネットワークの分断の時間など、さまざまなファ クターを考慮して設定される「べき」です。 a) reopメカニズムは、"reop遅延"が起こってからランダムな時間がたったとき 引き起こされます。これはおなじときにおなじチャンネルに2つの離れたサーバ がreopメカニズムを引き起こすという偶然性を制限するでしょう。 b) チャンネルが小さく(5ユーザかそれ以下くらい)、このチャンネルの"チャン ネル遅延"が満了した場合、少なくとも一人がそのサーバにとってローカルであ れば、すべてのチャンネルメンバーをreopします。 c) チャンネルが小さく(5ユーザかそれ以下くらい)、このチャンネルの"チャン ネル遅延"が満了し、さらに"reop遅延"がその値よりも長くなった場合、すべて のチャンネルメンバーをreopします。 d) ほかのケースでは、そのサーバに組み込まれている何らかの規則に基づいて そのチャンネルにいる最高一人のメンバーをreopします。メンバーのreopをし ないのであれば、ほかのサーバが誰かを操作するような規則をとっていなくて はなりません。規則はネットワーク上ですべておなじである「べき」です。よ き発見の助けは、単なるランダムなreopかもしれません。(現在の実装は実質的 に、場合によっては動作を延期して、そのサーバにとってローカルで長い間ア イドルでなかったメンバーを選ぼうとします。その間にほかのサーバは「あん まりアイドルでない」メンバーを見つけることができます。サーバは単に自分 のローカルユーザの"アイドル"な時間がわかってるだけだという事実のため、 これはあまりに込み入っています。) 6. 現状の問題点 IRCチャンネルを運営していくにあたってすでにわかっている問題がたくさんあり ます。この文書に出てくるルールに直接関係あるものもあるし、"IRC Server Protcol" [IRC-SERVER]の基礎となるものもあります。RFC 1459 [IRC]に由来すると はいえ、この文書は既知の問題を解決するため努力として、いくつかの新発案を紹介 します。 6.1 ラベル この文書はIRCプロトコルで使われるたくさんのラベルの一つを定義します。いく つかの明確なネームスペース(チャンネルネームプレフィックスに基づく)があります が、これらそれぞれの中での複製は許されていません。現在、違うサーバ上のユーザ は、衝突するかもしれないラベルを選ぶことが可能です(一つだけのサーバしか認識 していないチャンネルなら大丈夫という例外はありますが)。 6.1.1 チャンネル遅延 5.1(最近使われたチャンネルの記録)で述べられており、'#'というプレフィックス がついているチャンネルで使われるチャンネル遅延メカニズムは、衝突が起こるのを 防ぐシンプルな試みです。経験から、普通の環境ならこれは大変有効だということが わかっています。しかしながらこの方法には、ここで述べる問題のよき解決になれな い明らかな限界があります。 6.1.2 セーフチャンネル 3.2(セーフチャンネル)で述べられている"セーフチャンネル"は、ユーザが自分が 選んだラベルをすっかりコントロールできないようにする点で、チャンネルの衝突を 避けるまあまあいい方法です。明らかによくない点は、そのようなラベルはユーザー フレンドリーでないということです。 しかし、クライアントプログラムにこれを実装するのは簡単なことです。 6.2 モード伝達遅延 ネットワークに誘発されたネットワーク遅延のため、あるいはパス上のすべてのサ ーバがモード変更の妥当性(たとえば、ユーザが存在しており正しい特権をもってい るかなど)をチェックする「必要がある」ため、モードメッセージがネットワークの 一部のみに関係することは少なく、また大概、チャンネルの現在の状態についてサー バ間でずれが生じてしまいます。 これは簡単に直せるように思えるのですが(もともとのサーバだけがモード変更の 妥当性をチェックするようにすることで)、さまざまな理由でそうしないことに決め られました。一つ関係あるのは、サーバはお互いを信頼できないし、間違った動作を しているサーバは簡単に分かるからです。こうすることにより、違う方向からのモー ドチェンジがきたときに同期の取れていないチャンネルに対する波状効果を止めるこ ともできます。 6.3 衝突とチャンネルモード "Internet Relay Chat: Server Protocol"ドキュメント[IRC-SERVER]で、二つのサ ーバがつながれたときにチャンネルデータがどのようにやり取りされるかが述べられ ています。チャンネル衝突は(正当かどうかにかかわらず)包括的なイベントとして取 り扱われます。つまり、その結果できるチャンネルは、接続の前に両方のサーバ上の チャンネルのメンバーであったすべてのユーザを持つということになります。 同様に、各々のサーバはチャンネルモードを相手に送ります。そのため各々のサー バがこれらのチャンネルモードを受け取りもします。チャンネルにはフラグ、マス ク、データという3つのタイプのモードがあります。前二つのタイプは設定されるか されないかだけなので、簡単に扱えます。そのようなモードが片方のサーバで設定さ れたら、接続の結果、ほかのサーバでも設定され「なくてはなりません」。 トピックはこのやり取りの中では送られないので、問題にはなりません。しかし 'l'と'k'というチャンネルモードはやり取りされ、接続前に両方のサーバに設定され ていると、どちらが優先されるか決めるメカニズムはありません。このずれを直すこ とはユーザに任されています。 6.4 リソースの枯渇 4.3で書かれているマスクに基づくモードは、IRCサーバ(とIRCネットワーク)を単 純なabuseに対して弱くしています。たった一人のチャンネルオペレータが、できる 限りのマスクを一個のチャンネルに設定できるのです。このことで簡単にサーバがメ モリー、そしてネットワークの帯域(情報は他のサーバに送られるため)を無駄に使っ てしまいます。このような理由で、4.3で述べられているように、チャンネル毎のそ のようなマスクの数に制限を設けることが「推奨されます」。 さらに、同じチャンネルに設定される余計なマスクを避けるためにもっと複雑なメ カニズムが使われる「可能性もあります」。 7. セキュリティについての配慮 7.1 アクセスコントロール チャンネルへのアクセスをコントロールする主要な方法の一つは、ユーザネームや ユーザのホストネームに基づくマスクを使う方法です。このメカニズムは、IRCサー バがユーザの接続を認証する正確な方法をもっており、ユーザがそれを簡単にごまか せないようになっている場合にのみ、有効で安全です。理論上はそのような厳密な認 証メカニズムを実装することは可能ですが、ほとんどのIRCネットワーク(特に公開の ネットワーク)にはこのような機構はなく、クライアントの接続に関してのユーザネ ームやホストネームの正しさについての保証は、あまりありません。 別なアクセスのコントロール方法は、チャンネルキーを使うことです。しかしこの キーはプレーンテキストの形で送られるので、経路上でのアタックに対しては弱いと いうことになります。 7.2 チャンネルプライバシー チャンネルの衝突は包括的なイベントとして扱われるので(6.3参照)、そのチャン ネルのアクセスコントロール設定にかかわらず、ユーザがチャンネルに入ることが可 能です。この方法は長らく、そのチャンネルのチャンネルオペレータステータスを手 に入れることで"非合法的に"チャンネルを"譲り受ける"ために使われてきました。お なじやり方で、あるチャンネルのメンバーのリストを手に入れることもできるし、そ のチャンネルに送られたメッセージを受け取ることも可能です。 7.3 匿名性 匿名チャンネルフラグ(4.2.1参照)は、そのチャンネル宛てのすべてのメッセージ をニックネームが"anonymous"という偽名のユーザからのメッセージであるとして表 示することで、そのチャンネルのすべてのユーザを"anonymous"と表示するために使 えます。このことはクライアント-サーバレベルで行われるもので、サーバ-サーバレ ベルでは匿名性はありません。 読者の皆様にはおわかりだと思いますが、提供されている匿名性のレベルは大変貧 弱でセキュアでないので、クライアントプログラムはそのようなチャンネルに参加す るユーザに対して強く警告する「べき」です。 8. 現在のサポートおよび入手先 IRC関係の議論のメーリングリスト: 一般議論: ircd-users@irc.org プロトコル開発: ircd-dev@irc.org ソフトウエアの実装: ftp://ftp.irc.org/irc/server ftp://ftp.funet.fi/pub/unix/irc ftp://coombs.anu.edu.au/pub/irc ニュースグループ: 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. 筆者の連絡先 Christophe Kalt 99 Teaneck Rd, Apt #117 Ridgefield Park, NJ 07660 USA EMail: kalt@stealth.net 12. コピーライトの完全記述 Copyright (C) The Internet Society (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. 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 PARTICOLAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. 13. 日本語訳にあたって 関わった人と会社は下記のとおりです。 * 齋藤華子 (翻訳) * ワタナヴェイタル (HTML化) * 株式会社タフ (編集) 翻訳の正確さには可能なかぎりの努力をはらいましたが、不正確な部分や「よくない 訳」もまだまだあると思います。より正確な情報を求める方は原文も参照してくださ い。もし、誤訳や誤植を発見したり、もっといい翻訳があると思われた方は(株)タフ までご連絡ください。今後も継続的にメンテナンスしていく予定です。 [最終更新: 2000年8月8日]