Network Working Group                                           C. Kalt
Request for Comments: 2813                                   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）プロトコルは、クライアント・サーバモデルをベースとしながらも、サーバ同士が効果的にネットワークを形成することを可能にしています。

この文書では、サーバが相互に通信するために使用するプロトコルを定義しています。元々はクライアントプロトコルのスーパーセットでしたが、異なる進化を遂げました。

1993年5月に RFC 1459 [IRC] の一部として初めて正式に文書化され、それ以降にもたらされた変更のほとんどは、プロトコルの拡張性に重点を置いて開発されたため、ほとんどの変更点はこのドキュメントに記載されています。スケーラビリティの向上により、既存のワールドワイドなネットワークは成長を続け、旧来の仕様では考えられなかった規模に到達することができるようになりました。

1. 序説

この文書は、IRC サーバの実装に取り組んでいる人々を対象としていますが、IRC サービスを実装している人にも役に立つでしょう。

サーバは、"Internet Relay Chat: アーキテクチャ" [IRC-ARCH] で定義されたリアルタイム会議に必要な3つの基本サービスを提供します。クライアントプロトコルによるクライアントロケータ [IRC-CLIENT]、この文書で定義されたサーバプロトコルによるメッセージ中継、特定の規則に従ったチャネルのホストと管理 [IRC-CHAN] です。

2. グローバルデータベース

IRC プロトコルはかなり分散したモデルを定義していますが、各サーバは IRC ネットワーク全体に関する "グローバルな状態データベース" を維持します。このデータベースは理論上、すべてのサーバで同一です。

2.1 サーバ

サーバは、最大63文字からなる名前によって一意に識別されます。サーバ名に使用できるものとできないものについては、プロトコルの文法規則（3.3.1 項）を参照してください。

各サーバは通常、他のすべてのサーバによって知られていますが、"ホストマスク" を定義して、サーバをその名前に従ってグループ化することが可能です。ホストマスク領域内では、すべてのサーバがホストマスクに一致する名前を持ち、ホストマスクに一致する名前を持つ他のサーバは、ホストマスク領域外の IRC ネットワークに接続してはなりません。領域の外にいるサーバは、領域内に存在する個々のサーバについて何も知りませんが、その代わりに名前にホストマスクを持つ仮想サーバが提示されます。

2.2 クライアント

各クライアントに対して、すべてのサーバは以下の情報を持つ必要があります。

ネットワイド一意識別子（その形式はクライアントの種類によって異なります）。
およびクライアントが接続されているサーバ。

2.2.1 ユーザ

各ユーザは、最大9文字のユニークなニックネームによって他のユーザと区別されます。ニックネームに使用できるもの、できないものについてはプロトコルの文法規則（3.3.1 項）を参照してください。ニックネームに加えて、全てのサーバは全てのユーザについて以下の情報を持っている必要があります。

ユーザが実行されているホスト名。
そのホストでのユーザのユーザ名。
クライアントが接続されているサーバ。

2.2.2 サービス

各サービスは、ニックネームとサーバ名からなるサービス名で他のサービスと区別されます。ニックネームは最大9文字です。ニックネームに使用できるもの、できないものについてはプロトコルの文法規則（3.3.1 項）を参照してください。サービス名を構成するのに使われるサーバ名は、そのサービスが接続されているサーバの名前です。このサービス名に加えて、すべてのサーバはサービスタイプを知っている必要があります。

サービスはその識別子のフォーマットによってユーザと異なりますが、より重要なのは、サービスとユーザはサーバに対して同じ種類のアクセスを持っていないことです。サービスは、サーバが保持するグローバルな状態情報の一部または全部を要求することができますが、利用できるコマンドはより制限されます。（これについての詳細は "IRC クライアントプロトコル" [IRC- CLIENT] 参照。）また、チャネルへの参加が許可されていません。最後に、サービスは通常 5.8 節で説明されている "大量リクエスト対策" メカニズムの対象にはなりません。

2.3 チャネル

サービスと同様に、チャネルにもスコープ [IRC-CHAN] があり、必ずしもすべてのサーバに知られているわけではありません。チャネルの存在がサーバに知られている場合、サーバはチャネルのモードと同様にチャネルのメンバを記録しておかなければなりません。

3. IRC サーバ仕様

3.1 概要

ここで説明するプロトコルは、サーバ間の接続で使用するためのものです。クライアントからサーバへの接続については、IRC クライアントプロトコル仕様を参照してください。

ただし、サーバ接続よりも（信用できないとされる）クライアント接続の方が、より多くの制約があります。

3.2 文字コード

特定の文字セットは指定しません。プロトコルは、8ビットで構成されるオクテットという符号体系を基本としています。各メッセージはこのオクテットの数で構成されますが、一部のオクテット値はメッセージの区切りとなる制御コードに使用されます。

8ビットプロトコルであるにもかかわらず、デリミタとキーワードがあるため、US-ASCII の端末と telnet 接続でほとんど使用可能です。

IRC はスカンジナビア語が起源なので、{}|^ という文字は、それぞれ []\~ という文字に相当する小文字とみなされます。これは、2つのニックネームやチャネル名の等価性を判断する際に重要な問題です。

3.3 メッセージ

サーバとクライアントは互いにメッセージを送信し、その応答が発生することもあれば、発生しないこともあります。サーバはクライアントのためにルーティングタスクを行うことが多いため、サーバ間の通信のほとんどは応答を生成しません。

