Network Working Group C. Kalt
Request for Comments: 2810 April 2000
Updates: 1459
Category: Informational
Internet Relay Chat: Architecture
Status of this Memo
このメモの位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
Abstract
抽象
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（インターネットリレーチャット）プロトコルは、テキストベースの会議で使用するためです。これは、もともとは、それ自体でチャットする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.
まず、正式にRFC 1459 [IRC]で1993年5月に文書化され、プロトコルが進化し続けています。この文書は、現在の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
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
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（インターネットリレーチャット）プロトコルは、テキストベースの会議で使用するために数年にわたり設計されています。この文書は、現在のアーキテクチャについて説明します。
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.
それは、ネットワークが到達できる最大サイズを制限する深刻なハンデ、あるとしてグローバルな状態情報のコピーを持っている各サーバーを必要とし、この分散モデルは、まだプロトコルの中で最も目に余る問題です。既存のネットワークが信じられないほどのペースで成長を維持することができたならば、私達は私達にこれまで以上に強力なシステムを与えるために、ハードウェアメーカーに感謝しなければなりません。
The following paragraphs define the basic components of the IRC protocol.
以下の段落では、IRCプロトコルの基本的な構成要素を定義します。
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 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のバックボーンを形成する：それは、クライアントが互いに[IRC-CLIENT]に話を接続し、点できるためにどのポイントを提供します他のサーバーは、[IRC-SERVER]に接続するため。また、サーバはIRCプロトコルで定義された基本的なサービスを提供する責任があります。
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種類があります。
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経由で対話的に通信するために使用されるテキストベースのインターフェースを提供するプログラムです。クライアントのこの特定のタイプは、多くの場合、「ユーザー」と呼ばれています。
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ネットワーク上に接続されたユーザの起源についての統計を収集するサービスです。
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
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 ]
[図1サンプル小IRCネットワーク]
The IRC protocol provides no mean for two clients to directly communicate. All communication between clients is relayed by the server(s).
IRCプロトコルは、2つのクライアントが直接通信するための平均値を提供しません。クライアント間のすべての通信は、サーバ（群）によって中継されます。
This section describes the services offered by the IRC protocol. The combination of these services allow real-time conferencing.
このセクションでは、IRCプロトコルによって提供されるサービスについて説明します。これらのサービスの組み合わせは、リアルタイムの会議を可能にします。
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.
サーバに接続すると、クライアントは、クライアントが配置されている場所を知っている他のサーバーとクライアントで使用されているラベルを使用して登録します。サーバーが使用されているすべてのラベルを追跡するための責任があります。
The IRC protocol provides no mean for two clients to directly communicate. All communication between clients is relayed by the server(s).
IRCプロトコルは、2つのクライアントが直接通信するための平均値を提供しません。クライアント間のすべての通信は、サーバ（群）によって中継されます。
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人以上のユーザの名前付きグループです。チャネルは、その名前と現在のメンバーによって特徴付けられ、それはまた（の一部）は、そのメンバーによって操作することができるプロパティのセットを有します。
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-CHAN]：サーバの正確な役割は、「チャネル管理インターネットリレーチャット」に定義されています。
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プロトコルの組織とどのように異なるメッセージのクラスが提供されているの背後にある実際の概念を説明に専念しています。
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での通信は通常、クライアントによって行われます。クライアントがお互いに話をするための手段を提供するために、すべてのサーバーがどのクライアントに到達するためにスパニングツリーに沿って正確に一つの方向にメッセージを送ることができることが必要です。こうして送達されるメッセージのパスは、スパニングツリー上の任意の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の間のメッセージのみストレートクライアント2に送信し、サーバA、で見られています。
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によってのみ見られます。
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は、これを達成するには、いくつかの手段、独自の目的を果たすそれぞれを提供しています。
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でチャンネルはマルチキャストグループとロール相当しています。彼らの存在は動的であり、チャネル上で行われ、実際の会話しか与えられたチャネル上でユーザーをサポートしているサーバーに送らなければなりません。各サーバーは、それがすべての受信者に到達することを保証するために、元のメッセージのファンに責任があるとして、また、メッセージは、すべてのローカルリンクに一度送付されなければなりません。
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つのクライアント間のプライベートメッセージであるかのようにすべてのメッセージがパスを通過します。
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がメッセージを送信した場合、それはクライアント3にサーバBを経由して戻って、クライアント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.
関連するユーザーの大きな体にメッセージを送信するためにいくつかの機構を提供するには、ホストおよびサーバ・マスクメッセージが用意されています。これらのメッセージは、そのホストまたはサーバの情報マスクのものと一致ユーザーに送信されます。メッセージは、ユーザーのみがチャネルのと同様のやり方で、ある場所に送られます。
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.
これは、宛先リストが分割されるかもしれないし、必ず複製を作るために確認せずに送信され、ディスパッチは、各パスを下されていないので、チャネルを使用してほど効率的ではありません。
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.
メッセージの一部のクラスでは、各サーバが保持している状態情報がサーバー間で一貫しているように、すべてのサーバにそれを放送するが、オプションはありません。
There is no class of message which, from a single message, results in a message being sent to every other client.
単一のメッセージから、他のすべてのクライアントに送信されたメッセージになり、メッセージのないクラスがありません。
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.
状態情報の変化をもたらすコマンドのほとんどは、（チャネル・メンバーシップ、チャネルモード、ユーザーの状態、など）は、デフォルトではすべてのサーバに送らなければなりませんし、この分布は、クライアントによって変更されないものとします。
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で見つかった基本的なアイテムなので、サーバーから発信ほぼすべてのメッセージは、他のすべての接続されたサーバーにブロードキャストされます。
There are a number of recognized problems with this protocol, this section only addresses the problems related to the architecture of the protocol.
このプロトコルとの認識多くの問題がありますが、このセクションでは、プロトコルのアーキテクチャに関連する問題に対処しています。
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.
広く、大舞台で使用された場合、このプロトコルは十分にスケールしないことが認識されています。主な問題は、すべてのサーバーが、それが変更されるとすぐに更新されることについての他のすべてのサーバー、クライアント、およびチャネルおよびそれらに関するその情報を知る必要性から来ています。
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-SERVER]：この特定の問題は、「サーバープロトコルインターネットリレーチャット」で詳しく取り上げています。
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つのサーバー間のリンクが失敗する可能性があれば、だけでなく、この失敗は、より多くのネットワークトラフィックを生成しますが、二つのサーバの再接続は、（最終的には他の場所）にも発生しますより多くのトラフィック。
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.
これらの問題の影響を最小化する試みで、強く、サーバが自動的に事態を悪化させないようにするためには、あまりにも速く再接続しようとしないことをお勧めします。
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.
うまくスケーリングないだけでなく、サーバが他のエンティティに関するすべての情報を知っておく必要があるという事実は、プライバシーの問題も懸念されます。関連情報は、ユーザーがオンラインかどうかよりもかなり多くの暴露のです、これは、チャンネルのために特に当てはまります。
Asides from the privacy concerns mentioned in section 6.4 (Privacy), security is believed to be irrelevant to this document.
6.4節（プライバシー）で述べたプライバシーの問題からAsidesは、セキュリティは、この文書には無関係であると考えられています。
Mailing lists for IRC related discussion:
General discussion: ircd-users@irc.org
Protocol development: ircd-dev@irc.org
Software implementations: ftp://ftp.irc.org/irc/server ftp://ftp.funet.fi/pub/unix/irc ftp://coombs.anu.edu.au/pub/irc
ソフトウェアの実装：ftp://ftp.irc.org/irc/server ftp://ftp.funet.fi/pub/unix/irc ftp://coombs.anu.edu.au/pub/irc
Newsgroup: alt.irc
ニュースグループ：alt.irc
Parts of this document were copied from the RFC 1459 [IRC] which first formally documented the IRC Protocol. It has also benefited from many rounds of review and comments. In particular, the following people have made significant contributions to this document:
この文書の部分は、第一正式IRCプロトコルを文書RFC 1459 [IRC]からコピーされました。また、レビューやコメントの多くのラウンドの恩恵を受けています。具体的には、以下の人々は、このドキュメントへの重要な貢献をしました。
Matthew Green, Michael Neumayer, Volker Paulsen, Kurt Roeckx, Vesa Ruokonen, Magnus Tjernstrom, Stefan Zehl.
マシュー・グリーン、ミヒャエル・ノイマイアー、フォルカー・ポールセン、クルトRoeckx、のVesa Ruokonen、マグナスTjernström、ステファンZehl。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[キーワード]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[IRC] Oikarinen, J. and D. Reed, "Internet Relay Chat Protocol", RFC 1459, May 1993.
[IRC] Oikarinen、J.とD.リード、 "インターネットリレーチャットプロトコル"、RFC 1459、1993年5月。
[IRC-CLIENT] Kalt, C., "Internet Relay Chat: Client Protocol", RFC 2812, April 2000.
[IRC-CLIENT] Kalt、C.、 "インターネットリレーチャット：クライアントプロトコル"、RFC 2812、2000年4月。
[IRC-SERVER] Kalt, C., "Internet Relay Chat: Server Protocol", RFC 2813, April 2000.
[IRC-SERVER] Kalt、C.、 "インターネットリレーチャット：サーバプロトコル"、RFC 2813、2000年4月。
[IRC-CHAN] Kalt, C., "Internet Relay Chat: Channel Management", RFC 2811, April 2000.
[IRC-CHAN] Kalt、C.、 "インターネットリレーチャット：チャンネル管理"、RFC 2811、2000年4月。
Christophe Kalt 99 Teaneck Rd, Apt #117 Ridgefield Park, NJ 07660 USA
クリストフKalt 99ティーネックRdを、アプト＃117リッジフィールドパーク、ニュージャージー州07660米国
EMail: kalt@stealth.net
メールアドレス：kalt@stealth.net
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。