Network Working Group C. Kalt
Request for Comments: 2813 April 2000
Updates: 1459
Category: Informational
Internet Relay Chat: Server Protocol
Status of this Memo
このメモの位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
Abstract
抽象
While based on the client-server model, the IRC (Internet Relay Chat) protocol allows servers to connect to each other effectively forming a network.
クライアントサーバモデルに基づいている間、IRC（インターネットリレーチャット）プロトコルは、サーバが効果的にネットワークを形成して相互に接続することができます。
This document defines the protocol used by servers to talk to each other. It was originally a superset of the client protocol but has evolved differently.
この文書では、お互いに話をするために、サーバによって使用されるプロトコルを定義します。もともとはクライアントプロトコルのスーパーセットだったが、違った進化してきました。
First formally documented in May 1993 as part of RFC 1459 [IRC], most of the changes brought since then can be found in this document as development was focused on making the protocol scale better. Better scalability has allowed existing world-wide networks to keep growing and reach sizes which defy the old specification.
開発は、より良いプロトコルスケールを作ることに集中していたように、まず正式にRFC 1459 [IRC]の一環として、1993年5月に文書化され、それ以来もたらした変化のほとんどは、この文書に記載されています。スケーラビリティは、成長を維持し、古い仕様を無視するサイズに到達するために、既存の世界的なネットワークを許可されています。
Table of Contents
目次
1. Introduction ............................................... 3
2. Global database ............................................ 3
2.1 Servers ................................................ 3
2.2 Clients ................................................ 4
2.2.1 Users ............................................. 4
2.2.2 Services .......................................... 4
2.3 Channels ............................................... 4
3. The IRC Server Specification ............................... 5
3.1 Overview ............................................... 5
3.2 Character codes ........................................ 5
3.3 Messages ............................................... 5
3.3.1 Message format in Augmented BNF ................... 6
3.4 Numeric replies ........................................ 7
4. Message Details ............................................ 7
4.1 Connection Registration ................................ 8
4.1.1 Password message .................................. 8
4.1.2 Server message .................................... 9
4.1.3 Nick .............................................. 10
4.1.4 Service message ................................... 11
4.1.5 Quit .............................................. 12
4.1.6 Server quit message ............................... 13
4.2 Channel operations ..................................... 14
4.2.1 Join message ...................................... 14
4.2.2 Njoin message ..................................... 15
4.2.3 Mode message ...................................... 16
5. Implementation details .................................... 16
5.1 Connection 'Liveness' .................................. 16
5.2 Accepting a client to server connection ................ 16
5.2.1 Users ............................................. 16
5.2.2 Services .......................................... 17
5.3 Establishing a server-server connection. ............... 17
5.3.1 Link options ...................................... 17
5.3.1.1 Compressed server to server links ............ 18
5.3.1.2 Anti abuse protections ....................... 18
5.3.2 State information exchange when connecting ........ 18
5.4 Terminating server-client connections .................. 19
5.5 Terminating server-server connections .................. 19
5.6 Tracking nickname changes .............................. 19
5.7 Tracking recently used nicknames ....................... 20
5.8 Flood control of clients ............................... 20
5.9 Non-blocking lookups ................................... 21
5.9.1 Hostname (DNS) lookups ............................ 21
5.9.2 Username (Ident) lookups .......................... 21
6. Current problems ........................................... 21
6.1 Scalability ............................................ 21
6.2 Labels ................................................. 22
6.2.1 Nicknames ......................................... 22
6.2.2 Channels .......................................... 22
6.2.3 Servers ........................................... 22
6.3 Algorithms ............................................. 22
7. Security Considerations .................................... 23
7.1 Authentication ......................................... 23
7.2 Integrity .............................................. 23
8. Current support and availability ........................... 24
9. Acknowledgements ........................................... 24
10. References ................................................ 24
11. Author's Address .......................................... 25
12. Full Copyright Statement ................................... 26
This document is intended for people working on implementing an IRC server but will also be useful to anyone implementing an IRC service.
この文書では、IRCサーバを実装する上で働く人々のために意図されるが、IRCのサービスを実装誰にも有用であろう。
Servers provide the three basic services required for realtime conferencing defined by the "Internet Relay Chat: Architecture" [IRC-ARCH]: client locator (via the client protocol [IRC-CLIENT]), message relaying (via the server protocol defined in this document) and channel hosting and management (following specific rules [IRC-CHAN]).
[IRC-ARCH]：この中で定義されたサーバープロトコルを介してクライアントロケータ（クライアントプロトコルを経由して、[IRC-CLIENT]）、メッセージ中継（：サーバー「建築をインターネットリレーチャット」によって定義されたリアルタイムの会議のために必要な3つの基本的なサービスを提供します文書）とチャネルホスティングおよび管理（以下、特定の規則[IRC-CHAN]）。
Although the IRC Protocol defines a fairly distributed model, each server maintains a "global state database" about the whole IRC network. This database is, in theory, identical on all servers.
IRCプロトコルはかなり分散モデルを定義しますが、各サーバーは、全体のIRCネットワークについて「グローバルな状態データベース」を維持しています。このデータベースは、理論的には、すべてのサーバーで同一です。
Servers are uniquely identified by their name which has a maximum length of sixty three (63) characters. See the protocol grammar rules (section 3.3.1) for what may and may not be used in a server name.
サーバは、一意63（63）文字の最大長さを有し、その名前によって識別されます。そして、サーバ名に使用してもしなくてもよい何のためのプロトコルの文法規則（セクション3.3.1）を参照してください。
Each server is typically known by all other servers, however it is possible to define a "hostmask" to group servers together according to their name. Inside the hostmasked area, all the servers have a name which matches the hostmask, and any other server with a name matching the hostmask SHALL NOT be connected to the IRC network outside the hostmasked area. Servers which are outside the area have no knowledge of the individual servers present inside the area, instead they are presented with a virtual server which has the hostmask for name.
各サーバは、一般的に他のすべてのサーバによって知られている、しかし、自分の名前に応じて一緒にグループサーバに「hostmask」を定義することが可能です。 hostmaskedエリア内では、すべてのサーバーがhostmaskに一致する名前を持っている、とhostmaskに一致する名前を持つ他のサーバがhostmaskedエリア外のIRCネットワークに接続してはなりません。エリア外にあるサーバーではなく、彼らは名のhostmaskを持つ仮想サーバーに提示され、領域内に存在する個々のサーバーの知識がありません。
For each client, all servers MUST have the following information: a netwide unique identifier (whose format depends on the type of client) and the server to which the client is connected.
（その形式のクライアントの種類によって異なります）netwide一意の識別子とクライアントが接続しているサーバー：クライアントごとに、すべてのサーバーは、以下の情報を持たなければなりません。
Each user is distinguished from other users by a unique nickname having a maximum length of nine (9) characters. See the protocol grammar rules (section 3.3.1) for what may and may not be used in a nickname. In addition to the nickname, all servers MUST have the following information about all users: the name of the host that the user is running on, the username of the user on that host, and the server to which the client is connected.
各ユーザは、9つの文字の最大長さを有するユニークなニックネームで他のユーザと区別されます。ニックネームで使用してもしなくてもよいもののためのプロトコルの文法規則（セクション3.3.1）を参照。ユーザーが動作しているホストの名前、そのホスト上のユーザのユーザ名、およびクライアントが接続されているサーバー：ニックネームに加えて、すべてのサーバは、すべてのユーザーについて、以下の情報を持たなければなりません。
Each service is distinguished from other services by a service name composed of a nickname and a server name. The nickname has a maximum length of nine (9) characters. See the protocol grammar rules (section 3.3.1) for what may and may not be used in a nickname. The server name used to compose the service name is the name of the server to which the service is connected. In addition to this service name all servers MUST know the service type.
各サービスは、ニックネームとサーバー名で構成されるサービス名で、他のサービスと区別されます。ニックネームは、9つの文字の最大長さを有します。ニックネームで使用してもしなくてもよいもののためのプロトコルの文法規則（セクション3.3.1）を参照。サービス名を構成するために使用されるサーバー名は、サービスが接続されているサーバーの名前です。このサービス名に加えて、すべてのサーバーは、サービスタイプを知っている必要があります。
Services differ from users by the format of their identifier, but more importantly services and users don't have the same type of access to the server: services can request part or all of the global state information that a server maintains, but have a more restricted set of commands available to them (See "IRC Client Protocol" [IRC-CLIENT] for details on which) and are not allowed to join channels. Finally services are not usually subject to the "Flood control" mechanism described in section 5.8.
サービスには、識別子の形式により、ユーザーは異なり、より重要なサービスやユーザーはサーバーへのアクセスの同じ種類を持っていない：サービスは、サーバーが保持する一部またはグローバル状態情報の全てを要求することができますが、より多くを持っています（上の詳細については、「IRCクライアントプロトコル」[IRC-CLIENT]を参照してください）それらに利用可能なコマンドのセットを制限し、チャンネルへの参加を許可されていません。最後のサービスは通常、5.8節で説明した「治水」メカニズムの対象になりません。
Alike services, channels have a scope [IRC-CHAN] and are not necessarily known to all servers. When a channel existence is known to a server, the server MUST keep track of the channel members, as well as the channel modes.
同様のサービスは、チャネルが有効範囲を持っている[IRC-CHAN]、必ずしもすべてのサーバーに知られていません。チャネルの存在がサーバに知られている場合は、サーバーは、チャネルのメンバーだけでなく、チャンネルモードを追跡する必要があります。
The protocol as described herein is for use with server to server connections. For client to server connections, see the IRC Client Protocol specification.
本明細書に記載のプロトコルは、サーバ接続にサーバで使用するためです。サーバー接続へのクライアントのために、IRCクライアントプロトコル仕様を参照してください。
There are, however, more restrictions on client connections (which are considered to be untrustworthy) than on server connections.
サーバー接続に比べて（信用できないと考えられている）クライアント接続の詳細な制限は、しかし、があります。
No specific character set is specified. The protocol is based on a a set of codes which are composed of eight (8) bits, making up an octet. Each message may be composed of any number of these octets; however, some octet values are used for control codes which act as message delimiters.
いかなる特定の文字セットが指定されていません。プロトコルは、オクテットを構成する8つの（8）ビットで構成されているコードのセットに基づいています。各メッセージは、これらのオクテットの任意の数で構成されてもよいです。しかし、いくつかのオクテット値は、メッセージの区切り文字として機能する制御コードのために使用されます。
Regardless of being an 8-bit protocol, the delimiters and keywords are such that protocol is mostly usable from US-ASCII terminal and a telnet connection.
かかわらず、8ビットプロトコルであることの、区切り文字とキーワードは、プロトコルがUS-ASCII端末とtelnet接続から主に使用可能であるようなものです。
Because of IRC's Scandinavian origin, the characters {}|^ are considered to be the lower case equivalents of the characters []\~, respectively. This is a critical issue when determining the equivalence of two nicknames, or channel names.
そのためIRCのスカンジナビアの起源で、文字{} | ^は\〜、それぞれ[]文字の小文字の同等物とみなされています。 2つのニックネーム、またはチャンネル名の等価性を決定するとき、これは重要な問題です。
Servers and clients send each other messages which may or may not generate a reply. Most communication between servers do not generate any reply, as servers mostly perform routing tasks for the clients.
サーバとクライアントは、または応答を生成しない場合があり、それぞれ他のメッセージを送信します。サーバは、主にクライアントのルーティングタスクを実行するとサーバ間のほとんどの通信は、任意の応答を生成しません。
Each IRC message may consist of up to three main parts: the prefix (OPTIONAL), the command, and the command parameters (maximum of fifteen (15)). The prefix, command, and all parameters are separated by one ASCII space character (0x20) each.
各IRCメッセージは、最大3つの主要部分から構成されてもよい：プレフィックス（オプション）コマンド、およびコマンドパラメータ（15の最大（15））。プレフィックス、コマンド、およびすべてのパラメータは、1つのASCII空白文字（0x20）それぞれで分離されています。
The presence of a prefix is indicated with a single leading ASCII colon character (':', 0x3b), which MUST be the first character of the message itself. There MUST be NO gap (whitespace) between the colon and the prefix. The prefix is used by servers to indicate the true origin of the message. If the prefix is missing from the message, it is assumed to have originated from the connection from which it was received. Clients SHOULD not use a prefix when sending a message from themselves; if they use one, the only valid prefix is the registered nickname associated with the client.
接頭辞の存在は、単一リーディングASCII結腸文字で示されている（「：」、0x3b）、メッセージ自体の最初の文字でなければなりません。コロンとプレフィックスとの間に隙間（空白）があってはなりません。プレフィックスは、メッセージの真の起源を示すためにサーバによって使用されます。プレフィックスがメッセージから欠落している場合、それが受信された接続から発信されたと想定されます。自分自身からのメッセージを送信するとき、クライアントは接頭辞を使用しないでください。彼らはいずれかを使用する場合は、唯一の有効なプレフィックスは、クライアントに関連付けられて登録されたニックネームです。
When a server receives a message, it MUST identify its source using the (eventually assumed) prefix. If the prefix cannot be found in the server's internal database, it MUST be discarded, and if the prefix indicates the message comes from an (unknown) server, the link from which the message was received MUST be dropped. Dropping a link in such circumstances is a little excessive but necessary to maintain the integrity of the network and to prevent future problems. Another common error condition is that the prefix found in the server's internal database identifies a different source (typically a source registered from a different link than from which the message arrived). If the message was received from a server link and the prefix identifies a client, a KILL message MUST be issued for the client and sent to all servers. In other cases, the link from which the message arrived SHOULD be dropped for clients, and MUST be dropped for servers. In all cases, the message MUST be discarded.
サーバはメッセージを受信すると、それは（最終的に想定）プレフィックスを使用して、そのソースを識別しなければなりません。プレフィックスは、サーバの内部データベースで見つけることができない場合は、それを捨てなければなりませんし、接頭辞は（不明）サーバーから来たメッセージを示している場合、メッセージが受信されたリンクを下げなければなりません。このような状況でリンクを削除すると、ネットワークの整合性を維持し、将来の問題を防ぐために、少し過大が、必要です。別の一般的なエラー状態は、サーバの内部データベースで見つかったプレフィックスが異なるソース（メッセージが到着より、そこから異なるリンクから登録通常、ソース）を識別することです。メッセージは、サーバーのリンクから受け取ったとプレフィックスがクライアントを識別する場合、KILLメッセージはクライアントのために発行され、すべてのサーバに送らなければなりません。他の例では、メッセージが到着し、そこからリンクがクライアントのために廃棄されるべきであり、サーバに対して下げなければなりません。すべての場合において、メッセージは捨てなければなりません。
The command MUST either be a valid IRC command or a three (3) digit number represented in ASCII text.
コマンドは、いずれかの有効なIRCコマンドまたはASCIIテキストで表現3（3）桁の数字でなければなりません。
IRC messages are always lines of characters terminated with a CR-LF (Carriage Return - Line Feed) pair, and these messages SHALL NOT exceed 512 characters in length, counting all characters including the trailing CR-LF. Thus, there are 510 characters maximum allowed for the command and its parameters. There is no provision for continuation message lines. See section 5 for more details about current implementations.
IRCメッセージは常にCR-LF（キャリッジリターン - ラインフィード）で終端文字の線で対、及びこれらのメッセージは、末尾のCR-LFを含むすべての文字をカウントし、長さが512文字を超えてはなりません。したがって、コマンドとそのパラメータに許可510文字の最大があります。継続メッセージラインのための規定はありません。現在の実装の詳細についてはセクション5を参照してください。
The protocol messages must be extracted from the contiguous stream of octets. The current solution is to designate two characters, CR and LF, as message separators. Empty messages are silently ignored, which permits use of the sequence CR-LF between messages without extra problems.
プロトコルメッセージは、オクテットの連続ストリームから抽出されなければなりません。現在のソリューションは、メッセージセパレータとして、2つの文字、CRやLFを指定することです。空のメッセージは黙って余分に問題なくメッセージの間の配列CR-LFの使用を可能にする、無視されます。
The extracted message is parsed into the components <prefix>, <command> and list of parameters (<params>).
抽出されたメッセージは、コンポーネント<接頭辞>に解析され、パラメータの<コマンド>とリスト（<paramsは>）。
The Augmented BNF representation for this is found in "IRC Client Protocol" [IRC-CLIENT].
こののための増大しているBNF表現が「IRCクライアントプロトコル」[IRC-CLIENT]で発見されました。
The extended prefix (["!" user "@" host ]) MUST NOT be used in server to server communications and is only intended for server to client messages in order to provide clients with more useful information about who a message is from without the need for additional queries.
拡張された接頭辞（[「！」ユーザー「@」ホスト]）サーバーの通信にサーバーに使用してはいけませんとメッセージのみがなしから誰であるかについてのより多くの有用な情報を顧客に提供するために、クライアントメッセージへのサーバーを対象としてい追加のクエリのために必要。
Most of the messages sent to the server generate a reply of some sort. The most common reply is the numeric reply, used for both errors and normal replies. The numeric reply MUST be sent as one message consisting of the sender prefix, the three digit numeric, and the target of the reply. A numeric reply is not allowed to originate from a client; any such messages received by a server are silently dropped. In all other respects, a numeric reply is just like a normal message, except that the keyword is made up of 3 numeric digits rather than a string of letters. A list of different replies is supplied in "IRC Client Protocol" [IRC-CLIENT].
サーバーに送信されたメッセージのほとんどは、ある種の応答を生成します。最も一般的な回答はエラーと通常の応答の両方のために使用される数値の返信です。数値応答は、送信者のプレフィックスからなる1つのメッセージ、3桁の数字、および応答の標的として送らなければなりません。数値応答は、クライアントから発信することはできません。サーバーが受信した任意のこのようなメッセージは、黙って破棄されます。キーワードは3桁の数字ではなく文字の文字列で構成された以外は他のすべての点では、数値の回答は、単に通常のメッセージのようなものです。異なった応答のリストは、「IRCクライアントプロトコル」[IRC-CLIENT]に供給されます。
All the messages recognized by the IRC server and client are described in the IRC Client Protocol specification.
IRCサーバとクライアントで認識されたすべてのメッセージは、IRCクライアントプロトコル仕様に記述されています。
Where the reply ERR_NOSUCHSERVER is returned, it means that the target of the message could not be found. The server MUST NOT send any other replies after this error for that command.
返信ERR_NOSUCHSERVERが返される場合、そのメッセージのターゲットが見つからなかったことを意味します。サーバーは、そのコマンドのためにこのエラーが発生した後、他の回答を送ってはいけません。
The server to which a client is connected is required to parse the complete message, returning any appropriate errors. If the server encounters a fatal error while parsing a message, an error MUST be sent back to the client and the parsing terminated. A fatal error may follow from incorrect command, a destination which is otherwise unknown to the server (server, client or channel names fit this category), not enough parameters or incorrect privileges.
クライアントが接続しているサーバーは、任意の適切なエラーを返す、完全なメッセージを解析するために必要とされます。メッセージを解析中に、サーバーが致命的なエラーが発生した場合、エラーがクライアントに送り返さなければならないと解析が終了しました。致命的なエラーは、誤ったコマンドからサーバー（サーバー、クライアントまたはチャンネル名がこのカテゴリに合う）、十分ではないパラメータまたは不適切な権限にそれ以外の場合は不明である目的地に従うことができます。
If a full set of parameters is presented, then each MUST be checked for validity and appropriate responses sent back to the client. In the case of messages which use parameter lists using the comma as an item separator, a reply MUST be sent for each item.
パラメータの完全なセットが提示されている場合、各クライアントに送り返さ妥当性と適切な対応のためにチェックしなければなりません。項目セパレータとしてカンマを使用してパラメータ・リストを使用したメッセージの場合、応答は、各項目に送らなければなりません。
In the examples below, some messages appear using the full format:
以下の例では、いくつかのメッセージはフルフォーマットを使用して表示されます。
:Name COMMAND parameter list
：NAMEコマンドパラメータリスト
Such examples represent a message from "Name" in transit between servers, where it is essential to include the name of the original sender of the message so remote servers may send back a reply along the correct path.
そのような例は、リモートサーバが正しいパスに沿って応答を返送することができるように、メッセージの元の送信者の名前を含めることが不可欠であるサーバとの間の輸送中の「名前」からメッセージを表します。
The message details for client to server communication are described in the "IRC Client Protocol" [IRC-CLIENT]. Some sections in the following pages apply to some of these messages, they are additions to the message specifications which are only relevant to server to server communication, or to the server implementation. The messages which are introduced here are only used for server to server communication.
サーバ通信へのクライアントのためのメッセージの詳細は、「IRCクライアントプロトコル」[IRC-CLIENT]で説明されています。以下のページでいくつかのセクションでは、これらのメッセージの一部に適用される、彼らは、サーバーへの通信、またはサーバーの実装にサーバーにのみ関連しているメッセージの仕様に追加されています。ここで紹介されたメッセージは、サーバーへの通信サーバーで使用されています。
The commands described here are used to register a connection with another IRC server.
ここで説明するコマンドは、別のIRCサーバとの接続を登録するために使用されています。
Command: PASS Parameters: <password> <version> <flags> [<options>]
コマンド：PASSパラメータ：<パスワード> <バージョン> <フラグ> [<オプション>]
The PASS command is used to set a 'connection password'. The password MUST be set before any attempt to register the connection is made. Currently this means that servers MUST send a PASS command before any SERVER command. Only one (1) PASS command SHALL be accepted from a connection.
PASSコマンドは、「接続パスワード」を設定するために使用されます。接続を登録するための任意の試行が行われる前に、パスワードを設定しなければなりません。現在、これはサーバがどのSERVERコマンドの前にPASSコマンドを送信しなければならないことを意味します。一つ（1）PASSコマンドは接続から受け入れられるものとします。
The last three (3) parameters MUST be ignored if received from a client (e.g. a user or a service). They are only relevant when received from a server.
クライアント（例えば、ユーザまたはサービス）から受信した最後の3つのパラメータは無視しなければなりません。サーバーから受信したとき、彼らは唯一の関連しています。
The <version> parameter is a string of at least four (4) characters, and up to fourteen (14) characters. The first four (4) characters MUST be digits and indicate the protocol version known by the server issuing the message. The protocol described by this document is version 2.10 which is encoded as "0210". The remaining OPTIONAL characters are implementation dependent and should describe the software version number.
<バージョン>パラメータは、少なくとも4つの（4）文字の文字列で、最大14（14）文字。最初の4つ（4）の文字が数字であるとメッセージを発行サーバによって知られているプロトコルのバージョンを指定する必要があります。この文書によって説明されたプロトコルは「0210」として符号化されたバージョン2.10です。残りのオプションの文字は、実装依存しており、ソフトウェアのバージョン番号を記述する必要があります。
The <flags> parameter is a string of up to one hundred (100) characters. It is composed of two substrings separated by the character "|" (%x7C). If present, the first substring MUST be the name of the implementation. The reference implementation (See Section 8, "Current support and availability") uses the string "IRC". If a different implementation is written, which needs an identifier, then that identifier should be registered through publication of an RFC. The second substring is implementation dependent. Both substrings are OPTIONAL, but the character "|" is REQUIRED. The character "|" MUST NOT appear in either substring.
<フラグ>パラメータには、最大百の文字列（100）文字です。 「|」それは文字で区切られた2つの部分文字列で構成されています（％のx7C）。存在する場合、最初の部分文字列は、実装の名前でなければなりません。リファレンス実装では、（第8節、「現在のサポートと可用性」を参照してください）、文字列「IRC」を使用しています。異なる実装が識別子を必要とする、記述されている場合、その識別子は、RFCの出版を通じて登録されるべきです。第二のサブストリングは、実装依存です。どちらの部分文字列はオプションですが、文字「|」必要とされている。文字「|」いずれかのサブストリングに現れてはいけません。
Finally, the last parameter, <options>, is used for link options. The only options defined by the protocol are link compression (using the character "Z"), and an abuse protection flag (using the character
最後に、最後のパラメータ、<オプション>は、リンクオプションのために使用されています。プロトコルによって定義された唯一のオプションは、リンク圧縮（文字「Z」を使用）、および文字を使用して乱用保護フラグ（あります
"P"). See sections 5.3.1.1 (Compressed server to server links) and 5.3.1.2 (Anti abuse protections) respectively for more information on these options.
"P"）。これらのオプションの詳細については、それぞれのセクション5.3.1.1（サーバーへのリンクに圧縮サーバ）と5.3.1.2（アンチ虐待の保護）を参照してください。
Numeric Replies:
数値回答：
ERR_NEEDMOREPARAMS ERR_ALREADYREGISTRED
ERR_NEEDMOREPARAMS ERR_ALREADYREGISTRED
Example:
例：
PASS moresecretpassword 0210010000 IRC|aBgH$ Z
ABGH $ Z | PASSは0210010000 IRCをmoresecretpassword
Command: SERVER Parameters: <servername> <hopcount> <token> <info>
コマンド：サーバのパラメータ：<サーバー> <ホップカウント> <トークン> <インフォメーション>
The SERVER command is used to register a new server. A new connection introduces itself as a server to its peer. This message is also used to pass server data over whole net. When a new server is connected to net, information about it MUST be broadcasted to the whole network.
SERVERコマンドは、新しいサーバーを登録するために使用されます。新しい接続は、そのピアへのサーバとしての地位を紹介しています。このメッセージは、全体のネット上のサーバーデータを渡すために使用されます。新しいサーバーがネットに接続されている場合は、それについての情報がネットワーク全体にブロードキャストされなければなりません。
The <info> parameter may contain space characters.
<インフォメーション>パラメータは、空白文字を含めることができます。
<hopcount> is used to give all servers some internal information on how far away each server is. Local peers have a value of 0, and each passed server increments the value. With a full server list, it would be possible to construct a map of the entire server tree, but hostmasks prevent this from being done.
<ホップカウント>すべてのサーバーに、各サーバーがどのように遠くにいくつかの内部情報を与えるために使用されます。ローカルピアは0の値を持ち、かつそれぞれ渡されたサーバーは、値を増加させます。完全なサーバリストと、全体のサーバツリーのマップを構築することが可能であろうが、hostmasksが行われてからこれを防ぎます。
The <token> parameter is an unsigned number used by servers as an identifier. This identifier is subsequently used to reference a server in the NICK and SERVICE messages sent between servers. Server tokens only have a meaning for the point-to-point peering they are used and MUST be unique for that connection. They are not global.
<トークン>パラメータは、識別子として、サーバによって使用される符号なしの数値です。この識別子は、その後、サーバー間で送信NICKでサーバーとサービスメッセージを参照するために使用されます。サーバーのトークンは、ポイントツーポイント、それらが使用されているピアリングのための意味を持っており、その接続のためのユニークでなければなりません。彼らはグローバルではありません。
The SERVER message MUST only be accepted from either (a) a connection which is yet to be registered and is attempting to register as a server, or (b) an existing connection to another server, in which case the SERVER message is introducing a new server behind that server.
サーバ・メッセージは、サーバーメッセージが新しい導入された場合には、登録する未だあり、サーバとして登録しようとしている（A）接続、または別のサーバへの（b）は、既存の接続のいずれかから受け付けなければなりませんそのサーバーの背後にあるサーバー。
Most errors that occur with the receipt of a SERVER command result in the connection being terminated by the destination host (target SERVER). Because of the severity of such event, error replies are usually sent using the "ERROR" command rather than a numeric.
接続中SERVERコマンド結果の受信で発生ほとんどのエラーは、宛先ホスト（ターゲットサーバ）によって終了されています。そのため、このようなイベントの重要度を、エラー応答は、通常は「ERROR」コマンドではなく、数値を使用して送信されます。
If a SERVER message is parsed and it attempts to introduce a server which is already known to the receiving server, the connection, from which that message arrived, MUST be closed (following the correct procedures), since a duplicate route to a server has been formed and the acyclic nature of the IRC tree breaks. In some conditions, the connection from which the already known server has registered MAY be closed instead. It should be noted that this kind of error can also be the result of a second running server, problem which cannot be fixed within the protocol and typically requires human intervention. This type of problem is particularly insidious, as it can quite easily result in part of the IRC network to be isolated, with one of the two servers connected to each partition therefore making it impossible for the two parts to unite.
サーバ・メッセージが解析され、それが既に受信サーバに知られているサーバを導入しようとしている場合、サーバに重複経路がされているので、そのメッセージが到着し、そこからの接続は、（正しい手順に従って）閉じなければなりません形成され、IRCの木の切断の非環式自然。いくつかの条件では、既に知られているサーバが登録されている元の接続が代わりに閉鎖することができます。この種のエラーは、プロトコル内に固定することができない第2走行サーバ、問題の結果であると一般的に人間の介入を必要とすることに留意すべきです。それは非常に簡単に、したがって2つの部分は一体化することが不可能に各パーティションに接続された2台のサーバのいずれかを用いて、単離することがIRCネットワークの一部をもたらすことができるようにこの種の問題は、特に潜行性です。
Numeric Replies:
数値回答：
ERR_ALREADYREGISTRED
ERR_ALREADYREGISTRED
Example:
例：
SERVER test.oulu.fi 1 1 :Experimental server ; New server test.oulu.fi introducing itself and attempting to register.
サーバーtest.oulu.fi 1 1：実験サーバー。新しいサーバーtest.oulu.fi自身を導入し、登録しようと。
:tolsun.oulu.fi SERVER csd.bu.edu 5 34 :BU Central Server ; Server tolsun.oulu.fi is our uplink for csd.bu.edu which is 5 hops away. The token "34" will be used by tolsun.oulu.fi when introducing new users or services connected to csd.bu.edu.
：tolsun.oulu.fiサーバcsd.bu.edu 5 34：BU中央サーバー。サーバtolsun.oulu.fiは5ホップ離れているcsd.bu.eduための私たちのアップリンクです。 csd.bu.eduに接続され、新規ユーザーやサービスを導入する際のトークンが「34」tolsun.oulu.fiによって使用されます。
Command: NICK Parameters: <nickname> <hopcount> <username> <host> <servertoken> <umode> <realname>
コマンド：NICKパラメータ：<ニックネーム> <ホップ数> <ユーザー名> <ホスト> <servertoken> <UMODE> <本名>
This form of the NICK message MUST NOT be allowed from user connections. However, it MUST be used instead of the NICK/USER pair to notify other servers of new users joining the IRC network.
NICKメッセージのこの形式は、ユーザー接続から許されてはなりません。しかし、IRCネットワークに参加する新規ユーザーの他のサーバーに通知する代わりに、NICK / USERのペアを使用しなければなりません。
This message is really the combination of three distinct messages: NICK, USER and MODE [IRC-CLIENT].
NICK、USERとMODE [IRC-CLIENT]：このメッセージは、実際には三つの異なるメッセージの組み合わせです。
The <hopcount> parameter is used by servers to indicate how far away a user is from its home server. A local connection has a hopcount of 0. The hopcount value is incremented by each passed server.
<ホップカウント>パラメーターは、ユーザーがそのホームサーバからどれだけ離れているかを示すために、サーバによって使用されます。ローカル接続は、ホップカウント値をそれぞれ通過サーバインクリメントされる0のホップカウントを有します。
The <servertoken> parameter replaces the <servername> parameter of the USER (See section 4.1.2 for more information on server tokens).
<servertoken>パラメータには、ユーザー（サーバートークンの詳細については、セクション4.1.2を参照）の<サーバ名>パラメータを置き換えます。
Examples:
例：
NICK syrk 5 kalt millennium.stealth.net 34 +i :Christophe Kalt ; New user with nickname "syrk", username "kalt", connected from host "millennium.stealth.net" to server "34" ("csd.bu.edu" according to the previous example).
NICKのsyrk 5 kalt millennium.stealth.net 34 + I：クリストフKalt。 （前の例によれば、「csd.bu.edu」）サーバにホスト「millennium.stealth.net」から接続新しいニックネーム「syrk」を持つユーザは、ユーザ名「kalt」、「34」。
:krys NICK syrk ; The other form of the NICK message, as defined in "IRC Client Protocol" [IRC-CLIENT] and used between servers: krys changed his nickname to syrk
：krys NICKのsyrk。 NICKメッセージの他の形態、「IRCクライアントプロトコル」[IRC-CLIENT]で定義され、サーバ間で使用される：krysはsyrkに彼のニックネームを変更
Command: SERVICE Parameters: <servicename> <servertoken> <distribution> <type> <hopcount> <info>
コマンド：サービスパラメータ：<サービス名> <servertoken> <分布> <タイプ> <ホップカウント> <インフォメーション>
The SERVICE command is used to introduce a new service. This form of the SERVICE message SHOULD NOT be allowed from client (unregistered, or registered) connections. However, it MUST be used between servers to notify other servers of new services joining the IRC network.
SERVICEコマンドは、新しいサービスを導入するために使用されます。サービスメッセージのこの形式は、クライアント（未登録、または登録）接続から許されるべきではありません。しかし、IRCネットワークに参加する新たなサービスの他のサーバーに通知するためにサーバ間で使用されなければなりません。
The <servertoken> is used to identify the server to which the service is connected. (See section 4.1.2 for more information on server tokens).
<servertoken>サービスが接続されているサーバを識別するために使用されます。 （サーバートークンの詳細については、セクション4.1.2を参照してください）。
The <hopcount> parameter is used by servers to indicate how far away a service is from its home server. A local connection has a hopcount of 0. The hopcount value is incremented by each passed server.
<ホップカウント>パラメータは、サービスがそのホームサーバからどれだけ離れているかを示すために、サーバによって使用されます。ローカル接続は、ホップカウント値をそれぞれ通過サーバインクリメントされる0のホップカウントを有します。
The <distribution> parameter is used to specify the visibility of a service. The service may only be known to servers which have a name matching the distribution. For a matching server to have knowledge of the service, the network path between that server and the server to which the service is connected MUST be composed of servers whose names all match the mask. Plain "*" is used when no restriction is wished.
<分布>パラメータは、サービスの可視性を指定するために使用されます。サービスは、分布に一致する名前を持つサーバーに知られていてもよいです。マッチングサーバは、サービスの知識を持っているため、そのサーバ及びサービスが接続されたサーバ間のネットワークパスは、名前全てのマスクに一致するサーバーから構成されなければなりません。制限が望んされていない場合平原「*」が使用されています。
The <type> parameter is currently reserved for future usage.
<タイプ>パラメータは、現在、将来の使用のために予約されています。
Numeric Replies:
数値回答：
ERR_ALREADYREGISTRED ERR_NEEDMOREPARAMS
ERR_ERRONEUSNICKNAME
RPL_YOURESERVICE RPL_YOURHOST
RPL_MYINFO
Example:
例：
SERVICE dict@irc.fr 9 *.fr 0 1 :French Dictionary r" registered on server "9" is being announced to another server. This service will only be available on servers whose name matches "*.fr".
サービスのdict@irc.fr 9 * .fr 0 1：「サーバに登録され、 『フランスの辞書のR 9は、』別のサーバーに発表されている。このサービスは、名前が一致したサーバー上で利用できるようになります。 『* .fr』。
Command: QUIT Parameters: [<Quit Message>]
コマンド：パラメータをQUIT：[<終了メッセージ>]
A client session ends with a quit message. The server MUST close the connection to a client which sends a QUIT message. If a "Quit Message" is given, this will be sent instead of the default message, the nickname or service name.
クライアントセッションが終了メッセージを表示して終了します。サーバはQUITメッセージを送信し、クライアントへの接続を閉じる必要があります。 「メッセージを終了しますが、」与えられた場合、これは、デフォルトメッセージの代わりにニックネームやサービス名が送信されます。
When "netsplit" (See Section 4.1.6) occur, the "Quit Message" is composed of the names of two servers involved, separated by a space. The first name is that of the server which is still connected and the second name is either that of the server which has become disconnected or that of the server to which the leaving client was connected:
「netsplitは」（セクション4.1.6を参照）が発生した場合、スペースで区切っ関与する2台のサーバーの名前で構成されている「メッセージを終了します」。最初の名前はまだ接続されたサーバと第二名のいずれかに切断または残して、クライアントが接続しているサーバのものとなっているサーバーのものであるということです。
<Quit Message> = ":" servername SPACE servername
"：" サーバー名SPACEサーバー名= <メッセージ終了>を
Because the "Quit Message" has a special meaning for "netsplits", servers SHOULD NOT allow a client to use a <Quit Message> in the format described above.
「終了メッセージは」「netsplits」のために特別な意味を持っているので、サーバは、クライアントが上記の形式で<メッセージを終了します>使用しないようにしてください。
If, for some other reason, a client connection is closed without the client issuing a QUIT command (e.g. client dies and EOF occurs on socket), the server is REQUIRED to fill in the quit message with some sort of message reflecting the nature of the event which caused it to happen. Typically, this is done by reporting a system specific error.
、他のいくつかの理由のために、クライアント接続が（例えば、クライアントが死ぬとEOFがソケット上で発生する）QUITコマンドを発行するクライアントせずに閉じている場合は、サーバーがの性質を反映したメッセージのいくつかの並べ替えを終了したメッセージを埋めるために必要とされますそれが起こることを原因となったイベント。通常、これはシステム固有のエラーを報告することによって行われます。
Numeric Replies:
数値回答：
None.
無し。
Examples:
例：
:WiZ QUIT :Gone to have lunch ; Preferred message format.
：ウィズはQUIT：ゴーン昼食を持っています。好適なメッセージ・フォーマット。
Command: SQUIT Parameters: <server> <comment>
コマンド：SQUITパラメータ：<サーバー> <コメント>
The SQUIT message has two distinct uses.
SQUITメッセージは、2つの異なる用途を有します。
The first one (described in "Internet Relay Chat: Client Protocol" [IRC-CLIENT]) allows operators to break a local or remote server link. This form of the message is also eventually used by servers to break a remote server link.
（「インターネットリレーチャット：クライアントプロトコル」で説明した[IRC-CLIENT]）最初の一つは事業者がローカルまたはリモートサーバーのリンクを解除することができます。メッセージのこの形式はまた、最終的には、リモートサーバーのリンクを解除するためにサーバによって使用されます。
The second use of this message is needed to inform other servers when a "network split" (also known as "netsplit") occurs, in other words to inform other servers about quitting or dead servers. If a server wishes to break the connection to another server it MUST send a SQUIT message to the other server, using the name of the other server as the server parameter, which then closes its connection to the quitting server.
このメッセージの2番目の使用は（も「netsplit」として知られている）「ネットワーク分割」が発生したときに終了またはデッドサーバについて、他のサーバーに通知するために、他の言葉で、他のサーバーに通知するために必要とされています。サーバが別のサーバへの接続を切断したい場合には、その後、終了、サーバーへの接続を閉じ、サーバー・パラメータなどの他のサーバーの名前を使用して、他のサーバーにSQUITメッセージを送らなければなりません。
The <comment> is filled in by servers which SHOULD place an error or similar message here.
<コメント>はここでエラーや同様のメッセージを配置する必要があり、サーバによって満たされます。
Both of the servers which are on either side of the connection being closed are REQUIRED to send out a SQUIT message (to all its other server connections) for all other servers which are considered to be behind that link.
閉鎖されている接続のいずれかの側にあるサーバーの両方がそのリンクの後ろにあると考えられている他のすべてのサーバーのために（そのすべての他のサーバ接続に）SQUITメッセージを送信するために必要とされています。
Similarly, a QUIT message MAY be sent to the other still connected servers on behalf of all clients behind that quitting link. In addition to this, all channel members of a channel which lost a member due to the "split" MUST be sent a QUIT message. Messages to channel members are generated by each client's local server.
同様に、QUITメッセージが終了するリンクの背後にあるすべてのクライアントに代わって、他のまだ接続されたサーバに送ってもよいです。これに加えて、原因「スプリット」にメンバーを失ったチャネルのすべてのチャネルメンバーはQUITメッセージを送信しなければなりません。チャネルメンバーへのメッセージは、各クライアントのローカルサーバによって生成されます。
If a server connection is terminated prematurely (e.g., the server on the other end of the link died), the server which detects this disconnection is REQUIRED to inform the rest of the network that the connection has closed and fill in the comment field with something appropriate.
サーバー接続が（例えば、リンクのもう一方の端のサーバが死亡した）途中で終了した場合、この切断を検出し、サーバーは、接続が閉じられたネットワークの他の部分に通知し、何かをコメント欄に記入するために必要とされます適切な。
When a client is removed as the result of a SQUIT message, the server SHOULD add the nickname to the list of temporarily unavailable nicknames in an attempt to prevent future nickname collisions. See
クライアントがSQUITメッセージの結果として削除された場合、サーバーは、将来のニックネームの衝突を防止するための試みで、一時的に利用できないニックネームのリストにニックネームを追加する必要があります。見る
section 5.7 (Tracking recently used nicknames) for more information on this procedure.
この手順の詳細については、セクション5.7（トラッキング最近使用したニックネーム）。
Numeric replies:
数値の返信：
ERR_NOPRIVILEGES ERR_NOSUCHSERVER
ERR_NEEDMOREPARAMS
Example:
例：
SQUIT tolsun.oulu.fi :Bad Link ? ; the server link tolson.oulu.fi has been terminated because of "Bad Link".
SQUITのtolsun.oulu.fi：悪いリンク？ ;サーバーのリンクtolson.oulu.fiがあるため、「悪いリンク」で終了しました。
:Trillian SQUIT cm22.eng.umd.edu :Server out of control ; message from Trillian to disconnect "cm22.eng.umd.edu" from the net because "Server out of control".
：TrillianのSQUITのcm22.eng.umd.edu：コントロールのうちサーバー。 「コントロールのうちサーバ」ので、ネットから「cm22.eng.umd.edu」を切断するのTrillianからのメッセージ。
This group of messages is concerned with manipulating channels, their properties (channel modes), and their contents (typically users). In implementing these, a number of race conditions are inevitable when users at opposing ends of a network send commands which will ultimately clash. It is also REQUIRED that servers keep a nickname history to ensure that wherever a <nick> parameter is given, the server check its history in case it has recently been changed.
メッセージのこのグループは、操作チャネル、それらの特性（チャネルモード）、およびそれらの内容物（典型的にはユーザ）に関するものです。ネットワークの両端で、ユーザーは最終的に衝突するコマンドを送信するときに、これらの実施では、競合状態の数が避けられません。また、サーバは、<ニック>パラメータが指定されているところはどこでも、サーバはそれが最近変更された場合に、その履歴を確認することを保証するために、ニックネームの履歴を保持することが必要とされます。
Command: JOIN Parameters: <channel>[ %x7 <modes> ] *( "," <channel>[ %x7 <modes> ] )
コマンド：<チャンネル> [％のX7 <モード>] *（ "" <チャンネル> [％のX7 <モード>]）：パラメータを登録しよう
The JOIN command is used by client to start listening a specific channel. Whether or not a client is allowed to join a channel is checked only by the local server the client is connected to; all other servers automatically add the user to the channel when the command is received from other servers.
joinコマンドは、特定のチャネルを聞いて開始するためにクライアントによって使用されます。クライアントは、クライアントが接続しているローカルサーバーでのみ確認されたチャンネルに参加することが許可されているかどうか。他のすべてのサーバーが自動的にコマンドが他のサーバから受信されたチャンネルにユーザーを追加します。
Optionally, the user status (channel modes 'O', 'o', and 'v') on the channel may be appended to the channel name using a control G (^G or ASCII 7) as separator. Such data MUST be ignored if the message wasn't received from a server. This format MUST NOT be sent to clients, it can only be used between servers and SHOULD be avoided.
必要に応じて、チャネル上のユーザ状態（チャンネルモード「O」、「O」、および「V」）は、セパレータとしてコントロールG（^ GまたはASCII 7）を使用してチャンネル名に付加されてもよいです。メッセージは、サーバから受信されなかった場合、このようなデータは無視しなければなりません。このフォーマットは、クライアントに送ってはいけません、それが唯一のサーバ間で使用することができ、避けるべきです。
The JOIN command MUST be broadcast to all servers so that each server knows where to find the users who are on the channel. This allows optimal delivery of PRIVMSG and NOTICE messages to the channel.
各サーバはどこのチャンネル上にあるユーザーを検索する方法を知っているように、JOINコマンドは、すべてのサーバーにブロードキャストされなければなりません。これは、チャネルへのPRIVMSGとNOTICEメッセージの最適な配信を可能にします。
Numeric Replies:
数値回答：
ERR_NEEDMOREPARAMS ERR_BANNEDFROMCHAN
ERR_INVITEONLYCHAN ERR_BADCHANNELKEY
ERR_CHANNELISFULL ERR_BADCHANMASK
ERR_NOSUCHCHANNEL ERR_TOOMANYCHANNELS
ERR_TOOMANYTARGETS ERR_UNAVAILRESOURCE
RPL_TOPIC
Examples:
例：
:WiZ JOIN #Twilight_zone ; JOIN message from WiZ
：ウィズは#Twilight_zoneを登録しよう。ウィズからのメッセージを登録しよう
Command: NJOIN Parameters: <channel> [ "@@" / "@" ] [ "+" ] <nickname> *( "," [ "@@" / "@" ] [ "+" ] <nickname> )
コマンド：NJOINパラメータ：<チャンネル> [ "@@" / "@"] [ "+"] <ニックネーム> *（ "" [ "@@" / "@"] [ "+"] <ニックネーム>）
The NJOIN message is used between servers only. If such a message is received from a client, it MUST be ignored. It is used when two servers connect to each other to exchange the list of channel members for each channel.
NJOINメッセージのみをサーバ間で使用されています。このようなメッセージがクライアントから受信した場合、それを無視しなければなりません。 2台のサーバーが、各チャネルのチャネルメンバーのリストを交換し、相互に接続するときに使用します。
Even though the same function can be performed by using a succession of JOIN, this message SHOULD be used instead as it is more efficient. The prefix "@@" indicates that the user is the "channel creator", the character "@" alone indicates a "channel operator", and the character '+' indicates that the user has the voice privilege.
同じ関数がJOINの連続を用いて行うことができるにもかかわらず、それがより効率的であるように、このメッセージが代わりに使用されるべきです。接頭辞「@@」ユーザーが「チャンネルクリエイター」であることを示し、単独の「@」の文字が「チャンネルオペレータ」を示し、および文字「+」をユーザが音声権限を持っていることを示しています。
Numeric Replies:
数値回答：
ERR_NEEDMOREPARAMS ERR_NOSUCHCHANNEL
ERR_ALREADYREGISTRED
Examples:
例：
:ircd.stealth.net NJOIN #Twilight_zone :@WiZ,+syrk,avalon ; NJOIN message from ircd.stealth.net announcing users joining the #Twilight_zone channel: WiZ with channel operator status, syrk with voice privilege and avalon with no privilege.
：ircd.stealth.net NJOIN #Twilight_zone：ウィズ、+ syrk、アバロン@;チャンネルオペレータステータスのウィズ、無権限を持つ音声特典とアバロンとsyrk：#Twilight_zoneチャンネルに参加するユーザーを発表ircd.stealth.netからNJOINメッセージ。
The MODE message is a dual-purpose command in IRC. It allows both usernames and channels to have their mode changed.
MODEメッセージはIRCで兼用コマンドです。これは、ユーザ名とチャネルの両方が彼らのモードが変更されたことを可能にします。
When parsing MODE messages, it is RECOMMENDED that the entire message be parsed first, and then the changes which resulted passed on.
MODEメッセージを解析するとき、メッセージ全体が最初に解析されることが推奨され、次いで得られた変更が渡さ。
It is REQUIRED that servers are able to change channel modes so that "channel creator" and "channel operators" may be created.
サーバが「チャンネルクリエイター」と「チャンネルオペレータが」作成することができるように、チャネルモードを変更することができることが必要です。
A the time of writing, the only current implementation of this protocol is the IRC server, version 2.10. Earlier versions may implement some or all of the commands described by this document with NOTICE messages replacing many of the numeric replies. Unfortunately, due to backward compatibility requirements, the implementation of some parts of this document varies with what is laid out. One notable difference is:
執筆時点では、このプロトコルの唯一の現在の実装では、バージョン2.10 IRCサーバです。以前のバージョンでは、NOTICEメッセージが数値回答の多くを置き換えると、この文書で説明するコマンドの一部またはすべてを実施することができます。残念ながら、後方互換性の要件のために、このドキュメントのいくつかの部分の実装がレイアウトされているものと異なります。一つの顕著な違いは以下のとおりです。
* recognition that any LF or CR anywhere in a message marks
the end of that message (instead of requiring CR-LF);
The rest of this section deals with issues that are mostly of importance to those who wish to implement a server but some parts also apply directly to clients as well.
このセクションの残りの部分は、サーバーを実装したいが、いくつかの部分にも同様のクライアントに直接適用する人にほとんど重要である問題を扱っています。
To detect when a connection has died or become unresponsive, the server MUST poll each of its connections. The PING command (See "IRC Client Protocol" [IRC-CLIENT]) is used if the server doesn't get a response from its peer in a given amount of time.
接続が死亡または応答しなくなったときを検出するために、サーバーはその接続のそれぞれをポーリングしなければなりません。サーバーは、一定時間内のピアから応答を取得しない場合PINGコマンドが使用されている（「IRCクライアントプロトコル」[IRC-CLIENT]を参照してください）。
If a connection doesn't respond in time, its connection is closed using the appropriate procedures.
接続が時間内に応答しない場合、その接続は、適切な手順を使用して閉じられています。
When a server successfully registers a new user connection, it is REQUIRED to send to the user unambiguous messages stating: the user identifiers upon which it was registered (RPL_WELCOME), the server name and version (RPL_YOURHOST), the server birth information (RPL_CREATED), available user and channel modes (RPL_MYINFO), and it MAY send any introductory messages which may be deemed appropriate.
サーバーが正常に新しいユーザの接続を登録すると、それは述べ、ユーザーの明確なメッセージを送信する必要があります：それは登録されたユーザ識別子、その上に（RPL_WELCOME）、サーバー名とバージョン（RPL_YOURHOST）、サーバーの出産情報（RPL_CREATED） 、利用可能なユーザおよびチャネルモード（RPL_MYINFO）、それが適切と判断することができる任意の紹介メッセージを送信することができます。
In particular the server SHALL send the current user/service/server count (as per the LUSER reply) and finally the MOTD (if any, as per the MOTD reply).
特に、サーバは、最終的には、現在のユーザー/サービス/サーバ（LUSER応答ごとなど）のカウントと（MOTD応答あたりなどがあれば、）MOTDを送信しなければなりません。
After dealing with registration, the server MUST then send out to other servers the new user's nickname (NICK message), other information as supplied by itself (USER message) and as the server could discover (from DNS servers). The server MUST NOT send this information out with a pair of NICK and USER messages as defined in "IRC Client Protocol" [IRC-CLIENT], but MUST instead take advantage of the extended NICK message defined in section 4.1.3.
登録に対処した後、サーバーは、それ自体で供給されるような、他のサーバーに（USERメッセージを）他の情報を新しいユーザーのニックネーム（NICKメッセージ）を送信し、サーバーが（DNSサーバからの）発見できたとしてしなければなりません。サーバーは、「IRCクライアントプロトコル」[IRC-CLIENT]で定義されているようNICKとUSERメッセージのペアで、この情報を送ってはいけませんが、代わりにセクション4.1.3で定義された拡張NICKメッセージを利用しなければなりません。
Upon successfully registering a new service connection, the server is subject to the same kind of REQUIREMENTS as for a user. Services being somewhat different, only the following replies are sent: RPL_YOURESERVICE, RPL_YOURHOST, RPL_MYINFO.
成功した新しいサービス接続を登録すると、サーバはユーザのための要件としての同じ種類の対象となります。サービスが多少異なっている、唯一の次の応答が送信されます。RPL_YOURESERVICE、RPL_YOURHOST、RPL_MYINFOを。
After dealing with this, the server MUST then send out to other servers (SERVICE message) the new service's nickname and other information as supplied by the service (SERVICE message) and as the server could discover (from DNS servers).
これに対処した後、サーバーは、（DNSサーバーからの）を発見でき、サーバの他のサーバー（サービス・メッセージ）新しいサービスのニックネームやサービス（SERVICEメッセージ）によって提供されるなど、他の情報とし、通りに送らなければなりません。
The process of establishing a server-to-server connection is fraught with danger since there are many possible areas where problems can occur - the least of which are race conditions.
レースの条件である少なくともそのうち - 問題が発生する可能性があり、多くの可能な領域があるので、サーバー間の接続を確立するプロセスは、危険性をはらんでいます。
After a server has received a connection following by a PASS/SERVER pair which were recognized as being valid, the server SHOULD then reply with its own PASS/SERVER information for that connection as well as all of the other state information it knows about as described below.
サーバーが有効であると認められたPASS / SERVERのペアで、次の接続を受信した後、サーバーはその接続のために、自身のPASS / SERVERの情報を返信すべきであるだけでなく、他の状態情報の全ては、それが説明するように知っています未満。
When the initiating server receives a PASS/SERVER pair, it too then checks that the server responding is authenticated properly before accepting the connection to be that server.
開始サーバがPASS / SERVERのペアを受信すると、それはあまりにも、サーバーの応答がそのサーバになるように、接続を受け入れる前に、正しく認証されていることを確認します。
Server links are based on a common protocol (defined by this document) but a particular link MAY set specific options using the PASS message (See Section 4.1.1).
サーバーのリンクは、（本書で定義された）共通のプロトコルに基づいていますが、特定のリンク（セクション4.1.1を参照してください）PASSメッセージを使用して特定のオプションを設定することができます。
If a server wishes to establish a compressed link with its peer, it MUST set the 'Z' flag in the options parameter to the PASS message. If both servers request compression and both servers are able to initialize the two compressed streams, then the remainder of the communication is to be compressed. If any server fails to initialize the stream, it will send an uncompressed ERROR message to its peer and close the connection.
サーバはそのピアと圧縮されたリンクを確立することを希望する場合は、PASSメッセージにオプションパラメータに「Z」フラグを設定しなければなりません。両方のサーバが圧縮を要求し、両方のサーバは、2つの圧縮ストリームを初期化することが可能である場合、通信の残りの部分は、圧縮されるべきです。いずれかのサーバがストリームの初期化に失敗した場合、それはそのピアに圧縮されていないエラーメッセージを送信し、接続を閉じます。
The data format used for the compression is described by RFC 1950 [ZLIB], RFC 1951 [DEFLATE] and RFC 1952 [GZIP].
圧縮のために使用されるデータフォーマットは、RFC 1950 [ZLIB]、RFC 1951 [DEFLATE]およびRFC 1952 [GZIP]によって記載されています。
Most servers implement various kinds of protections against possible abusive behaviours from non trusted parties (typically users). On some networks, such protections are indispensable, on others they are superfluous. To require that all servers implement and enable such features on a particular network, the 'P' flag is used when two servers connect. If this flag is present, it means that the server protections are enabled, and that the server REQUIRES all its server links to enable them as well.
ほとんどのサーバーは、非信頼できる関係者（通常はユーザ）から可能な虐待行為に対する保護の様々な種類を実装しています。一部のネットワークでは、このような保護は、他の人に、彼らが不要で、不可欠です。 2台のサーバーが接続すると、すべてのサーバーが実装することを必要とし、特定のネットワーク上で、このような機能を有効にするには、「P」フラグが使用されています。このフラグが存在している場合は、サーバーの保護が有効になっていることを意味し、そのサーバーは、同様にそれらを有効にするために、すべてのサーバーのリンクが必要です。
Commonly found protections are described in sections 5.7 (Tracking recently used nicknames) and 5.8 (Flood control of clients).
一般的に見られる保護はセクション5.7（トラッキング最近使用されたニックネーム）と5.8（クライアントの洪水制御）に記載されています。
The order of state information being exchanged between servers is essential. The REQUIRED order is as follows:
サーバ間で交換される状態情報のオーダーは必要不可欠です。次のように必要な順序は次のとおりです。
* all known servers;
*すべての既知のサーバー。
* all known client information;
*すべての既知のクライアント情報。
* all known channel information.
*すべての既知のチャネル情報。
Information regarding servers is sent via extra SERVER messages, client information with NICK and SERVICE messages and channels with NJOIN/MODE messages.
サーバに関する情報は、余分なサーバーメッセージ、NICKとサービスメッセージとNJOIN / MODEメッセージのチャネルを使用してクライアントの情報を経由して送信されます。
NOTE: channel topics SHOULD NOT be exchanged here because the TOPIC command overwrites any old topic information, so at best, the two sides of the connection would exchange topics.
注：TOPICコマンドは、任意の古いトピック情報が上書きされるための最高の状態で、接続の2つの側面が話題を交換しますので、チャンネルのトピックは、ここで交換されるべきではありません。
By passing the state information about servers first, any collisions with servers that already exist occur before nickname collisions caused by a second server introducing a particular nickname. Due to the IRC network only being able to exist as an acyclic graph, it may be possible that the network has already reconnected in another location. In this event, the place where the server collision occurs indicates where the net needs to split.
最初のサーバに関する状態情報を渡すことによって、既に存在するサーバを有する任意の衝突が特定のニックネームを導入する第二のサーバに起因するニックネームの衝突の前に起こります。唯一の非循環グラフとして存在することができるIRCネットワークのために、ネットワークが既に別の場所に再接続していることが可能であってもよいです。ネットを分割する必要がある場合、このイベントでは、サーバーの衝突が発生した場所を示します。
When a client connection unexpectedly closes, a QUIT message is generated on behalf of the client by the server to which the client was connected. No other message is to be generated or used.
クライアント接続が予期せず終了した場合、QUITメッセージは、クライアントが接続しているサーバによってクライアントに代わって生成されます。他のメッセージが生成または使用されるべきではありません。
If a server-server connection is closed, either via a SQUIT command or "natural" causes, the rest of the connected IRC network MUST have its information updated by the server which detected the closure. The terminating server then sends a list of SQUITs (one for each server behind that connection). (See Section 4.1.6 (SQUIT)).
サーバー・サーバー接続がクローズされている場合は、どちらかSQUITコマンドまたは「自然」の原因を経由して、接続されているIRCネットワークの残りの部分は、その情報が閉鎖を検出したサーバーによって更新持たなければなりません。終端サーバは、SQUITs（その接続の背後にある各サーバに対して1つ）のリストを送信します。 （セクション4.1.6（SQUIT）を参照してください）。
All IRC servers are REQUIRED to keep a history of recent nickname changes. This is important to allow the server to have a chance of keeping in touch of things when nick-change race conditions occur with commands manipulating them. Messages which MUST trace nick changes are:
すべてのIRCサーバは最新のニックネームの変更の履歴を保持する必要があります。これは、サーバーがニック・チェンジの競合状態がそれらを操作するコマンドで発生したときに、物事の連絡を保つの機会を持つことができるようにすることが重要です。ニックの変更を追跡しなければならないメッセージは、次のとおりです。
* KILL (the nick being disconnected)
* KILL（ニックが切断されます）
* MODE (+/- o,v on channels)
* MODE（+/- O、チャンネルのV）
* KICK (the nick being removed from channel)
* KICK（ニックをチャネルから除去されます）
No other commands need to check nick changes.
他のコマンドはニックの変更をチェックする必要がありません。
In the above cases, the server is required to first check for the existence of the nickname, then check its history to see who that nick now belongs to (if anyone!). This reduces the chances of race conditions but they can still occur with the server ending up affecting the wrong client. When performing a change trace for an above command it is RECOMMENDED that a time range be given and entries which are too old ignored.
上記の例では、サーバはまず、ニックネームの存在をチェックニックは今に属している人を見て、その履歴を確認するために必要とされる（誰場合！）。これは競合状態の可能性を減少させたが、彼らはまだ、サーバーが間違ったクライアントに影響を与え終わると発生する可能性があります。上記のコマンドの変更トレースを実行する場合、時間が与えられ、古すぎるエントリは無視されるレンジことが推奨されます。
For a reasonable history, a server SHOULD be able to keep previous nickname for every client it knows about if they all decided to change. This size is limited by other factors (such as memory, etc).
合理的な歴史のために、サーバは、それは彼らがすべて変更することを決めた場合は知っているすべてのクライアントのために、以前のニックネームを維持することができるべきです。このサイズは（メモリなど、など）他の要因によって制限されます。
This mechanism is commonly known as "Nickname Delay", it has been proven to significantly reduce the number of nickname collisions resulting from "network splits"/reconnections as well as abuse.
このメカニズムは、一般に「ニックネーム遅延」として知られ、かなり「ネットワーク分割」/再接続だけでなく、虐待の結果ニックネームの衝突の数を減らすことが証明されています。
In addition of keeping track of nickname changes, servers SHOULD keep track of nicknames which were recently used and were released as the result of a "network split" or a KILL message. These nicknames are then unavailable to the server local clients and cannot be re-used (even though they are not currently in use) for a certain period of time.
ニックネームの変更を追跡するのに加えて、サーバは、最近使用されたと「ネットワーク分割」またはKILLメッセージの結果として放出されたニックネームのトラックを維持する必要があります。これらのニックネームは、サーバのローカルクライアントでは利用できませんし、一定時間（彼らは現在使用されていないにもかかわらず）、再使用することはできません。
The duration for which a nickname remains unavailable SHOULD be set considering many factors among which are the size (user wise) of the IRC network, and the usual duration of "network splits". It SHOULD be uniform on all servers for a given IRC network.
ニックネームが利用できないままでいる期間は、サイズIRCネットワークの（ユーザごとの）、および「ネットワーク分割」の通常の持続期間である間、多くの要因を考慮して設定されるべきです。これは、特定のIRCネットワークのすべてのサーバー上で均一でなければなりません。
With a large network of interconnected IRC servers, it is quite easy for any single client attached to the network to supply a continuous stream of messages that result in not only flooding the network, but also degrading the level of service provided to others. Rather than require every 'victim' to provide their own protection, flood protection was written into the server and is applied to all clients except services. The current algorithm is as follows:
相互接続されたIRCサーバの大規模なネットワークでは、それだけではなく、ネットワークをフラッディングするだけでなく、他の人に提供されるサービスのレベルを低下させることにつながるメッセージの連続ストリームを供給するために、ネットワークに接続された任意の単一のクライアントのために非常に簡単です。自分自身の保護を提供するために、すべての「被害者」を必要とするのではなく、洪水の保護がサーバーに書き込まれた及びサービス以外のすべてのクライアントに適用されます。次のように現在のアルゴリズムは次のとおりです。
* check to see if client's `message timer' is less than current time (set to be equal if it is);
*クライアントの `メッセージタイマーが」（それがある場合に等しくなるように設定された）現在の時刻よりも小さいかどうかを確認します。
* read any data present from the client;
*クライアントから存在する任意のデータを読み取ります。
* while the timer is less than ten (10) seconds ahead of the current time, parse any present messages and penalize the client by two (2) seconds for each message;
*タイマが先に現在の時刻の10未満（10）秒であるが、任意の現在のメッセージを解析し、メッセージごとに2秒てクライアントを罰します。
* additional penalties MAY be used for specific commands which generate a lot of traffic across the network.
*追加の罰則は、ネットワーク上のトラフィックの多くを生成する特定のコマンドのために使用されるかもしれません。
This in essence means that the client may send one (1) message every two (2) seconds without being adversely affected. Services MAY also be subject to this mechanism.
本質的にこれは、クライアントが悪影響を及ぼすことなく、1つ（1）メッセージを2秒ごとに送信してもよいことを意味します。サービスはまた、このメカニズムを受ける可能性があります。
In a real-time environment, it is essential that a server process does as little waiting as possible so that all the clients are serviced fairly. Obviously this requires non-blocking IO on all network read/write operations. For normal server connections, this was not difficult, but there are other support operations that may cause the server to block (such as disk reads). Where possible, such activity SHOULD be performed with a short timeout.
リアルタイム環境では、すべてのクライアントが公平にサービスが提供されるように、サーバプロセスができるだけ少ない待ちをしていることが不可欠です。これは明らかに、すべてのネットワークの読み取り/書き込み操作に非ブロックIOが必要です。通常のサーバ接続の場合、これは難しいことではありませんでしたが、サーバーが（ディスクの読み取りなど）をブロックする可能性があり、他のサポート業務があります。可能な場合、そのような活性は、短いタイムアウトを用いて行われるべきです。
Using the standard resolver libraries from Berkeley and others has meant large delays in some cases where replies have timed out. To avoid this, a separate set of DNS routines were written for the current implementation. Routines were setup for non-blocking IO operations with local cache, and then polled from within the main server IO loop.
バークレーなどから、標準のリゾルバライブラリを使用すると、返信がタイムアウトしたいくつかのケースでは、大きな遅延を意味しています。これを回避するには、DNSルーチンの別のセットは、現在の実装のために書かれました。ルーチンは、ローカルキャッシュと非ブロック入出力操作用のセットアップした後、メインサーバーIOループ内からポーリング。
Although there are numerous ident libraries (implementing the "Identification Protocol" [IDENT]) for use and inclusion into other programs, these caused problems since they operated in a synchronous manner and resulted in frequent delays. Again the solution was to write a set of routines which would cooperate with the rest of the server and work using non-blocking IO.
他のプログラムに使用し、含めるため（「識別プロトコル」[IDENT]を実装する）多数のIDENTライブラリが存在するが、それらが同期的に動作し、頻繁に遅延が生じているため、これらの問題を引き起こしました。ここでも解決策は、ノンブロッキングIOを使用して、サーバーとの仕事の残りの部分と協力する一連のルーチンを書くことでした。
There are a number of recognized problems with this protocol, all of which are hoped to be solved sometime in the near future during its rewrite. Currently, work is underway to find working solutions to these problems.
その書き換え時に、近い将来にいつかは解決することを望んでいるすべてがこのプロトコルで認識問題の数があります。現在、仕事は、これらの問題に取り組んで解決策を見つけるために進行中です。
It is widely recognized that this protocol does not scale sufficiently well when used in a large arena. The main problem comes from the requirement that all servers know about all other servers and clients and that information regarding them be updated as soon as it changes. It is also desirable to keep the number of servers low so that the path length between any two points is kept minimal and the spanning tree as strongly branched as possible.
広く、大舞台で使用された場合、このプロトコルは十分にスケールしないことが認識されています。主な問題は、すべてのサーバーが、それが変更されるとすぐに更新されることについての他のすべてのサーバーとクライアントおよびそれらに関するその情報を知る必要性から来ています。任意の2点間の経路の長さが最小に保たれ、スパニングツリーは、として強く可能として分岐するように、また、低いサーバーの数を維持することが望ましいです。
The current IRC protocol has 4 types of labels: the nickname, the channel name, the server name and the service name. Each of the four types has its own domain and no duplicates are allowed inside that domain. Currently, it is possible for users to pick the label for any of the first three, resulting in collisions. It is widely recognized that this needs reworking, with a plan for unique names for nicks that don't collide being desirable as well as a solution allowing a cyclic tree.
ニックネーム、チャンネル名、サーバー名およびサービス名：現在のIRCプロトコルは、ラベルの4種類があります。 4種類のそれぞれが独自のドメインを持っており、何の重複は、そのドメイン内で許可されません。ユーザーは、衝突が生じ、最初の3のいずれのラベルを選択するために、現在、それが可能です。広く、これは望ましいものと同様に巡回ツリーを許可するソリューション衝突しないニックのためのユニークな名前のための計画で、再加工が必要であることを認識されています。
The idea of the nickname on IRC is very convenient for users to use when talking to each other outside of a channel, but there is only a finite nickname space and being what they are, it's not uncommon for several people to want to use the same nick. If a nickname is chosen by two people using this protocol, either one will not succeed or both will be removed by use of KILL (See Section 3.7.1 of "IRC Client Protocol" [IRC-CLIENT]).
複数の人が同じを使用したいためにIRC上のニックネームのアイデアは、チャネルの相互外に話したときに、ユーザーが使用するために非常に便利ですが、唯一の有限ニックネームスペースと彼らが何であるかであることがあり、それは珍しいことではありませんニック。ニックネームは、このプロトコルを使用して、2つの人々によって選択された場合、どちらか一方が成功しないだろうか、両方がKILLの使用（「IRCクライアントプロトコル」[IRC-CLIENT]のセクション3.7.1を参照）によって削除されます。
The current channel layout requires that all servers know about all channels, their inhabitants and properties. Besides not scaling well, the issue of privacy is also a concern. A collision of channels is treated as an inclusive event (people from both nets on channel with common name are considered to be members of it) rather than an exclusive one such as used to solve nickname collisions.
現在のチャネルのレイアウトは、すべてのサーバを約すべてのチャネル、その住民との特性を知っている必要があります。うまくスケーリングないだけでなく、プライバシーの問題も懸念されます。チャネルの衝突を含めイベント（一般名を持つチャネル上の両方のネットからの人々はそれのメンバーであると考えられる）ではなくニックネームの衝突を解決するために使用されるような排他的なものとして扱われます。
This protocol defines "Safe Channels" which are very unlikely to be the subject of a channel collision. Other channel types are kept for backward compatibility.
このプロトコルは、チャネル衝突の対象となるのは非常にそうもない「安全チャンネル」を定義します。他のチャンネルタイプは、下位互換性のために保持されています。
Although the number of servers is usually small relative to the number of users and channels, they too are currently REQUIRED to be known globally, either each one separately or hidden behind a mask.
サーバの数は、ユーザーおよびチャネルの数に対して通常は小さいですが、彼らはあまりにも、現在世界的に知られるように必要に応じて、いずれか一つ一つ個別にまたはマスクの後ろに隠されています。
In some places within the server code, it has not been possible to avoid N^2 algorithms such as checking the channel list of a set of clients.
サーバのコード内のいくつかの場所では、そのようなクライアントのセットのチャンネルリストをチェックするようにN ^ 2つのアルゴリズムを回避することができませんでした。
In current server versions, there are only few database consistency checks, most of the time each server assumes that a neighbouring server is correct. This opens the door to large problems if a connecting server is buggy or otherwise tries to introduce contradictions to the existing net.
現在のサーバのバージョンでは、ごく少数のデータベースの整合性チェックがあり、ほとんどの時間、各サーバは、隣接サーバーが正しいと仮定しています。接続サーバはバグがあるか、そうでない場合は、既存のネットに矛盾を導入しようとする場合、これは大きな問題への扉を開きます。
Currently, because of the lack of unique internal and global labels, there are a multitude of race conditions that exist. These race conditions generally arise from the problem of it taking time for messages to traverse and effect the IRC network. Even by changing to unique labels, there are problems with channel-related commands being disrupted.
現在、なぜならユニークな内部およびグローバルラベルの不足のため、存在する競合状態の群衆があります。それが横断し、IRCネットワークを達成するために、メッセージのために時間を割いて、これらの競合状態は、一般的な問題から生じます。でもユニークなラベルを変更することで、中断されるチャネル関連のコマンドに問題があります。
Servers only have two means of authenticating incoming connections: plain text password, and DNS lookups. While these methods are weak and widely recognized as unsafe, their combination has proven to be sufficient in the past:
プレーンテキストのパスワード、およびDNSルックアップ：サーバーは2つのだけの着信接続を認証する手段を持っています。これらのメソッドは弱く、広く安全ではないと認識しながら、その組み合わせは、過去に十分であることが証明されました：
* public networks typically allow user connections with only few restrictions, without requiring accurate authentication.
*公衆ネットワークは、通常、正確な認証を必要とせず、唯一のいくつかの制限付きユーザー接続を許可します。
* private networks which operate in a controlled environment often use home-grown authentication mechanisms not available on the internet: reliable ident servers [IDENT], or other proprietary mechanisms.
信頼性のidentサーバ[IDENT]、またはその他の独自のメカニズム：*制御された環境で動作プライベートネットワークは、多くの場合、インターネット上で利用可能ではない自家製の認証メカニズムを使用します。
The same comments apply to the authentication of IRC Operators.
同じコメントがIRCオペレータの認証に適用されます。
It should also be noted that while there has been no real demand over the years for stronger authentication, and no real effort to provide better means to safely authenticate users, the current protocol offers enough to be able to easily plug-in external authentication methods based on the information that a client can submit to the server upon connection: nickname, username, password.
また、より強力な認証、および安全にユーザーを認証するためのより良い手段を提供することがない本当の努力のための年間の本当の需要がなかった一方で、現在のプロトコルは簡単にプラグインに基づいて外部認証方式できるように十分に提供していますことに留意すべきですニックネーム、ユーザー名、パスワード：クライアントが接続時にサーバに送信することができた情報に。
Since the PASS and OPER messages of the IRC protocol are sent in clear text, a stream layer encryption mechanism (like "The TLS Protocol" [TLS]) could be used to protect these transactions.
IRCプロトコルのPASSとOPERメッセージは平文で送信されるので、（「TLSプロトコル」[TLS]のような）ストリームレイヤの暗号化機構は、これらのトランザクションを保護するために使用することができます。
Mailing lists for IRC related discussion:
General discussion: ircd-users@irc.org
Protocol development: ircd-dev@irc.org
Software implementations: ftp://ftp.irc.org/irc/server ftp://ftp.funet.fi/pub/unix/irc ftp://coombs.anu.edu.au/pub/irc
ソフトウェアの実装：ftp://ftp.irc.org/irc/server ftp://ftp.funet.fi/pub/unix/irc ftp://coombs.anu.edu.au/pub/irc
Newsgroup: alt.irc
ニュースグループ：alt.irc
Parts of this document were copied from the RFC 1459 [IRC] which first formally documented the IRC Protocol. It has also benefited from many rounds of review and comments. In particular, the following people have made significant contributions to this document:
この文書の部分は、第一正式IRCプロトコルを文書RFC 1459 [IRC]からコピーされました。また、レビューやコメントの多くのラウンドの恩恵を受けています。具体的には、以下の人々は、このドキュメントへの重要な貢献をしました。
Matthew Green, Michael Neumayer, Volker Paulsen, Kurt Roeckx, Vesa Ruokonen, Magnus Tjernstrom, Stefan Zehl.
マシュー・グリーン、ミヒャエル・ノイマイアー、フォルカー・ポールセン、クルトRoeckx、のVesa Ruokonen、マグナスTjernström、ステファンZehl。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[キーワード]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[ABNF]クロッカー、D.、およびP. Overell、 "構文仕様のための増大しているBNF：ABNF"、RFC 2234、1997年11月。
[IRC] Oikarinen, J. and D. Reed, "Internet Relay Chat Protocol", RFC 1459, May 1993.
[IRC] Oikarinen、J.とD.リード、 "インターネットリレーチャットプロトコル"、RFC 1459、1993年5月。
[IRC-ARCH] Kalt, C., "Internet Relay Chat: Architecture", RFC 2810, April 2000.
[IRC-ARCH] Kalt、C.、 "インターネットリレーチャット：アーキテクチャ"、RFC 2810、2000年4月。
[IRC-CLIENT] Kalt, C., "Internet Relay Chat: Client Protocol", RFC 2812, April 2000.
[IRC-CLIENT] Kalt、C.、 "インターネットリレーチャット：クライアントプロトコル"、RFC 2812、2000年4月。
[IRC-CHAN] Kalt, C., "Internet Relay Chat: Channel Management", RFC 2811, April 2000.
[IRC-CHAN] Kalt、C.、 "インターネットリレーチャット：チャンネル管理"、RFC 2811、2000年4月。
[ZLIB] Deutsch, P. and J-L. Gailly, "ZLIB Compressed Data Format Specification version 3.3", RFC 1950, May 1996.
【ZLIB]ドイツ、P.及びJ-L。 Gailly氏、 "ZLIB圧縮データフォーマット仕様バージョン3.3"、RFC 1950、1996年5月。
[DEFLATE] Deutsch, P., "DEFLATE Compressed Data Format Specification version 1.3", RFC 1951, May 1996.
[DEFLATE]ドイツ、P.、 "DEFLATE圧縮データフォーマット仕様バージョン1.3"、RFC 1951、1996年5月。
[GZIP] Deutsch, P., "GZIP file format specification version 4.3", RFC 1952, May 1996.
[GZIP]ドイツ、P.、 "GZIPファイル形式の仕様バージョン4.3"、RFC 1952、1996年5月。
[IDENT] St. Johns, M., "The Identification Protocol", RFC 1413, February 1993.
【IDENT】セントジョーンズ、M.、 "識別プロトコル"、RFC 1413、1993年2月。
[TLS] Dierks, T. and C. Allen, "The TLS Protocol", RFC 2246, January 1999.
[TLS]ダークス、T.とC.アレン、 "TLSプロトコル"、RFC 2246、1999年1月。
Christophe Kalt 99 Teaneck Rd, Apt #117 Ridgefield Park, NJ 07660 USA
クリストフKalt 99ティーネックRdを、アプト＃117リッジフィールドパーク、ニュージャージー州07660米国
EMail: kalt@stealth.net
メールアドレス：kalt@stealth.net
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
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 Editor機能のための基金は現在、インターネット協会によって提供されます。