各 IRC メッセージは、接頭辞（オプション）、コマンド、コマンドパラメータ（最大15個）の最大3つの主要部分から構成されることができます。接頭辞、コマンド、およびすべてのパラメータは、それぞれ1つの ASCII スペース文字（0x20）で区切られます。

接頭辞の存在は、先頭の ASCII コロン文字（:、0x3b）1つで示され、これはメッセージ自体の最初の文字でなければなりません。コロンと接頭辞の間に隙間（ホワイトスペース）を入れてはいけません。接頭辞は、サーバがメッセージの本当の出所を示すために使われます。接頭辞がない場合、そのメッセージは受信したコネクションから発信されたものとみなされます。クライアントは自分からメッセージを送るときには接頭辞を使うべきではありません。もし使うなら、有効な接頭辞はそのクライアントに関連付けられた登録済みのニックネームだけです。

サーバーはメッセージを受信すると、最終的に想定される接頭辞を使用してその送信元を特定する必要があります。サーバ内部のデータベースで接頭辞が見つからない場合は破棄し、接頭辞が不明なサーバからのメッセージであることを示す場合は、そのメッセージを受信したリンクを切断しなければなりません。このような状況でリンクを落とすことは少し過剰ですが、ネットワークの整合性を維持し、将来の問題を防ぐために必要なことです。もう一つの一般的なエラー条件は、サーバー内部のデータベースで見つかった接頭辞が、メッセージが到着した場所とは異なるリンクから登録された別のソースを識別することです。メッセージがサーバリンクから受信され、接頭辞がクライアントを識別する場合、クライアントに対して KILL メッセージを発行し、全サーバに送信しなければなりません。その他の場合、メッセージが到着したリンクは、クライアントの場合は破棄されるべきで、サーバの場合は破棄されなければなりません。いずれの場合も、メッセージは破棄されなければなりません。

コマンドは、有効な IRC コマンドか、ASCII テキストで表現された3桁の数字でなければなりません。

IRC メッセージは常に CR-LF（キャリッジリターン-ラインフィード）のペアで終了する文字の行であり、これらのメッセージは最後の CR-LF を含むすべての文字をカウントして512文字を超えないものとします。従って、コマンドとそのパラメータには最大510文字が許されます。継続メッセージ行の規定はありません。現在の実装の詳細については、5 章を参照してください。

3.3.1 拡張 BNF によるメッセージフォーマット

プロトコルメッセージは、オクテットの連続したストリームから抽出されなければなりません。現在の解決策は、CR と LF という2つの文字をメッセージのセパレータとして指定することです。空のメッセージは黙って無視されるので、メッセージ間で CR-LF のシーケンスが余分な問題なく使用できるようになります。

抽出されたメッセージは、<prefix>、<command>、パラメータのリスト（<params>）という構成要素にパースされます。

このための拡張 BNF 表現は、"IRC Client Protocol" [IRC-CLIENT] にあります。

拡張接頭辞（[! ユーザ、@ ホスト ]）は、サーバ間通信では使用してはならず、サーバからクライアントへのメッセージにのみ使用し、クライアントが追加の問い合わせをしなくてもメッセージの送信元に関するより有用な情報を提供することを目的としています。

3.4 数値返信

サーバに送信されたメッセージのほとんどは、何らかの応答を生成します。最も一般的な返信は数値による返信で、エラーと正常な返信の両方に使用されます。数値返信は、送信者接頭辞、3桁の数値、リプライのターゲットからなる1つのメッセージとして送信する必要があります。サーバがこのようなメッセージを受信すると、静かに削除されます。キーワードが文字列ではなく3桁の数字で構成されていることを除けば、他のすべての点で、数値による返信は通常のメッセージと同じです。異なる返信のリストは "IRC クライアントプロトコル" [IRC-CLIENT] で提供されています。

4. メッセージの詳細

IRC サーバとクライアントが認識するすべてのメッセージは、IRC クライアントプロトコル仕様に記述されています。

ERR_NOSUCHSERVER が返信された場合、メッセージのターゲットが見つからなかったことを意味します。サーバは、このエラー以降、そのコマンドに対して他の応答を送ってはなりません。

クライアントが接続されているサーバは、メッセージ全体を解析し、適切なエラーを返すことが要求されます。メッセージの解析中に致命的なエラーが発生した場合、クライアントにエラーを返し、解析は終了しなければなりません。致命的なエラーは、不正なコマンド、サーバにとって未知の宛先（サーバ、クライアント、チャネル名がこれに該当）、十分でないパラメータ、不正な権限に起因する場合があります。

パラメータの完全なセットが提示された場合、それぞれの有効性をチェックし、適切なレスポンスをクライアントに返さなければなりません。コンマを区切り文字としてパラメータリストを使用するメッセージの場合、各項目に対して応答を送信しなければなりません。

以下の例では、一部のメッセージはフルフォーマットで表示されます。

:Name COMMAND parameter list

このような例は、"Name" からのメッセージがサーバ間で転送されていることを表しています。リモートサーバが正しい経路で返信できるように、メッセージの元の送信者の名前を含めることが不可欠です。

クライアントからサーバへの通信のためのメッセージの詳細は、"IRC クライアントプロトコル" [IRC-CLIENT] に記述されています。以下のページのいくつかの章は、これらのメッセージの一部に適用されます。それらは、サーバ間の通信にのみ関連するメッセージの仕様への追加、またはサーバの実装への追加です。ここで紹介するメッセージは、サーバ間通信にのみ使用されるものです。

4.1 接続登録

ここで説明するコマンドは、他の IRC サーバとの接続を登録するために使用されます。

4.1.1 Password メッセージ

   Command: PASS
