RFC2813 日本語訳
2813 Internet Relay Chat: Server Protocol. C. Kalt. April 2000. (Format: TXT=56681 bytes) (Updates RFC1459) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group C. Kalt Request for Comments: 2813 April 2000 Updates: 1459 Category: Informational
Kaltがコメントのために要求するワーキンググループC.をネットワークでつないでください: 2813 2000年4月は以下をアップデートします。 1459年のカテゴリ: 情報
Internet Relay Chat: Server Protocol
インターネットリレーチャット: サーバプロトコル
Status of this Memo
この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.
Copyright(C)インターネット協会(2000)。 All rights reserved。
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(インターネットRelay Chat)プロトコルで、サーバは、ネットワークを形成しながら、有効に互いに接します。
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.
1993年5月にまず最初にRFC1459[IRC]の一部として正式に記録されていて、本書では開発が、より上手にプロトコルスケールを作るのに焦点を合わせられたようにそれ以来持って来られた変化の大部分を見つけることができます。 より良いスケーラビリティで、既存の世界的なネットワークは、成長し続けて、古い仕様を無視するサイズに達しました。
Kalt Informational [Page 1] RFC 2813 Internet Relay Chat: Server Protocol April 2000
Kaltの情報[1ページ]のRFC2813インターネットリレーチャット: サーバプロトコル2000年4月
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
1. 序論… 3 2. グローバルなデータベース… 3 2.1のサーバ… 3 2.2人のクライアント… 4 2.2 .1人のユーザ… 4 2.2 .2 修理します。 4 2.3 精神を集中します… 4 3. IRCサーバ仕様… 5 3.1概要… 5 3.2 キャラクターコード… 5 3.3のメッセージ… 5 3.3 .1 Augmented BNFのメッセージ形式… 6 3.4数値は返答します… 7 4. メッセージの詳細… 7 4.1 接続登録… 8 4.1 .1パスワードメッセージ… 8 4.1 .2サーバメッセージ… 9 4.1 .3 陰で非難してください… 10 4.1 .4 メッセージを修理してください… 11 4.1 .5 やめてください… 12 4.1 .6サーバはメッセージをやめました… 13 4.2は操作を向けます… 14 4.2 .1 メッセージを接合してください… 14 4.2 .2Njoinメッセージ… 15 4.2 .3モードメッセージ… 16 5. 実装の詳細… 16 5.1接続'活性'… 16 5.2 サーバ接続にクライアントを受け入れます… 16 5.2 .1人のユーザ… 16 5.2 .2 修理します。 17 5.3 サーバサーバ接続を確立します。 ............... 17 5.3 .1 オプションをリンクしてください… 17 5.3 .1 サーバへの.1の圧縮されたサーバはリンクされます… 18 5.3 .1 .2 反乱用保護… 18 5.3 .2 接続するときには情報交換を述べてください… 18 5.4 サーバクライアント接続を終えます… 19 5.5 サーバサーバ接続を終えます… 19 5.6の追跡あだ名は変化します… 19 5.7 最近追跡するのはあだ名を使用しました… 20 5.8 クライアントのコントロールをあふれさせてください… 20 5.9 非ブロッキングルックアップ… 21 5.9 .1 ホスト名(DNS)ルックアップ… 21 5.9 .2 ユーザ名(Ident)ルックアップ… 21 6. 現在の問題… 21 6.1スケーラビリティ… 21 6.2 ラベルします。 22
Kalt Informational [Page 2] RFC 2813 Internet Relay Chat: Server Protocol April 2000
Kaltの情報[2ページ]のRFC2813インターネットリレーチャット: サーバプロトコル2000年4月
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
6.2.1 あだ名… 22 6.2 .2 精神を集中します… 22 6.2 .3のサーバ… 22 6.3のアルゴリズム… 22 7. セキュリティ問題… 23 7.1認証… 23 7.2保全… 23 8. 現在のサポートと有用性… 24 9. 承認… 24 10. 参照… 24 11. 作者のアドレス… 25 12. 完全な著作権宣言文… 26
1. Introduction
1. 序論
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]).
サーバが定義されたリアルタイムで会議に必要である3つの基本サービスを提供する、「インターネットリレーチャット:」 「アーキテクチャ」[IRC-アーチ]: クライアントロケータ(クライアントプロトコル[IRC-CLIENT]を通した)、メッセージリレー(本書では定義されたサーバプロトコルを通した)、チャンネル接待、および管理(次の特定の規則[IRCチェン])。
2. Global database
2. グローバルなデータベース
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ネットワークに関する「グローバルな州のデータベース」を維持します。 このデータベースはすべてのサーバで理論上同じです。
2.1 Servers
2.1 サーバ
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 SHALLに合っている名前に合わせる名前を接続しないすべて中では、IRCは外でhostmasked領域をネットワークでつなぎます。 領域の外にあるサーバは領域の中の現在の個々のサーバに関する知識を全く持たないで、代わりに、名前のためにhostmaskを持っている仮想サーバをそれらに与えます。
Kalt Informational [Page 3] RFC 2813 Internet Relay Chat: Server Protocol April 2000
Kaltの情報[3ページ]のRFC2813インターネットリレーチャット: サーバプロトコル2000年4月
2.2 Clients
2.2 クライアント
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のユニークな識別子(形式をクライアントのタイプに頼る)とクライアントが関連しているサーバ。
2.2.1 Users
2.2.1 ユーザ
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(9)キャラクタがあるユニークなあだ名によって他のユーザと区別されます。 あだ名で使用されるかもしれないことに関してプロトコル文法規則(セクション3.3.1)を見てください。 あだ名に加えて、すべてのサーバには、すべてのユーザの以下の情報がなければなりません: ユーザが走っているホストの名前、そのホストの上のユーザのユーザ名、およびクライアントが関連しているサーバ。
2.2.2 Services
2.2.2 サービス
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(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で説明された「治水」メカニズムを受けることがありません。
2.3 Channels
2.3個のチャンネル
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-チェン]を持っていて、必ずすべてのサーバに知られているというわけではありません。 チャンネル存在がサーバに知られていると、サーバはチャンネルメンバーの動向をおさえなければなりません、チャンネルモードと同様に。
Kalt Informational [Page 4] RFC 2813 Internet Relay Chat: Server Protocol April 2000
Kaltの情報[4ページ]のRFC2813インターネットリレーチャット: サーバプロトコル2000年4月
3. The IRC Server Specification
3. IRCサーバ仕様
3.1 Overview
3.1 概要
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 Clientプロトコル仕様を見てください。
There are, however, more restrictions on client connections (which are considered to be untrustworthy) than on server connections.
しかしながら、クライアント接続(信頼できないと考えられる)のサーバ接続より多くの制限があります。
3.2 Character codes
3.2 キャラクターコード
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)ビットで構成される1セットのコードに基づいています、八重奏を作って。 各メッセージはこれらのいろいろな八重奏で構成されるかもしれません。 しかしながら、いくつかの八重奏値がメッセージデリミタとして機能する制御コードに使用されます。
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ビットのプロトコルであることにかかわらず、デリミタとキーワードはプロトコルが米国-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つのあだ名、またはチャンネル名の等価性を決定するとき、これは重大な問題です。
3.3 Messages
3.3 メッセージ
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つの主部から成るかもしれません: (OPTIONAL)、コマンド、およびコマンドパラメタを前に置いてください。(15(15))では、最大です。 接頭語、コマンド、およびすべてのパラメタがそれぞれ1つのASCII間隔文字(0×20)によって切り離されます。
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)、メッセージ自体の最初のキャラクタであるに違いない。 コロンと接頭語の間には、ギャップ(空白)が全くあるはずがありません。 接頭語はサーバによって使用されて、メッセージの本当の発生源を示します。 接頭語がメッセージからなくなるなら、受け取られた接続から発したと思われます。 自分たちからメッセージを送るとき、クライアントSHOULDは接頭語を使用しません。 彼らが1つを使用するなら、唯一の有効な接頭語がクライアントに関連している登録されたあだ名です。
Kalt Informational [Page 5] RFC 2813 Internet Relay Chat: Server Protocol April 2000
Kaltの情報[5ページ]のRFC2813インターネットリレーチャット: サーバプロトコル2000年4月
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メッセージをクライアントのために発行して、すべてのサーバに送らなければならないなら。 他のケース、メッセージが到着したリンクでは、SHOULDをクライアントのために下げられて、サーバのために下げなければなりません。 すべての場合では、メッセージを捨てなければなりません。
The command MUST either be a valid IRC command or a three (3) digit number represented in ASCII text.
コマンドは、ASCIIテキストに表された有効なIRCコマンドか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(キャリッジReturn--線Feed)組と共に終えられたキャラクタの系列と、SHALL NOTが長さで512のキャラクタを超えているというこれらのメッセージです、引きずっているCR-LFを含むすべてのキャラクタを数えて。 したがって、最大がコマンドとそのパラメタのために許容した510のキャラクタがあります。 継続メッセージ行への支給が全くありません。 現在の実装に関するその他の詳細に関してセクション5を見てください。
3.3.1 Message format in Augmented BNF
3.3.1 Augmented BNFのメッセージ・フォーマット
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].
このAugmented 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.
外からメッセージがだれであるかの、より役に立つ情報をもっているクライアントに追加質問の必要性を提供して、拡張接頭語([“!"ユーザ"@"ホスト])は、サーバコミュニケーションへのサーバに使用されてはいけなくて、サーバのためにクライアントメッセージに意図するだけです。
Kalt Informational [Page 6] RFC 2813 Internet Relay Chat: Server Protocol April 2000
Kaltの情報[6ページ]のRFC2813インターネットリレーチャット: サーバプロトコル2000年4月
3.4 Numeric replies
3.4 数値回答
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].
サーバに送られたメッセージの大部分はある種の回答を生成します。 最も一般的な回答は誤りと通常の回答の両方に使用される数値回答です。 送付者接頭語、3ケタ数値、および回答の目標から成る1つのメッセージとして数値回答を送らなければなりません。 数値回答はクライアントから発することができません。 サーバによって受け取られたどんなそのようなメッセージも静かに下げられます。 他のすべての点で、数値回答はまさしく正常なメッセージに似ています、キーワードが一連の手紙よりむしろ数値3ケタで作られるのを除いて。 「IRCクライアントプロトコル」[IRC-CLIENT]で異なった回答のリストを提供します。
4. Message Details
4. メッセージの詳細
All the messages recognized by the IRC server and client are described in the IRC Client Protocol specification.
IRCサーバとクライアントによって認められたすべてのメッセージがIRC Clientプロトコル仕様で説明されます。
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
:名前COMMANDパラメータ・リスト
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
「IRCクライアントプロトコル」[IRC-CLIENT]でメッセージの詳細はサーバコミュニケーションへのクライアントに説明されます。 以下のページの数人のセクションがこれらのメッセージのいくつかに適用されて、それらはサーバだけに関連しているメッセージ仕様への追加です。
Kalt Informational [Page 7] RFC 2813 Internet Relay Chat: Server Protocol April 2000
Kaltの情報[7ページ]のRFC2813インターネットリレーチャット: サーバプロトコル2000年4月
server communication, or to the server implementation. The messages which are introduced here are only used for server to server communication.
サーバコミュニケーション、サーバ実装 ここで紹介されるメッセージはサーバにサーバコミュニケーションに使用されるだけです。
4.1 Connection Registration
4.1 接続登録
The commands described here are used to register a connection with another IRC server.
ここで説明されたコマンドは、別のIRCサーバとの関係を登録するのに使用されます。
4.1.1 Password message
4.1.1 パスワードメッセージ
Command: PASS
Parameters: <password> <version> <flags> [<options>]
コマンド: パラメタを通過してください: <パスワード><バージョン><は>に旗を揚げさせます。[<オプション>]
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(1)PASSだけが、SHALLが接続から受け入れられると命令します。
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(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です。 残っているOPTIONALキャラクタは、実装に依存していて、ソフトウェアバージョン番号について説明するべきです。
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の(100)キャラクタです。 「それはキャラクタによって切り離された2つのサブストリングで構成されます」|「(%x7C)。」 存在しているなら、最初のサブストリングは実装の名前であるに違いありません。 参照実装(セクション8と、「現在のサポートと有用性」を見る)はストリング"IRC"を使用します。 異なった実装(識別子を必要とする)が書かれるなら、その識別子はRFCの公表を通して登録されるべきです。 2番目のサブストリングは実装に依存しています。 「しかし、両方のサブストリングはOPTIONAL、キャラクタです」|「REQUIREDです」 「キャラクタ」|「どちらのサブストリングにも現れてはいけません。」
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」を使用する)と、乱用保護旗である、(キャラクタを使用すること。
Kalt Informational [Page 8] RFC 2813 Internet Relay Chat: Server Protocol April 2000
Kaltの情報[8ページ]のRFC2813インターネットリレーチャット: サーバプロトコル2000年4月
"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
間違え、_NEEDMOREPARAMSが間違える、_ALREADYREGISTRED
Example:
例:
PASS moresecretpassword 0210010000 IRC|aBgH$ Z
PASS moresecretpassword0210010000IRC|aBgH$Z
4.1.2 Server message
4.1.2 サーバメッセージ
Command: SERVER
Parameters: <servername> <hopcount> <token> <info>
コマンド: サーバパラメタ: <servername><hopcount><トークン><インフォメーション>。
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コマンドは、新しいサーバを登録するのに使用されます。新しい接続は、サーバを同輩に自己紹介します。 また、このメッセージも全体のネットの上にサーバデータを通過するのにおいて使用されています。 新しいサーバがネットに関連づけられるとき、全体のネットワークにそれの情報をbroadcastedしなければなりません。
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.
<hopcount>は、それぞれのサーバがどれくらいほど遠いかの何らかの内部の情報をすべてのサーバに教えるのに使用されます。 地元の同輩には、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.
<トークン>パラメタは識別子としてサーバによって使用される符号のない数です。 この識別子は次に、ニックとSERVICEメッセージのサーバがサーバの間で送った参照に使用されます。 サーバトークンだけが、二地点間じっと見る意味を使用されるようにして、その接続に、ユニークであるに違いありません。 それらはグローバルではありません。
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) 既存の接続のどちらかから別のサーバまでSERVERメッセージを受け入れるだけでよいです、その場合、SERVERメッセージはそのサーバの後ろで新しいサーバを紹介しています。
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コマンドの領収書で発生するほとんどの誤りがあて先ホスト(目標SERVER)によって終えられる接続をもたらします。 そのようなイベントの厳しさのために、通常、エラー応答に数値よりむしろ「誤り」コマンドを使用させます。
Kalt Informational [Page 9] RFC 2813 Internet Relay Chat: Server Protocol April 2000
Kaltの情報[9ページ]のRFC2813インターネットリレーチャット: サーバプロトコル2000年4月
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.
SERVERメッセージが分析されて、既に知られているサーバを受信サーバに紹介するのを試みるなら、接続(そのメッセージは到着した)は閉店しなければなりません(正しい手順に従って)、サーバへの写しルートを形成してあって、IRC木の非循環の自然が壊れるので。 いくつかの状態で、既に知られているサーバが登録してある接続は代わりに閉店するかもしれません。 また、この種類の誤りが2番目の実行サーバ、プロトコルの中で修理できないで、人間の介入を通常必要とする問題の結果であるかもしれないことに注意されるべきです。 このタイプの問題が特に油断のならない、全く容易に一部結果として生じることができる間、2つのものの1つで隔離されるべきIRCネットワークでは、サーバはしたがって、2つの部品が結合するのを不可能にする各パーティションに接続しました。
Numeric Replies:
数値回答:
ERR_ALREADYREGISTRED
間違え、_ALREADYREGISTRED
Example:
例:
SERVER test.oulu.fi 1 1 :Experimental server ; New server
test.oulu.fi introducing itself and
attempting to register.
SERVER test.oulu.fi1 1:Experimentalサーバ。 自己紹介して、登録するのを試みる新しいサーバ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 SERVER csd.bu.edu5 34:BUセントラルServer。 サーバtolsun.oulu.fiは遠くの5つのホップであるcsd.bu.eduのための私たちのアップリンクです。 トークン、「新しいユーザかcsd.bu.eduに接続されたサービスを紹介するとき、34インチはtolsun.oulu.fiによって使用されるでしょう」。
4.1.3 Nick
4.1.3 ニック
Command: NICK
Parameters: <nickname> <hopcount> <username> <host> <servertoken>
<umode> <realname>
コマンド: パラメタに傷を付けてください: <あだ名><hopcount><ユーザ名><ホスト><servertoken><umode><realname>。
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.
ユーザ接続からニックメッセージのこのフォームを許容してはいけません。 しかしながら、ニック/USER組の代わりにIRCネットワークに加わる新しいユーザの他のサーバに通知するのにそれを使用しなければなりません。
This message is really the combination of three distinct messages: NICK, USER and MODE [IRC-CLIENT].
このメッセージは本当に3つの異なったメッセージの組み合わせです: ニック、ユーザ、およびモード[IRC-クライアント]。
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.
<hopcount>パラメタはサーバによって使用されます。ユーザがホームサーバからどれくらい遠いかを示して、市内接続は0のhopcountを持っています。 hopcount値はそれぞれの通っているサーバによって増加されます。
Kalt Informational [Page 10] RFC 2813 Internet Relay Chat: Server Protocol April 2000
Kaltの情報[10ページ]のRFC2813インターネットリレーチャット: サーバプロトコル2000年4月
The <servertoken> parameter replaces the <servername> parameter of the USER (See section 4.1.2 for more information on server tokens).
<servertoken>パラメタはUSERの<servername>パラメタを置き換えます(サーバトークンの詳しい情報に関してセクション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).
ニックsyrk5kalt millennium.stealth.net34+i:Christophe Kalt。 "syrk"というあだ名をもっている新しいユーザ("kalt"というユーザ名)は「34インチ(前の例に従った"csd.bu.edu")」ホスト"millennium.stealth.net"からサーバまで接続しました。
: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 ; 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
4.1.4 Service message
4.1.4 Service message
Command: SERVICE
Parameters: <servicename> <servertoken> <distribution> <type>
<hopcount> <info>
Command: SERVICE Parameters: <servicename> <servertoken> <distribution> <type> <hopcount> <info>
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.
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.
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).
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).
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.
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.
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 <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.
The <type> parameter is currently reserved for future usage.
Kalt Informational [Page 11] RFC 2813 Internet Relay Chat: Server Protocol April 2000
Kalt Informational [Page 11] RFC 2813 Internet Relay Chat: Server Protocol April 2000
Numeric Replies:
Numeric Replies:
ERR_ALREADYREGISTRED ERR_NEEDMOREPARAMS
ERR_ERRONEUSNICKNAME
RPL_YOURESERVICE RPL_YOURHOST
RPL_MYINFO
ERR_ALREADYREGISTRED ERR_NEEDMOREPARAMS ERR_ERRONEUSNICKNAME RPL_YOURESERVICE RPL_YOURHOST RPL_MYINFO
Example:
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".
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".
4.1.5 Quit
4.1.5 Quit
Command: QUIT
Parameters: [<Quit Message>]
Command: QUIT Parameters: [<Quit Message>]
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.
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.
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:
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:
<Quit Message> = ":" servername SPACE servername
<Quit Message> = ":" servername SPACE servername
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.
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.
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.
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.
Numeric Replies:
Numeric Replies:
None.
None.
Kalt Informational [Page 12] RFC 2813 Internet Relay Chat: Server Protocol April 2000
Kalt Informational [Page 12] RFC 2813 Internet Relay Chat: Server Protocol April 2000
Examples:
Examples:
:WiZ QUIT :Gone to have lunch ; Preferred message format.
:WiZ QUIT :Gone to have lunch ; Preferred message format.
4.1.6 Server quit message
4.1.6 Server quit message
Command: SQUIT
Parameters: <server> <comment>
Command: SQUIT Parameters: <server> <comment>
The SQUIT message has two distinct uses.
The SQUIT message has two distinct uses.
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.
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.
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.
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.
The <comment> is filled in by servers which SHOULD place an error or similar message here.
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.
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.
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.
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.
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.
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
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
Kalt Informational [Page 13] RFC 2813 Internet Relay Chat: Server Protocol April 2000
Kalt Informational [Page 13] RFC 2813 Internet Relay Chat: Server Protocol April 2000
section 5.7 (Tracking recently used nicknames) for more information on this procedure.
section 5.7 (Tracking recently used nicknames) for more information on this procedure.
Numeric replies:
Numeric replies:
ERR_NOPRIVILEGES ERR_NOSUCHSERVER
ERR_NEEDMOREPARAMS
ERR_NOPRIVILEGES ERR_NOSUCHSERVER ERR_NEEDMOREPARAMS
Example:
Example:
SQUIT tolsun.oulu.fi :Bad Link ? ; the server link tolson.oulu.fi
has been terminated because of "Bad
Link".
SQUIT tolsun.oulu.fi :Bad Link ? ; the server link tolson.oulu.fi has been terminated because of "Bad Link".
: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 :Server out of control ; message from Trillian to disconnect "cm22.eng.umd.edu" from the net because "Server out of control".
4.2 Channel operations
4.2 Channel operations
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.
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.
4.2.1 Join message
4.2.1 Join message
Command: JOIN
Parameters: <channel>[ %x7 <modes> ]
*( "," <channel>[ %x7 <modes> ] )
Command: JOIN Parameters: <channel>[ %x7 <modes> ] *( "," <channel>[ %x7 <modes> ] )
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.
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.
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.
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.
Kalt Informational [Page 14] RFC 2813 Internet Relay Chat: Server Protocol April 2000
Kalt Informational [Page 14] RFC 2813 Internet Relay Chat: Server Protocol April 2000
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.
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.
Numeric Replies:
Numeric Replies:
ERR_NEEDMOREPARAMS ERR_BANNEDFROMCHAN
ERR_INVITEONLYCHAN ERR_BADCHANNELKEY
ERR_CHANNELISFULL ERR_BADCHANMASK
ERR_NOSUCHCHANNEL ERR_TOOMANYCHANNELS
ERR_TOOMANYTARGETS ERR_UNAVAILRESOURCE
RPL_TOPIC
ERR_NEEDMOREPARAMS ERR_BANNEDFROMCHAN ERR_INVITEONLYCHAN ERR_BADCHANNELKEY ERR_CHANNELISFULL ERR_BADCHANMASK ERR_NOSUCHCHANNEL ERR_TOOMANYCHANNELS ERR_TOOMANYTARGETS ERR_UNAVAILRESOURCE RPL_TOPIC
Examples:
Examples:
:WiZ JOIN #Twilight_zone ; JOIN message from WiZ
:WiZ JOIN #Twilight_zone ; JOIN message from WiZ
4.2.2 Njoin message
4.2.2 Njoin message
Command: NJOIN
Parameters: <channel> [ "@@" / "@" ] [ "+" ] <nickname>
*( "," [ "@@" / "@" ] [ "+" ] <nickname> )
Command: NJOIN Parameters: <channel> [ "@@" / "@" ] [ "+" ] <nickname> *( "," [ "@@" / "@" ] [ "+" ] <nickname> )
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.
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.
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.
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.
Numeric Replies:
Numeric Replies:
ERR_NEEDMOREPARAMS ERR_NOSUCHCHANNEL
ERR_ALREADYREGISTRED
ERR_NEEDMOREPARAMS ERR_NOSUCHCHANNEL ERR_ALREADYREGISTRED
Examples:
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 :@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.
Kalt Informational [Page 15] RFC 2813 Internet Relay Chat: Server Protocol April 2000
Kalt Informational [Page 15] RFC 2813 Internet Relay Chat: Server Protocol April 2000
4.2.3 Mode message
4.2.3 Mode message
The MODE message is a dual-purpose command in IRC. It allows both usernames and channels to have their mode changed.
The MODE message is a dual-purpose command in IRC. It allows both usernames and channels to have their mode changed.
When parsing MODE messages, it is RECOMMENDED that the entire message be parsed first, and then the changes which resulted passed on.
When parsing MODE messages, it is RECOMMENDED that the entire message be parsed first, and then the changes which resulted passed on.
It is REQUIRED that servers are able to change channel modes so that "channel creator" and "channel operators" may be created.
It is REQUIRED that servers are able to change channel modes so that "channel creator" and "channel operators" may be created.
5. Implementation details
5. Implementation details
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:
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:
* recognition that any LF or CR anywhere in a message marks
the end of that message (instead of requiring CR-LF);
* 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.
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.
5.1 Connection 'Liveness'
5.1 Connection 'Liveness'
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.
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.
If a connection doesn't respond in time, its connection is closed using the appropriate procedures.
If a connection doesn't respond in time, its connection is closed using the appropriate procedures.
5.2 Accepting a client to server connection
5.2 Accepting a client to server connection
5.2.1 Users
5.2.1 Users
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.
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.
Kalt Informational [Page 16] RFC 2813 Internet Relay Chat: Server Protocol April 2000
Kalt Informational [Page 16] RFC 2813 Internet Relay Chat: Server Protocol April 2000
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).
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).
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.
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.
5.2.2 Services
5.2.2 Services
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.
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.
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).
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).
5.3 Establishing a server-server connection.
5.3 Establishing a server-server connection.
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.
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.
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.
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.
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.
5.3.1 Link options
5.3.1 Link options
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).
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).
Kalt Informational [Page 17] RFC 2813 Internet Relay Chat: Server Protocol April 2000
Kalt Informational [Page 17] RFC 2813 Internet Relay Chat: Server Protocol April 2000
5.3.1.1 Compressed server to server links
5.3.1.1 Compressed server to server links
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.
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.
The data format used for the compression is described by RFC 1950 [ZLIB], RFC 1951 [DEFLATE] and RFC 1952 [GZIP].
The data format used for the compression is described by RFC 1950 [ZLIB], RFC 1951 [DEFLATE] and RFC 1952 [GZIP].
5.3.1.2 Anti abuse protections
5.3.1.2 Anti abuse protections
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.
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.
Commonly found protections are described in sections 5.7 (Tracking recently used nicknames) and 5.8 (Flood control of clients).
Commonly found protections are described in sections 5.7 (Tracking recently used nicknames) and 5.8 (Flood control of clients).
5.3.2 State information exchange when connecting
5.3.2 State information exchange when connecting
The order of state information being exchanged between servers is essential. The REQUIRED order is as follows:
The order of state information being exchanged between servers is essential. The REQUIRED order is as follows:
* all known servers;
* all known servers;
* all known client information;
* all known client information;
* all known channel 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.
Information regarding servers is sent via extra SERVER messages, client information with NICK and SERVICE messages and channels with NJOIN/MODE messages.
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.
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.
Kalt Informational [Page 18] RFC 2813 Internet Relay Chat: Server Protocol April 2000
Kalt Informational [Page 18] RFC 2813 Internet Relay Chat: Server Protocol April 2000
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.
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.
5.4 Terminating server-client connections
5.4 Terminating server-client connections
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.
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.
5.5 Terminating server-server connections
5.5 Terminating server-server connections
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)).
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)).
5.6 Tracking nickname changes
5.6 Tracking nickname changes
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:
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:
* KILL (the nick being disconnected)
* KILL (the nick being disconnected)
* MODE (+/- o,v on channels)
* MODE (+/- o,v on channels)
* KICK (the nick being removed from channel)
* KICK (the nick being removed from channel)
No other commands need to check nick changes.
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.
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.
Kalt Informational [Page 19] RFC 2813 Internet Relay Chat: Server Protocol April 2000
Kalt Informational [Page 19] RFC 2813 Internet Relay Chat: Server Protocol April 2000
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).
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).
5.7 Tracking recently used nicknames
5.7 Tracking recently used nicknames
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.
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.
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.
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.
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.
5.8 Flood control of clients
5.8 Flood control of clients
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:
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:
* check to see if client's `message timer' is less than current time
(set to be equal if it is);
* 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;
* 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;
* 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;
* additional penalties MAY be used for specific commands which
generate a lot of traffic across the network.
* 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.
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.
Kalt Informational [Page 20] RFC 2813 Internet Relay Chat: Server Protocol April 2000
Kalt Informational [Page 20] RFC 2813 Internet Relay Chat: Server Protocol April 2000
5.9 Non-blocking lookups
5.9 Non-blocking lookups
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.
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.
5.9.1 Hostname (DNS) lookups
5.9.1 Hostname (DNS) lookups
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.
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.
5.9.2 Username (Ident) lookups
5.9.2 Username (Ident) lookups
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.
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.
6. Current problems
6. Current problems
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.
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.
6.1 Scalability
6.1 Scalability
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.
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.
Kalt Informational [Page 21] RFC 2813 Internet Relay Chat: Server Protocol April 2000
Kalt Informational [Page 21] RFC 2813 Internet Relay Chat: Server Protocol April 2000
6.2 Labels
6.2 Labels
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.
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.
6.2.1 Nicknames
6.2.1 Nicknames
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を見る)の使用でともに取り除くでしょう。
6.2.2 Channels
6.2.2 チャンネル
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.
このプロトコルは非常にチャンネル衝突の対象でありそうにない「安全なチャンネル」を定義します。 他のチャンネル種別は後方の互換性のために保たれます。
6.2.3 Servers
6.2.3 サーバ
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.
サーバの数は通常ユーザとチャンネルの数に比例して少ないのですが、現在彼らもグローバルに知られるべきREQUIREDです、それぞれ、別々に、または、マスクの後ろに隠されます。
6.3 Algorithms
6.3のアルゴリズム
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.
サーバコードの中では、チャンネルをチェックなどなどの2つのアルゴリズムが記載する1セットのクライアントのN^を避けるのは所々、可能ではありません。
Kalt Informational [Page 22] RFC 2813 Internet Relay Chat: Server Protocol April 2000
Kaltの情報[22ページ]のRFC2813インターネットリレーチャット: サーバプロトコル2000年4月
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ネットワークを横断して、作用するメッセージのための時間がかかりながら、それの問題から起こります。 ユニークなラベルに変化さえすることによって、中断するチャンネル関連のコマンドに関する問題があります。
7. Security Considerations
7. セキュリティ問題
7.1 Authentication
7.1 認証
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:
サーバには、接続要求を認証する2つの手段しかありません: プレーンテキストパスワード、およびDNSルックアップ。 これらのメソッドは、弱く危険であるとして広く認識されていますが、彼らの組み合わせは過去に十分であると判明しました:
* 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 Operatorsの認証に適用されます。
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.
また、実需が全くより強い認証のための数年間なくて、また提供するどんな本当の取り組みも、安全にユーザを認証することを意味しないほうがよいのですが、現在のプロトコルが容易にクライアントが接続のときにサーバに提出できるという情報に基づくプラグイン外部認証メソッドにできることができるくらい提供することに注意されるべきです: あだ名、ユーザ名、パスワード。
7.2 Integrity
7.2 保全
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]のような)を使用できました。
Kalt Informational [Page 23] RFC 2813 Internet Relay Chat: Server Protocol April 2000
Kaltの情報[23ページ]のRFC2813インターネットリレーチャット: サーバプロトコル2000年4月
8. Current support and availability
8. 現在のサポートと有用性
Mailing lists for IRC related discussion:
General discussion: ircd-users@irc.org
Protocol development: ircd-dev@irc.org
IRCのためのメーリングリストは議論を関係づけました: 一般議論: ircd-users@irc.org プロトコル開発: 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
Newsgroup: alt.irc
9. Acknowledgements
9. 承認
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プロトコルを記録したRFC1459[IRC]からコピーされました。 また、それはレビューとコメントの多くのラウンドの利益を得ました。 以下の人々はこのドキュメントへの重要な貢献を特に、しました:
Matthew Green, Michael Neumayer, Volker Paulsen, Kurt Roeckx, Vesa Ruokonen, Magnus Tjernstrom, Stefan Zehl.
マシュー・グリーン、マイケル・ノイマイアー、ボルカー・ポールセン、カートRoeckx、Vesa Ruokonen、マグヌスTjernstrom、ステファンZehl。
10. References
10. 参照
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[KEYWORDS]ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[ABNF] クロッカー、D.、およびP.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、1997年11月のRFC2234。
[IRC] Oikarinen, J. and D. Reed, "Internet Relay Chat
Protocol", RFC 1459, May 1993.
[IRC] Oikarinen、J.、およびD.リード(「インターネットリレーチャットプロトコル」、RFC1459)は1993がそうするかもしれません。
[IRC-ARCH] Kalt, C., "Internet Relay Chat: Architecture", RFC 2810,
April 2000.
[IRC-アーチ]Kalt、C.、「インターネットリレーチャット:」 「アーキテクチャ」、RFC2810、2000年4月。
[IRC-CLIENT] Kalt, C., "Internet Relay Chat: Client Protocol", RFC
2812, April 2000.
[IRC-クライアント]Kalt、C.、「インターネットリレーチャット:」 「クライアントプロトコル」、RFC2812、2000年4月。
[IRC-CHAN] Kalt, C., "Internet Relay Chat: Channel Management", RFC
2811, April 2000.
[IRC-チェン]Kalt、C.、「インターネットリレーチャット:」 「チャンネル管理」、RFC2811、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。 ゲイル、「ZLIB Compressed Data Format Specification、バージョン3.3インチ、RFC1950、1996インチ年5月。
Kalt Informational [Page 24] RFC 2813 Internet Relay Chat: Server Protocol April 2000
Kaltの情報[24ページ]のRFC2813インターネットリレーチャット: サーバプロトコル2000年4月
[DEFLATE] Deutsch, P., "DEFLATE Compressed Data Format
Specification version 1.3", RFC 1951, May 1996.
ドイツ語、[DEFLATE]P.、「DEFLATE Compressed Data Format Specification、バージョン1.3インチ、RFC1951、1996インチ年5月。
[GZIP] Deutsch, P., "GZIP file format specification version
4.3", RFC 1952, May 1996.
ドイツ語、P.、[GZIP]「GZIPは1996年5月に書式仕様バージョン4.3インチ、RFC1952をファイルします」。
[IDENT] St. Johns, M., "The Identification Protocol", RFC 1413,
February 1993.
[IDENT] 聖ジョーンズ、M.、「識別プロトコル」、RFC1413、1993年2月。
[TLS] Dierks, T. and C. Allen, "The TLS Protocol", RFC 2246,
January 1999.
[TLS]DierksとT.とC.アレン、「TLSプロトコル」、1999年1月のRFC2246。
11. Author's Address
11. 作者のアドレス
Christophe Kalt 99 Teaneck Rd, Apt #117 Ridgefield Park, NJ 07660 USA
クリストフKalt99ティーネック、しやすい#117リッジフィールド・パーク、ニュージャージー07660第米国
EMail: kalt@stealth.net
メール: kalt@stealth.net
Kalt Informational [Page 25] RFC 2813 Internet Relay Chat: Server Protocol April 2000
Kaltの情報[25ページ]のRFC2813インターネットリレーチャット: サーバプロトコル2000年4月
12. Full Copyright Statement
12. 完全な著作権宣言文
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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機能のための基金は現在、インターネット協会によって提供されます。
Kalt Informational [Page 26]
Kalt情報です。[26ページ]
一覧
スポンサーリンク
