Request for Comments: 1459 Internet Relay Chat Protocol [この文章の取り扱い] この文章にはInternet communityのためのExperimental Protocolを定義し、改善のための意見と提案が寄せられています。 このプロトコルと標準化の状況については"IAB Official Protocol Standards"の最新版を参照して下さい。 この文章の配布は自由に行ってかまいません。 <訳者注:>これは原文の取り扱いです。日本語訳についてはセクション13.2 「日本語訳について」に準じます。 また、IRCプロトコルの定義はあくまで原文であることを断っておきます。 [概要] 最初にBBS上のユーザ間のチャットの方法として使われ初めてから4年間以上にわたって、IRCプロトコルは開発が進められています。 現在、このプロトコルはサーバ／クライアント方式で世界中のネットワークをカバーしています。そして、ネットワークの成長に伴って、プロトコルも改善されてきています。 過去2年間、主要なIRCネットワークを利用するユーザの数は10倍にも膨れ上がっています。 IRCプロトコルはテキストベースのプロトコルで、クライアントはサーバとソケットでつなぐシンプルなプログラムです。 [目次] 1. 導入 1.1 サーバ 1.2 クライアント 1.2.1 IRCオペレータ 1.3 チャンネル 1.3.1 チャンネルオペレータ 2. IRCの仕様 2.1 概観 2.2 文字コード 2.3 メッセージ 2.3.1 疑似BNFによるメッセージ形式 2.4 ニュメリックリプライ 3. IRCのコンセプト 3.1 1=>1の通信 3.2 1=>多人数 3.2.1 =>リスト 3.2.2 =>グループ(チャンネル) 3.2.3 ホスト／サーバ マスクに対する通信 3.3 1=>全体 3.3.1 クライアント-クライアント 3.3.2 クライアント-サーバ 3.3.3 サーバ-サーバ 4. メッセージの詳細 4.1 接続の開始 4.1.1 PASS(password)メッセージ 4.1.2 NICK(nickname)メッセージ 4.1.3 USERメッセージ 4.1.4 SERVERメッセージ 4.1.5 OPER(operator)メッセージ 4.1.6 QUITメッセージ 4.1.7 SQUIT(server quit)メッセージ 4.2 チャンネル操作 4.2.1 JOIN(参加)メッセージ 4.2.2 PART(離脱)メッセージ 4.2.3 MODEメッセージ 4.2.3.1 チャンネルモード 4.2.3.2 ユーザモード 4.2.4 TOPICメッセージ 4.2.5 NAMESメッセージ 4.2.6 LISTメッセージ 4.2.7 INVITE(招待)メッセージ 4.2.8 KICK(追放)メッセージ 4.3 サーバへの要求とメッセージ 4.3.1 VERSIONメッセージ 4.3.2 SATAS(状態)メッセージ 4.3.3 LINKメッセージ 4.3.4 TIMEメッセージ 4.3.5 CONNECT(接続)メッセージ 4.3.6 TRACE(追跡)メッセージ 4.3.7 ADMIN(管理者)メッセージ 4.3.8 INFOメッセージ 4.4 メッセージの送信 4.4.1 PRIVMSG(private message)メッセージ 4.4.2 NTICEメッセージ 4.5 ユーザ情報の要求 4.5.1 WHOメッセージ 4.5.2 WHOISメッセージ 4.5.3 WHOWASメッセージ 4.6 その他のメッセージ 4.6.1 KILLメッセージ 4.6.2 PINGメッセージ 4.6.3 PONGメッセージ 4.6.4 ERRORメッセージ 5. OPTIONALメッセージ 5.1 AWAYメッセージ 5.2 REHASHメッセージ 5.3 RESTARTメッセージ 5.4 SUMMON(召還)メッセージ 5.5 USERSメッセージ 5.6 WALLOPS(operwall)メッセージ 5.7 USERHOSTメッセージ 5.8 ISONメッセージ 6. リプライ 6.1 エラーリプライ 6.2 メッセージ応答 6.3 予約番号 7. クライアント／サーバ認証 8. 現在の実装の詳細 8.1 TCPネットワークプロトコル 8.1.1 UNIXソケットのサポート 8.2 メッセージの構文解析 8.3 メッセージの配信 8.4 接続の生涯 8.5 サーバ-クライアント間の接続の確立 8.6 サーバ-サーバ間の接続の確立 8.6.1 サーバによる接続の状態情報の交換 8.7 サーバ-クライアント間の接続の切断 8.8 サーバ-サーバ間の接続の切断 8.9 ニックネーム変更の探知 8.10 クライアントのデータ流入管理 8.11 ノンブロックキング検索 8.11.1 ホスト名の(DNSのよる)検索 8.11.2 ユーザ名の(IDENTによる)検索 8.12 設定ファイル 8.12.1 接続を許可するクライアント 8.12.2 オペレータ 8.12.3 接続を許可するサーバ 8.12.4 経由地の管理 8.13 チャンネルのメンバー 9. 現在の問題 9.1 スケーラビリティ 9.2 ラベル 9.2.1 ニックネーム 9.2.2 channel 9.2.3 サーバ 9.3 アルゴリズム 10. 現在のサポートと入手先 11. セキュリティに対する配慮 12. 筆者の宛先 13. 日本語訳にあたって 13.1 謝辞 13.2 日本語訳について 13.3 訳者の連絡先 [1. 導入] IRC(=Internet Relay Chat)プロトコルはテキストベースで会話をするプロトコルとして、何年もに渡ってその設計が改良されてきています。 このドキュメントには現在のIRCプロトコルが述べられています。 IRCプロトコルはTCP/IPネットワークプロトコルを使用したシステム上で開発されましたが、これは必要条件ではなく、この動作はTCP/IPプロトコルの範囲に限定するものではありません。 IRCは遠隔的会話システムです。そして、これは(クライアント／サーバモデルのため)多くの機種で動作します。 典型的な構成としては、クライアント(や他のサーバ)の接続点の中心として一つのプロセス(サーバ)を配置します。必要なメッセージの配信、多重送信等の機能をサーバが提供します。 [1.1 サーバ] サーバがIRCのバックボーンを形成しています。サーバは、クライアントが互いに接続して会話をしたり、他のサーバとの接続して会話をする接続点を提供し、IRCネットワークを形成しています。 IRCサーバのとりうるネットワーク形態は伸縮自在な木構造のみです。(Fig.1を見よ)あるサーバから見て、それ以外のネットワークの中心ノードとして働くように、各々のサーバを配置します。 [Server 15] [Server 13] [Server 14] | | | [Server 11]----[Server 1]-| [Server 12]---------| | | | |---------[Server 2] |--[Server 3]---------| | | | [Server 5] |-[Server 4]-| [Server 6] | | | | [Server 7]--| [Server 8] |--[Server 9] [Server 10] : [etc.] [Fig.1 IRCネットワークの形式] [1.2 クライアント] 一つのサーバに接続しているクライアントは他のサーバに接続してはなりません。 各クライアントは他のクライアントから最長9文字のニックネームによって認識されます。 ニックネームにどの文字が使えてどの文字が使えないかはプロトコルの文法規約を参照して下さい。 ニックネームに加えて次に挙げる全クライアントの情報を、すべてのサーバは保持していなくてはなりません: (a)クライアントの走っているホストの正式名称 (b)そのホスト上でのクライアントのユーザ名 (c)クライアントの接続しているサーバ [1.2.1 IRCオペレータ] 適切な状態にIRCネットワークを保つため、クライアントの特別な形態であるIRCオペレータ(IRC operator)にネットワーク上で高レベルな保守機能を使用することを許可しています。 オペレータに与えられた権限が「危険と」考えることもできますが、それでもなおIRCオペレータは必要とされます。 長期間に渡って粗悪なネットワークルーティング(network routing)が使われることを防ぐために、必要に応じて接続を切ったり、つなぎ直したりするネットワークの根幹にかかわる操作をIRCオペレータは行うことができます。 プロトコルでは、この必要性を認めているので、IRCオペレータのみにこのような機能を使用する権限を認めています。 セクション4.1.7(SQUITメッセージ)及びセクション4.3.5(CONNECTメッセージ)を参照のこと まだ多くの議論の余地があるIRCオペレータの権限に、「強制的に」ネットワーク接続からクライアントを排除する能力が挙げられます。オペレータはどんなクライアント-サーバ間の接続でも閉じることができます。 乱用すると破壊的になり、悩みのタネになってしまうので、この問題に対する正当な理由はデリケートです。(IRCオペレータはこのような一般クライアントを追放することができます。) このような行動のより詳細については、セクション4.6.1(KILLメッセージ)を参照のこと [1.3 チャンネル] チャンネルとは、一つ以上のクライアントから構成された、ある名付けられたグループをいいます。その「チャンネル」に宛られた全てのメッセージはそれを構成するクライアントに送信されます。 チャンネルは最初のクライアントがJOIN(参加)したときに暗黙のうちに作り出され、そして最後のクライアントが抜けた時に消滅します。 チャンネルが存在する間、クライアントはチャンネルの名前を使って、チャンネルを参照することができます。 チャンネルの名前は最長200文字までの文字列です。(これは'&'または'#'の文字で始まります) 先頭の文字が'&'か'#'であることが必要な条件であることを除くと、 スペース(' ')、C-g(^G　ASCIIコードで7)とコンマ(',' これはリストのアイテムのセパレータとしてプロトコルが使用します)を含まないということだけが、チャンネル名に対する制約となります。 2種類のチャンネルがこのプロトコルで認められています。 一つは'#'ではじまるチャンネルでIRCネットワークに接続するすべてのサーバに対して公開されているチャンネルです。 この種のチャンネルの第一の特徴ははチャンネルにJOINしているサーバ上のクライアントが一つでもあれば、IRCネットワーク上に存在するということです。 これらは'&'の文字で始まるものとは区別されます。 これら2種類のチャンネル上で利用できる種々のチャンネルモードで個々のチャンネルの性質を変更することができます。 <訳者注:>&ではじまるチャンネルはサーバにローカルなチャンネルです。(つまり同じサーバにつないでるクライアントからしか見えない) このメッセージの詳細はセクション 4.2.3(MODEメッセージ)を参照のこと 新しいチャンネルを作るもしくは現存のチャンネルに加わるには、クライアントはチャンネルにJOINすることが必要です。 もしチャンネルにJOINするよりも前にチャンネルが存在していなければ、チャンネルが作られ、そして作ったクライアントがチャンネルオペレータになります。 チャンネルがすでに存在していた場合、そのチャンネルにJOINする要求が認められるかどうかは、その時のチャンネルのチャンネルモードによります。 例えば、チャンネルモードが"invite-only"(mode +i)ならば、"INVITE(招待)"されている時だけJOINできます。 クライアントは同時に複数のチャンネルに参加できます。しかし、初心者からベテランまで十分な数として、10チャンネルまでに制限されています。 この点のより詳細はセクション8.13を参照のこと。 2つのサーバ間が分断され、IRCネットワークの接続が切れた場合、双方が、まだ接続されているサーバ内でチャンネルを再構成します。ひょっとすると分断されたどちらか一方の側では消滅するかもしれません。 分断が回復したとき、接続したサーバは互いに、それぞれのチャンネルとそのチャンネルモードをアナウンスします。 チャンネルが双方で存在していた場合、JOINとMODEは新たに接続した双方のチャンネルにどのクライアントがいてどのようなモードなのか整合するように包括的な方法で解決されます。 [1.3.1 チャンネルオペレータ] 権限を与えられたチャンネル上のチャンネルオペレータ("chop"や"chanop"とも呼ばれています。※日本では「なると持ち」と呼ばれています)がそのチャンネルを「所有」するとみなされます。 チャンネルオペレータのこの地位を認めて、チャンネルの管理と健全性を保つための権限をチャンネルオペレータは持っています。 チャンネルオペレータは、チャンネルの所有者なので、チャンネルオペレータに行動の理由を問うことはできません。もし仮にチャンネルオペレータの行動が一般社会常識に反したり、口汚くてもです。この時はIRCオペレータに仲裁するように頼むか、あるいはユーザが直ちに去り、問題のチャンネルオペレータの所有しているチャンネルから他の場所へ行き、自分自身でチャンネルを作るのがよいでしょう。 チャンネルオペレータのみが使用できるメッセージは以下のものです: KICK - クライアントをチャンネルから追放します MODE - チャンネルモードを変更します INVITE - "invite-only"(mode +i)のチャンネルにクライアントを招待します TOPIC - (mode +t)のときにチャンネルを変更します チャンネルに参加しているときに(NAMES,WHO,WHOISメッセージのリプライとして表示される)ニックネームのそばの'@'記号でチャンネルオペレータは識別できます。 (※'@'記号がラーメンなどに浮いている「なると」に似ている事が、日本ではチャンネルオペレータの事を「なると持ち」という由来です。) [2. IRCの仕様] [2.1 概観] ここに記述されているプロトコルはサーバ-サーバ間、クライアント-サーバ間の接続の両方共で使用されています。 しかし、サーバの接続に対する制限よりクライアントの接続に対する制限の方が厳しくなっています。クライアントの接続は信頼性がないとみなさているからです。 [2.2 文字コード] 具体的な文字セットの仕様は定められていません。 1オクテット(=8 bit)のコードのセットをプロトコルではベースとしています。 このオクテットをいくつかまとめたものから、各メッセージは成り立っています。オクテットの値のうちいくつかはデリミタとして働くコントロールコードに使われています。 8ビットプロトコルであることは問題になりません。デリミタとキーワードは大抵のUSASCIIターミナルやtelnet接続のプロトコルのようなものだからです。 スカンジナビア語がIRCの起源なので、文字'{}|'はそれぞれ文字'[]\'の小文字に当たるものとみなされます。 これは2つのニックネームが同じのものであることを確定するときに重要な問題となります。 [2.3 メッセージ] サーバとクライアントは互いにメッセージを送信し合います。これらのうちには、リプライするものもしないものもあります。 メッセージが正しいコマンドを含んでいた場合、後のセクションで述べますが、クライアントは仕様通りのリプライを期待しています。しかしこれはリプライを永久に待たねばならないことを意味しているわけではありません。クライアント-サーバ間、サーバ-サーバ間の通信は基本的に非同期です。 どのIRCメッセージも最大3つの主な部分から成り立っています: (a)プレフィックス(prefix)(使用は任意) (b)コマンド(command) (c)コマンドパラメータ(command parameters)(最大15個まで) プレフィックス、コマンド、全コマンドパラメータは1つ以上のASCIIコードのスペース文字(0x20)によって分けられます。 先頭に付いてるコロン(':',0x3b)一文字によって、プレフィックスの存在が表現されます。そしてこれはメッセージ自体の先頭の文字となります。 コロンとプレフィックスの間には飛び(空白文字)があってはいけません。 プレフィックスはメッセージの送信元を表すために、サーバが使用します。 プレフィックスがメッセージから抜け落ちていた場合、送信してきた接続先が送信者であると仮定します。 クライアントはメッセージを送信するときにプレフィックスを使用すべきではありません。クライアントがプレフィックスを使用するとすれば、唯一の妥当なプレフィックスはそのクライアントと関連付けて登録されているニックネームのみです。 プレフィックスによって識別された送信者がサーバの持っているデータベースで見つからない、または、メッセージの来た接続先とは異なった接続のものとしてその送信者が登録されている場合、サーバは黙ってそのメッセージを無視します。 コマンドは正しいIRCコマンドまたはASCIIテキストを表された3桁の10進数のどちらかでなくてはいけません。 IRCメッセージはいつもCR-LF(Carriage Return- Line Feed)で終わる文字の列です。そして、これらのメッセージは512文字を超えた長さにはできません。全文字数に末尾のCR-LFは含まれます。 従って、最大510文字がコマンドとそのパラメータに使用できます。 連続したメッセージ行のための規定はありません。 この事のより詳細についてはセクション7を参照のこと。 [2.3.1 疑似BNFによるメッセージ形式] プロトコルのメッセージを連続したオクテットのストリームから抽出しなくてはいけません。 現在の解決策はメッセージの区切りとして、2文字(CRとLF)を使用することです。 空のメッセージは黙って無視されます。特別な問題が無ければメッセージの間にCR-LFシーケンスを使用できます。 抽出されたメッセージは,,の成分に構文解析され、さらに、はまたは成分にマッチします。 このためのBNF表現は以下にあげるようなものになります。 ::= [':' ] ::= | [ '!' ] [ '@' ] ::= { } | ::= ' ' { ' ' } ::= [ ':' | ] ::= <先頭が':'ではなく,SPACE,NUL,CR,CFを含まない、空でないオクテットの列> ::= ::= CR LF 注: 1) は1つ以上の空白文字(' ',0x20)だけからなります。 タブおよび、その他全てのコントロール文字は「非空白文字」であることに特に注意して下さい。 2) パラメータリストを抽出した後は,のいずれにマッチしても、全てのパラメータは同等のものとなります。 は単にパラメータの範囲内でSPACEを許すためのシンタックス上のトリックです。 3) メッセージフレームの仕様のため、CRとLFがパラメータの文字列の中に入れることができないという事になっています。 これはいずれ変更されるかもしれません 4) NUL文字はメッセージフレームの中では特別なものではありません。そこで、基本的には、NUL文字はパラメータ内の終端に使用できます。しかし、これは普通のCの文字列操作で余計な複雑さを引き起こすことになります。 したがって、メッセージの中で使用することを認めてません。 5) 最後のパラメータは空のオクテットの列でもかまいません。 6) 抽出したプレフィックスに使う(['!' ] ['@' ])はサーバからサーバへの通信には使用してはいけません。これはサーバ-クライアント間でメッセージをクライアントに送信する時に、サーバに追加して要求する必要なしにメッセージがどこから来たかという情報をクライアントに渡す有用な方法として使用されます。 ほとんどのプロトコルメッセージはリスト中の位置からパラメータ文字列を抽出するにあたり追加の意味と構文を定義しています。 例えば、多くのサーバコマンドはコマンドの後の最初のパラメータが送信先のリストであることを仮定するでしょう。 それは以下のように表現することができます: ::= [ "," ] ::= | '@' | | ::= ('#' | '&') ::= ::=※ホスト名についての詳細はRFC 952 [DNS:4] を参照 ::= { | | } ::= ('#' | '$') ::= <8bitコード(SPACE, BELL, NUL, CR, LF, ','を除く)> 他のパラメータの構文は ::= { } ::= 'a' ... 'z' | 'A' ... 'Z' ::= '0' ... '9' ::= '-' | '[' | ']' | '\' | '`' | '^' | '{' | '}' ::= <8bitコード(SPACE(0x20),NUL(0x0),CR(0xd),LF(0xa)を除く) [2.4 ニュメリックリプライ] サーバに送信された大抵のメッセージが、なんらかのリプライを生成します。 もっとも一般的なリプライはニュメリックリプライ(numeric reply)です。これはエラーにも通常のリプライにも使用されます。 ニュメリックリプライは送信者のプレフィックスと3桁の数字、そしてリプライの送信先から成り立っています。 クライアントはニュメリックリプライを送信することは認められていません。どんなメッセージでもサーバは受け取りますが黙って落とされます。 これ以外の点おいては、ニュメリックリプライが普通の文字列より短い3桁の数字からキーワードから成り立っていることを除いて、普通のメッセージとまったく同じように扱われます。 種々のリプライのリストがセクション6にあります。 [3. IRCのコンセプト] このセクションではIRCプロトコルの構成の背景にあるコンセプトと、現在、いろいろな異なる形態のメッセージの送信がどのように実装されているかを述べていきます。 1--A--2 D--4 | | | | 3--B------C------E サーバ :A,B,C,D,E クライアント:1,2,3,4 [Fig.2. 小規模なIRCネットワークの例] [3.1 1=>1の通信] ほとんどのサーバ-サーバ間のトラフィックは互いのサーバの通信結果だけでは済まないので、1対1の通信は通常、クライアントだけが行います。 クライアントが互いに会話をする機能を安全な方法で提供するには、全サーバがどのクライアントにもたどり着けるように、正確に木構造のネットワークに沿って、単一の方向にメッセージを配信できるようになっていなくてはなりません。 送信されるメッセージの経路は木構造のネットワーク上の2点間の最も短い経路になります。 以下の例はFig.2のに沿って述べられています。 例 1: クライアント1と2の間のメッセージはサーバAだけを通過します。サーバAはこれを直接クライアント2に送信します。 例 2: クライアント1と3の間のメッセージはサーバA,Bおよびクライアント3を通過します。 他のクライアントとサーバはメッセージを見ることはできません。 例 3: クライアント2と4の間のメッセージはサーバA,B,C,Dおよびクライアント4を通過します。 [3.2 1=>多人数] IRCの主な目的は簡単で効果的なコンファレンス(一対多の会話)が可能なフォーラムを提供することです。 IRCはこれを達成するため複数の方法を提供しています。それぞれの使用目的によってそれぞれの送信方法があります。 [3.2.1 =>リスト] 一対多の会話の最も効率の悪いスタイルはクライアントがクライアントのリストを使用して通信することです。 それがどのようになされるかは、ほとんど自明でしょう。 クライアントはメッセージの送信先のリストを与えてメッセージを送信します。サーバはリストを分解し、それぞれの送信先に送信するため、メッセージをコピーして別々に送信します。 これはグループを使うより効率的ではありません。なぜなら送信先のリストが分解され、各経路で複製が送信されないという信頼性がチェックをすることなく、送信されるからです。 [3.2.2 =>グループ(チャンネル)] IRCのチャンネルはマルチキャストグループと等価な役割を持ちます。この存在はダイナミックなものです。(人がチャンネルに参加したり、別れていくにつれて、出現したり消滅したりします。)そして、チャンネルでなされた実際の会話はそのチャンネルのクライアントを受け持っているサーバのみに送信されます。 同じチャンネルのクライアントが同一サーバ上に多数いる場合、メッセージテキストはそのサーバにたった一度だけ送信されます。そしてサーバは同じチャンネル上の各クライアントに送信します。 各クライアント-サーバ間の送信は繰り返され、送信されたメッセージは各チャンネルのメンバーに到達します。 Fig 2.に沿って例を挙げていきます。 例 4: 1つしかクライアントのいないチャンネルでは、チャンネルへのメッセージはサーバへ送信され、そしてその後はどこにも送信されません。 例 5: チャンネルに2つのクライアントがいるとき、全てのメッセージは、あたかもそれが2つのクアイアント間のプライベートメッセージであるかのように経路を通過します。 例 6: クライアント1,2,3がチャンネルにいるとき、チャンネルへの全てのメッセージは、それがあたかも一つのクライアントへのプライベートメッセージであるかのように、(チャンネルにいる)各クライアントとメッセージが通過しなくてはならないサーバに送信されます。 クライアント1がメッセージを送信したとしましょう。クライアント2にはサーバAから送信され、クライアント3にはサーバBを経由して送信されます。 [3.2.3 ホスト／サーバ マスクに対する通信] 関係ユーザ、ホスト、サーバへのマスクメッセージを使って配信するためのメカニズムをIRCオペレータは利用することができます。 これらのメッセージはホストやサーバの情報がマスクに一致するクライアントに送信されます。 メッセージはチャンネルと似通った方法でクライアントの所に送信されます。 [3.3 1=>全体] 「1=>全体」タイプのメッセージはブロードキャストメッセージと言った方がよいでしょう。全てのクライアントやサーバまたはその両方にメッセージを送信します。 クライアントとサーバからなる巨大なネットワーク上では、一つのメッセージが、全ての送信先に到達する作業のために、ネットワークに大量のトラフィックを生むことになります。 いくつかのメッセージは全サーバへブロードキャストする以外の選択ができません。なぜなら、サーバ間で整合性ある状態情報を、全サーバが保持せねばならないからです。 [3.3.1 クライアント-クライアント] ある単独のクライアントが他の全クライアントにメッセージが送信するような、メッセージ形態は用意されていません。 [3.3.2 クライアント-サーバ] 大部分の状態情報(チャンネルメンバー,チャンネルモード,ユーザ情報など、)を変化させるコマンドはデフォルトで全サーバに向けて送信せねばなりません。クライアントはこの送信の設定を変更することはできません。 [3.3.3 サーバ-サーバ] サーバ間のメッセージが全ての「他の」サーバに送信される時は大抵、クライアント、チャンネルあるいはサーバに影響するメッセージの時だけに必要になります。 これはIRCにおいて根幹にかかわる事ですので、サーバから送信されるおおよそ全てのメッセージは接続している他の全サーバへのブロードキャストとなります。 [4. メッセージの詳細] 以下ではIRCサーバとクライアントが使用可能な各メッセージについて述べています。 本プロトコルによる全サーバがこのセクションで述べている全てのコマンドを実装しなくてはなりません。 一覧表にあるリプライ"ERR_NOSHUCHSERVER"はパラメータに該当するサーバが見つからないことを意味しています。 このリプライを受けた後は、サーバはそのコマンドのために他のリプライを送信してはいけません。 クライアントと接続しているサーバは完全なメッセージをパースし適切なエラーを返すことが必要です。 サーバがメッセージをパースしているときに致命的なエラーを発見した場合、エラーをクライアントに返信し、パースを終了しなくてはなりません。 不正なコマンド、サーバに不明なホスト(サーバ,ニックネーム,チャンネル名,などこのカテゴリに属するもの)、パラメータの不足、特権違反等が致命的エラーとみなされます。 パラメータが完全にそろっていた場合は、クライアントに返信されてきた応答の正当性と妥当性をチェックしなくてはなりません。 コンマを項目のセパレータとするメッセージの場合、リプライは各項目にたいして送信する必要があります。 この下の例では、いくつかのメッセージはフルフォーマットで使用してます: :Name COMMAND parameter list この例はサーバ間で通過する"Name"からのメッセージを表しています。ここで重要な点は、正確な経路を通ってリモートサーバへリプライを返すために、メッセージの最初の送信者の名前が含まれているという点です。 [4.1 接続の開始] ここで説明されるメッセージはIRCサーバに接続を開始したり、もちろんクライアントやサーバが正常に接続を切ったりすることにも使用します。 PASSコマンドはクライアントやサーバの接続の登録に必須ではありません。しかし行うならば、SERVERメッセージや、すぐ後で説明するNICK/USERメッセージに先だって行わなければなりません。 サーバ間の接続に関しては実際の接続で一定のセキュリティの水準を保つために、パスワードを設定することを強く推奨します。 クライアントが登録を行う場合、以下に述べる順にメッセージを送ることを推奨します: 1. PASSメッセージ 2. NICKメッセージ 3. USERメッセージ [4.1.1 PASS(password)メッセージ] Command: PASS Parameters: PASSメッセージは接続パスワードを送信するために使います。 パスワードは接続を開始しようとする前に送信することが可能ですし、送信しなくてはなりません。 現在クライアントは、NICK/USERの関連付けを送信する前にPASSメッセージを送信すること、サーバはSERVERメッセージを送信する前に必ずPASSメッセージを送信せねばならないとが、定められています。 送信されたパスワードはC/N行(サーバ)またはI行(クライアント)にマッチしなくてはなりません。 接続が登録される前に何度PASSメッセージを送信してもかまいませんが、最後に送信したものだけが認証には使用されます。接続が一度登録されたら変更することはできません。 ニュメリックリプライ: ERR_NEEDMOREPARAMS ERR_ALREADYREGISTRED 例: PASS ここに秘密のpasswordを書く [4.1.2 NICK(nickname)メッセージ] Command: NICK Parameters: [ ] NICKメッセージはクライアントにニックネームを与えたり、前のものから変更したりするために使用します。 のパラメータはニックネームのホームサーバからどのくらい離れているか示すためにサーバだけが使用します。 ローカルな接続のhopcountは0です。 クライアントが送った場合は、hopcountは無視すべきです。 サーバが受信したNICKメッセージが他のクライアントのすでに使用しているニックネームと同一であることが判明した場合、ニックネームの衝突が発生します。 ニックネームの衝突のがおこると、ニックネームに関する全ての情報がサーバのデータベースから取り除かれます。そして他の全サーバのデータベースからこのニックネームを取り除くために、KILLメッセージが送信されます。 衝突を引き起こしたNICKメッセージがニックネームの変更ならば、そのときは元の(古い)ニックネームもまた削除されます。 サーバがデータベースにあるのと同一のニックネームを指定するNICKメッセージを直接接続してきたローカルなクライアントから受け取った場合は、そのローカルなクライアントに対してERR_NICKCOLLISIONを発行し、NICKメッセージをドロップします。そしてニックネームは生成されず、KILLも行われません。 ニュメリックリプライ: ERR_NONICKNAMEGIVEN ERR_ERRONEUSNICKNAME ERR_NICKNAMEINUSE ERR_NICKCOLLISION 例: NICK Wiz 新しいニックネーム"Wiz"を登録します。 :WiZ NICK Kilroy WiZはニックネームをKilroyに変更します [4.1.3 USERメッセージ] Command: USER Parameters: USERメッセージは接続の最初に新しいクライアントのユーザ名、ホスト名、サーバ名、本名を指定するために使います。 これは2つのサーバ間での通信でもIRC上の新しいクライアントの到着を示すのに使用します。USERとNICKの両方を受け取った後にサーバはユーザを登録するからです。 サーバ間ではUSERメッセージはクライアントのニックネームのプレフィックスが必要です。 USERメッセージは直接接続したクライアントから来た時、とをIRCサーバは(安全のために)無視することに注意してください。しかし、これらはサーバ-サーバ通信では使用されます。 新しいユーザを残りのネットワークに紹介する時、USERコマンドで情報を送信する前にNICKメッセージを送信せねばならないことを意味します。 のパラメータは最後のパラメータであることに注意してください。これはこのパラメータはスペース文字を含むかもしれないからです。このようにスペースを認識させるためにコロン(':')のプレフィックスを付けねばなりません。 の取得はUSERメッセージにのみ依存しているので、クライアントは偽ることが容易です。そこでサーバには"Indentity Server"の使用が推奨されています。(訳者注:RFC1413を参照) クライアントの接続しているホストが"Identity Server"を使用可能ならばは"Identity Server"からのリプライに従って設定されます。 ニュメリックリプライ: ERR_NEEDMOREPARAMS ERR_ALREADYREGISTRED 例: USER guest tolmoon tolsun :Ronnie Reagan "guest"というでが"Ronnie Reagan"をクライアントに登録します。 :testnick USER guest tolmoon tolsun :Ronnie Reagan サーバ間で送信されるUSERメッセージの送信者のニックネームつきのメッセージです。 [4.1.4 SERVERメッセージ] Command: SERVER Parameters: SERVERメッセージは新しく接続した端点はサーバであることを伝えるのに使用します。 このメッセージは全ネットワークにサーバのデータを伝えるためにも使われます。 新しいサーバがネットワークに接続したとき、このサーバについての情報はネットワーク全体にブロードキャストされます。 はそのサーバからどのくらい離れているかという内部情報を全てのサーバに渡すのに使われます。 完全なサーバリストを漬かって、全体のサーバツリーのマップを構築することが可能となっています。しかし、ホストマスクがこれを行うのに邪魔になります。 SERVERメッセージは以下のどちらかの場合の時しか受け付けてはなりません。: (a) 接続が確立していてかつサーバとして接続しようとしている場合 (b) 既存の接続を通して新しいサーバを接続しようとしている場合 (b)の場合、新しいサーバはSERVERメッセージを使って既存の接続先の SERVERメッセージの受信時に起こるほとんどのエラーは受信先のホスト(ターゲットSERVER)が接続を拒否した結果です。 エラーリプライは通常、ニュメリックリプライよりむしろ"ERROR"メッセージを使って送信されます。これは、この場合には有益な性質を持っているためです。 SERVERメッセージが解析された結果、すでに接続されているサーバへの登録が試みられた場合、サーバへの2重の経路が形成され、非循環的なIRCツリーが壊されるので、そのメッセージによる接続は(正しい手続きの後に)閉じなくてはなりません。 ニュメリックリプライ: ERR_ALREADYREGISTRED 例: SERVER test.oulu.fi 1 :[tolsun.oulu.fi] Experimental server 新しいサーバtest.oulu.fiを自分自身を登録し、接続の確立を試みます。 []の中の名前はtest.oulu.fiの走っているホストのホスト名です :tolsun.oulu.fi SERVER csd.bu.edu 5 :BU Central Serve サーバ tolsun.oulu.fiは5 hop 離れたcsd.bu.eduに接続します。 [4.1.5 OPER(operator)メッセージ] Command: OPER Parameters: OPERメッセージは一般クライアントがIRCオペレータの権限を得るために使用します。 との組み合わせがIRCオペレータの権限を得るために必要です。 OPERメッセージを送信したクライアントがそのユーザに割り当てられた正しいパスワードを送った場合、サーバはクライアントのニックネームに対して"MODE +o"を送信することによって新しいオペレータを残りのネットワークに知らせます OPERメッセージはクライアント-サーバ間のみで使用されます。 ニュメリックリプライ: ERR_NEEDMOREPARAMS ERR_NOOPERHOST ERR_PASSWDMISMATCH RPL_YOUREOPER 例: OPER foo bar "foo"というユーザ名で"bar"をpasswordとしてIRCオペレータに登録することを試みます [4.1.6 QUITメッセージ] Command: QUIT Parameters: [] クライアントのセッションをと共に終了します。 サーバはQUITメッセージを送信したクライアントとの接続を閉じなくてはなりません。 が与えられた場合、これはデフォルトメッセージのニックネームの代わりに送信されます。 ネットスプリット(2つのサーバ間の接続の切断)が発生したとき、はネットスプリットに巻き込まれた2つのサーバの名前をスペースで区切ったものとなります。 1番目の名前はまだ接続しているサーバのもので、2番目の名前は接続が切断されたサーバの名前です。 他の何らかの理由で、クライアントがQUITメッセージを発行することなしにクライアントの接続が閉じたられた場合(例えばクライアントが死んで、ソケット上にEOFが発生した時)、サーバは、終了の原因を反映するような終了メッセージを代わりに使用することが必要となります。 ニュメリックリプライ: 存在しません 例: QUIT :昼めし食いに行きます！ このようなメッセージフォーマットを使います。 [4.1.7 SQUIT(server quit)メッセージ] Command: SQUIT Parameters: SQUITメッセージはサーバが終了または死ぬことを送信するために使用されます。 サーバがあるサーバとの接続を破棄したい場合、サーバは他のサーバにSQUITメッセージを送らねばなりません。その時、パラメータには送り先のサーバの名前を使用します。すると送り先のサーバは終了しようとしているサーバとの接続を閉じます。 このメッセージはIRCオペレータがIRCサーバの適切なネットワークを維持するために使用されます。 IRCオペレータはリモートサーバの接続に対するSQUITメッセージを発行することも可能です。 この場合以下に述べるように、SQUITはIRCオペレータとリモートサーバの間にはさまれる各サーバによって構文解析され、各サーバが保持するネットワークの形状が更新されます。 IRCオペレータは、リモートサーバ(これは現在オペレータのいるサーバ サーバもまたにエラーやそれに類似したメッセージを置いてゆきます。 ネットワークの閉じる接続の向こう側に広がる全サーバのために、閉じる接続の両端のサーバはSQUITメッセージを(そのサーバに接続している他の全てのサーバに)送信することが要求されます。 同様に、切りはなされる方のネットワークに接続している全クライアント分のQUITメッセージを送信せねばなりません。 これに加えて、分断によってそのチャンネルのメンバーを失う全チャンネルのメンバーはQUITメッセージを送信せねばなりません。 サーバとの接続が突然切れた場合(例えば、接続先のサーバが死んだ場合)、この接続の切断を検知したサーバは接続が閉じられた残りのネットワークに、何らかの妥当なコメントをコメントフィールドに記載して知らせることが必要です。 ニュメリックリプライ: ERR_NOPRIVILEGES ERR_NOSUCHSERVER 例: SQUIT tolsun.oulu.fi :Bad Link ? サーバリンクtolson.oulu.fi は"Bad link"のために接続を終了しました :Trillian SQUIT cm22.eng.umd.edu :Server out of control "Server out of control"が原因でネットワークと"cm22.eng.umd.edu"の接続が切断されることついてのTrillianからのメッセージです [4.2 チャンネル操作] このメッセージ群はチャンネルの操作、チャンネルの性質(チャンネルモード),そしてチャンネルの(特にクライアントの)内容と関係があります。 ネットワークで２つのクライアントが最終的に衝突するメッセージを送信した時、これに対する反応には必然的にいく種類かの状態が存在します。 いつでもが指定できることを保証するためにサーバがニックネームのヒストリーを保持することもまた必要です。ニックネームが変更された場合、サーバはこのヒストリをチェックします。 [4.2.1 JOIN(参加)メッセージ] Command: JOIN Parameters: {,} [{,}] JOINメッセージはクライアントが実際にチャンネルに接続しはじめるのに使います。 クライアントがそのチャンネルにJOINできるかどうかは、クライアントが接続しているサーバがチェックします。そのサーバがメッセージを受領した場合、他のサーバは自動的にクライアントをチャンネルに加えます。 以下のような事が影響します: 1. クライアントはチャンネルがinvite-onlyの時はINVITE(招待)されていなくてはなりません。 2. クライアントのニックネーム/ユーザ名/ホスト名がアクティブなbanにマッチしてはいけません。 3. key(password)が設定されているならば正しくそれを入力しなくてはいけません。 より詳細な記述はMODEメッセージの解説のところにあります。 (詳細はセクション4.2.3を参照のこと。) まず、クライアントがチャンネルにJOINすると、クライアントにはサーバが受け取ったチャンネルに影響する全てのメッセージについてのNOTICEメッセージが送信されてきます。 PRIVMSG/NOTICEメッセージはもちろん,MODE,KICK,PART,QUITメッセージなどが含まれます。 JOINメッセージは各サーバがチャンネル上のクライアントがどこにいるか知らなくてはいけないので、全てのサーバへのブロードキャストが必要です。 これによって、チャンネルへのPRIVMSG/NOTICEメッセージの送信が最適化されます。 JOINが成功した場合、クライアントにはチャンネルのトピック(RPL_TOPICが使用されます)、そしてチャンネル上のクライアントのリスト(RPL_NAMREPLYが使用されます)が送られてきます。リストにはJOINしたクライアントも含まれます。 ニュメリックリプライ: ERR_NEEDMOREPARAMS ERR_BANNEDFROMCHAN ERR_INVITEONLYCHAN ERR_BADCHANNELKEY ERR_CHANNELISFULL ERR_BADCHANMASK ERR_NOSUCHCHANNEL ERR_TOOMANYCHANNELS RPL_TOPIC RPL_NAMEREPLY 例: JOIN #foobar チャンネル#fooberにJOINします JOIN &foo fubar チャンネル&fooにkey "fubar"を使ってJOINします。 JOIN #foo,&bar fubar チャンネル#fooにkey"fuber"を使い、&barにはkeyを使わないでJOINします。 JOIN #foo,#bar fubar,foobar チャンネル#fooにはkey "fubar"をチャンネル#barにはkey"foobar"を使ってJOINします。 JOIN #foo,#bar チャンネル#fooと#barにJOINします。 :WiZ JOIN #Twilight_zone WiZからのJOINメッセージ [4.2.2 PART(離脱)メッセージ] Command: PART Parameters: {,} PARTメッセージはパラメータにリストで指定した全チャンネルからクライアントが抜けるときに使用されます。パラメータにリストされた全チャンネルのユーザリストからそのクライアントを取り除きます。 ニュメリックリプライ: ERR_NEEDMOREPARAMS ERR_NOSUCHCHANNEL ERR_NOTONCHANNEL 例: PART #twilight_zone チャンネル#twilight_zoneから抜けます PART #oz-ops,&group5 チャンネル&group5と#oz-opsの両方から抜けます [4.2.3 MODEメッセージ] Command: MODE MODEメッセージはIRCでは2つの目的を持つメッセージです。 これはユーザ名とチャンネルの両方をモード変更の対象としています。 この理論的根拠は、将来ニックネームが使用されなくなったときにそれに等価なものがチャンネルになるからです。 MODEメッセージを構文解析する時、最初にメッセージ全体を解析することが推奨されます。そしてモードを変更する際はその解析結果をもとにします。 [4.2.3.1 チャンネルモード] Parameters: {[+|-]|o|p|s|i|t|n|b|v} [] [][] MODEメッセージはチャンネルオペレータが「彼らの」チャンネルの特徴を変更するために提供されています。 チャンネルオペレータがモードを変更できるように、サーバも変更することができる必要があります。 チャンネルで利用できる各種のモードは以下の通りです: o - チャンネルオペレータの特権(channelＯperator privileges)を授与／剥奪します。 p - プライベートチャンネル(Ｐrivate channel)属性を設定／解除します。 s - シークレットチャンネル(Ｓecret channel)属性を設定／解除します。 i - インバイトオンリー(Ｉnvite-only)属性を設定／解除します。 t - トピックの変更権(Ｔopic settable)をチャンネルオペレータのみに設定／解除します。 n - チャンネル外のクライアントのメッセージ(Ｎo message)の受信を許可／不許可します。 m - モデレートチャンネル(Ｍoderated channel:司会つきチャンネル)属性を設定／解除します。 l - チャンネルに参加するクライアントの数を制限(userＬimit)する。 b - クライアントの侵入を拒むBANマスク(Ｂan mask)を設定／解除します。 v - モデレートチャンネル属性のついているチャンネルでの発言権を授与／剥奪します。 k - チャンネルキー(channelＫey)(=password)を設定／解除します。 'o'と'b'のオプションを使用した時、全部で3つの事がMODEメッセージでは必要とされます。 これは、'o'や...と関連づけられた... <訳者注:>原文も途中で終わっています。ここは「これは、'o'に関連付けられるニックネームや'b'に関連付けられるバンマスクです。」ではないかと思われます。 [4.2.3.2 ユーザモード] Parameters: {[+|-]|i|w|s|o} ユーザモードは大抵、クライアントが他の人からの見え方やクライアントに送られてくる「余分な」メッセージに影響します。 メッセージの送信者とパラメータとして与えられたニックネームの両方が同一の時に、ユーザMODEメッセージは受領されます。 以下に述べるものがモードとして使用可能です: i - クライアントを不可視(Invisible)とします。 s - サーバのNOTICE(Server notice)メッセージを受信します。 w - クライアントはWALLOPSメッセージを受信します o - IRCオペレータフラグ(Operator flag)を立てます。 後ほど追加のモードが利用できるようになるかもしれません。 クライアントが自分自身を"+o"フラグを使ってIRCオペレータに任命しようとした場合、その試みは無視されます。 しかしながら、自分自身を"-o"を使うことでIRCオペレータをやめること(deopping)することにはなんの制約もありません。 ニュメリックリプライ: ERR_NEEDMOREPARAMS ERR_CHANOPRIVSNEEDED ERR_NOSUCHNICK ERR_NOTONCHANNEL ERR_KEYSET ERR_UNKNOWNMODE ERR_NOSUCHCHANNEL ERR_USERSDONTMATCH ERR_UMODEUNKNOWNFLAG RPL_CHANNELMODEIS RPL_BANLIST RPL_ENDOFBANLIST RPL_UMODEIS 例: チャンネルモードの使い方: MODE #Finnish +im #Finnish チャンネルにモデレートとインバイトオンリーの属性を付加します。 MODE #Finnish +o Kilroy #Finnish チャンネル上でのチャンネルオペレータの権限をKilroyさんに授与します。 MODE #Fins -s #Fins チャンネルからシークレットフラグを解除します。 MODE #42 +k oulu チャンネルキー(=password)に"oulu"を設定します。 MODE #eu-opers +l 10 チャンネル上のクライアントの数の制限を10に設定します。 MODE &oulu +b チャンネルに設定されているbanマスクのリストを表示します。 MODE &oulu +b *!*@* 全てのクライアントの参加を拒否します。 MODE &oulu +b *!*@*.edu ホスト名が"*.edu"にマッチするクライアントの参加を拒否します。 ユーザモードでの使い方: MODE WiZ -w WIZからのWALLOPSメッセージの受信を無視します。 :Angel MODE Angel +i Angelからのメッセージを自分自身で不可視にします MODE WiZ -o WiZを"deopping"します(IRCオペレータ状態を解除します) このメッセージの単なる逆("MODE WiZ +o")は、OPERメッセージでバイパスされているので、クライアントには許可されていません。 [4.2.4 TOPICメッセージ] Command: TOPIC Parameters: [] TOPICメッセージはチャンネルのトピックを見たり変更したりするために使用します。 もし、がなかった場合、で指定されたチャンネルのトピックが返されます。 のパラメータが送られた場合、チャンネルモードのパーミッションが許せばチャンネルのトピックが変更されます。 ニュメリックリプライ: ERR_NEEDMOREPARAMS ERR_NOTONCHANNEL ERR_CHANOPRIVSNEEDED RPL_NOTOPIC RPL_TOPIC 例: :Wiz TOPIC #test :New topic クライアントWizがトピックを設定します。 TOPIC #test :another topic #testに"another topic"というトピックを設定します。 TOPIC #test #testのトピックをチェックします。 [4.2.5 NAMESメッセージ] Command: NAMES Parameters: [{,}] NAMESメッセージを使うことによって、クライアントはそのクライアントが可視なチャンネル上のニックネームを全て一覧することができます。 可視なチャンネルとはprivate(+p)やsecret(+s)などが設定されていない、実際にだれかいるチャンネルを言います。 その指定が妥当なものなら、パラメータは情報を返すチャンネルを指定します。 間違ったチャンネル名に対するエラーリプライはありません。 パラメータが与えられなかった場合は、全てのチャンネルとその参加者のリストが帰ってきます。 このリストの最後には、クライアントのいるチャンネル上もしくは可視なチャンネル上にいない可視なクライアントのリストが、「チャンネル」"*"として一覧表示されます。 ニュメリックリプライ: RPL_NAMREPLY RPL_ENDOFNAMES 例: NAMES #twilight_zone,#42 チャンネルがあなたにとって可視ならば、#twilight_zoneと#42上の可視なクライアントを一覧表示します。 NAMES 全ての可視なチャンネルと可視なクライアントを一覧表示します。 [4.2.6 LISTメッセージ] Command: LIST Parameters: [{,} []] LISTメッセージはチャンネルとそのチャンネルのトピックを一覧表示するのに使用します。 パラメータが使われた場合、チャンネルのステータスを表示するだけです。 プライベートチャンネルでは、クライアントがそのプライベートチャンネルにいるのでなければ、チャンネル"Prv"として、(トピックなしで)一覧表示されます。 同様にシークレットチャンネルでは、クライアントが問題のチャンネルメンバーでなければ、全くリストにのりません。 ニュメリックリプライ: ERR_NOSUCHSERVER RPL_LISTSTART RPL_LIST RPL_LISTEND 例: LIST 全チャンネルを一覧表示します。 LIST #twilight_zone,#42 #twilight_zoneと#42のチャンネルを一覧表示します。 [4.2.7 INVITE(招待)メッセージ] Command: INVITE Parameters: INVITEメッセージはチャンネルにクライアントを招待するために使用します。 パラメータはターゲットのチャンネルに招かれる人のニックネームです。 ターゲットとなるクライアントが招かれるチャンネルが存在しなくてはならないとか、有効なチャンネルでなければならないといった必要性はありません。 クライアントをinvite-onlyなチャンネル(mode +i)に招くには、INVITEを送信するクライアントがそのチャンネル上でチャンネルオペレータの権限をもっていなくてはなりません。 ニュメリックリプライ: ERR_NEEDMOREPARAMS ERR_NOSUCHNICK ERR_NOTONCHANNEL ERR_USERONCHANNEL ERR_CHANOPRIVSNEEDED RPL_INVITING RPL_AWAY 例: :Angel INVITE Wiz #Dust クライアントAngelはWizをチャンネル#Dustに招待しています。 INVITE Wiz #Twilight_Zone Wizを#Twilight_Zoneに招待する命令です。 [4.2.8 KICK(追放)メッセージ] Command: KICK Parameters: [] KICKメッセージは強制的にチャンネルからクライアントを削除するときに使うことができます。 これはチャンネルから「追い出だし(kicks them out)」(強制離脱)ます。 チャンネルオペレータだけがチャンネルの外からきた他のクライアントを追い出すことができます。 チャンネルからキックの犠牲者を削除する前に、KICKメッセージを受け取ったサーバは、これが有効かどうか(送信者が本当にチャンネルオペレータかどうか)チェックします。 ニュメリックリプライ: ERR_NEEDMOREPARAMS ERR_NOSUCHCHANNEL ERR_BADCHANMASK ERR_CHANOPRIVSNEEDED ERR_NOTONCHANNEL 例: KICK &Melbourne Matthew &MelbourneからMatthewを追い出します KICK #Finnish John :Speaking English Johnを#Finnishから"Speaking English"を理由として(コメント)追い出します。 :WiZ KICK #Finnish John Johnをチャンネル#Finnishから削除するWiZからのKICKメッセージです。 注: KICKメッセージをパラメータを以下のように拡張することも可能です: {,} {,} [] [4.3 サーバへのクエリーとメッセージ] サーバに対するクエリーメッセージ群はネットワークに接続しているサーバについての情報を返すように設計されています。 接続している全てのサーバはこれらの要求に正確に応答しなくてはなりません。 どんなものでもその不当な(または不足している)リプライはそのサーバが壊れたサインのと受け取られます。そして、状況が回復するまで、可能な限り速やかにそのサーバと接続を切断または接続を不可能にしなくてはいけません。 これらのクエリーでは、として現れるパラメータの所に、いつでもニックネームまたはサーバまたはいく種類かのワイルドカードを使った名前がくる事を意味します。 しかしながら、それぞれパラメータについても、たった一つのクエリーとリプライのセットが生成されます。 [4.3.1 VERSIONメッセージ] Command: VERSION Parameters: [] VERSIONメッセージはサーバプログラムのバージョンを要求するために使用します。 オプショナルなパラメータはクライアントが直接接続していないサーバプログラムのバージョンを請求する時に使用します。 ニュメリックリプライ: ERR_NOSUCHSERVER RPL_VERSION 例: :Wiz VERSION *.se "*.se"にマッチするサーバのバージョンをチェックするWizからのメッセージです。 VERSION tolsun.oulu.fi サーバ"tolsun.oulu.fi"のバージョンをチェックします。 [4.3.2 SATAS(状態)メッセージ] Command: STATS Parameters: [ [] STATSメッセージはある特定のサーバの統計を要求するのに使用します。 パラメータが書かれていなかった場合、単にRPL_ENDOFSTATSが送信されてきます。 サーバは下記の(ような)クエリーを供給できなくてはならないのですが、このメッセージの実装はサーバに高く依存します。 送信先のサーバ(パラメータで指定できます)に対して、クエリーとして1文字を指定します。中継するサーバはこれを無視し変更せずに転送します。 以下に述べる要求は現在のIRCで実装されているもので、サーバのセットアップ情報の大部分が供給されます。 これらはバージョンによって同じようにはサポートされていないかもしれません。クエリーの目的と現在使用されているリプライのフォーマットに矛盾しない、正しいリプライをサーバはSTATSメッセージに対してリプライしなくてはなりません。 現在サポートされている要求: c サーバが接続できるまたは接続を許可しているサーバの一覧を返します。 h リーフ(ネットワークの末端)として扱われることが強制されるか、ハブ(ネットワークの中心)として動くことが許可されているか、という点についてのサーバの一覧を返します。 i クライアントの接続することをサーバが許可しているホストのリストを返します。 k サーバが禁止しているユーザ名/ホスト名の組み合わせのリストを返します。 l サーバの接続のリストを返します。各接続の確立の持続時間、その接続の各方向からのオクテット単位のトラフィック量、メッセージが分かります。 m サーバがサポートしているメッセージと（もし使用されているならば）それぞれの使用回数のリストを返します。 o 通常のクライアントがIRCオペレータになれるホストのリストを返します。 y サーバの初期設定ファイルからYクラス行を表示します。 u サーバが稼働し続けている時間を示す文字列を返します。 ニュメリックリプライ: ERR_NOSUCHSERVER RPL_STATSCLINE RPL_STATSNLINE RPL_STATSILINE RPL_STATSKLINE RPL_STATSQLINE RPL_STATSLLINE RPL_STATSLINKINFO RPL_STATSUPTIME RPL_STATSCOMMANDS RPL_STATSOLINE RPL_STATSHLINE RPL_ENDOFSTATS 例: STATS m 接続しているサーバの使えるメッセージチェックします。 :Wiz STATS c eff.org サーバeff.orgのC/N行の情報をWiZが要求しています。 [4.3.3 LINKメッセージ] Command: LINKS Parameters: [[] ] LINKSメッセージによって、サーバが要求に答えることで知ることのできる全サーバをクライアントは一覧表示する事ができます。 返されるサーバのリストはマスクにマッチするもののリストかマスクが指定されていなければ完全なリストです。 に加えてが指定されていた場合、LINKSメッセージはそのにマッチした最初のサーバへ転送されます。そして、そのサーバが要求に対して応答をします。 ニュメリックリプライ: ERR_NOSUCHSERVER RPL_LINKS RPL_ENDOFLINKS 例: LINKS *.au "*.au"にマッチする名前を持つ全サーバのリスト :WiZ LINKS *.bu.edu *.edu WiZから"*.edu"にマッチする最初のサーバへの"*.bu.edu"にマッチするサーバのリストを要求するLINKSメッセージ [4.3.4 TIMEメッセージ] Command: TIME Parameters: [] TIMEメッセージは指定したサーバのローカルタイム(地方時間)を要求するのに使用されます。 パラメータが指定されなかった場合、メッセージを扱うサーバが要求に対して応答を返します。 ニュメリックリプライ: ERR_NOSUCHSERVER RPL_TIME 例: TIME tolsun.oulu.fi サーバ"tolson.oulu.fi"の時間をチェックします。 :Angel TIME *.au クライアントAngelが"*.edu"にマッチするサーバの時間をチェックします。 [4.3.5 CONNECT(接続)メッセージ] Command: CONNECT Parameters: [ []] CONNECTメッセージは直ちに他のサーバとの新しい接続の確立を試る事をサーバに強制する時に使用します。 CONNECTメッセージを実行する権限はIRCオペレータのみに与えられています。 リモートサーバを指定した場合、サーバはCONNECTメッセージをのに対して試みます。 ニュメリックリプライ: ERR_NOSUCHSERVER ERR_NOPRIVILEGES ERR_NEEDMOREPARAMS 例: CONNECT tolsun.oulu.fi tolsun.oulu.fiとサーバの接続を試みます。 :WiZ CONNECT eff.org 6667 csd.bu.edu WiZが送信したサーバcsd.bu.eduとサーバeff.org間がポート6667で接続するCONNECTメッセージを試みます。 [4.3.6 TRACE(追跡)メッセージ] Command: TRACE Parameters: [] TRACEメッセージは指定されたサーバへの経路を探すのに使用されます。 このメッセージを処理する各サーバはそのサーバの経路リンクを通過した事を示すリプライメッセージをTRACEメッセージの送信者に送信しなくてはいけません。こうして、経路追跡を使うことで得られる結果に似た一連のリプライが構成されます。 リプライを送信した後、指定したサーバに到達するまでは、次のサーバにTRACEメッセージ送信しなくてはなりません。 パラメータが書き落とされていた場合、TRACEコマンドに対して、現在のサーバが直接接続しているサーバを示すメッセージを送信者に送り返さなくてはいけません。 パラメータによって指定されたサーバが実在する場合、そのサーバは自分に接続された全サーバ、及びクライアントをレポートすることが求められていますが、現在のクライアントについてはIRCオペレータのみ見ることが出来ます。 パラメータによって指定された受信先がニックネームの場合、単にニックネームがリプライとして割り当てられます。 ニュメリックリプライ: ERR_NOSUCHSERVER TRACEメッセージを他のサーバに転送する場合、全ての中継サーバはTRACEメッセージがそこを通過し次にどこに転送されたかということ示すためにリプライRPL_TRACELINKを返さなくてはいけません。 RPL_TRACELINK TRACEリプライは以下に述べるニュメリックリプライのいくつかの集まりで構成されます。 RPL_TRACECONNECTING RPL_TRACEHANDSHAKE RPL_TRACEOPERATOR RPL_TRACEUSER RPL_TRACESERVER RPL_TRACESERVICE RPL_TRACENEWTYPE RPL_TRACECLASS 例: TRACE *.oulu.fi "*.oulu.fi"にマッチするサーバへの経路をTRACE(追跡)します。 :WiZ TRACE AngelDust WiZのニックネーム AngelDusに対して送信したTRACEメッセージです。 [4.3.7 ADMIN(管理者)メッセージ] Command: ADMIN Parameters: [] ADMINメッセージは、指定したサーバまたはが省略された場合は現在のサーバの管理者の名前を見つけるためにつかいます。 各サーバはADMINメッセージを他のサーバに転送できなければなりません。 ニュメリックリプライ: ERR_NOSUCHSERVER RPL_ADMINME RPL_ADMINLOC1 RPL_ADMINLOC2 RPL_ADMINEMAIL 例: ADMIN tolsun.oulu.fi tolsun.oulu.fiにADMINリプライを要求します。 :WiZ ADMIN *.edu WiZからの最初に"*.edu"にマッチしたサーバへのADMINメッセージです。 [4.3.8 INFOメッセージ] Command: INFO Parameters: [] INFOメッセージはサーバについての以下のような情報を返すために使用します: (a) サーバのバージョン (b) いつコンパイルされたか (c) パッチレベル (d) いつ起動されたか (e) 重要と思われるその他雑多な情報 ニュメリックリプライ: ERR_NOSUCHSERVER RPL_INFO RPL_ENDOFINFO 例: INFO csd.bu.edu csd.bu.eduにINFOメッセージに対する応答を要求します。 :Avalon INFO *.fi このINFOメッセージはAvalonからの最初に"*.fi"にマッチしたサーバにリプライを要求します。 INFO Angel Angelの接続しているサーバにINFOメッセージに対するリプライを要求します。 [4.4 メッセージの送信] IRCプロトコルの主な目的はクライアントが互いに通信する基礎を提供することです。 PRIVMSGとNOTICEだけが、あるクライアントから他のクライアントへテキストメッセージを実際に送信可能なメッセージです。残りは信頼性や順序を保証したりすることを可能とするために使用されます。 [4.4.1 PRIVMSG(private message)メッセージ] Command: PRIVMSG Parameters: {,} PRIVMSGはクライアント間のプライベートメッセージを送信するのに使われます はメッセージを受け取る人のニックネームです。 はコンマで区切ることでニックネームやチャンネルのリストにすることもできます。 パラメータはホストマスク(#mask)やサーバマスク($mask)を使用することもできます。 どちらの場合も、サーバはマスクにマッチするサーバやホストにPRVMSGメッセージを配信するだけです。 マスクは最低1つの"."を含んでいなくてはなりません。そして最後の"."の後にワイルドカードがあってはいけません。 この制限は誰かがメッセージを"#*"や"$*"へ送信することを防ぐために存在します。これは、全てのクライアントに対するブロードキャストになってしまいます。経験的にこれらは正しく意図的に使用されることよりも誤用されることが多いからです。 ワイルドカードは'*'と'?'の文字が使用できます。 このPRIVMSGメッセージへの拡張はIRCオペレータのみが使用できます。 ニュメリックリプライ: ERR_NORECIPIENT ERR_NOTEXTTOSEND ERR_CANNOTSENDTOCHAN ERR_NOTOPLEVEL ERR_WILDTOPLEVEL ERR_TOOMANYTARGETS ERR_NOSUCHNICK RPL_AWAY 例: :Angel PRIVMSG Wiz :Hello are you receiving this message ? AngelからWizに対するメッセージです PRIVMSG Angel :yes I'm receiving it !receiving it !'u>(768u+1n) .br Angelへのメッセージです。 PRIVMSG jto@tolsun.oulu.fi :Hello ! サーバtolsun.oulu.fi上のユーザ名が"jto"というクライアントへのメッセージです PRIVMSG $*.fi :Server tolsun.oulu.fi rebooting. "*.fi"にマッチする名前のサーバ上にいる全員へのメッセージです。 PRIVMSG #*.edu :NSFNet is undergoing work, expect interruptions "*.edu"にマッチする名前のホストから来た全クライアントへのメッセージです。 [4.4.2 NTICEメッセージ] Command: NOTICE Parameters: NOTICEメッセージはPRIVMSGと同じように使用します。 NOTICEとPRIVMSGの間で異なる点は、 NOTICEメッセージを受け取った場合、それに対してなにも反応して送信してはいけません。 この規定はサーバに対しても適用されます。NOTICEメッセージを受け取ったクライアントにエラーリプライすら返信する必要してはいけません。 この規定の目的は、メッセージに対して自動的になにかを送信するクライアントとの間のループを避けることです。 これは典型的なオートマトン(クライアントはAIまたは人間が操作する会話的なプログラムです)によって使用されます。すなわち、他のオートマトンとのリプライのループが切りたいオートマトンが使用します。 リプライの詳細と例はPRIVMSGを参照のこと [4.5 ユーザ情報の要求] ユーザ情報の要求は特にクライアントやクライアントのグループ(チャンネル)について詳細を調べる関係したメッセージ群です。 これらのメッセージにおいてワイルドカードを使用したとき、ワイルドカードがマッチした場合、「見える(visible)」クライアントの情報を返すだけです。 クライアントの可視性はユーザモードと同一のチャンネルにいるかどうかという事の組み合わせに従って決定されます。 [4.5.1 WHOメッセージ] Command: WHO Parameters: [ []] WHOメッセージはクライアントがパラメータにマッチしたクライアントの情報のリストを返すクエリーを生成するために使用されます。 パラメータが欠如していた場合、全ての可視なクライアント(不可視(user mode +i)になっていないクライアントで、かつ、クエリーを送信したクライアントと共通のチャンネルにいないクライアント)のリストを表示します。 "0"というを使うか、全てのエントリに完全にマッチするワイルドカードを使うことで同じ結果を得ることができます。 WHOメッセージに渡されたは、channelにマッチしない場合、クライアントのhost,server,real,nickに対してマッチします。 "o"パラメータが与えられた場合、与えられたネームマスクによる結果のうちIRCオペレータだけを返します。 ニュメリックリプライ: ERR_NOSUCHSERVER RPL_WHOREPLY RPL_ENDOFWHO 例: WHO *.fi "*.fi"にマッチする全クライアントのリストを要求します。 WHO jto* o "jto*"にマッチする全クライアントの内のIRCオペレータのリストを要求します。 [4.5.2 WHOISメッセージ] Command: WHOIS Parameters: [] [,[,...]] このWHOISメッセージはクライアント個別の情報を要求するために使用されます。 にマッチする(見る資格を持っている)各クライアントの状態の違いを示すニュメリックリプライによってこのメッセージに回答します。 にワイルドカードが使われていない場合、可視なニックネームについての情報が表示されます。 コンマ','でニックネームのリストを区切ることで複数指定することができます。 別の使い方では指定したサーバにクエリーを送信できます。 他の情報は全体に行き渡っているのですが、問題のユーザがどのくらいidle状態にあるかといったローカルサーバ(すなわち、ユーザが直接に接続しているサーバ)にしか分からないことを知りたい場合に便利です。 ニュメリックリプライ: ERR_NOSUCHSERVER ERR_NONICKNAMEGIVE ERR_NOSUCHNICK RPL_WHOISUSER RPL_WHOISCHANNELS RPL_WHOISSERVER RPL_AWAY RPL_WHOISOPERATOR RPL_WHOISIDLE RPL_ENDOFWHOIS 例: WHOIS wiz ニックネームがWiZのユーザ情報を可能な限り返します。 WHOIS eff.org trillian サーバeff.orgにtrillianのユーザ情報を問い合わせます。 [4.5.3 WHOWASメッセージ] Command: WHOWAS Parameters: [ []] WHOWASメッセージはもう存在していないの情報を問い合わせます。 これはニックネームが変更されたり、IRCから去ったりした場合に使用します。 このクエリーに対するリプライは、サーバがニックネームヒストリを使ってに該当する見出しのエントリを探索します。(ここではワイルドカードマッチを使用しません。) ヒストリは後方検索され、最初に見つかったエントリを最初に返します。 複数のエントリがあった場合、個までのリプライが返されます。(パラメータを指定しなかった場合は見つかるだけ全て返します。) として非正数が渡された場合、見つかるだけ全てを返します。 ニュメリックリプライ: ERR_NONICKNAMEGIVEN ERR_WASNOSUCHNICK RPL_WHOWASUSER RPL_WHOISSERVER RPL_ENDOFWHOWAS 例: WHOWAS WiZ ニックネームヒストリ中のニックネーム"WiZ"に関する全情報を返します。 WHOWAS Mermaid 9 最近9個までの"Mermaid"に関するニックネームヒストリのエントリを返します。 WHOWAS Trillian 1 *.edu 最初に"*.edu"にマッチしたサーバ上のヒストリで、最も新しい"Trillian"のエントリを返します。 [4.6 その他のメッセージ] このカテゴリのメッセージはどのカテゴリにも属さないものですが、プロトコルの一部であり必要なものです。 [4.6.1 KILLメッセージ] Command: KILL Parameters: KILLメッセージはクライアント-サーバ間の接続を直接接続しているサーバが閉じるときに使われます。 サーバが、正確なニックネームリストでだぶったエントリに遭遇したときに、この2つのエントリをKILLメッセージを使って削除します。 これはIRCオペレータも使用することができます。 単に接続を短時間切断するだけのことなので、事実上自動的に再接続するアルゴリズムを持っているクライアントにはこのメッセージに利用価値はありません。 クライアントは生成されたKILLメッセージを拒否することが出来ないので、問題の箇所に目星をつけてデータの流れを中断させ、大きな被害になることを食い止めるのに使うことができます。 ニックネームはいつでも世界中でユニークな事が要求されます。「二重性」が検知された時は(すなわち、2つのクライアントが同一のニックネームを登録しようとした時)いかなる時でも両者が消えるか、片方だけ再び出現することを期待して送信されます。 はKILLメッセージに対する実際の理由を反映していなくてはいけません。 サーバが生成するKILLメッセージのコメントは2つの衝突したニックネームの所在に関する詳細な情報で構成されます。 これを見た他のユーザが満足できる十分な理由をユーザが提供することは、それぞれにまかされています。 偽のKILLメッセージの送信者が自分自身の情報を隠すのを防ぐために、このコマンドを通過させるサーバは仁の名前を'kill-path'と呼ばれるものを後ろに付け加えて、これをに含めます。 ニュメリックリプライ: ERR_NOPRIVILEGES ERR_NEEDMOREPARAMS ERR_NOSUCHNICK ERR_CANTKILLSERVER KILL David (csd.bu.edu <- tolsun.oulu.fi) ニックネームの衝突がcsd.bu.eduとtolson.oulu.fiの間で起こりました。 注: KILLメッセージを使って他のクライアントをKILLする事はオペレータのみに許可されています。 理想的にはIRCオペレータすらこれを行う必要はありません。これを使用するものとしてはサーバだけが残ります。 [4.6.2 PINGメッセージ] Command: PING Parameters: [] PINGメッセージはコネクションの他端のアクティブなクライアントの状態をテストするために使われます。 他端の接続からアクティブなものが検知できない場合、PINGメッセージが一定間隔をおいて送信されます。 接続が規定時間以内にPINGメッセージに対して反応しなかった場合、その接続は閉じられます。 PINGメッセージを受け取ったクライアントは、まだ接続が生きていることを示すために、に対してできる限り速やかに適切なPONGメッセージを返信しなくてはいけません。 サーバはPINGメッセージに対して返信はしません。しかし、PINGに対するリプライから他端の接続からの接続が生きている事を信用します。 パラメータが指定された場合、PINGメッセージはそこに転送されます。 ニュメリックリプライ: ERR_NOORIGIN ERR_NOSUCHSERVER 例 PING tolsun.oulu.fi 別のサーバがまだ生きていること確かめるためにサーバが送信するPINGメッセージ PING WiZ PINGメッセージをニックネーム WiZに対して送信します。 [4.6.3 PONGメッセージ] Command: PONG Parameters: [] PONGメッセージはPINGメッセージに対するリプライです。 パラメータが指定された場合、このメッセージは指定のデーモンに転送されます。 パラメータはPINGメッセージに対してこのPONGメッセージを生成して返信を行うデーモンの名前です。 ニュメリックリプライ: ERR_NOORIGIN ERR_NOSUCHSERVER 例: PONG csd.bu.edu tolsun.oulu.fi csd.bu.eduからtolsun.oulu.fiへのPONGメッセージです [4.6.4 ERRORメッセージ] Command: ERROR Parameters: ERRORメッセージはIRCオペレータに、深刻なまたは致命的なエラーを報告するために、サーバが使用します。 あるサーバから別のサーバに対して送信することもできます。しかし、通常、他端のクライアントからのものは受領されません。 ERRORメッセージはサーバ-サーバ間の接続で発生したエラーを報告するためだけに使用されます。 ERRORメッセージは全サーバ(これは、直接接続しているオペレータ全員にERRORメッセージを伝えます)と直接接続している全オペレータに対して送信されます。 あるサーバからERRORメッセージが届いた場合、サーバはERRORメッセージを他のサーバに転送しません。 サーバがIRCオペレータに受信したERRORメッセージを送信するときは、クライアントがこのエラーに対して反応しないように指示するために、をNOTICEメッセージにします。 ニュメリックリプライ: 存在しません。 例: ERROR :Server *.fi already exists このエラーが起きたサーバへのERRORメッセージです NOTICE WiZ :ERROR from csd.bu.edu -- Server *.fi already exists 他端のサーバ上のクライアントWiZへ送る場合の、上記と同じようなERRORメッセージです。 [5. OPTIONALメッセージ] このセクションではOPTIONALメッセージについて述べてゆきます。 サーバはここのプロトコルで述べる実装をする必要はありません。 このオプションがないときは、エラーリプライメッセージを生成するか、さもなければ、不明なメッセージのエラーとします。 他のサーバがそのメッセージにリプライを送信するいる場合があるので、これを通過させなくてはいけません。(従って、要素を解析をする必要があります。) これらのリプライに割り当てられた番号はメッセージの説明の後に並べてあります。 [5.1 AWAYメッセージ] Command: AWAY Parameters: [message] AWAY(チャンネルに対して送信されたものではなく)そのクライアントに直接配信されたPRIVMSGメッセージに対して自動的にリプライメッセージを返信するようにクライアントは指定することができます。 クライアントに配信されたPRIVMSGメッセージに対してサーバが自動リプライを送信します。 リプライをするサーバは送信したクライアントがつながっているサーバだけです。 パラメータを1つ指定した時(AWAYメッセージを設定する)とパラメータなしの時(AWAYメッセージを解除する)の両方の場合で使用できます。 ニュメリックリプライ: RPL_UNAWAY RPL_NOWAWAY 例: AWAY :Gone to lunch. Back in 5 AWAYメッセージに"Gone to lunch. Back in 5"と設定する。 :WiZ AWAY WiZのAWAYメッセージを解除します。 [5.2 REHASHメッセージ] Command: REHASH Parameters: None REHASHメッセージは強制的にサーバに設定ファイルを読み込ませるためにIRCオペレータが使用します。 ニュメリックリプライ: ERR_NOPRIVILEGES RPL_REHASHING 例: REHASH IRCオペレータの権限をもつクライアントからサーバに対して設定ファイルを読み込む事を指示するメッセージです。 [5.3 RESTARTメッセージ] Command: RESTART Parameters: None RESTARTメッセージは強制的にサーバを再起動するためにIRCオペレータが使用します。 IRCオペレータとしてサーバに接続しているひとが、なにかの間違いでRESTARTメッセージを送信するリスクがあるので、このメッセージはオプションあつかいになっています。このメッセージは(最低でも)IRCサービスの中断を引き起こします。 RESTARTメッセージはいつでも、送信したクライアントが接続しているサーバに作用します。接続している他のサーバに転送されることはありません。 ニュメリックリプライ: ERR_NOPRIVILEGES 例: RESTART パラメータは必要ありません [5.4 SUMMON(召還)メッセージ] Command: SUMMON Parameters: [] SUMMONメッセージはIRCサーバの走っているホストのユーザにIRCに参加するように呼びかけるメッセージを与えるために使用します。 以下のような条件を満たす場合のみメッセージは送信されます: (a) 送信先のサーバがSUMMONできる (b) 目的とするユーザがログインしている (c) サーバプロセスがそのユーザのtty(またはそれと同等のもの)に書き込みできる。 パラメータが指定されなかった場合、クライアントがつないでいるサーバを送信先サーバと仮定して、をSUMMON(召喚)することを試みます。 そのサーバでSUMMON(召喚)できなかった場合、ニュメリックリプライERR_SUMMONDISABLEDが返され、SUMMONメッセージは失敗します。 ニュメリックリプライ: ERR_NORECIPIENT ERR_FILEERROR ERR_NOLOGIN ERR_NOSUCHSERVER RPL_SUMMONING 例: SUMMON jto サーバホスト上にいるユーザjtoを召還します。 SUMMON jto tolsun.oulu.fi サーバ"tolsun.oulu.fi"の走っているホスト上にいるユーザjtoを召還します。 [5.5 USERSメッセージ] Command: USERS Parameters: [] USERSメッセージはそのサーバのユーザログインリストを、who(1)やrusers(1)、finger(1)のような形式で返します。 セキュリティに関係する理由で、接続しているサーバ上でこのメッセージが使えない人がいる事もあります。 使えない場合、この事を示すため、正しいニュメリックリプライを返さなくてはいけません。 ニュメリックリプライ ERR_NOSUCHSERVER ERR_FILEERROR RPL_USERSSTART RPL_USERS RPL_NOUSERS RPL_ENDOFUSERS ERR_USERSDISABLED 使用されなくなったニュメリックリプライ: ERR_USERSDISABLED 例: USERS eff.org サーバeff.org上のユーザログインリスト要求します。 :John USERS tolsun.oulu.fi Johnからのサーバtolsun.oulu.fi上のロユーザグインリストの要求です。 [5.6 WALLOPS(operwall)メッセージ] Command: WALLOPS Parameters: 現在オンライン中の全IRCオペレータに送信するテキスト 現在オンライン中の全IRCオペレータに対してメッセージを送信します。 ユーザメッセージとしてWALLOPSの実装をすると、(WALLとよく似た)多くの人にメッセージを送信する方法としてよく悪用されます。 このため現在は、以下の例のように、WALLOPSの送信者としてはサーバのみを認めるようにWALLOPSを実装しなくてはなりません。 ニュメリックリプライ: ERR_NEEDMOREPARAMS 例: :csd.bu.edu WALLOPS :Connect '*.uiuc.edu 6667' from Joshua JoshuaからのCONNECTメッセージをアナウンスするcsd.bu.eduからのWALLOPSメッセージです。 [5.7 USERHOSTメッセージ] USERHOSTメッセージは最大5つのニックネームをスペース文字で区切ったリストをパラメータとしてとることができます。各ニックネームについて見つかった情報を返します。 各リプライはスペースで区切ったリストとして返されます。 ニュメリックリプライ: RPL_USERHOST ERR_NEEDMOREPARAMS 例: USERHOST Wiz Michael Marty p ニックネームが"WiZ","Michael","Marty","p"の情報をUSERHOSTは要求します。 [5.8 ISONメッセージ] Command: ISON Parameters: {} ISONメッセージはすばやく効果的にニックネームが現在IRC上にいるかどうかを得る方法を提供するために実装されていました。 ISONはたった1つのパラメータをとります。それはスペースで区切られたニックネームのリストです。 このリストにある各ニックネームがいた場合、サーバはリプライ文字列にそのニックネームを加えます。 従って、空文字列(指定されたニックネームがいない時)から、パラメータ文字列の完全なコピー(全ていた時)まで、パラメータで指定したニックネームの部分集合がリプライの文字列として返されます。 チェックできるニックネームの数の制限は文字列の長さできまります。長すぎる場合はパラメータの文字列は512文字以内になるようにサーバが切り落とします。 ISONはローカルサーバがメッセージを発送したクライアントに対して実行します。遠方の他のサーバには転送しません。 ニュメリックリプライ: RPL_ISON ERR_NEEDMOREPARAMS 例: ISON phone trillian WiZ jarlek Avalon Angel Monstah 7つのニックネームのISONを要求する例です。 [6. リプライ] 以下は、メッセージに応じて生成されるニュメリックリプライのリストです。 各々のニュメリックリプライにはその番号と名前とリプライ文字列が割り当てられています。 [6.1 エラーリプライ] 401 ERR_NOSUCHNICK " :No such nick/channel" " :そのようなnickやchannelはありません" メッセージの与えたパラメータのニックネームが現在使用されていないことを示すために使用されます。 402 ERR_NOSUCHSERVE " :No such server" " :そのようserverはありません" 指定したサーバ名が存在しないことを示すために使用されます。 403 ERR_NOSUCHCHANNEL " :No such channel" " :そのようなchannelはありません" 与えたチャンネル名が不正であることを示すために使用されます。 404 ERR_CANNOTSENDTOCHAN " :Cannot send to channel" " :チャンネルに送れません" (a)mode +nがセットされている場合、チャンネル上にいない (b)mode +mがセットされている場合、チャンネル上でチャンネルオペレータではない(またはmode +vされていない) 以上のような条件で、クライアントがチャンネルにPRIVMSGメッセージを送信しようとすると、そのクライアントにこのメッセージが返信されます。 405 ERR_TOOMANYCHANNELS " :You have joined too many channels" " :あなたは多くのチャンネルにJOIN(参加)しすぎです" 許可されているチャンネル最大数にすでにJOINしているときに、もうひとつ他のチャンネルにJOINしようとしたクライアントにこのメッセージが返信されます。 406 ERR_WASNOSUCHNICK " :There was no such nickname" " :その様なニックネームは存在しません" WHOWASメッセージは該当するニックネームの情報がヒストリ上にないことを示します。 407 ERR_TOOMANYTARGETS " :Duplicate recipients. No message delivered" " :2重に受信ました。メッセージは配信されません" user@hostに該当するクライアントが複数存在している場合に、user@host形式であらわされた送信先へPRIVMSG/NOTICEを送信しようとしたクライアントに返されるエラーリプライです。 409 ERR_NOORIGIN ":No origin specified" ":送信者が指定されていません" 必要な送信者のパラメータを落としたPINGやPONGメッセージです。PINGやPONGメッセージは正しいプレフィックスなしでも働かなくてはならなりません。 411 ERR_NORECIPIENT ":No recipient given ()" ":()の指定した受信先がありません" 412 ERR_NOTEXTTOSEND ":No text to send" ":送信すべきテキストがありません" 413 ERR_NOTOPLEVE " :No toplevel domain specified" " :最上位のドメインが指定されていません" 414 ERR_WILDTOPLEVEL " :Wildcard in toplevel domain" " :最上位のドメインでワイルドカードが使用されています" PRIVMSGが412〜414のリプライを何らかの理由によってメッセージが配信されなかったこと示すために返します。 ERR_NOTOPLEVELとERR_WILDTOPLEVELは"PRIVMSG $"や"PRIVMSG #"の試行が不正に使用されたときに返されるエラーです 421 ERR_UNKNOWNCOMMAND " :Unknown command" " :不明なコマンドです" 送られたコマンドがサーバにとって不明な事を示すためにクライアントに返されます。 422 ERR_NOMOTD ":MOTD File is missing" ":MOTDファイルがありません" サーバがサーバのMOTDファイルを開くことができませんでした。 423 ERR_NOADMININFO " :No administrative info available" " :利用可能な管理情報がありません" サーバが適切な情報を検索中にエラーがあったときADMINメッセージへの応答として返します。 424 ERR_FILEERROR ":File error doing on " ":上のの実行中にファイルエラーが起きました" 生成されたエラーメッセージはメッセージの処理中に起きた、ファイル操作の失敗を報告するために使用されます。 431 ERR_NONICKNAMEGIVEN ":No nickname given" ":ニックネームが指定されていません" パラメータが必要なメッセージでパラメータが見つからない時に返します。 432 ERR_ERRONEUSNICKNAME " :Erroneous nickname" " :間違ったニックネームです" 定義された文字セットにない文字を含んだNICKメッセージを受け取った後に返します。 433 ERR_NICKNAMEINUSE " :Nickname is already in use" " :ニックネームはすでに使用中です" NICKメッセージが現在すでに存在しているニックネームに変更しようとしたときに返します。 436 ERR_NICKCOLLISION " :Nickname collision KILL " :ニックネームの衝突が発生しKILLされました" ニックネームの衝突(他のサーバにすでに存在しているニックネームを登録しようとした)を検知した時にサーバがクライアントに返します。 441 ERR_USERNOTINCHANNEL " :They aren't on that channel" " :彼らはそのチャンネル上にいません" メッセージの送信先クライアントが指定のチャンネル上にいないこと示すためにサーバが返します。 442 ERR_NOTONCHANNE " :You're not on that channel" " :あなたはそのチャンネル上にいません" クライアントがメンバーでないチャンネルに効果をおよぼすメッセージを実行しようとした時にサーバが返します。 443 ERR_USERONCHANNEL " :is already on channel" " :すでにチャンネル上にいます" クライアントがすでにチャンネル上にいるユーザをチャンネルに招こうとした時に返されます。 444 ERR_NOLOGIN " :User not logged in" " :ユーザはログインしていません" 該当するユーザがログインしていないのでSUMMONメッセージを実行できなかった時に返されます。 445 ERR_SUMMONDISABLED ":SUMMON has been disabled" ":SUMMONは実行できません" SUMMONメッセージに対する応答として返されます。 この機能を実装していないサーバは返さなくてはなりません。 446 ERR_USERSDISABLED ":USERS has been disabled" ":USERSは実行できません" USERSメッセージに対する応答として返されます。 この機能を実装していないサーバは返さなくてはなりません。 451 ERR_NOTREGISTERED ":You have not registered" ":あなたは登録されていません" サーバがメッセージの詳細を構文解析することを許可する前に、クライアントが登録しなくてはならないことを示すためにサーバが返します。 461 ERR_NEEDMOREPARAM " :Not enough parameters" " :パラメータが不足しています" 数々のメッセージにおいてパラメータが不足していることをクライアントに示すためにサーバが返します。 462 ERR_ALREADYREGISTRE ":You may not reregister" ":あなたは再登録できません" 登録の詳細(例えば、パスワードやUSERメッセージで得られるパスワードやユーザの詳細)の一部を変更しようとしている接続にサーバが返します。 463 ERR_NOPERMFORHOST ":Your host isn't among the privileged" ":あなたのホストは接続を許可されていません" 接続を試みようとしたホストからの接続が許可されるように設定されていないサーバに登録しようとしたクライアントに返されます。 464 ERR_PASSWDMISMATCH ":Password incorrect ":パスワードが間違っています" パスワードが必要な時に、パスワードが指定されていない、または正しくないことが原因で、接続を登録できなかったことを示すために返されます。 465 ERR_YOUREBANNEDCREEP ":You are banned from this server" ":あなたはこのサーバへの接続を禁止されています" 明示的に接続を拒否するように設定されているサーバに、拒否することが指定されているものが登録／接続しようとすると返されます。 467 ERR_KEYSET " :Channel key already set" " :チャンネルkeyはすでに設定されています" 471 ERR_CHANNELISFULL " :Cannot join channel (+l)" " :(mode +lのために)チャンネルにJOINできません" 472 ERR_UNKNOWNMODE " :is unknown mode char to me" " :mode が不明です。の指定が間違っています" 473 ERR_INVITEONLYCHAN " :Cannot join channel (+i)" " :(mode +iのために)チャンネルにJOINできません" 474 ERR_BANNEDFROMCHAN " :Cannot join channel (+b)" " :(mode +bのために)チャンネルにJOINできません" 475 ERR_BADCHANNELKEY " :Cannot join channel (+k)" " :(mode +kのために)チャンネルにJOINできません" 481 ERR_NOPRIVILEGES ":Permission Denied- You're not an IRC operator" ":権限がありません- IRC operatorではありません" 行使するのにIRCオペレータの権限が必要なメッセージを実行しようして失敗したことを示ために返すエラーです。 482 ERR_CHANOPRIVSNEEDED " :You're not channel operator" " :あなたはチャンネルオペレータではありません" チャンネルオペレータの権限が必要なメッセージ(例えばMODEメッセージ)をチャンネル上で指定されたチャンネルオペレータでないクライアントが実行しようとした時に返すエラーです。 483 ERR_CANTKILLSERVER ":You cant kill a server!" ":サーバをKILLすることはできません!" サーバ上でKILLメッセージは使えません。そしてこのエラーは直接クライアントに返されます。 491 ERR_NOOPERHOST ":No O-lines for your host ":あなたのホストにはOラインがありません" クライアントがOPERメッセージを送り、サーバがオペレータとしてクライアントのホストを接続することを許可しないように設定されている時、このエラーが返されます。 501 ERR_UMODEUNKNOWNFLAG ":Unknown MODE flag" ":不明なMODEフラグです" MODEメッセージがニックネームと共に送信されていて、かつ送信されたMODEフラグが理解できないことを示すためにサーバが返します。 502 ERR_USERSDONTMATCH ":Cant change mode for other users" ":他のユーザのモードは変更できません" 自分自身以外の他のクライアントのユーザモードを見ようとしたまたは変えようとしたクライアントにエラーが返信されます。 [6.2 メッセージ応答] 300 RPL_NONE この番号のリプライは使われません 302 RPL_USERHOST ":[{}]" USERHOSTの使用するリプライの形式です。 リプライの文字列は以下のような構成になります: ::= ['*'] '=' <'+'|'-'> クライアントがIRCオペレータとして登録されているかどうかを'*'は示します。 クライアントのAWAYメッセージが設定／解除されているか、それぞれ'-'/'+'で表しています。 303 RPL_ISON ":[ {}]" ISONの使用するリプライ形式です。 301 RPL_AWAY " :" 305 RPL_UNAWAY ":You are no longer marked as being away" 306 RPL_NOWAWAY ":You have been marked as being away" これらのリプライはAWAYメッセージと共に使われます。 AWAYを設定しているクライアントにPRIVMSGを送信したクライアントにRPL_AWAYが返信されます。 クライアントが接続しているサーバがRPL_AWAYを送信します。 クライアントがAWAYを解除/設定したときに、リプライRPL_UNAWAYとRPL_NOWAWAYが返信されます。 311 RPL_WHOISUSER " * :" 312 RPL_WHOISSERVER " :" 313 RPL_WHOISOPERATOR " :is an IRC operator" 317 RPL_WHOISIDLE " :seconds idle" 318 RPL_ENDOFWHOIS " :End of /WHOIS list" 319 RPL_WHOISCHANNELS " :{[@|+]} リプライ311〜313及び317〜319は全てWHOISメッセージに対する反応として生成されるリプライです。 必要なパラメータがきちんと指定されていた場合、回答するサーバは 上記のニュメリックリプライの中からリプライを組み立るか、エラーリプライを返すかしなくてはなりません。 RPL_WHOISUSERの中の'*'はリテラルな文字です。ワイルドカードではありません。 各リプライのセットの内で、RPL_WHOISCHANNELSだけは複数回現れます。 チャンネル名の後に続く'@'と'+'の文字はそれぞれクライアントがチャンネルオペレータまたはmoderated channel(mode +m)での発言権が与えられていることを示します。 RPL_ENDOFWHOISリプライはWHOISメッセージを実行した後にその印として使われます。 314 RPL_WHOWASUSER " * :" 369 RPL_ENDOFWHOWAS " :End of WHOWAS" WHOWASメッセージに対してリプライするとき、RPL_WHOWASUSER,RPL_WHOISSERVER,ERR_WASNOSUCHNICKのいずれかを利用して、指定されたリスト上の各ニックネームに対して、サーバはリプライを返さなくてはいけません。 全てのリプライの束が処理し終わると、(一つしかリプライしなかったときや、エラーがあった場合でも)RPL_ENDOFWHOWASが送信されます。 321 RPL_LISTSTART "Channel :Users Name" 322 RPL_LIST " <# visible> :" 323 RPL_LISTEND ":End of /LIST" リプライRPL_LISTSTART,RPL_LIST,RPL_LISTENDは、LISTメッセージに対するサーバの応答の、それぞれ、始まり、実際のリプライのデータ、終わりを表しています。 返すべきチャンネルがなかった場合、単に始まり(RPL_LISTSTART)と終わり(RPL_LISTEND)が返送されるだけです。 324 RPL_CHANNELMODEIS " " 331 RPL_NOTOPIC " :No topic is set" 332 RPL_TOPIC " :" TOPICメッセージがチャンネルトピックを決定するために送られたとき、2つのリプライの内の一つが返信されます。 トピックが設定されていた場合、RPL_TOPICが返信されます。そうでない場合は、RPL_NOTOPICが返信されます。 341 RPL_INVITING " " INVITEメッセージの試行が成功し、受信先のクライアントにメッセージが配信されたことを示すためにサーバがこのリプライを返します。 342 RPL_SUMMONING " :Summoning user to IRC" SUMMONメッセージの回答として、ユーザをSUMMON(召還)した事を示すためにサーバが返します。 351 RPL_VERSION ". :" サーバのバージョンの詳細を示すために、サーバが返します。 は使っているソフトウェアのバージョン(パッチレベル,リビジョンを含みます)です。そして、はサーバがデバッグモードで走っているかどうかを示します。 のフィールドにはバージョンのコメントか、より詳しいバージョンが入っています。 352 RPL_WHOREPLY " [*][@|+] : " 315 RPL_ENDOFWHO " :End of /WHO list" RPL_WHOREPLYとRPL_ENDOFWHOの組はWHOメッセージの回答に使用されます。 WHOメッセージにマッチした場合だけに、RPL_WHOREPLYは返送されます。 WHOメッセージにパラメータのリストがある場合、リストの各項のに対してリプライが返信された後にRPL_ENDOFWHOが返信されます。 353 RPL_NAMREPLY " :[[@|+] [[@|+] [...]]]" 366 RPL_ENDOFNAME " :End of /NAMES list" NAMESメッセージにリプライするため、RPL_NAMREPLYとRPL_ENDOFNAMESのリプライの組をクライアントにサーバが返信します。 要求されたチャンネルが見つからない場合、単にRPL_ENDOFNAMESを返すだけです。 この例外として、NAMESメッセージがパラメータ無しで送られた時に、全ての可視チャンネルとそこにいるクライアントのリストが一連のRPL_NAMEREPLYリプライが返信され、最後にRPL_ENDOFNAMESが終わりの印として返信されます。 364 RPL_LINKS " : " 365 RPL_ENDOFLINKS " :End of /LINKS list" LINKメッセージのリプライとして使われます。サーバはRPL_LINKSを返し、リストの終わりの印としてRPL_ENDOFLINKSリプライを返します。 367 RPL_BANLIST " " 368 RPL_ENDOFBANLIST " :End of channel ban list" サーバはRPL_BANLISTとRPL_ENDOFBANLISTリプライを使って、チャンネルに設定された'ban'のリストを返信します。 各RPL_BANLISTは有効なbanをそれぞれ示します。 banのリストが返信し終わった後(もしくは、存在しなかったら)、RPL_ENDOFBANLISTが返信されます。 371 RPL_INFO ":" 374 RPL_ENDOFINFO ":End of /INFO list" INFOメッセージ対してサーバは全てのINFO(情報)を連続したRPL_INFOリプライとその最後にリプライの終わりを示すRPL_ENDOFINFOリプライを返信する必要があります。 375 RPL_MOTDSTART ":- Message of the day - " 372 RPL_MOTD ":- " 376 RPL_ENDOFMOTD ":End of /MOTD command" MOTDメッセージに対して反応しMOTDファイルを検索する場合、ファイル中で表示する各行(各行は長くとも80文字まで)はRPL_MOTDの形式のリプライで返信されます。 これらRPL_MOTDは前はRPL_MOTDSTART、後ろはRPL_ENDOFMOTDとの間にはさまれなくてはいけません。 381 RPL_YOUREOPER ":You are now an IRC operator" 送信したOPERメッセージが成功しIRCオペレータの地位が授与されたクライアントにRPL_YOUREOPERは返信されます。 382 RPL_REHASHING " :Rehashing REHASHオプションが使用され、IRCオペレータがREHASHメッセージを送信した場合、RPL_REHASHINGがオペレータに返信されます。 391 RPL_TIME " :" サーバはTIMEメッセージ対して上記のRPL_TIMEの形式で返信しなくてはいけません。 時間の示す文字列はそこでの正確な日付と時間とを含んでいます。 時間の文字列以外は必要ありません。 392 RPL_USERSSTART ":UserID Terminal Host" 393 RPL_USERS ":%-8s %-9s %-8s" 394 RPL_ENDOFUSERS ":End of users" 395 RPL_NOUSERS ":Nobody logged in サーバがUSERメッセージを受信した場合、リプライRPL_USERSTART,RPL_USERS,RPL_ENDOFUSERS,RPL_NOUSERSが使われます。 RPL_USERSSTARTは最初に送信されます。続いて連続してRPL_USERSが送信されるか、RPL_NOUSERが一つ送信されます。 最後にRPL_ENDOFUSERSが送信されます。 200 RPL_TRACELINK "Link " 201 RPL_TRACECONNECTING "Try. " 202 RPL_TRACEHANDSHAKE "H.S. " 203 RPL_TRACEUNKNOWN "???? []" 204 RPL_TRACEOPERATOR "Oper " 205 RPL_TRACEUSER "User " 206 RPL_TRACESERVER "Serv S C @" 208 RPL_TRACENEWTYPE " 0 " 261 RPL_TRACELOG "File " 全てのRPL_TRACE* はTRACEメッセージに対するサーバの応答として返されます。 いくつのリプライが返されるかは、TRACEメッセージとそれがIRCオペレータが送信したのかそうでないのかによります。 その量はあらかじめ決められてはいません。 リプライRPL_TRACEUNKNOWN,RPL_TRACECONNECTING,RPL_TRACEANDSHAKEは全て、確立されていない接続、不明な接続、接続がまだ試行中、'server handshake'の済んだプロセス、等に対して使われます。 RPL_TRACELINKはTRACEメッセージを受信したサーバが返信します。そして、そのサーバは他のサーバに転送します。 RPL_TRACELINKのリストはTRACEメッセージの通過した、実際にサーバがパスに沿って接続しているIRCネットワークを反映するものとして返信されてきます。 RPL_TRACENEWTYPEは、とりあえず表示はされますが、どのカテゴリにも属さない接続に対して使われます。 211 RPL_STATSLINKINF "