Parameters: <password> <version> <flags> [<options>]

PASS コマンドは、"接続パスワード" を設定するために使用します。このパスワードは、接続を登録しようとする前に設定する必要があります。現在、これはサーバが SERVER コマンドの前に PASS コマンドを送信する必要があることを意味します。PASS コマンドは、1つの接続に対して1つだけ受け付けます。

最後の3つのパラメータは、クライアント（ユーザやサービスなど）から受信した場合は無視しなければなりません。これらは、サーバから受信した場合にのみ関連します。

<version> パラメータは，最低4文字，最高14文字までの文字列を指定します。最初の4文字は数字でなければならず，メッセージを発行するサーバが知っているプロトコルのバージョンを示します。この文書で記述されるプロトコルはバージョン 2.10 であり，0210 と符号化されます。残りのオプションのキャラクタは実装に依存し、ソフトウェアのバージョン番号を記述する必要があります。

<flags> パラメータは最大100文字の文字列です。文字 |（%x7C）で区切られた2つの部分文字列で構成されます。存在する場合、最初の部分文字列は実装の名前でなければなりません。参考実装（8. 現在のサポートと可用性参照）では、"IRC" という文字列を使用しています。識別子を必要とする別の実装が書かれた場合、その識別子は RFC の発行を通じて登録される必要がありませす。2番目の部分文字列は実装に依存します。どちらの文字列もオプションですが，文字 | は必須です。文字 | は，いずれの部分文字列にも出現してはなりません。

最後のパラメータである <options> はリンクオプションに使用されます。プロトコルで定義されているオプションは、リンク圧縮（文字 Z を使用）と不正利用防止フラグ（文字 P を使用）のみです。これらのオプションの詳細については、それぞれ 5.3.1.1 圧縮されたサーバ間リンクと 5.3.1.2 不正利用防止対策を参照してください。

数値返信：

        ERR_NEEDMOREPARAMS              ERR_ALREADYREGISTRED

例：

     PASS moresecretpassword 0210010000 IRC|aBgH$ Z

4.1.2 Server メッセージ

   Command: SERVER
Parameters: <servername> <hopcount> <token> <info>

SERVER コマンドは、新しいサーバを登録するために使用されます。新しい接続は、その相手に対して自分自身をサーバとして紹介します。このメッセージは、サーバのデータをネット全体に渡すためにも使われます。新しいサーバがネットに接続されると、そのサーバに関する情報はネットワーク全体にブロードキャストされなければなりません。

<info> パラメータには空白文字が含まれることがあります。

<hopcount>は、各サーバがどの程度離れているかという内部情報を全サーバに与えるために使用されます。ローカルピアの値は 0 で、渡されたサーバごとに値が増加します。完全なサーバリストがあれば、サーバツリー全体のマップを作成することが可能ですが、ホストマスクがこれを阻んでいます。

<token> パラメータは、サーバが識別子として使用する符号なし数字です。この識別子は、その後サーバ間で送信される NICK および SERVICE メッセージでサーバを参照するために使用されます。サーバトークンは、使用されるポイントツーポイントピアリングでのみ意味を持ち、その接続で一意でなければなりません。これらはグローバルではありません。

SERVER メッセージは、(a) まだ登録されておらず、サーバとして登録しようとしている接続、または (b) 他のサーバへの既存の接続、この場合、SERVER メッセージはそのサーバの後ろに新しいサーバを紹介している、のいずれかからのみ受け入れられなければなりません。

SERVER コマンドを受信した際に発生するエラーの多くは、宛先ホスト（ターゲットサーバ）によって接続が切断されることになります。このような事象は重大であるため、エラーの返答は通常、数値ではなく "ERROR" コマンドを使用して送信されます。

SERVER メッセージが解析され、それが受信サーバにすでに知られているサーバを紹介しようとした場合、サーバへの重複したルートが形成され、IRC ツリーの非周期性が壊れるため、そのメッセージが到着した接続は（正しい手順で）閉じられなければなりません。条件によっては、すでに知られているサーバが登録されている接続を代わりに閉じてもかまいません。この種のエラーは、2番目に稼働しているサーバの問題である可能性もあり、プロトコル内で修正することはできず、通常は人間の介入を必要とすることに注意する必要があります。この種の問題は、IRC ネットワークの一部が簡単に孤立してしまい、それぞれのパーティションに接続されている2台のサーバのうち1台が、2つのパーティションを結合することができなくなるため、特に陰湿なものとなっています。

数値返信：

        ERR_ALREADYREGISTRED

例：

SERVER test.oulu.fi 1 1 :Experimental server
    ; 新しいサーバ test.oulu.fi が自己紹介し、登録を試みています。

:tolsun.oulu.fi SERVER csd.bu.edu 5 34 :BU Central Server
    ; サーバ tolsun.oulu.fi は、5ホップ離れている csd.bu.edu へのアップリンクです。
      トークン "34" は、csd.bu.edu に接続する新しいユーザやサービスを紹介する際に、tolsun.ulu.fi によって使用されます。

4.1.3 Nick

   Command: NICK
Parameters: <nickname> <hopcount> <username> <host> <servertoken>
            <umode> <realname>

この形式の NICK メッセージは、ユーザ接続から許可されてはいけません。しかし、IRC ネットワークに新しいユーザが参加したことを他のサーバに通知するために、NICK/USER ペアの代わりに使用する必要があります。

このメッセージは、実際には3つの異なるメッセージが組み合わされたものです。NICK、USER、MODE [IRC-CLIENT] です。

