RFC2810 日本語訳
2810 Internet Relay Chat: Architecture. C. Kalt. April 2000. (Format: TXT=19087 bytes) (Updates RFC1459) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group C. Kalt Request for Comments: 2810 April 2000 Updates: 1459 Category: Informational
Kaltがコメントのために要求するワーキンググループC.をネットワークでつないでください: 2810 2000年4月は以下をアップデートします。 1459年のカテゴリ: 情報
Internet Relay Chat: Architecture
インターネットリレーチャット: アーキテクチャ
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
要約
The IRC (Internet Relay Chat) protocol is for use with text based conferencing. It has been developed since 1989 when it was originally implemented as a mean for users on a BBS to chat amongst themselves.
IRC(インターネットRelay Chat)プロトコルはテキストがある使用が会議を基礎づけたからです。 BBSの上のユーザが自分たちの中でチャットするように元々平均として実装された1989年以来それは開発されています。
First formally documented in May 1993 by RFC 1459 [IRC], the protocol has kept evolving. This document is an update describing the architecture of the current IRC protocol and the role of its different components. Other documents describe in detail the protocol used between the various components defined here.
1993年5月にまず最初にRFC1459[IRC]によって正式に記録されていて、プロトコルは発展し続けました。 このドキュメントは現在のIRCプロトコルのアーキテクチャと異なったコンポーネントの役割について説明する最新版です。 他のドキュメントは詳細にここで定義された様々なコンポーネントの間で使用されるプロトコルについて説明します。
Table of Contents
目次
1. Introduction ............................................... 2 2. Components ................................................. 2 2.1 Servers ................................................ 2 2.2 Clients ................................................ 3 2.2.1 User Clients ...................................... 3 2.2.2 Service Clients ................................... 3 3. Architecture ............................................... 3 4. IRC Protocol Services ...................................... 4 4.1 Client Locator ......................................... 4 4.2 Message Relaying ....................................... 4 4.3 Channel Hosting And Management ......................... 4 5. IRC Concepts ............................................... 4 5.1 One-To-One Communication ............................... 5 5.2 One-To-Many ............................................ 5 5.2.1 To A Channel ...................................... 5 5.2.2 To A Host/Server Mask ............................. 6
1. 序論… 2 2. コンポーネント… 2 2.1のサーバ… 2 2.2人のクライアント… 3 2.2 .1 ユーザクライアント… 3 2.2 .2 クライアントにサービスを提供してください… 3 3. アーキテクチャ… 3 4. IRCはサービスについて議定書の中で述べます… 4 4.1クライアントロケータ… 4 4.2 メッセージリレー… 4 4.3 接待と経営者側はチャネルを開設します… 4 5. IRC概念… 4 5.1 一対一コミュニケーション… 5 多くへの5.2 1… 5 5.2 .1対1は向けられます… 5 5.2 .2 ホスト/サーバマスクに… 6
Kalt Informational [Page 1] RFC 2810 Internet Relay Chat: Architecture April 2000
Kaltの情報[1ページ]のRFC2810インターネットリレーチャット: アーキテクチャ2000年4月
5.2.3 To A List ......................................... 6 5.3 One-To-All ............................................. 6 5.3.1 Client-to-Client .................................. 6 5.3.2 Client-to-Server .................................. 7 5.3.3 Server-to-Server .................................. 7 6. Current Problems ........................................... 7 6.1 Scalability ............................................ 7 6.2 Reliability ............................................ 7 6.3 Network Congestion ..................................... 7 6.4 Privacy ................................................ 8 7. Security Considerations .................................... 8 8. Current Support And Availability ........................... 8 9. Acknowledgements ........................................... 8 10. References ................................................ 8 11. Author's Address .......................................... 9 12. Full Copyright Statement .................................. 10
5.2.3 Aに、記載してください… 6 すべてへの5.3 1… 6 5.3 .1のクライアントからクライアント… 6 5.3 .2のクライアントからサーバ… 7 5.3 .3のサーバからサーバ… 7 6. 現在の問題… 7 6.1スケーラビリティ… 7 6.2の信頼性… 7 6.3 混雑をネットワークでつないでください… 7 6.4プライバシー… 8 7. セキュリティ問題… 8 8. 現在のサポートと有用性… 8 9. 承認… 8 10. 参照… 8 11. 作者のアドレス… 9 12. 完全な著作権宣言文… 10
1. Introduction
1. 序論
The IRC (Internet Relay Chat) protocol has been designed over a number of years for use with text based conferencing. This document describes its current architecture.
IRC(インターネットRelay Chat)プロトコルは使用のために何年間もにわたってもテキストに基づいている会議で設計されています。 このドキュメントは現在のアーキテクチャについて説明します。
The IRC Protocol is based on the client-server model, and is well suited to running on many machines in a distributed fashion. A typical setup involves a single process (the server) forming a central point for clients (or other servers) to connect to, performing the required message delivery/multiplexing and other functions.
IRCプロトコルは、クライアント・サーバモデルに基づいていて、分配されたファッションで多くのマシンで動くのによく適しています。 典型的なセットアップはクライアント(または、他のサーバ)が接続する主要なポイントを形成しながら、単一のプロセス(サーバ)を伴います、必要なメッセージ配送/マルチプレクシングと他の機能を実行して。
This distributed model, which requires each server to have a copy of the global state information, is still the most flagrant problem of the protocol as it is a serious handicap, which limits the maximum size a network can reach. If the existing networks have been able to keep growing at an incredible pace, we must thank hardware manufacturers for giving us ever more powerful systems.
これはモデルを分配しました。(モデルは、各サーバにはグローバルな州の情報のコピーがあるのが必要であり、それでも、それが重大な障害であるのでプロトコルの最も極悪の問題であり、ネットワークが達することができる最大サイズを制限します)。 既存のネットワークが信じられないペースで成長し続けたことができるなら、私たちは、より強力なシステムを私たちに与えて頂いて、ハードウェアメーカーに感謝しなければなりません。
2. Components
2. コンポーネント
The following paragraphs define the basic components of the IRC protocol.
以下のパラグラフはIRCプロトコルの基本的な成分を定義します。
2.1 Servers
2.1 サーバ
The server forms the backbone of IRC as it is the only component of the protocol which is able to link all the other components together: it provides a point to which clients may connect to talk to
サーバは他のすべてのコンポーネントを結びつけるのが、プロトコルの唯一のできる成分であるので、IRCのバックボーンを形成します: それはクライアントが接続するかもしれないポイントを話す提供します。
Kalt Informational [Page 2] RFC 2810 Internet Relay Chat: Architecture April 2000
Kaltの情報[2ページ]のRFC2810インターネットリレーチャット: アーキテクチャ2000年4月
each other [IRC-CLIENT], and a point for other servers to connect to [IRC-SERVER]. The server is also responsible for providing the basic services defined by the IRC protocol.
他のサーバが[IRC-SERVER]に接する互い[IRC-CLIENT]、およびポイント。 また、サーバもIRCプロトコルによって定義された基本サービスを提供するのに原因となります。
2.2 Clients
2.2 クライアント
A client is anything connecting to a server that is not another server. There are two types of clients which both serve a different purpose.
クライアントは別のサーバでないサーバに接続する何かです。両方が異なる役割をサービスするクライアントの2つのタイプがあります。
2.2.1 User Clients
2.2.1 ユーザクライアント
User clients are generally programs providing a text based interface that is used to communicate interactively via IRC. This particular type of clients is often referred as "users".
テキストがIRCを通ってインタラクティブに交信するのに使用されるインタフェースを基礎づけたなら、一般に、ユーザクライアントはプログラムです。 この特定のタイプのクライアントは「ユーザ」としてしばしば参照されます。
2.2.2 Service Clients
2.2.2 サービスクライアント
Unlike users, service clients are not intended to be used manually nor for talking. They have a more limited access to the chat functions of the protocol, while optionally having access to more private data from the servers.
ユーザと異なって、手動と話すのにサービスクライアントが使用されることを意図しません。 彼らは任意にサーバからの、より個人的なデータに近づく手段を持つ間、プロトコルのチャット機能により限られたアクセスを持っています。
Services are typically automatons used to provide some kind of service (not necessarily related to IRC itself) to users. An example is a service collecting statistics about the origin of users connected on the IRC network.
通常、サービスはある種のサービスをユーザに提供するのにおいて(必ず、IRC自身に関連するというわけではありません)中古のオートマトンです。 例はIRCネットワークで接されたユーザの生まれに関する統計を集めるサービスです。
3. Architecture
3. アーキテクチャ
An IRC network is defined by a group of servers connected to each other. A single server forms the simplest IRC network.
IRCネットワークは互いに接されたサーバのグループによって定義されます。 ただ一つのサーバは最も簡単なIRCネットワークを形成します。
The only network configuration allowed for IRC servers is that of a spanning tree where each server acts as a central node for the rest of the network it sees.
IRCサーバのために許容された唯一のネットワーク・コンフィギュレーションは各サーバがネットワークの残りのための主要なノードとして機能するスパニングツリーでは、見るということです。
1--\ A D---4 2--/ \ / B----C / \ 3 E
1 --\A、D---4 2--/\/B----3C/円のE
Servers: A, B, C, D, E Clients: 1, 2, 3, 4
サーバ: A、B、C、D、Eクライアント: 1, 2, 3, 4
[ Fig. 1. Sample small IRC network ]
[小さいIRCがネットワークでつなぐ図1個のサンプル]
Kalt Informational [Page 3] RFC 2810 Internet Relay Chat: Architecture April 2000
Kaltの情報[3ページ]のRFC2810インターネットリレーチャット: アーキテクチャ2000年4月
The IRC protocol provides no mean for two clients to directly communicate. All communication between clients is relayed by the server(s).
IRCプロトコルは、直接交信するために2人のクライアントに備えます。 クライアントのすべてのコミュニケーションがサーバによってリレーされます。
4. IRC Protocol Services
4. IRCプロトコルサービス
This section describes the services offered by the IRC protocol. The combination of these services allow real-time conferencing.
このセクションはIRCプロトコルによって提供されたサービスについて説明します。 これらのサービスの組み合わせはリアルタイムの会議を許容します。
4.1 Client Locator
4.1 クライアントロケータ
To be able to exchange messages, two clients must be able to locate each other.
メッセージ、2人のクライアントを交換できるのは互いの場所を見つけることができなければなりません。
Upon connecting to a server, a client registers using a label which is then used by other servers and clients to know where the client is located. Servers are responsible for keeping track of all the labels being used.
サーバに接続すると、クライアントは、次にクライアントがどこに位置しているかを知るのに他のサーバとクライアントが使用されるラベルを使用することで登録します。 サーバは使用されるすべてのラベルの動向をおさえるのに原因となります。
4.2 Message Relaying
4.2 メッセージリレー
The IRC protocol provides no mean for two clients to directly communicate. All communication between clients is relayed by the server(s).
IRCプロトコルは、直接交信するために2人のクライアントに備えます。 クライアントのすべてのコミュニケーションがサーバによってリレーされます。
4.3 Channel Hosting And Management
4.3 チャンネル接待と管理
A channel is a named group of one or more users which will all receive messages addressed to that channel. A channel is characterized by its name and current members, it also has a set of properties which can be manipulated by (some of) its members.
チャンネルはそのチャンネルに扱われたメッセージをすべて受け取る1人以上のユーザの命名されたグループです。 チャンネルが名前と現在のメンバーによって描写されて、また、それには操作できる1セットの特性がある、(いくつか、)、そのメンバー。
Channels provide a mean for a message to be sent to several clients. Servers host channels, providing the necessary message multiplexing. Servers are also responsible for managing channels by keeping track of the channel members. The exact role of servers is defined in "Internet Relay Chat: Channel Management" [IRC-CHAN].
チャンネルは数人のクライアントに送られるべきメッセージに平均を供給します。 必要なメッセージマルチプレクシングを提供して、サーバはチャンネルをホスティングします。 また、サーバもチャンネルメンバーの動向をおさえることによってチャンネルを管理するのに原因となります。 サーバの正確な役割は中で定義されて、「インターネットはチャットをリレーする」ということです。 「チャンネル管理。」[IRC-チェン]
5. IRC Concepts
5. IRC概念
This section is devoted to describing the actual concepts behind the organization of the IRC protocol and how different classes of messages are delivered.
このセクションはIRCプロトコルと異なったクラスに関するメッセージがどう提供されるかに関する組織の後ろで実際の概念について説明するのにささげられます。
Kalt Informational [Page 4] RFC 2810 Internet Relay Chat: Architecture April 2000
Kaltの情報[4ページ]のRFC2810インターネットリレーチャット: アーキテクチャ2000年4月
5.1 One-To-One Communication
5.1 一対一コミュニケーション
Communication on a one-to-one basis is usually performed by clients, since most server-server traffic is not a result of servers talking only to each other. To provide a means for clients to talk to each other, it is REQUIRED that all servers be able to send a message in exactly one direction along the spanning tree in order to reach any client. Thus the path of a message being delivered is the shortest path between any two points on the spanning tree.
通常、1〜1個のベースに関するコミュニケーションはクライアントによって実行されます、ほとんどのサーバサーバートラフィックがサーバが互いだけに話すという結果でないので。 クライアントが互いに話す手段を提供するために、すべてのサーバがどんなクライアントにも届くようにスパニングツリーに沿ってちょうど一方向にメッセージを送ることができるのは、REQUIREDです。 したがって、提供されるメッセージの経路はスパニングツリーの任意な2点の間の最短パスです。
The following examples all refer to Figure 1 above.
以下の例はすべて、上の図1を参照します。
Example 1: A message between clients 1 and 2 is only seen by server A, which sends it straight to client 2.
例1: クライアント1と2の間のメッセージはサーバAによって見られるだけです。(それは、まっすぐなクライアント2にそれを送ります)。
Example 2: A message between clients 1 and 3 is seen by servers A & B, and client 3. No other clients or servers are allowed see the message.
例2: クライアント1と3の間のメッセージはサーバA&B、およびクライアント3によって見られます。 クライアントかサーバが許容されているどんな他のものもメッセージを見ません。
Example 3: A message between clients 2 and 4 is seen by servers A, B, C & D and client 4 only.
例3: クライアント2と4の間のメッセージはサーバA、B、C&D、およびクライアント4だけによって見られます。
5.2 One-To-Many
5.2 多くへの1
The main goal of IRC is to provide a forum which allows easy and efficient conferencing (one to many conversations). IRC offers several means to achieve this, each serving its own purpose.
IRCの第一目的は簡単で効率的な会議(多くの会話への1)を許容するフォーラムを提供することになっています。 それぞれそれ自身の目的に役立って、IRCはこれを達成するいくつかの手段を提供します。
5.2.1 To A Channel
5.2.1 チャンネルに
In IRC the channel has a role equivalent to that of the multicast group; their existence is dynamic and the actual conversation carried out on a channel MUST only be sent to servers which are supporting users on a given channel. Moreover, the message SHALL only be sent once to every local link as each server is responsible to fan the original message to ensure that it will reach all the recipients.
IRCでは、チャンネルは役割をマルチキャストグループのものに同等にします。 それらの存在はダイナミックです、そして、与えられたチャンネルの上にユーザをサポートしているサーバにチャンネルで行われた実際の会話を送るだけでよいです。 SHALLを通信させてください。そのうえ、それぞれのサーバがすべての受取人に届くのを保証するオリジナルのメッセージを扇ぐのにおいて原因となるので、一度単にあらゆる地方のリンクに送ってください。
The following examples all refer to Figure 2.
以下の例はすべて、図2を参照します。
Example 4: Any channel with 1 client in it. Messages to the channel go to the server and then nowhere else.
例4: 1人のクライアントがそれにいるどんなチャンネル。 チャンネルへのメッセージはほかにそしてどこにもサーバに行きません。
Example 5: 2 clients in a channel. All messages traverse a path as if they were private messages between the two clients outside a channel.
例5: チャンネルによる2人のクライアント。 すべてのメッセージがまるでそれらがチャンネルの外における2人のクライアントの間のプライベート・メッセージであるかのように経路を横断します。
Kalt Informational [Page 5] RFC 2810 Internet Relay Chat: Architecture April 2000
Kaltの情報[5ページ]のRFC2810インターネットリレーチャット: アーキテクチャ2000年4月
Example 6: Clients 1, 2 and 3 in a channel. All messages to the channel are sent to all clients and only those servers which must be traversed by the message if it were a private message to a single client. If client 1 sends a message, it goes back to client 2 and then via server B to client 3.
例6: チャンネルによるクライアント1、2、および3。 すべてのクライアントとそれが独身のクライアントへのプライベート・メッセージであるならメッセージで横断しなければならないそれらのサーバだけにチャンネルへのすべてのメッセージを送ります。 クライアント1がメッセージを送るなら、それはクライアント2とそして、サーバBでクライアント3に戻ります。
5.2.2 To A Host/Server Mask
5.2.2 ホスト/サーバマスクに
To provide with some mechanism to send messages to a large body of related users, host and server mask messages are available. These messages are sent to users whose host or server information match that of the mask. The messages are only sent to locations where users are, in a fashion similar to that of channels.
発信するために何らかのメカニズムに供給するために、関連するユーザ、ホスト、およびサーバマスクメッセージの大きいボディーへのメッセージは利用可能です。 ホストかサーバ情報がマスクのものに合っているユーザにこれらのメッセージを送ります。 チャンネルのものと同様のファッションでユーザがそうである位置にメッセージを送るだけです。
5.2.3 To A List
5.2.3 リストに
The least efficient style of one-to-many conversation is through clients talking to a 'list' of targets (client, channel, mask). How this is done is almost self explanatory: the client gives a list of destinations to which the message is to be delivered and the server breaks it up and dispatches a separate copy of the message to each given destination.
目標(クライアント、チャンネル、マスク)の'リスト'と話しているクライアントを通して多くへの1つの会話の最も効率的でないスタイルがあります。 これがどう完了しているかは、ほとんど自明です: クライアントはメッセージが提供されることであり、サーバがそれを壊れさせる送付先と発信のリストにそれぞれの与えられた目的地へのメッセージの別々のコピーを与えます。
This is not as efficient as using a channel since the destination list MAY be broken up and the dispatch sent without checking to make sure duplicates aren't sent down each path.
これは目的地リストが壊れたかもしれなくて、発信が写しが各経路の下側に送られないのを確実にするためにチェックしないで発信したのでチャンネルを使用するほど効率的ではありません。
5.3 One-To-All
5.3 すべてへの1
The one-to-all type of message is better described as a broadcast message, sent to all clients or servers or both. On a large network of users and servers, a single message can result in a lot of traffic being sent over the network in an effort to reach all of the desired destinations.
すべてへの1つのタイプに関するメッセージはすべてのクライアント、サーバまたは両方に送られた同報メッセージとして記述されているほうがよいです。 ユーザとサーバの大きいネットワークでは、ただ一つのメッセージは必要な目的地のすべてに達するように取り組みでネットワークの上に送られる多くのトラフィックをもたらすことができます。
For some class of messages, there is no option but to broadcast it to all servers so that the state information held by each server is consistent between servers.
何らかのクラスに関するメッセージのために、すべてのサーバにそれを放送するのを除いたオプションが全くないので、各サーバによって保持された州の情報はサーバの間で一貫しています。
5.3.1 Client-to-Client
5.3.1 クライアントからクライアント
There is no class of message which, from a single message, results in a message being sent to every other client.
ただ一つのメッセージからすべての他のクライアントに送られるメッセージをもたらすメッセージのクラスが全くありません。
Kalt Informational [Page 6] RFC 2810 Internet Relay Chat: Architecture April 2000
Kaltの情報[6ページ]のRFC2810インターネットリレーチャット: アーキテクチャ2000年4月
5.3.2 Client-to-Server
5.3.2 クライアントからサーバ
Most of the commands which result in a change of state information (such as channel membership, channel mode, user status, etc.) MUST be sent to all servers by default, and this distribution SHALL NOT be changed by the client.
州の情報(チャンネル会員資格、チャンネルモード、使用者の地位などの)の変化をもたらすコマンドの大部分 デフォルトですべてのサーバに送らなければならない、この分配SHALL NOT、クライアントによって変えられてください。
5.3.3 Server-to-Server
5.3.3 サーバからサーバ
While most messages between servers are distributed to all 'other' servers, this is only required for any message that affects a user, channel or server. Since these are the basic items found in IRC, nearly all messages originating from a server are broadcast to all other connected servers.
サーバの間のほとんどのメッセージが'他'のすべてのサーバに分配されますが、これがユーザ、チャンネルまたはサーバに影響するどんなメッセージにも必要であるだけです。これらがIRCで見つけられた定番商品であるので、サーバから発するほとんどすべてのメッセージが他のすべての接続サーバに放送されます。
6. Current Problems
6. 現在の問題
There are a number of recognized problems with this protocol, this section only addresses the problems related to the architecture of the protocol.
このプロトコルに関する多くの認識された問題があって、このセクションはプロトコルのアーキテクチャに関連するその問題を訴えるだけです。
6.1 Scalability
6.1 スケーラビリティ
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, clients and channels and that information regarding them be updated as soon as it changes.
大きいアリーナで使用される場合このプロトコルが十分よく比例しないと広く認められます。 主な問題は変化するとすぐに、彼らのサーバが他のすべてのサーバに関して知っているすべて、クライアント、チャンネル、およびその情報をアップデートするという要件から来ます。
6.2 Reliability
6.2 信頼性
As the only network configuration allowed for IRC servers is that of a spanning tree, each link between two servers is an obvious and quite serious point of failure. This particular issue is addressed more in detail in "Internet Relay Chat: Server Protocol" [IRC- SERVER].
唯一のネットワークとして、IRCサーバのために許された構成はスパニングツリーでは、2つのサーバの間の各リンクが失敗の明白でかなり重大なポイントであるということです。 この特定の問題は中で、より詳細に扱われて、「インターネットはチャットをリレーする」ということです。 「サーバプロトコル。」[IRCサーバ]
6.3 Network Congestion
6.3 ネットワークの混雑
Another problem related to the scalability and reliability issues, as well as the spanning tree architecture, is that the protocol and architecture for IRC are extremely vulnerable to network congestions. This problem is endemic, and should be solved for the next generation: if congestion and high traffic volume cause a link between two servers to fail, not only this failure generates more network traffic, but the reconnection (eventually elsewhere) of two servers also generates more traffic.
スケーラビリティ、信頼性の問題、およびスパニングツリーアーキテクチャに関連する別の問題はIRCのためのプロトコルとアーキテクチャがネットワーク渋滞に非常に被害を受け易いということです。 この問題は、風土病であり、次世代のために解決されるべきです: 混雑と高い交通量が2つのサーバの間のリンクに失敗されるなら、この失敗だけが、より多くのネットワークがトラフィックであると生成しませんが、また、2つのサーバの再接続(結局ほかの場所)は、より多くのトラフィックを生成します。
Kalt Informational [Page 7] RFC 2810 Internet Relay Chat: Architecture April 2000
Kaltの情報[7ページ]のRFC2810インターネットリレーチャット: アーキテクチャ2000年4月
In an attempt to minimize the impact of these problems, it is strongly RECOMMENDED that servers do not automatically try to reconnect too fast, in order to avoid aggravating the situation.
これらの問題の影響を最小にする試みでは、強く、サーバがするRECOMMENDEDは自動的にあまりに速く再接続しようとしません、状況を悪化させるのを避けるためにことです。
6.4 Privacy
6.4 プライバシー
Besides not scaling well, the fact that servers need to know all information about other entities, the issue of privacy is also a concern. This is in particular true for channels, as the related information is quite a lot more revealing than whether a user is online or not.
さらに、よく比例していません、サーバが、他の実体のすべての情報を知る必要があるという事実、また、プライバシーの問題は関心です。 これはチャンネルのために本当に特定にあります、関連情報がユーザがオンラインであるかどうかよりかなり顕なロットであるので。
7. Security Considerations
7. セキュリティ問題
Asides from the privacy concerns mentioned in section 6.4 (Privacy), security is believed to be irrelevant to this document.
セクション6.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。
Kalt Informational [Page 8] RFC 2810 Internet Relay Chat: Architecture April 2000
Kaltの情報[8ページ]のRFC2810インターネットリレーチャット: アーキテクチャ2000年4月
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月。
[IRC] Oikarinen, J. and D. Reed, "Internet Relay Chat Protocol", RFC 1459, May 1993.
[IRC] Oikarinen、J.、およびD.リード(「インターネットリレーチャットプロトコル」、RFC1459)は1993がそうするかもしれません。
[IRC-CLIENT] Kalt, C., "Internet Relay Chat: Client Protocol", RFC 2812, April 2000.
[IRC-クライアント]Kalt、C.、「インターネットリレーチャット:」 「クライアントプロトコル」、RFC2812、2000年4月。
[IRC-SERVER] Kalt, C., "Internet Relay Chat: Server Protocol", RFC 2813, April 2000.
[IRC-サーバ]Kalt、C.、「インターネットリレーチャット:」 「サーバプロトコル」、RFC2813、2000年4月。
[IRC-CHAN] Kalt, C., "Internet Relay Chat: Channel Management", RFC 2811, April 2000.
[IRC-チェン]Kalt、C.、「インターネットリレーチャット:」 「チャンネル管理」、RFC2811、2000年4月。
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 9] RFC 2810 Internet Relay Chat: Architecture April 2000
Kaltの情報[9ページ]のRFC2810インターネットリレーチャット: アーキテクチャ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 10]
Kalt情報です。[10ページ]
一覧
スポンサーリンク