<hopcount> パラメータは、ユーザがホームサーバからどのくらい離れているかを示すためにサーバが使用します。ローカル接続の場合、ホップカウントは 0 です。ホップカウントの値は、渡されたサーバごとに増加されます。

<servertoken> パラメータは USER の <servername> パラメータを置き換えます（サーバートークンの詳細については 4.1.2 項を参照してください）。

例：

NICK syrk 5 kalt millennium.stealth.net 34 +i :Christophe Kalt
    ; ニックネーム "syrk"、ユーザ名 "kalt" の新規ユーザが、
      ホスト "millennium.stealth.net" からサーバ "34" （前の例では "csd.bu.edu"）に接続した場合。

:krys NICK syrk
    ; "IRC クライアントプロトコル" [IRC-CLIENT] で定義され、サーバ間で使用される NICK メッセージのもう一つの形式：
      krys はニックネームを syrk に変更しました。

4.1.4 Service メッセージ

   Command: SERVICE
Parameters: <servicename> <servertoken> <distribution> <type>
             <hopcount> <info>

SERVICE コマンドは、新しいサービスを導入するために使用されます。この形式の SERVICE メッセージは、クライアント（未登録、または登録済み）接続から許可されるべきではありません。しかし、IRC ネットワークに参加する新しいサービスを他のサーバに通知するために、サーバ間で使用されなければなりません。

<servertoken> は、サービスが接続されているサーバを識別するために使用されます。（サーバートークンの詳細については、4.1.2 節を参照してください）。

<hopcount> パラメータは、サーバが、あるサービスがホームサーバからどれだけ離れているかを示すために使用されます。ローカル接続の場合、ホップカウントは 0 です。ホップカウントの値は、渡されたサーバによって増加します。

<distribution> パラメータは、サービスの可視性を指定するために使用します。サービスは、ディストリビューションに一致する名前を持つサーバにのみ知られている可能性があります。一致するサーバがサービスを知るためには、そのサーバとサービスの接続先サーバとの間のネットワーク経路が、すべてマスクに一致する名前を持つサーバで構成されている必要があります。制限をかけない場合は、プレーンな * を使用します。

<type> パラメータは現在、将来の使用のために予約されています。

数値返信：

        ERR_ALREADYREGISTRED            ERR_NEEDMOREPARAMS
        ERR_ERRONEUSNICKNAME
        RPL_YOURESERVICE                RPL_YOURHOST
        RPL_MYINFO

例：

VICE dict@irc.fr 9 *.fr 0 1
    ; サーバ "9" に登録されている "フランス語辞書 r" を他のサーバにアナウンスしています。
     このサービスは、サーバ名が "*.fr" に一致するサーバでのみ利用可能です。

4.1.5 Quit

   Command: QUIT
Parameters: [<Quit Message>]

クライアントのセッションは QUIT メッセージで終了します。サーバは、QUIT メッセージを送信したクライアントとの接続を終了しなければなりません。"終了メッセージ" が指定された場合、デフォルトのメッセージ、ニックネーム、サービス名の代わりにこれが送られます。

"ネットスプリット"（4.1.6 節参照）が発生した場合、"終了メッセージ" は関係する2つのサーバの名前をスペースで区切って構成されます。最初の名前はまだ接続しているサーバの名前であり，2番目の名前は切断されたサーバの名前、または離脱したクライアントが接続していたサーバの名前です。

   <Quit Message> =  ":" servername SPACE servername

"終了メッセージ" は "ネットスプリット" に対して特別な意味を持つので、サーバはクライアントが上記のような形式の <Quit Message> を使用することを許可してはいけません。

その他の理由で、クライアントが QUIT コマンドを発行せずにクライアント接続を閉じた場合（例：クライアントが死亡し、ソケットで EOF が発生）、サーバは、その原因となったイベントの性質を反映した何らかのメッセージで、終了メッセージを埋める必要があります。一般的に、これはシステム固有のエラーを報告することによって行われます。

数値返信：

        None.

例：

:WiZ QUIT :Gone to have lunch
    ; 望ましいメッセージの形成。

4.1.6 Server quit メッセージ

   Command: SQUIT
Parameters: <server> <comment>

SQUITメッセージには、2つの明確な使い方があります。

最初のもの（"Internet Relay Chat: クライアントプロトコル" [IRC-CLIENT] で説明）は、オペレータがローカルまたはリモートサーバのリンクを切断することを可能にします。この形式のメッセージは、最終的にはサーバがリモートサーバのリンクを切断するためにも使用されます。

このメッセージの2つ目の用途は、"ネットワークスプリット"（"ネットスプリット"とも呼ばれる）が発生したとき、言い換えれば、終了したサーバや死んだサーバを他のサーバに知らせるために必要です。あるサーバが他のサーバとの接続を切断したい場合、他のサーバに SQUIT メッセージを送信する必要があります。このとき、サーバパラメータとして他のサーバの名前を使用し、サーバは終了するサーバとの接続を切断します。

<comment> は、エラーメッセージや同様のメッセージをここに置くべきサーバによって埋められます。

コネクションを閉じた側のサーバは、そのリンクの背後にあると考えられる他のすべてのサーバのコネクションに対して、SQUIT メッセージを送信する必要があります。

同様に、QUIT メッセージは、その終了するリンクの背後にあるすべてのクライアントに代わって、まだ接続している他のサーバに送信されるかもしれません。これに加えて、"分割" によってメンバを失ったチャネルの全メンバに QUIT メッセージを送らなければなりません。チャネルメンバへのメッセージは、各クライアントのローカルサーバで生成されます。

サーバ接続が早期に切断された場合（リンクの反対側のサーバが死んだなど）、この切断を検出したサーバは、ネットワークの残りの部分に接続が終了したことを通知し、コメントフィールドに適切な内容を記入することが要求されます。

SQUIT メッセージの結果としてクライアントが削除されたとき、サーバは将来のニックネームの衝突を防ぐために、一時的に利用できないニックネームのリストにニックネームを追加すべきです。この手順の詳細については 5.7 最近使ったニックネームの追跡を参照してください。

数値返信：

        ERR_NOPRIVILEGES                ERR_NOSUCHSERVER
        ERR_NEEDMOREPARAMS

例：

SQUIT tolsun.oulu.fi :Bad Link ?
    ; tolson.oulu.fi のサーバリンクは "Bad Link" のため、終了しました。

:Trillian SQUIT cm22.eng.umd.edu :Server out of control
    ; Trillian からの "Server out of control" のため
      "cm22.eng.umd.edu" をネットから切断するというメッセージ。

4.2 チャネル操作

このメッセージ群は、チャネル、そのプロパティ（チャネルモード）、およびそのコンテンツ（通常はユーザ）を操作することに関係しています。これらの実装では、ネットワークの反対側の端にいるユーザがコマンドを送信すると、最終的に衝突することになるため、多くのレースコンディションが不可避となります。また、<nick> パラメータが与えられると、それが最近変更された場合に備えて、サーバがその履歴をチェックすることを保証するために、ニックネームの履歴を保持することが要求されています。

4.2.1 Join メッセージ

   Command: JOIN
Parameters: <channel>[ %x7 <modes> ]
            *( "," <channel>[ %x7 <modes> ] )

JOIN コマンドは、クライアントが特定のチャネルのリスニングを開始するために使用されます。クライアントがチャネルに参加できるかどうかは、クライアントが接続しているローカルサーバのみが確認します。他のサーバは、他のサーバからコマンドを受信すると、自動的にユーザをチャネルに追加します。

オプションとして、制御 G（^G または ASCII 7）をセパレータとして、チャネルのユーザステータス（チャネルモード O, o, v）をチャネル名に付加することができます。このようなデータは、メッセージがサーバから受信されていない場合は無視されなければなりません。このフォーマットはクライアントに送信してはならず、サーバ間でのみ使用可能であり、避けるべきです。

JOIN コマンドは全サーバにブロードキャストされ、各サーバがチャネルに参加しているユーザの居場所を知ることができるようにする必要があります。これにより、PRIVMSG と NOTICE メッセージがチャネルに最適に配信されます。

数値返信：

        ERR_NEEDMOREPARAMS              ERR_BANNEDFROMCHAN
        ERR_INVITEONLYCHAN              ERR_BADCHANNELKEY
        ERR_CHANNELISFULL               ERR_BADCHANMASK
        ERR_NOSUCHCHANNEL               ERR_TOOMANYCHANNELS
        ERR_TOOMANYTARGETS              ERR_UNAVAILRESOURCE
        RPL_TOPIC

例：

:WiZ JOIN #Twilight_zone
    ; WiZ からの JOIN メッセージ

4.2.2 Njoin メッセージ

   Command: NJOIN
Parameters: <channel> [ "@@" / "@" ] [ "+" ] <nickname>
                      *( "," [ "@@" / "@" ] [ "+" ] <nickname> )

NJOIN メッセージは、サーバ間でのみ使用されます。クライアントからこのようなメッセージを受信した場合、無視しなければなりません。2台のサーバが接続し、各チャネルのチャネルメンバー一覧を交換するときに使用されます。

JOIN を連続させることで同じ機能を実現することができますが、より効率的であるため、このメッセージを代わりに使用することが望まれます。接頭辞 @@ は "チャネル作成者"、@ のみは "チャネルオペレータ"、+は "音声権限者" であることを示します。

数値返信：

        ERR_NEEDMOREPARAMS              ERR_NOSUCHCHANNEL
        ERR_ALREADYREGISTRED

例：

:ircd.stealth.net NJOIN #Twilight_zone :@WiZ,+syrk,avalon
    ; ircd.stealth.net からの NJOIN メッセージで、#Twilight_zone チャネルに参加するユーザをお知らせしています。
      WiZ はチャネルオペレータ、syrk は音声権限、avalon は権限なし。

4.2.3 Mode メッセージ

MODE メッセージは、IRC では2つの目的で使われるコマンドです。ユーザ名とチャネルの両方にモードを変更させることができます。

MODE メッセージを解析する場合、まずメッセージ全体を解析し、その結果生じた変更を引き継ぐことをお勧めします。

"チャネル作成者" と "チャネルオペレータ" を作成できるように、サーバがチャネルモードを変更できることが必要です。

5. 実装内容

このプロトコルの現在の実装は、執筆時点では IRC サーバのバージョン 2.10 のみです。それ以前のバージョンでは、このドキュメントで説明されているコマンドの一部または全部を、数値返信の多くを NOTICE メッセージに置き換えて実装しているかもしれません。残念ながら、後方互換性の要求のために、この文書のいくつかの部分の実装は、レイアウトされたものと異なっています。顕著な違いの1つは

メッセージ内の任意の LF または CR は、CR-LF を必要とする代わりに、そのメッセージの終わりをマークすることを認識します。

この章の残りの部分は、主にサーバを実装しようとする人にとって重要な問題を扱っていますが、いくつかの部分はクライアントにも直接適用されます。

5.1 接続の '有効性'

接続が切れたり応答しなくなったりしたことを検出するために、サーバは各接続をポーリングする必要があります。PING コマンド（"IRC クライアントプロトコル" [IRC-CLIENT] 参照）は、サーバが一定時間内に相手から応答を得られない場合に使用されます。

接続が時間内に応答しない場合、その接続は適切な手順で閉じられます。

5.2 クライアントからサーバへの接続受入れ

5.2.1 ユーザ

サーバは、新しいユーザ接続の登録に成功した場合、ユーザに対して以下のような明確なメッセージを送信することが要求されます。登録されたユーザー識別子（RPL_WELCOME）、サーバ名とバージョン（RPL_YOURHOST）、サーバ誕生情報（RPL_CREATED）、利用可能なユーザモードとチャネルモード（RPL_MYINFO）。と、適切と思われる紹介メッセージを送信することができます。

特に、サーバは LUSER 応答で現在のユーザ／サービス／サーバ数を送信し、最後に MOTD 応答で MOTD があればそれを送信します。

登録を処理した後、サーバは新しいユーザのニックネーム（NICK メッセージ）、それ自身から提供されたその他の情報（USER メッセージ）、およびサーバが DNS サーバから発見できたものを他のサーバに送信しなければなりません。サーバはこの情報を "IRC クライアントプロトコル" [IRC-CLIENT] で定義されているように NICK と USER メッセージのペアで送信してはいけませんが、代わりに 4.1.3 項で定義されている拡張 NICK メッセージを活用しなければなりません。

5.2.2 サービス

新しいサービス接続の登録に成功すると、サーバにはユーザと同じ種類の要件が適用されます。サービスは多少異なるため、以下の応答のみが送信されます。rpl_youreservice, rpl_yourhost, rpl_myinfo。

これを処理した後、サーバは新しいサービスのニックネームとサービスから提供されたその他の情報（SERVICE メッセージ）およびサーバが DNS サーバから発見できた情報を他のサーバに SERVICE メッセージで送信しなければなりません。

5.3 サーバ-サーバの接続確立

サーバ間接続のプロセスは、レースコンディションを筆頭に、問題が発生する可能性のある領域が数多く存在するため、危険と隣り合わせなのです。

サーバは、有効であると認識された PASS/SERVER のペアに続く接続を受け取った後、その接続に対する自身の PASS/SERVER 情報と、以下に述べるように知っている他のすべての状態情報を返信する必要があります。

開始サーバは PASS/SERVER のペアを受け取ると、応答したサーバが適切に認証されていることを確認した上で、そのサーバへの接続を受け入れます。

5.3.1 リンクオプション

サーバリンクは共通のプロトコル（本書で定義）に基づきますが、特定のリンクは PASS メッセージを用いて特定のオプションを設定することができます（4.1.1 項参照）。

5.3.1.1 圧縮されたサーバ間リンク

サーバが相手と圧縮リンクを確立したい場合は、PASS メッセージのオプションパラメータに "Z" フラグを設定する必要があります。両方のサーバが圧縮を要求し、両方のサーバが2つの圧縮されたストリームを初期化できる場合、残りの通信は圧縮されることになります。いずれかのサーバがストリームの初期化に失敗した場合、そのサーバは圧縮されていない ERROR メッセージを相手側に送信し、接続を終了します。

圧縮に使用するデータ形式は、RFC1950 [ZLIB]、RFC1951 [DEFLATE]、RFC1952 [GZIP] で記述されています。

5.3.1.2 不正使用防止対策

ほとんどのサーバは、信頼できない当事者（通常はユーザ）から起こりうる悪用行為に対して、さまざまな種類の保護機能を実装しています。ネットワークによっては、このような保護が必要不可欠な場合もあれば、不必要な場合もあります。特定のネットワークにおいて、すべてのサーバがそのような機能を実装し、有効にすることを要求するために、2つのサーバが接続するときに "P" フラグが使用されます。このフラグがある場合、サーバの保護機能が有効であることを意味し、サーバはすべてのサーバリンクに対して同様に保護機能を有効にすることを要求します。

一般的に見られる保護機能は、5.7 最近使ったニックネームの追跡と 5.8 クライアントの大量リクエスト対策で説明されています。

5.3.2 接続時の状態情報の交換

サーバ間で交換される状態情報の順序が重要です。必要な順序は以下の通りです。

既知の全サーバ
すべての既知のクライアント情報
すべての既知のチャネル情報

サーバに関する情報は SERVER メッセージ、クライアント情報は NICK メッセージと SERVICE メッセージ、チャネルは NJOIN/MODE メッセージで追加送信されます。

NOTE：TOPIC コマンドは古いトピック情報を上書きするため、せいぜい接続の両側でトピックを交換する程度なので、ここでチャネルのトピックを交換するべきではありません。

サーバの状態情報を先に渡すことで、すでに存在するサーバとの衝突は、第二サーバが特定のニックネームを導入することによるニックネームの衝突よりも先に発生します。IRC ネットワークは非周期的なグラフとしてしか存在できないため、ネットワークがすでに別の場所で再接続されている可能性があります。この場合、サーバの衝突が発生した場所は、ネットが分割される必要がある場所を示しています。

5.4 サーバ-クライアント接続の終了

クライアント接続が予期せず終了した場合、そのクライアントが接続していたサーバが、クライアントに代わって QUIT メッセージを生成します。他のメッセージは生成されず、使用されません。

5.5 サーバ-サーバの接続終了

サーバとサーバの接続が、SQUIT コマンドまたは "自然な" 原因によって閉じられた場合、接続されている残りの IRC ネットワークは、閉鎖を検出したサーバによってその情報が更新されなければなりません。終了するサーバは次に SQUIT のリスト（その接続の背後にある各サーバに対して1つ)を送信する。(セクション4.1.6(SQUIT)参照)。

サーバとサーバの接続が、SQUIT コマンドまたは "自然な" 原因によって閉じられた場合、接続されている残りの IRC ネットワークは、閉鎖を検出したサーバによってその情報が更新されなければなりません。終了するサーバは次に SQUIT のリスト（その接続の背後にある各サーバに対して1つ）を送信します。（4.1.6 SQUIT 参照）。

5.6 ニックネーム変更の追跡

すべての IRC サーバは最近のニックネームの変更履歴を保持することが要求されます。これはニックネームを操作するコマンドでニックネーム変更の競合状態が発生したときに、サーバが状況を把握する機会を持つために重要です。ニックネームの変更を追跡しなければならないメッセージは以下の通りです。

KILL （切断されるニックネーム）
MODE （チャネル上の +/- o,v）
KICK （チャネルから外されるニックネーム）

他のコマンドでニックの変更を確認する必要はありません。

上記の場合、サーバはまずニックネームの存在を確認し、次にそのニックネームが今誰のものなのか（もし誰かいれば！）履歴を確認する必要があります。これはレースコンディションの可能性を減らしますが、サーバが間違ったクライアントに影響を及ぼしてしまうということはまだ起こり得ます。上記のコマンドで変更履歴を調べるときは、時間範囲を指定し、古すぎるエントリは無視することをお勧めします。

合理的な履歴のために、サーバは、彼らがすべて変更することを決めた場合、それが知っているすべてのクライアントのために前のニックネームを保持することができるはずです。このサイズは他の要因（例えばメモリなど）によって制限されます。

5.7 最近使ったニックネームの追跡

この機構は一般に "ニックネーム遅延" と呼ばれ、"ネットワーク分割"/再接続や不正使用によるニックネーム衝突の数を大幅に減少させることが証明されています。

ニックネームの変更を追跡することに加え、サーバは最近使用され、"ネットワーク分割" または KILL メッセージの結果として解放されたニックネームを追跡する必要があります。これらのニックネームはサーバ・ローカルクライアントから利用できなくなり、一定期間現在使用されていないにもかかわらず再利用することができなくなります。

ニックネームが利用できなくなる期間は、IRC ネットワークのサイズ（ユーザ数）や "ネットワーク分割" の通常の期間など、多くの要因を考慮して設定する必要があります。これはある IRC ネットワークのすべてのサーバで均一であるべきです。

5.8 クライアントの大量リクエスト対策

IRC サーバが相互に接続された大規模なネットワークでは、ネットワークに接続している任意の1つのクライアントが、ネットワークをフラッディングさせるだけでなく、他のクライアントに提供するサービスのレベルを低下させる結果となるメッセージの連続ストリームを供給することは非常に簡単です。すべての "犠牲者" が独自の保護を提供することを要求するのではなく、フラッド保護がサーバに書き込まれ、サービス以外のすべてのクライアントに適用されます。現在のアルゴリズムは以下の通りです。

クライアントの "メッセージタイマー" が現在の時刻より小さいかどうか調べます（小さい場合は等しくなるように設定します）。
クライアントから存在するあらゆるデータを読み取ります。
タイマーが現在時刻より10秒以上進んでいない間、現在のメッセージをすべて解析し、メッセージごとにクライアントに2秒のペナルティを課します。
ネットワーク上で多くのトラフィックを発生させる特定のコマンドに対して、追加のペナルティを使用することができます。

これは要するに、クライアントが悪影響を受けることなく、2秒に1回メッセージを送信できることを意味します。サービスにもこの仕組みが適用される場合があります。

5.9 ノンブロッキングルックアップ

リアルタイム環境では、すべてのクライアントに公平にサービスを提供するために、サーバプロセスができるだけ待機しないことが重要です。このためには、ネットワーク上のすべての読み取り/書き込み操作において、ノンブロッキング IO が必要であることは明らかです。通常のサーバ接続では、これは難しいことではありませんでしたが、サーバがブロックする可能性のある他のサポート操作（ディスク読み取りなど）があります。可能であれば、そのような動作は短いタイムアウトで実行されるべきです。

5.9.1 ホスト名 (DNS) ルックアップ

Berkeley などの標準的なリゾルバライブラリを使用すると、返信がタイムアウトするケースもあり、大きな遅延が発生しました。これを避けるために、現在の実装では、DNS ルーチンの別セットが書かれました。ルーチンはローカルキャッシュによるノンブロッキング IO 操作のためにセットアップされ、メインサーバの IO ループの中からポーリングされました。

5.9.2 ユーザ名 (Ident) ルックアップ

他のプログラムに組み込んで使用するための ident ライブラリ（"Ident Protocol" [IDENT] を実装）は数多く存在するが、これらは同期的に動作するため、頻繁に遅延が生じるという問題がありました。この場合も、サーバの他の部分と協調し、ノンブロッキング IO で動作するルーチン群を書くことが解決策となりました。

6. 現在の問題点

このプロトコルにはいくつかの問題があるとされており、近い将来の書き換えで解決されることが期待されています。現在、これらの問題に対する実用的な解決策を見つけるための作業が進行中です。

6.1 スケーラビリティ

このプロトコルは、大規模な舞台で使用する場合、十分にスケールしないことが広く認識されています。主な問題は、すべてのサーバが他のすべてのサーバとクライアントについて知っており、それらに関する情報が変更されたらすぐに更新されるという要件から来るものです。また、任意の2点間の経路長が最小に保たれ、スパニングツリーができるだけ強く分岐するように、サーバの数を少なくすることが望ましいとされています。

6.2 ラベル

現在の IRC プロトコルには、ニックネーム、チャネル名、サーバ名、サービス名の4種類のラベルがあります。4つのタイプはそれぞれ独自のドメインを持ち、そのドメイン内では重複が許されません。現在、ユーザが最初の3つのラベルのいずれかを選ぶことが可能で、その結果、衝突が発生しています。衝突しないようなニックネームの計画が望まれますし、循環ツリーを可能にする解決策も必要であることは広く認識されています。

6.2.1 ニックネーム

IRC におけるニックネームの考え方は、ユーザがチャネル外で会話する際に非常に便利ですが、ニックネームのスペースは有限であり、そのようなものである以上、複数の人が同じニックネームを使いたいと思うことは珍しいことではありません。もしこのプロトコルを使っている二人がニックネームを選んだ場合、どちらかが成功しないか、KILL を使って両方が削除されます（"IRC クライアントプロトコル" [IRC-CLIENT] の 3.7.1 節を参照してください)。

6.2.2 チャネル

現在のチャネルレイアウトでは、すべてのサーバがすべてのチャネル、その住人、プロパティについて知っている必要があります。うまく拡張できないことに加えて、プライバシの問題も懸念されます。チャネルの衝突は、ニックネームの衝突を解決するために使用されるような排他的なものではなく、共通の名前を持つチャネル上の両方のネットの人々がそのメンバであるとみなされる包括的なイベントとして扱われます。

このプロトコルでは、チャネル衝突の可能性が極めて低い "安全なチャネル" を定義しています。その他のチャネルタイプは後方互換性のために残されています。

6.2.3 サーバ

通常、サーバの数はユーザやチャネルの数に比べて少ないのですが、現在、サーバもそれぞれ個別に、あるいはマスクの後ろに隠れてグローバルに知られていることが要求されています。

6.3 アルゴリズム

サーバコード内のいくつかの場所では、クライアントのセットのチャネルリストをチェックするような \(N^2\) アルゴリズムを回避することができませんでした。

現在のサーバのバージョンでは、データベースの整合性チェックはほとんど行われておらず、ほとんどの場合、各サーバは隣のサーバが正しいことを前提にしています。そのため、接続先のサーバがバグっていたり、既存のネットに矛盾を持ち込もうとしたりすると、大きな問題が発生する可能性があります。

現在、内部およびグローバルラベルが一意でないため、多数のレースコンディションが存在します。これらの競合状態は、一般に、メッセージが IRC ネットワークを横断して影響を及ぼすのに時間がかかるという問題から生じます。ユニークなラベルに変更することによっても、チャネル関連のコマンドが中断される問題があります。

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

7.1 認証

サーバには、プレーンテキストパスワードと DNS ルックアップという2つの認証手段しかありません。これらの方法は脆弱であり、安全でないことは広く認識されていますが、過去には以下の組み合わせで十分であることが証明されています。

公共ネットワークは通常、正確な認証を必要とせず、わずかな制限でユーザ接続を許可します。
管理された環境で運用されるプライベートネットワークでは、インターネットでは利用できない自前の認証機構、すなわち信頼できる ID サーバ [IDENT] やその他の独自機構を使用することがよくあります。

IRC オペレータの認証についても、同様のコメントがあります。

また、より強力な認証が長年にわたって求められてきたわけではなく、ユーザを安全に認証するためのより良い手段を提供するための真の努力もなされてこなかったが、現在のプロトコルでは、クライアントが接続時にサーバに送信できる情報（ニックネーム、ユーザ名、パスワード）に基づいて、外部認証手段を簡単にプラグインできるような十分な環境が整っていることも指摘しておかなければならないだろう。

また、長年にわたって認証の強化が求められてきたわけではなく、ユーザを安全に認証するためのより良い手段を提供するための真の努力もなされてこなかったことに留意する必要があります。現在のプロトコルは、クライアントが接続時にサーバに送信できる情報（ニックネーム、ユーザ名、パスワード）に基づいて、外部の認証方法を簡単にプラグインできるようにするのに十分な機能を備えています。

7.2 インテグリティ

IRC プロトコルの PASS と OPER メッセージは平文で送信されるので、これらの取引を保護するために "The TLS Protocol" [TLS] のようなストリーム層暗号化機構を使用することができます。

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

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

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

ソフトウェアの実装：

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.

[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 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-CHAN] Kalt, C., "Internet Relay Chat: Channel Management", RFC 2811, April 2000.

[ZLIB] Deutsch, P. and J-L. Gailly, "ZLIB Compressed Data Format Specification version 3.3", RFC 1950, May 1996.

[DEFLATE] Deutsch, P., "DEFLATE Compressed Data Format Specification version 1.3", RFC 1951, May 1996.

[GZIP] Deutsch, P., "GZIP file format specification version 4.3", RFC 1952, May 1996.

[IDENT] St. Johns, M., "The Identification Protocol", RFC 1413, February 1993.

[TLS] Dierks, T. and C. Allen, "The TLS Protocol", RFC 2246, January 1999.

11. Author's Address

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

   EMail: kalt@stealth.net

12. Full Copyright Statement

   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 PARTICULAR PURPOSE.

Acknowledgement

Funding for the RFC Editor function is currently provided by the Internet Society.

RFC 2813 サーバプロトコル

Internet Relay Chat: サーバプロトコル