RFC999 日本語訳
0999 Requests For Comments summary notes: 900-999. A. Westine, J.Postel. April 1 1987. (Format: TXT=62877 bytes) (Obsoletes RFC0160) (Obsoleted by RFC1000) (Status: UNKNOWN)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group A. Westine
Request for Comments: 999 J. Postel
ISI
April 1987
Westineがコメントのために要求するワーキンググループA.をネットワークでつないでください: 999 J.ポステルISI1987年4月
Requests For Comments Summary
Notes: 900-999
概要が注意するコメントを求める要求: 900-999
Status of this Memo
このMemoの状態
This RFC is a slightly annotated list of the 100 RFCs from RFC-900 through RFC-999. This is a status report on these RFCs. Distribution of this memo is unlimited.
このRFCはRFC-900からRFC-999の100RFCsのわずかに注釈されたリストです。 これはこれらのRFCsに関する現状報告です。 このメモの分配は無制限です。
RFC Author Date Title --- ------ ---- -----
RFC作者日付のタイトル--- ------ ---- -----
999 Westine Apr 87 Requests For Comments Summary
999 コメント概要に関するWestine4月87日の要求
This memo.
このメモ。
998 Lambert Mar 87 NETBLT: A Bulk Data Transfer
Protocol
998 ランバート3月87日のNETBLT: バルク・データ転送プロトコル
This document is a description of, and a specification for, the NETBLT protocol. It is a revision of the specification published in RFC-969. NETBLT (NETwork BLock Transfer) is a transport level protocol intended for the rapid transfer of a large quantity of data between computers. It provides a transfer that is reliable and flow controlled, and is designed to provide maximum throughput over a wide variety of networks. Although NETBLT currently runs on top of the Internet Protocol (IP), it should be able to operate on top of any datagram protocol similar in function to IP. This document is published for discussion and comment, and does not constitute a standard. The proposal may change and certain parts of the protocol have not yet been specified; implementation of this document is therefore not advised. Obsoletes RFC-969.
このドキュメントが記述である、仕様、NETBLTは議定書を作ります。 それはRFC-969で発表された仕様の改正です。 NETBLT(NETwork BLock Transfer)は平らなプロトコルがコンピュータの間の多量のデータの迅速な移転のために意図した輸送です。 それが信頼できる転送を供給して、流れは、制御して、さまざまなネットワークの上に最大のスループットを提供するように設計されています。 NETBLTは現在インターネットプロトコル(IP)の上で稼働しますが、それは機能においてIPと同様のどんなデータグラムプロトコルの上でも作動できるべきです。 このドキュメントは、議論とコメントのために発行されて、規格を構成しません。 提案は変化するかもしれません、そして、プロトコルのある部分はまだ指定されていません。 したがって、このドキュメントの実装は教えられません。 RFC-969を時代遅れにします。
997 Reynolds Mar 87 Internet Numbers
997 レイノルズ3月87日のインターネット番号
This memo is an official status report on the network numbers used in the Internet community. As of 1-Mar-87 the Network Information Center (NIC) at SRI International has assumed responsibility for assignment of Network Numbers and Autonomous System Numbers. This RFC documents the current assignments of these numbers at the time of this transfer of responsibility. Obsoletes RFC-990, 960, 943, 923 and 900.
このメモはインターネットコミュニティで使用されるネットワーク・ナンバーに関する公式の現状報告です。 1987年3月1日現在、SRIインターナショナルのNetworkインフォメーション・センター(NIC)はNetwork民数記とAutonomous System民数記の課題への責任を負いました。 このRFCは責任のこの転送時点で、これらの数の現在の課題を記録します。 RFC-990、960、943、923、および900を時代遅れにします。
Westine & Postel [Page 1] RFC 999 March 1987
Westineとポステル[1ページ]RFC999 1987年3月
996 Mills Feb 87 Statistics Server
996の工場2月87日統計サーバ
This RFC specifies a standard for the ARPA Internet community. Hosts and gateways on the DARPA Internet that choose to implement a remote statistics monitoring facility may use this protocol to send statistics data upon request to a monitoring center or debugging host.
このRFCはARPAインターネットコミュニティの規格を指定します。 DARPAインターネットのリモート統計モニターが施設であると実装するのを選ぶホストとゲートウェイは、モニターしているセンターかデバッグホストへの要求に統計データを送るのにこのプロトコルを使用するかもしれません。
995 ANSI Apr 86 End System to Intermediate System
Routing Exchange Protocol for use in
conjunction with ISO 8473.
995 ISO8473に関連した使用のためのIntermediate Systemルート設定ExchangeプロトコルへのANSI4月86日のEnd System。
This Protocol is one of a set of International Standards produced to facilitate the interconnection of open systems. The set of standards covers the services and protocols required to achieve such interconnection. This Protocol is positioned with respect to other related standards by the layers defined in the Reference Model for Open Systems Interconnection (ISO 7498) and by the structure defined in the Internal Organization of the Network Layer (DIS 8648). In particular, it is a protocol of the Network Layer. This Protocol permits End Systems and Intermediate Systems to exchange configuration and routing information to facilitate the operation of the routing and relaying functions of the Network Layer.
このプロトコルはオープンシステムのインタコネクトを容易にするために生産された国際Standardsの1セットの1つです。規格のセットはサービスをカバーしています、そして、プロトコルがそのようなインタコネクトを達成するのが必要です。 オープン・システム・インターコネクションのためにReference Modelで定義された層(ISO7498)とNetwork LayerのInternal Organizationで定義された構造(DIS8648)によってこのプロトコルは他の関連する規格に関して置かれます。 それは特に、Network Layerのプロトコルです。 このプロトコルは、End SystemsとIntermediate SystemsがNetwork Layerのルーティングとリレー機能の操作を容易にするために構成とルーティング情報を交換することを許可します。
994 ANSI Mar 86 Final Text of DIS 8473, Protocol for
Providing the Connectionless Mode
Network Service
994 不-8473年のANSI3月86日の最終版の教科書、コネクションレスなモードネットワーク・サービスを提供するためのプロトコル
This Protocol Standard is one of a set of International Standards produced to facilitate the interconnection of open systems. The set of standards covers the services and protocols required to achieve such interconnection. This Protocol Standard is positioned with respect to other related standards by the layers defined in the Reference Model for Open Systems Interconnection (ISO 7498). In particular, it is a protocol of the Network Layer. This Protocol may be used between network-entities in end systems or in Network Layer relay systems (or both). It provides the Connectionless-mode Network Service as defined in Addendum 1 to the Network Service Definition Covering Connectionless-mode Transmission (ISO 8348/AD1).
このプロトコルStandardはオープンシステムのインタコネクトを容易にするために生産された国際Standardsの1セットの1つです。規格のセットはサービスをカバーしています、そして、プロトコルがそのようなインタコネクトを達成するのが必要です。 このプロトコルStandardはオープン・システム・インターコネクション(ISO7498)のためにReference Modelで定義された層のそばに他の関連する規格に関して置かれます。 それは特に、Network Layerのプロトコルです。 このプロトコルはエンドシステムかNetwork Layerリレー方式のネットワーク実体(ともに)の間で使用されるかもしれません。 それはAddendum1でNetwork Service Definition Covering Connectionless-モードTransmission(ISO8348/AD1)と定義されるようにConnectionless-モードNetwork Serviceを提供します。
993 Clark Dec 86 PCMAIL: A Distributed Mail System for
Personal Computers
993 クラーク12月86日のPCMAIL: パーソナルコンピュータの分配されたメールシステム
This document is a discussion of the Pcmail workstation-based distributed mail system. It is a revision of the design published in NIC RFC-984. The revision is based on discussion and comment fromm a variety of sources, as well as further research into the design of interactive Pcmail clients and the use of client code on machines other than IBM PCs. As this design may change, implementation of this document is not advised. Obsoletes RFC-984.
このドキュメントはPcmailの議論です。ワークステーションベースの分配されたメールシステム。 それはNIC RFC-984で発行されたデザインの改正です。 改正は、議論とコメントfrommに基づいたさまざまなソースと、対話的なPcmailクライアントのデザインとIBM PC以外のマシンにおけるクライアントコードの使用のさらなる研究です。 このデザインが変化するとき、このドキュメントの実装は教えられません。 RFC-984を時代遅れにします。
Westine & Postel [Page 2] RFC 999 March 1987
Westineとポステル[2ページ]RFC999 1987年3月
992 Birman Nov 86 On Communication Support for
Fault-Tolerant Process Groups
992 フォールトトレラントプロセスグループのコミュニケーションサポートでのバーマン11月86日
This memo describes a collection of multicast communication primitives integrated with a mechanism for handling process failure and recovery. These primitives facilitate the implementation of fault-tolerant process groups, which can be used to provide distributed services in an environment subject to non-malicious crash failures.
このメモは取り扱い過程の失敗と回復のためにメカニズムについて統合しているマルチキャストコミュニケーション基関数の収集について説明します。 これらの基関数はフォールトトレラントプロセスグループの実装を容易にします。(非悪意がある速成の失敗を条件として分配されたサービスを環境に提供するのにグループを使用できます)。
991 Reynolds Nov 86 Official ARPA-Internet Protocols
991 レイノルズ11月86日の公式のアルパインターネットプロトコル
This RFC identifies the documents specifying the official protocols used in the Internet. Comments indicate any revisions or changes planned. This memo is an official status report on the numbers used in protocols in the ARPA-Internet community. Obsoletes RFC-961, 944 and 924.
このRFCはインターネットで使用される公式のプロトコルを指定するドキュメントを特定します。 コメントは、どんな改正や変化も計画されていたのを示します。 このメモはARPA-インターネットコミュニティのプロトコルに使用される数に関する公式の現状報告です。 RFC-961、944、および924を時代遅れにします。
990 Reynolds Nov 86 Assigned Numbers
990 レイノルズ11月86日は数を割り当てました。
This Network Working Group Request for Comments documents the currently assigned values from several series of numbers used in network protocol implementations. This memo is an official status report on the numbers used in protocols in the ARPA-Internet community. See RFC-997. Obsoletes RFC-960, 943, 923 and 900.
CommentsのためのこのNetwork作業部会Requestはネットワーク・プロトコル実装に使用されるいくつかのシリーズの数から現在割り当てられた値を記録します。 このメモはARPA-インターネットコミュニティのプロトコルに使用される数に関する公式の現状報告です。 RFC-997を見てください。 RFC-960、943、923、および900を時代遅れにします。
989 Linn Feb 87 Privacy Enhancement for Internet
Electronic Mail: Part I: Message
Encipherment and Authentication
Procedures
989 インターネット電子メールのためのリン2月87日のプライバシー増進: 部分I: メッセージ暗号文と認証手順
This RFC suggests a proposed protocol for the Internet community and requests discussion and suggestions for improvements. This RFC is the outgrowth of a series of IAB Privacy Task Force meetings and of internal working papers distributed for those meetings. This RFC defines message encipherment and authentication procedures, as the initial phase of an effort to provide privacy enhancement services for electronic mail transfer in the Internet. It is intended that the procedures defined here be compatible with a wide range of key management approaches, including both conventional (symmetric) and public-key (asymmetric) approaches for encryption of data encrypting keys. Use of conventional cryptography for message text encryption and/or authentication is anticipated.
このRFCは改良のためのインターネットコミュニティ、要求議論、および提案のために提案されたプロトコルを勧めます。 このRFCは一連のIAB Privacy Task Forceミーティングとそれらのミーティングのために配布された内部の働く書類の派生物です。 このRFCは、電子メール転送のためのプライバシー増進サービスをインターネットに提供するためにメッセージ暗号文と認証手順を取り組みの初期位相と定義します。 ここで定義された手順はさまざまなかぎ管理アプローチと互換性があることを意図します、キーを暗号化するデータの暗号化のためのともに従来(左右対称の)、公開鍵の(非対称)のアプローチを含んでいて。 従来の暗号のメッセージ・テキスト暗号化、そして/または、認証の使用は予期されます。
988 Deering Jul 86 Host Extensions for IP Multicasting
988 デアリング7月86日はIPマルチキャスティングのための拡大を主催します。
This memo specifies the extensions required of a host implementation of the Internet Protocol (IP) to support internetwork multicasting. This specification supersedes that given in RFC-966, and constitutes a proposed protocol standard for IP multicasting in the ARPA-Internet. The reader is directed to RFC-966 for a discussion of the motivation and rationale behind the multicasting extension specified here.
このメモはインターネットワークマルチキャスティングをサポートするのにインターネットプロトコル(IP)のホスト導入について必要である拡大を指定します。 この仕様は、ARPA-インターネットでRFC-966で与えられたそれに取って代わって、IPマルチキャスティングの提案されたプロトコル標準を構成します。 読者は動機と原理の議論のためにここで指定されたマルチキャスティング拡大の後ろにRFC-966に向けられます。
Westine & Postel [Page 3] RFC 999 March 1987
Westineとポステル[3ページ]RFC999 1987年3月
987 Kille Jun 86 Mapping between X.400 and RFC-822
987 X.400とRFC-822の間のKille6月86日のマッピング
The X.400 series protocols have been defined by CCITT to provide an Interpersonal Messaging Service (IPMS), making use of a store and forward Message Transfer Service. It is expected that this standard will be implemented very widely. This document describes a set of mappings which will enable interworking between systems operating the X.400 protocols and systems using RFC-822 mail protocol or protocols derived from RFC-822. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements.
X.400シリーズプロトコルはInterpersonalメッセージサービス(IPMS)を提供するためにCCITTによって定義されました、店と前進のMessage Transfer Serviceを利用して。 この規格が非常に広く実装されると予想されます。 このドキュメントはRFC-822メールプロトコルかRFC-822から得られたプロトコルを使用することでX.400プロトコルとシステムを操作するシステムの間の織り込むことを可能にする1セットのマッピングについて説明します。 このRFCは改良のためにARPA-インターネットコミュニティ、要求議論、および提案のための提案されたプロトコルを勧めます。
986 Callon Jun 86 Working Draft -- Guidelines for the Use
of Internet-IP addressing in the ISO
Connectionless-Mode Network Protocol
986Callon6月86日作業草案--NetworkがプロトコルであるとISO Connectionless-モードで扱うインターネットIPのUseのためのガイドライン
This RFC suggests a method to allow the existing IP addressing, including the IP protocol field, to be used for the ISO Connectionless Network Protocol (CLNP). This is a draft solution to one of the problems inherent in the use of "ISO-grams" in the DOD Internet. Related issues will be discussed in subsequent RFCs. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements.
このRFCは既存のIPアドレシングを許容するメソッドを勧めます、ISO Connectionless Networkプロトコル(CLNP)に使用されるためにIPプロトコル分野を含んでいて。 これはDODインターネットでの「等値線」の使用の固有である問題の1つへの草稿ソリューションです。 その後のRFCsで関連問題について議論するでしょう。 このRFCは改良のためにARPA-インターネットコミュニティ、要求議論、および提案のための提案されたプロトコルを勧めます。
985 Mills May 86 Requirements for Internet Gateways
インターネットゲートウェイのための985の工場5月86日要件
This RFC summarizes the requirements for gateways to be used on networks supporting the DARPA Internet protocols. While it applies specifically to National Science Foundation research programs, the requirements are stated in a general context and are believed applicable throughout the Internet community. The purpose of this document is to present guidance for vendors offering products that might be used or adapted for use in an Internet application. It enumerates the protocols required and gives references to RFCs and other documents describing the current specification.
このRFCはDARPAインターネットがプロトコルであるとサポートしながらゲートウェイがネットワークで使用されるという要件をまとめます。 それが特に科学基金の研究計画に適用されている間、要件は、一般情勢に述べられていて、インターネットコミュニティ中で適切であると信じられています。 このドキュメントの目的はインターネットアプリケーションにおける使用のために使用されるか、または適合させられるかもしれない製品を提供するベンダーのために指導を提示することです。 それは、現在の仕様を説明するRFCsと他のドキュメントに、必要であるプロトコルを列挙して、参照を与えます。
984 Clark May 86 PCMAIL: A Distributed Mail System for
Personal Computers
984 クラーク5月86日のPCMAIL: パーソナルコンピュータの分配されたメールシステム
This document is a preliminary discussion of the design of a personal-computer-based distributed mail system. Pcmail is a distributed mail system that provides mail service to an arbitrary number of users, each of which owns one or more personal computers (PCs). The system is divided into two halves. The first consists of a single entity called the "repository". The repository is a storage center for incoming mail. Mail for a Pcmail user can arrive externally from the Internet or internally from other repository users. The repository also maintains a stable copy of each user's mail state. The repository is therefore typically a computer with a large amount of disk storage. It is published for discussion and comment, and does not constitute a standard. As the proposal may change, implementation of this document is not advised. See RFC-993.
このドキュメントは個人的なコンピュータベースの分配されたメールシステムの設計の予備的な討論です。 Pcmailはそれのそれぞれが1台以上のパーソナルコンピュータ(PC)を所有しているユーザの特殊活字の数字に対するメールサービスを提供する分配されたメールシステムです。 システムは2つの半分に分割されます。 1番目は「倉庫」と呼ばれる単一体から成ります。 倉庫は入って来るメールのためのストレージセンターです。 Pcmailユーザのためのメールはインターネットから他の倉庫ユーザから外部的に内部的に到着できます。 また、倉庫は安定したコピーの各ユーザのメール状態を維持します。 したがって、通常、倉庫は多量のディスクストレージがあるコンピュータです。 それは、議論とコメントのために発行されて、規格を構成しません。 提案が変化するとき、このドキュメントの実装は教えられません。 RFC-993を見てください。
9Westine & Postel [Page 4] RFC 999 March 1987
9Westineとポステル[4ページ]RFC999 1987年3月
983 Cass Apr 86 ISO Transport Services on Top of the
TCP
983 キャス4月86日のISOはTCPの上でサービスを輸送します。
This memo describes a proposed protocol standard for the ARPA Internet community. The CCITT and the ISO have defined various session, presentation, and application recommendations which have been adopted by the international community and numerous vendors. To the largest extent possible, it is desirable to offer these higher level services directly in the ARPA Internet, without disrupting existing facilities. This permits users to develop expertise with ISO and CCITT applications which previously were not available in the ARPA Internet. The intention is that hosts in the ARPA-Internet that choose to implement ISO TSAP services on top of the TCP be expected to adopt and implement this standard. Suggestions for improvement are encouraged.
このメモはARPAインターネットコミュニティの提案されたプロトコル標準について説明します。 CCITTとISOは国際社会によって採用された様々なセッション、プレゼンテーション、およびアプリケーション推薦と多数のベンダーを定義しました。 可能な最も大きい範囲に、直接存在を混乱させることのないARPAインターネットでのこれらのより高い平らなサービスに施設を提供するのは望ましいです。 これは、ユーザが以前にARPAインターネットで利用可能でなかったISOとCCITTアプリケーションで専門知識を伸ばすことを許可します。 意志はARPA-インターネットのTCPの上でISO TSAPにサービスを実装するのを選ぶホストがこの規格を採用して、実装すると予想されるということです。 改善提案は奨励されます。
982 ANSI Apr 86 Guidelines for the Specification of the
Structure of the Domain Specific Part
(DSP) of the ISO Standard NSAP Address
982 ISOの標準のNSAPアドレスのドメインの特定の部分(DSP)の構造の仕様のためのANSI4月86日のガイドライン
This RFC is a draft working document of the ANSI "Guidelines for the Specification of the Structure of the Domain Specific Part (DSP) of the ISO Standard NSAP Address". It provides guidance to private address administration authorities on preferred formats and semantics for the Domain Specific Part (DSP) of an NSAP address. This RFC specifies the way in which the DSP may be constructed so as to facilitate efficient address assignment. This RFC is for informational purposes only and its distribution is unlimited and does not specify a standard of the ARPA-Internet.
このRFCは「ISOの標準のNSAPアドレスのドメインの特定の部分(DSP)の構造の仕様のためのガイドライン」というANSIのドキュメントを扱う草稿です。 それはNSAPアドレスのDomain Specific Part(DSP)のために都合のよい形式と意味論でプライベート・アドレス管理機関に指導を提供します。 このRFCはDSPが効率的なアドレス課題を容易にするために組み立てられるかもしれない方法を指定します。 このRFCが情報の目的だけのためのものであり、分配は、無制限であり、ARPA-インターネットの規格を指定しません。
981 Mills Mar 86 An Experimental Multiple-Path Routing
Algorithm
981は3月86日に実験複数の経路ルーティング・アルゴリズムを製粉します。
This document introduces wiretap algorithms, a class of experimental, multiple routing algorithms that compute quasi-optimum routes for stations sharing a packet-radio broadcast channel. The primary route (a minimum-distance path), and additional paths ordered by distance, which serve as alternate routes should the primary route fail, are computed. This prototype is presented as an example of a class of routing algorithms and data-base management techniques that may find wider application in the Internet community. Discussions and suggestions for improvements are welcomed.
このドキュメントは盗聴アルゴリズム、実験的のクラス、パケットラジオ放送チャンネルを共有するステーションに準最適なルートを計算する複数のルーティング・アルゴリズムを導入します。 代替経路としてのサーブはそうするべきである距離に従って(最小の距離経路)の、そして、追加している経路が幹線道路やり損ないを注文した幹線道路、計算されます。 このプロトタイプはインターネットコミュニティで、より広い法則を見つけるかもしれないルーティング・アルゴリズムとデータベースの管理のテクニックのクラスに関する例として提示されます。 改良のための議論と提案は歓迎されます。
980 Jacobsen Mar 86 Protocol Document Order Information
980 ジェイコブセン3月86日はドキュメントオーダー情報について議定書の中で述べます。
This RFC indicates how to obtain various protocol documents used in the DARPA research community. Included is an overview of the new 1985 DDN Protocol Handbook and available sources for obtaining related documents (such as DOD, ISO, and CCITT).
このRFCはDARPA研究団体で使用される様々なプロトコルドキュメントを入手する方法を示します。 含まれているのは、関連するドキュメント(DODや、ISOや、CCITTなどの)を入手するための新しい1985DDNプロトコルHandbookと利用可能なソースの概要です。
9
9
9Westine & Postel [Page 5] RFC 999 March 1987
9Westineとポステル[5ページ]RFC999 1987年3月
979 Malis Mar 86 PSN End-to-End Functional Specification
979 Malis3月86日のPSN終わりから終わりへの機能的な仕様
This memo is an updated version of BBN Report 5775, "End-to-End Functional Specification and describes important changes to the functionality of the interface between a Host and the PSN, and should be carefully reviewed by anyone involved in supporting a host on either the ARPANET or MILNET". The new End-to-End protocol (EE) is being developed in order to correct a number of deficiencies in the old EE, to improve its performance and overall throughput, and to better equip the Packet Switch Node (PSN, also known as the IMP) to support its current and anticipated host population.
このメモは、BBN Report5775のアップデートされたバージョンであり、「Functional Specificationを終わりに終わらせて、HostとPSNに重要な変化をインタフェースの機能性に説明して、アルパネットかMILNETのどちらかでホストをサポートするのにかかわるだれによっても慎重に見直されるべきです」。 Endから終わりへの新しいプロトコル(EE)は、性能と総合的なスループットを向上させて、現在の、そして、予期されたホスト人口をサポートするために、Packet Switch Node(また、IMPとして知られているPSN)をよりよく、備えるために古いEEの多くの欠乏を修正するために開発されています。
978 Reynolds Feb 86 Voice File Interchange Protocol (VFIP)
978 レイノルズ2月86日の声のファイル置き換えプロトコル(VFIP)
The purpose of the Voice File Interchange Protocol (VFIP) is to permit the interchange of various types of speech files between different systems in the ARPA-Internet community. Suggestions for improvement are encouraged.
Voice File Interchangeプロトコル(VFIP)の目的はARPA-インターネットコミュニティの異系統の間の様々なタイプのスピーチファイルの置き換えを可能にすることです。 改善提案は奨励されます。
977 Kantor Feb 86 Network News Transfer Protocol
977 カンター2月86日のネットワークの電子情報を転送するプロトコル
NNTP specifies a protocol for the distribution, inquiry, retrieval, and posting of news articles using a reliable stream-based transmission of news among the ARPA-Internet community. NNTP is designed so that news articles are stored in a central database allowing a subscriber to select only those items he wishes to read. Indexing, cross-referencing, and expiration of aged messages are also provided. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements.
NNTPは、ARPA-インターネットコミュニティの中でニュースの信頼できるストリームベースの伝達を使用することでニュース記事の分配、問い合せ、検索、および任命にプロトコルを指定します。 NNTPは、加入者が彼が読みたがっているそれらの項目だけを選択するのを許容しながらニュース記事が主要なデータベースに保存されるように、設計されています。 また、老いているメッセージのインデックス、十字参照箇所、および満了を提供します。 このRFCは改良のためにARPA-インターネットコミュニティ、要求議論、および提案のための提案されたプロトコルを勧めます。
976 Horton Feb 86 UUCP Mail Interchange Format Standard
976 ホートン2月86日のUUCPメール置き換え形式規格
This document defines the standard format for the transmission of mail messages between computers in the UUCP Project. It does not however, address the format for storage of messages on one machine, nor the lower level transport mechanisms used to get the date from one machine to the next. It represents a standard for conformance by hosts in the UUCP zone.
このドキュメントはUUCP Projectのコンピュータの間のメール・メッセージの伝達のために標準書式を定義します。 しかしながら、それはそうしないで、アドレスは1台のマシンにおけるメッセージのストレージのための形式です、または、下のレベル移送機構が以前は1台のマシンから次まで日付をよく得ていました。 それはUUCPゾーンにホストによる順応の規格を表します。
975 Mills Feb 86 Autonomous Confederations
975は2月86日に自動同盟者を製粉します。
This RFC proposes enhancements to the Exterior Gateway Protocol (EGP) to support a simple, multiple-level routing capability while preserving the robustness features of the current EGP model. The enhancements generalize the concept of core system to include multiple communities of autonomous systems, called autonomous confederations. Discussion and suggestions for improvement are requested.
このRFCは、現在のEGPモデルの丈夫さ機能を保存している間、簡単で、複数のレベルのルーティングが能力であるとサポートするためにExteriorゲートウェイプロトコル(EGP)に増進を提案します。 自動同盟者は、増進が自律システムの複数の共同体を含むようにコア・システムの概念を広めると呼びました。 議論と改善提案は要求されています。
Westine & Postel [Page 6] RFC 999 March 1987
Westineとポステル[6ページ]RFC999 1987年3月
974 Partridge Jan 86 Mail Routing and the Domain System
974 1月86日がルート設定を郵送するヤマウズラとドメインシステム
This RFC presents a description of how mail systems on the Internet are expected to route messages based on information from the domain system. This involves a discussion of how mailers interpret MX RRs, which are used for message routing.
このRFCはインターネットのメールシステムがドメインシステムから情報に基づくメッセージを発送するとどう予想されるかに関する記述を提示します。 これは郵送者がどうメッセージルーティングに使用されるMX RRsを解釈するかに関する議論にかかわります。
973 Mockapetris Jan 86 Domain System Changes and Observations
973 1月86日のドメインシステムが変えるMockapetrisと観測
This RFC documents updates to Domain Name System specifications RFC-882 and RFC-883, suggests some operational guidelines, and discusses some experiences and problem areas in the present system.
このRFCは現行制度でドメインネームシステム仕様のRFC-882とRFC-883にアップデートを記録して、いくつかの運用指針を勧めて、いくつかの経験と問題領域について議論します。
972 Wancho Jan 86 Password Generator Protocol
972 Wancho1月86日のパスワードジェネレータプロトコル
This RFC specifies a standard for the ARPA Internet community. The Password Generator Service (PWDGEN) provides a set of six randomly generated eight-character "words" with a reasonable level of pronounceability, using a multi-level algorithm. Hosts on the ARPA Internet that choose to implement a password generator service are expected to adopt and implement this standard.
このRFCはARPAインターネットコミュニティの規格を指定します。 Password Generator Service(PWDGEN)は8キャラクタ「単語」であると手当たりしだいに生成された1セットの6をpronounceabilityの妥当な水準に提供します、マルチレベルアルゴリズムを使用して。 ARPAインターネットのパスワードがジェネレータサービスであると実装するのを選ぶホストは、この規格を採用して、実装すると予想されます。
971 DeSchon Dec 85 A Survey of Data Representation
Standards
971DeSchon12月85日 データ表現規格の調査
This RFC is a comparison of several data representation standards that are currently in use. The standards discussed are the CCITT X.409 recommendation, the NBS Computer Based Message System (CBMS) standard, DARPA Multimedia Mail system, the Courier remote procedure call protocol, and the SUN Remote Procedure Call package. No proposals in this document are intended as standards for the ARPA-Internet at this time. Rather, it is hoped that a general consensus will emerge as to the appropriate approach to a data representation standard, leading eventually to the adoption of an ARPA-Internet standard.
このRFCはいくつかの現在使用中のデータ表現規格の比較です。 議論した規格は、CCITT X.409推薦と、NBSコンピュータBased Message System(CBMS)規格と、DARPA Multimediaメールシステムと、Courier遠隔手続き呼び出しプロトコルと、SUN Remote Procedure Callパッケージです。 提案は全くこのとき、ARPA-インターネットの規格として本書では意図しません。 むしろ、全体的な合意がデータ表現規格への適切なアプローチに関して現れることが望まれています、結局ARPA-インターネット標準の採用に通じて。
970 Nagle Dec 85 On Packet Switches With Infinite
Storage
970 無限のストレージがあるパケット交換機の上のネーグル12月85日
The purpose of this RFC is to focus discussion on a particular problem in the ARPA-Internet and possible methods of solution. Most prior work on congestion in datagram systems focuses on buffer management. In this memo the case of a packet switch with infinite storage is considered. Such a packet switch can never run out of buffers. It can, however, still become congested. The meaning of congestion in an infinite-storage system is explored. An unexpected result is found that shows a datagram network with infinite storage, first-in-first-out queuing, at least two packet switches, and a finite packet lifetime will, under overload, drop all packets. By attacking the problem of congestion for the infinite-storage case, new solutions applicable to switches with finite storage may be found. No proposed solutions this document are intended as standards for the ARPA-Internet at this time.
このRFCの目的はARPA-インターネットの特定の問題とソリューションの可能なメソッドに議論の焦点を合わせることです。 データグラムシステムにおける混雑に対するほとんどの先の仕事がバッファ管理に焦点を合わせます。 このメモでは、無限のストレージがあるパケット交換機に関するケースは考えられます。 そのようなパケット交換機はバッファを決して使い果たすことができません。 しかしながら、それはまだ混雑するようになることができます。 無限のストレージシステムにおける混雑の意味は探られます。 無限のストレージに応じて、ファーストインファーストアウトの列を作り、少なくとも2個のパケット交換機、および有限パケット生存期間がオーバーロードの下ですべてのパケットを下げるのをデータグラム・ネットワークに示す予期しなかった結果は見つけられます。 無限のストレージケースのための混雑の問題を攻撃することによって、有限ストレージでスイッチに適切な新しいソリューションは見つけられるかもしれません。 これが記録しない提案されたソリューションは全くこのとき、ARPA-インターネットの規格として意図します。
Westine & Postel [Page 7] RFC 999 March 1987
Westineとポステル[7ページ]RFC999 1987年3月
969 Clark Dec 85 NETBLT: A Bulk Data Transfer Protocol
969 クラーク12月85日のNETBLT: バルク・データ転送プロトコル
This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements. This is a preliminary discussion of the Network Block Transfer (NETBLT) protocol. NETBLT is intended for the rapid transfer of a large quantity of data between computers. It provides a transfer that is reliable and flow controlled, and is structured to provide maximum throughput over a wide variety of networks. This description is published for discussion and comment, and does not constitute a standard. As the proposal may change, implementation of this document is not advised. See RFC-998.
このRFCは改良のためにARPA-インターネットコミュニティ、要求議論、および提案のための提案されたプロトコルを勧めます。 これはNetwork Block Transfer(NETBLT)プロトコルの予備的な討論です。 NETBLTはコンピュータの間の多量のデータの迅速な移転のために意図します。 それが信頼できる転送を供給して、流れは、制御して、さまざまなネットワークの上に最大のスループットを提供するために構造化されます。 この記述は、議論とコメントのために発行されて、規格を構成しません。 提案が変化するとき、このドキュメントの実装は教えられません。 RFC-998を見てください。
968 Cerf Dec 85 'Twas the Night Before Start-up'
968 上にから始まるサーフ12月85日の'Twas夜前'
This memo discusses problems that arise and debugging techniques used in bringing a new network into operation.
このメモは新しいネットワークを起動する際に使用される起こる問題とデバッグ技術について議論します。
967 Padlipsky Dec 85 All Victims Together
967Padlipsky12月85日 一緒にすべての犠牲者
This RFC proposes a new set of RFCs on how the networking code is integrated with various operating systems. It appears that this topic has not received enough exposure in the literature. Comments and suggestions are encouraged.
このRFCはネットワークコードが様々なオペレーティングシステムについてどう統合しているかのRFCsの新しいセットを提案します。この話題が文学の十分な暴露を受けていないように見えます。 コメントと提案は奨励されます。
966 Deering Dec 85 A Multicast Extension to the Internet
Protocol
966 インターネットプロトコルへのマルチキャスト拡大あたりのデアリング12月85日
This RFC defines a model of service for Internet multicasting and proposes an extension to the Internet Protocol (IP) to support such a multicast service. Discussion and suggestions for improvements are requested. See RFC-988.
このRFCは、インターネットマルチキャスティングのためにサービスのモデルを定義して、そのようなマルチキャストサービスをサポートするためにインターネットプロトコル(IP)に拡大を提案します。 改良のための議論と提案は要求されています。 RFC-988を見てください。
965 Aguilar Dec 85 A Format for a Graphical Communication
Protocol
965アギラル12月85日 グラフィカルな通信プロトコルのための形式
This RFC describes the requirements for a graphical format on which to base a graphical on-line communication protocol, and proposes an Interactive Graphical Communication Format using the GKSM session metafile. We hope this contribution will encourage the discussion of multimedia data exchange and the proposal of solutions.
このRFCは、グラフィカルなオンライン通信プロトコルを基礎づけるグラフィカルな形式のために要件について説明して、GKSMセッションメタファイルを使用することでInteractive Graphical Communication Formatを提案します。 この貢献がマルチメディアデータ交換の議論とソリューションの提案を奨励することを願っています。
964 Sidhu Nov 85 Some Problems with the Specification of
the Military Standard Transmission
Control Protocol
964 軍事の標準の転送管理の仕様に関するいくつかの問題が議定書の中で述べるSidhu11月85日
The purpose of this RFC is to provide helpful information on the Military Standard Transmission Control Protocol (MIL-STD-1778) so that one can obtain a reliable implementation of this protocol standard. This note points out three errors with this specification. This note also proposes solutions to these problems.
このRFCの目的は1つがこのプロトコル標準の信頼できる実装を得ることができるようにMilitary Standard通信制御プロトコル(軍規格-1778)に関する役立つ情報を提供することです。 この注意はこの仕様で3つの誤りを指摘します。 また、この注意はこれらの問題にソリューションを提案します。
Westine & Postel [Page 8] RFC 999 March 1987
Westineとポステル[8ページ]RFC999 1987年3月
963 Sidhu Nov 85 Some Problems with the Specification of
the Military Standard Internet Protocol
963 軍事の標準のインターネットの仕様に関するいくつかの問題が議定書の中で述べるSidhu11月85日
The purpose of this RFC is to provide helpful information on the Military Standard Internet Protocol (MIL-STD-1777) so that one can obtain a reliable implementation of this protocol. This paper points out several problems in this specification. This note also proposes solutions to these problems.
このRFCの目的は1つがこのプロトコルの信頼できる実装を得ることができるようにMilitary Standardインターネットプロトコル(軍規格-1777)に関する役立つ情報を提供することです。 この論文はこの仕様によるいくつかの問題を指摘します。 また、この注意はこれらの問題にソリューションを提案します。
962 Padlipsky Nov 85 TCP-4 Prime
962 TCP-4が用意するPadlipsky11月85日
This memo is in response to Bob Braden's call for a transaction oriented protocol (RFC-955), and continues the discussion of a possible transaction oriented transport protocol. This memo does not propose a standard.
このメモは、トランザクションの指向のプロトコル(RFC-955)のためのボブ・ブレーデンの呼び出しに対応していて、可能なトランザクション指向のトランスポート・プロトコルの議論を続けています。 このメモは規格を提案しません。
961 Reynolds Dec 85 Official ARPA-Internet Protocols
961 レイノルズ12月85日の公式のアルパインターネットプロトコル
This memo identifies the documents specifying the official protocols used in the Internet, and comments on any revisions or changes planned. This edition of the Official Protocols updates and obsoletes RFC-944. This memo is an official status report on the protocols used in the ARPA-Internet community. See RFC-991.
このメモが、どんな改正に関してもインターネットで使用される公式のプロトコルを指定するドキュメントを特定して、コメントしたか、または変化は計画されていました。 Officialプロトコルのこの版は、RFC-944をアップデートして、時代遅れにします。 このメモはARPA-インターネットコミュニティで使用されるプロトコルに関する公式の現状報告です。 RFC-991を見てください。
960 Reynolds Dec 85 Assigned Numbers
960 レイノルズ12月85日は数を割り当てました。
This memo documents the currently assigned values from several series of numbers used in network protocol implementations. This edition of Assigned Numbers updates and obsoletes RFC-943. This memo is an official status report on the numbers used in protocols in the ARPA-Internet community. See RFC-990 and 997.
このメモはネットワーク・プロトコル実装に使用されるいくつかのシリーズの数から現在割り当てられた値を記録します。 Assigned民数記のこの版は、RFC-943をアップデートして、時代遅れにします。 このメモはARPA-インターネットコミュニティのプロトコルに使用される数に関する公式の現状報告です。 RFC-990と997を見てください。
959 Postel Oct 85 File Transfer Protocol (FTP)
959 ポステル10月85日File Transfer Protocol(FTP)
This memo is the official specification of the File Transfer Protocol (FTP) for the DARPA Internet community. The primary intent is to clarify and correct the documentation of the FTP specification, not to change the protocol. The following new optional commands are included in this edition of the specification: Change to Parent Directory (CDUP), Structure Mount (SMNT), Store Unique (STOU), Remove Directory (RMD), Make Directory (MKD), Print Directory (PWD), and System (SYST). Note that this specification is compatible with the previous edition.
このメモはDARPAインターネットコミュニティのためのFile Transferプロトコル(FTP)に関する公式の仕様書です。 プライマリ意図は、プロトコルを変えるのではなく、FTP仕様のドキュメンテーションをはっきりさせて、修正することです。 以下の新しい任意のコマンドは仕様のこの版に含まれています: 親ディレクトリ(CDUP)、構造山の(SMNT)に変化してください、そして、ユニークな(STOU)を保存してください、そして、ディレクトリ(RMD)を取り除いてください、そして、ディレクトリ(MKD)、印刷ディレクトリ(PWD)、およびシステム(SYST)を作ってください。 この仕様は前の版と互換性があることに注意してください。
958 Mills Sep 85 Network Time Protocol (NTP)
958の工場9月85日が時間プロトコルをネットワークでつなぎます。(NTP)
This document describes the Network Time Protocol (NTP), a protocol for synchronizing a set of network clocks using a set of distributed clients and servers. NTP is built on the User Datagram Protocol (UDP), which provides a connectionless transport mechanism. It is evolved from the Time Protocol and the ICMP Timestamp message and is a suitable replacement for both. This RFC suggests a proposed protocol for the
このドキュメントはNetwork Timeプロトコル(NTP)(1セットの分配されたクライアントとサーバを使用することで1セットのネットワーク時計を連動させるためのプロトコル)について説明します。 NTPはユーザー・データグラム・プロトコル(UDP)に造られます。(それは、コネクションレスな移送機構を提供します)。 それは、TimeプロトコルとICMP Timestampメッセージから発展されて、両方への適当な交換です。 このRFCは提案されたプロトコルを勧めます。
Westine & Postel [Page 9] RFC 999 March 1987
Westineとポステル[9ページ]RFC999 1987年3月
ARPA-Internet community, and requests discussion and suggestions for improvements.
改良のためのARPA-インターネットコミュニティ、要求議論、および提案。
957 Mills Sep 85 Experiments in Network Clock
Synchronization
9月85日が実験する957の工場が時計同期をネットワークでつなぎます。
This RFC discusses some experiments in clock synchronization in the ARPA-Internet community, and requests discussion and suggestions for improvements. One of the services frequently neglected in computer network design is a high-quality, time-of-day clock capable of generating accurate timestamps with small errors compared to one-way network delays. Such a service would be useful for tracing the progress of complex transactions, synchronizing cached data bases, monitoring network performance and isolating problems. In this memo one such clock service design will be described and its performance assessed. This design has been incorporated as an integral part of the network routing and control protocols of the Distributed Computer Network (DCnet) architecture.
このRFCは改良のためにARPA-インターネットコミュニティ、要求議論、および提案における時計同期におけるいくつかの実験について議論します。 コンピュータネットワークデザインで頻繁に無視されたサービスの1つは小さい誤りが一方向ネットワーク遅延にたとえられている状態で正確なタイムスタンプを生成することができる高品質な時刻時計です。 そのようなサービスは複雑なトランザクションの進歩をたどることの役に立つでしょう、ベース、モニターしているネットワーク性能. このメモのそのようなデザインのクロック・サービス1つが説明されることにおける問題を隔離して、およびその性能が評価したキャッシュされたデータを同期させて。 このデザインはネットワークルーティングの不可欠の部分とDistributedコンピュータNetwork(DCnet)アーキテクチャの制御プロトコルとして法人組織でした。
956 Mills Sep 85 Algorithms for Synchronizing Network
Clocks
ネットワーク時計を連動させるための956の工場9月85日アルゴリズム
This RFC discussed clock synchronization algorithms for the ARPA-Internet community, and requests discussion and suggestions for improvements. The recent interest within the Internet community in determining accurate time from a set of mutually suspicious network clocks has been prompted by several occasions in which errors were found in usually reliable, accurate clock servers after thunderstorms which disrupted their power supply. To these sources of error should be added those due to malfunctioning hardware, defective software and operator mistakes, as well as random errors in the mechanism used to set and synchronize clocks. This report suggests a stochastic model and algorithms for computing a good estimator from time-offset samples measured between clocks connected via network links. Included in this report are descriptions of certain experiments which give an indication of the effectiveness of the algorithms.
このRFCは改良のためにARPA-インターネットコミュニティ、要求議論、および提案のための時計同期アルゴリズムについて議論しました。 1セットの互いに疑わしげなネットワーク時計からの正確な時間を決定することにおけるインターネットコミュニティの中の最近の関心は誤りがそれらの電源を混乱させた雷雨の後に通常信頼できて、正確な時計サーバで見つけられたいくつかの時でうながされました。 誤りのこれらの源と、時計は、メカニズムにおけるハードウェア、欠陥があるソフトウェア、オペレータのミス、および無作為の誤りが以前はよく設定していた誤動作への加えられた当然のそれらであり、連動しているはずです。 このレポートは、時間オフセットのサンプルから良い見積り人を計算するための確率的模型とアルゴリズムがネットワークリンクを通して接続された時計の間で測定したと示唆します。 このレポートに含まれているのは、アルゴリズムの有効性のしるしを与えるある実験の記述です。
955 Braden Sep 85 Towards a Transport Service for
Transaction Processing Applications
955 トランザクション処理アプリケーションのための輸送サービスに向かったブレーデン9月85日
The DoD Internet protocol suite includes two alternative transport service protocols, TCP and UDP, which provide virtual circuit and datagram service, respectively. These two protocols represent points in the space of possible transport service attributes which are quite "far apart". We want to examine an important class of applications, those which perform what is often called "transaction processing". We will see that the communication needs for these applications fall into the gap "between" TCP and UDP -- neither protocol is very appropriate. This RFC is concerned with the possible design of one or more new protocols for the ARPA-Internet, to support kinds of applications which are not well supported at present. The RFC is intended to spur
DoDインターネット・プロトコル群は2代替手段の輸送サービスのプロトコル、TCP、およびUDPを含んでいます。(UDPはそれぞれ仮想の回路とデータグラムサービスを提供します)。 これらの2つのプロトコルがかなり「かけ離れている」可能な輸送サービス属性のスペースにポイントを表します。 重要なクラスのアプリケーション、しばしば「トランザクション処理」と呼ばれることを実行するものを調べたいと思います。 私たちは、これらのアプリケーションのコミュニケーションの必要性がギャップの“between" TCPとUDPになるのを見るでしょう--どちらのプロトコルもそれほど適切ではありません。 現在のところよくサポートされないアプリケーションの種類をサポートすることをARPA-インターネットへの1つ以上の新しいプロトコルの可能なデザインにこのRFCを心配させます。 RFCが急いでいることを意図します。
Westine & Postel [Page 10] RFC 999 March 1987
Westineとポステル[10ページ]RFC999 1987年3月
discussion in the Internet research community towards the development of new protocols and/or concepts, in order to meet these unmet application requirements. It does not represent a standard, nor even a concrete protocol proposal.
これらのunmetアプリケーション要件を満たす新しいプロトコル、そして/または、概念の開発に向かったインターネット研究団体での議論。 それは規格、および具体的なプロトコル提案さえ表しません。
954 Harrenstien Oct 85 NICNAME/WHOIS
954は10月85日にNICNAME/WHOISをHarrenstienします。
This RFC is the official specification of the NICNAME/WHOIS protocol. This memo describes the protocol and the service. This is an update of RFC-812.
このRFCはNICNAME/WHOISプロトコルに関する公式の仕様書です。 このメモはプロトコルとサービスについて説明します。 これはRFC-812のアップデートです。
953 Harrenstien Oct 85 Hostname Server
953 Harrenstien10月85日のホスト名サーバ
This RFC is the official specification of the Hostname Server Protocol. This edition of the specification includes minor revisions to RFC-811 which brings it up to date.
このRFCはHostname Serverプロトコルに関する公式の仕様書です。 仕様のこの版はそれを最新の状態にするRFC-811に小さい方の改正を含んでいます。
952 Harrenstien Oct 85 DoD Internet Host Table Specification
952 Harrenstien10月85日のDoDインターネットホストテーブル仕様
This RFC is the official specification of the format of the Internet Host Table. This edition of the specification includes minor revisions to RFC-810 which brings it up to date.
このRFCはインターネットHost Tableの形式に関する公式の仕様書です。 仕様のこの版はそれを最新の状態にするRFC-810に小さい方の改正を含んでいます。
951 Croft Sep 85 Bootstrap Protocol (BOOTP)
951 耕地9月85日はプロトコルを独力で進みます。(BOOTP)
This RFC describes an IP/UDP bootstrap protocol (BOOTP) which allows a diskless client machine to discover its own IP address, the address of a server host, and the name of a file to be loaded into memory and executed. The bootstrap operation can be thought of as consisting of TWO PHASES. This RFC describes the first phase, which could be labeled `address determination and bootfile selection'. After this address and filename information is obtained, control passes to the second phase of the bootstrap where a file transfer occurs. The file transfer will typically use the TFTP protocol, since it is intended that both phases reside in PROM on the client. However BOOTP could also work with other protocols such as SFTP or FTP. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements.
このRFCはディスクレスクライアントマシンが、それ自身のIPアドレス、サーバー・ホストのアドレス、およびファイルの名前がメモリにロードされると発見できるプロトコル(BOOTP)を独力で進んで、実行されたIP/UDPについて説明します。 操作を独力で進んでください。TWO PHASESから成ると考えることができます。 このRFCは第1段階について説明します。(それは、'アドレス決断とbootfile選択'とラベルされるかもしれません)。 このアドレスとファイル名情報を得た後にコントロールが2番目のフェーズに通る、ファイル転送が起こるところに独力で進んでください。 ファイル転送はTFTPプロトコルを通常使用するでしょう、両方のフェーズがクライアントの上のPROMにあることを意図するので。 しかしながら、また、BOOTPはSFTPかFTPなどの他のプロトコルで働くことができました。 このRFCは改良のためにARPA-インターネットコミュニティ、要求議論、および提案のための提案されたプロトコルを勧めます。
950 Mogul Aug 85 Internet Standard Subnetting Procedure
950 要人の8月85日のインターネットの標準のサブネッティング手順
This memo discusses the utility of "subnets" of Internet networks, which are logically visible sub-sections of a single Internet network. For administrative or technical reasons, many organizations have chosen to divide one Internet network into several subnets, instead of acquiring a set of Internet network numbers. This memo specifies procedures for the use of subnets. These procedures are for hosts (e.g., workstations). The procedures used in and between subnet gateways are not fully described. Important motivation and background information for a subnetting standard is provided in RFC-940. This RFC specifies a protocol for the ARPA-Internet community. If subnetting is implemented it is strongly recommended that these procedures be followed.
このメモはただ一つのインターネット網の論理的に目に見える小区分であるインターネット網の「サブネット」に関するユーティリティについて議論します。 管理的、または、技術的な理由で、多くの組織が、1つのインターネット網をいくつかのサブネットに分割するのを選びました、1セットのインターネットネットワーク・ナンバーを取得することの代わりに。 このメモはサブネットの使用のための手順を指定します。 これらの手順はホスト(例えば、ワークステーション)のためのものです。 ゲートウェイとサブネットゲートウェイの間で用いられた手順は完全に説明されるというわけではありません。 サブネッティング規格のための重要な動機と基礎的な情報をRFC-940に提供します。 このRFCはARPA-インターネットコミュニティにプロトコルを指定します。 サブネッティングが実装されるなら、これらの手順が従われることが強く勧められます。
9Westine & Postel [Page 11] RFC 999 March 1987
9Westineとポステル[11ページ]RFC999 1987年3月
949 Padlipsky Jul 85 FTP Unique-Named Store Command
949 Padlipsky7月85日のFTPのユニークに命名された保存命令
There are various contexts in which it would be desirable to have an FTP command that had the effect of the present STOR but rather than requiring the sender to specify a file name istead caused the resultant file to have a unique name relative to the current directory. This RFC proposes an extension to the File Transfer Protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements. See RFC-959.
しかし、送付者が結果のファイルがカレントディレクトリに比例してユニークな名前を持つために引き起こされたファイル名前isteadを指定するのが必要であるというよりも現在のSTORの効果を持っていたFTPコマンドを持っているのが望ましい様々な文脈がむしろあります。 このRFCはARPA-インターネットコミュニティ、および要求議論のためのFile Transferプロトコルへの拡大と改良のための提案を提案します。 RFC-959を見てください。
948 Winston Jun 85 Two Methods for the Transmission of IP
Datagrams Over IEEE 802.3 Networks
948 IEEE802.3の上のIPデータグラムの送信のための2つのメソッドがネットワークでつなぐウィンストン6月85日
This RFC describes two methods of encapsulating Internet Protocol (IP) datagrams on an IEEE 802.3 network. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements.
このRFCはIEEE802.3ネットワークでインターネットプロトコル(IP)がデータグラムであるとカプセル化する2つのメソッドを説明します。 このRFCは改良のためにARPA-インターネットコミュニティ、要求議論、および提案のための提案されたプロトコルを勧めます。
947 Lebowitz Jun 85 Multi-Network Broadcasting Within the
Internet
947 インターネットの中で放送されるレボウィッツ6月85日のMulti-Network
This RFC describes the extension of a network's broadcast domain to include more than one physical network through the use of a broadcast packet repeater.
このRFCは、放送パケットリピータの使用で1つ以上の物理ネットワークを含むようにネットワークの放送ドメインの拡大について説明します。
946 Nedved May 85 Telnet Terminal Location Number Option
946 ネドべド5月85日のtelnet端末位置の数のオプション
Many systems provide a mechanism for finding out where a user is logged in from usually including information about telephone extension and office occupants names. The information is useful for physically locating people and/or calling them on the phone. In 1982 CMU designed and implemented a terminal location database and modified existing network software to handle a 64-bit number called the Terminal Location Number (or TTYLOC). It now seems appropriate to incorporate this mechanism into the TCP-based network protocol family. The mechanism is not viewed as a replacement for the Terminal Location Telnet Option (SEND-LOCATION) but as a shorthand mechansim for communicating terminal location information between hosts in a localized community. This RFC proposes a new option for Telnet for the ARPA-Internet community, and requests discussion and suggestions for improvements.
ユーザが通常電話拡大とオフィス占有者名の情報を含んでいるのでどこでログインされるかを見つけるのに多くのシステムがメカニズムを提供します。 物理的に人々の居場所を見つける、そして/または、電話で彼らと呼ぶことの情報は役に立ちます。 1982年に、64ビットの数を扱うために端末の位置のデータベースと変更された既存のネットワークソフトウェアであると設計されていて、実装された米カーネギーメロン大学はTerminal Location Number(または、TTYLOC)を呼びました。 TCPを拠点とするネットワーク・プロトコルファミリーにこのメカニズムを組み入れるのは今、適切に思えます。 メカニズムは交換としてTerminal Location Telnet Option(SEND-LOCATION)に関して見なされるのではなく、ローカライズしている共同体のホストの間の端末の位置情報を伝えるための速記mechansimとして見なされます。 このRFCはARPA-インターネットコミュニティ、および要求議論のためのTelnetのための新しいオプションと改良のための提案を提案します。
945 Postel May 85 A DoD Statement on the NRC Report
945 NRCレポートに関するDoD声明あたりのポステル5月85日
In May 1983 the National Research Council (NRC) was asked jointly by DoD and NBS to study the issues and recommend a course of action. The final report of the NRC committee was published in February 1985 (see RFC-942). The enclosed letter is from Donald C. Latham (ASDC3I) to DCA transmitting the NRC report and requesting specific actions relative to the recommendations of the report. This RFC reproduces a letter from the Assistant Secretary of Defense for Command, Control, Communications, and Intelligence (ASDC3I) to the Director of the Defense Communications Agency (DCA). This letter is distributed for information only.
1983年5月に、調査評議会(NRC)は、DoDとNBSによって問題を研究して、行動を推薦するように共同で頼まれました。 NRC委員会に関する最終報告書は1985年2月に発表されました(RFC-942を見てください)。 ドナルドC.レイサム(ASDC3I)からレポートの推薦に比例してNRCレポートを伝えて、特定の動作を要求するDCAまで同封書簡があります。 このRFCはCommand、Control、Communications、およびIntelligence(ASDC3I)のためのDefenseの次官補からDefense Communications Agency(DCA)のディレクターへの手紙を複製します。 この手紙は情報だけのために配布されます。
9Westine & Postel [Page 12] RFC 999 March 1987
9Westineとポステル[12ページ]RFC999 1987年3月
944 Reynolds Apr 85 Official ARPA-Internet Protocols
944 レイノルズ4月85日の公式のアルパインターネットプロトコル
This RFC identifies the documents specifying the official protocols used in the Internet. This edition of Official ARPA-Internet Protocols obsoletes RFC-924 and earlier editions. This RFC will be updated periodically, and current information can be obtained from Joyce Reynolds. This memo is an official status report on the protocols used in the ARPA-Internet community. See RFC-991.
このRFCはインターネットで使用される公式のプロトコルを指定するドキュメントを特定します。 Official ARPA-インターネットプロトコルのこの版はRFC-924と以前の版を時代遅れにします。 定期的にこのRFCをアップデートするでしょう、そして、ジョイス・レイノルズから現行情報を得ることができます。 このメモはARPA-インターネットコミュニティで使用されるプロトコルに関する公式の現状報告です。 RFC-991を見てください。
943 Reynolds Apr 85 Assigned Network Numbers
943 レイノルズ4月85日はネットワーク・ナンバーを割り当てました。
This Network Working Group Request for Comments documents the currently assigned values from several series of numbers used in network protocol implementations. This RFC will be updated periodically, and in any case current information can be obtained from Joyce Reynolds. The assignment of numbers is also handled by Joyce. If you are developing a protocol or application that will require the use of a link, socket, port, protocol, network number, etc., please contact Joyce to receive a number assignment. This memo is an official status report on the numbers used in protocols in the ARPA-Internet community. See RFC-990 and 997.
CommentsのためのこのNetwork作業部会Requestはネットワーク・プロトコル実装に使用されるいくつかのシリーズの数から現在割り当てられた値を記録します。 定期的にこのRFCをアップデートするでしょう、そして、どのような場合でも、ジョイス・レイノルズから現行情報を得ることができます。 また、数の課題はジョイスによって扱われます。 リンク、ソケット、ポート、プロトコル、ネットワーク・ナンバーなどの使用を必要とするプロトコルかアプリケーションを開発しているなら、ジョイスに連絡して、数の課題を受け取ってください。 このメモはARPA-インターネットコミュニティのプロトコルに使用される数に関する公式の現状報告です。 RFC-990と997を見てください。
942 NRC Feb 85 Transport Protocols for Department of
Defense Data Networks
942 NRC2月85日は国防総省データ網のためにプロトコルを輸送します。
This RFC reproduces the National Research Council report resulting from a study of the DoD Internet Protocol (IP) and Transmission Control Protocol (TCP) in comparison with the ISO Internet Protocol (ISO-IP) and Transport Protocol level 4 (TP-4).
このRFCはISOインターネットプロトコル(ISO-IP)とTransportプロトコルレベル4(TP-4)との比較における、DoDインターネットプロトコル(IP)と通信制御プロトコル(TCP)の研究から生じる調査評議会のレポートを複製します。
941 ISO Apr 85 Addendum to the Network Service
Definition Covering Network Layer
Addressing
941 ネットワーク層アドレシングをカバーするネットワーク・サービス定義へのISO4月85日の付加物
This Addendum to the Network Service Definition Standard, ISO 8348, defines the abstract syntax and semantics of the Network Address (Network Service Access Point Address). The Network Address defined in this Addendum is the address that appears in the primitives of the connection-mode Network Service as the calling address, called address, and responding address parameters, and in the primitives of the connectionless-mode Network Service as the source address and destination address parameters. This document is distributed as an RFC for information only. It does not specify a standard for the ARPA-Internet.
Network Service Definition StandardへのこのAddendum(ISO8348)はNetwork Address(ネットワークService Access Point Address)の抽象構文と意味論を定義します。 このAddendumで定義されたNetwork Addressは呼ぶアドレス、着呼アドレス、および応じるのがパラメタを扱う、およびソースアドレスと目的地アドレスパラメタとしてのコネクションレスなモードNetwork Serviceに関する基関数に接続モードNetwork Serviceに関する基関数に現れるアドレスです。 このドキュメントは情報だけのためのRFCとして配布されます。 それはARPA-インターネットの規格を指定しません。
9
9
9Westine & Postel [Page 13] RFC 999 March 1987
9Westineとポステル[13ページ]RFC999 1987年3月
940 GADS Apr 85 Toward an Internet Standard Scheme for
Subnetting
サブネッティングのインターネットの標準の体系に向かった940個の突き棒4月85日
Several sites now contain a complex of local links connected to the Internet via a gateway. The details of the internal connectivity are of little interest to the rest of the Internet. One way of organizing these local complexes of links is to use the same strategy as the Internet uses to organize networks, that is, to declare each link to be an entity (like a network) and to interconnect the links with devices that perform routing functions (like gateways). This general scheme is called subnetting, the individual links are called subnets, and the connecting devices are called subgateways (or bridges, or gateways). This RFC discusses standardizing the protocol used in subnetted environments in the ARPA-Internet.
いくつかのサイトが現在、ゲートウェイを通してインターネットに接続された地方のリンクの複合体を含みます。 内部の接続性の詳細はインターネットの残りへのわずかの関心のものです。 リンクのこれらのローカルの複合体を組織化する1つの方法がネットワークを組織化するのにインターネット用途と同じ戦略を使用することであり、すなわち、各リンクが実体(ネットワークのような)であり、ルーティングを実行するデバイスとのリンクとインタコネクトすると宣言するのが機能します(ゲートウェイのように)。 この一般的な体系はサブネッティングと呼ばれます、そして、個々のリンクはサブネットと呼ばれます、そして、接続デバイスは「副-門」(または、ブリッジ、またはゲートウェイ)と呼ばれます。 このRFCは、ARPA-インターネットの「副-網で覆」われた環境で使用されるプロトコルを標準化するのを議論します。
939 NRC Feb 85 Executive Summary of the NRC Report on
Transport Protocols for Department of
Defense Data Networks
939 国防総省データ網のためのトランスポート・プロトコルにおけるNRCレポートのNRC2月85日の要約
This RFC reproduces the material from the "front pages" of the National Research Council report resulting from a study of the DOD Internet Protocol (IP) and Transmission Control Protocol (TCP) in comparison with the ISO Internet Protocol (ISO-IP) and Transport Protocol level 4 (TP-4). The point of this RFC is to make the text of the Executive Summary widely available in a timely way. The order of presentation has been altered, and the pagination changed. This RFC is distributed for information only. This RFC does not establish any policy for the DARPA research community or the DDN operational community.
このRFCはISOインターネットプロトコル(ISO-IP)とTransportプロトコルレベル4(TP-4)との比較における、DODインターネットプロトコル(IP)と通信制御プロトコル(TCP)の研究から生じる調査評議会のレポートの「第一面」から材料を再生させます。 このRFCの先はタイムリーな方法でExecutive Summaryのテキストを広く利用可能にすることです。 プレゼンテーションの注文を変更しました、そして、丁付けは変化しました。 このRFCは情報だけのために分配されます。 このRFCはDARPA研究団体かDDNの操作上の共同体にどんな方針も確立しません。
938 Miller Feb 85 Internet Reliable Transaction Protocol
Functional and Interface Specification
938 ミラー2月85日のインターネットの信頼できるトランザクションプロトコル機能的、そして、インタフェース仕様
This RFC is being distributed to members of the DARPA research community in order to solicit their reactions to the proposals contained in it. While the issues discussed may not be directly relevant to the research problems of the DARPA community, they may be interesting to a number of researchers and implementors. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements.
このRFCは、それに含まれた提案への彼らの反応に請求するためにDARPA研究団体のメンバーに分配されています。 議論した問題が直接DARPA共同体の研究課題に関連していないかもしれない間、多くの研究者と作成者にとって、それらはおもしろいかもしれません。 このRFCは改良のためにARPA-インターネットコミュニティ、要求議論、および提案のための提案されたプロトコルを勧めます。
937 Reynolds Feb 85 Post Office Protocol - Version 2
937レイノルズ2月85日のPOP--バージョン2
This RFC suggests a simple method for workstations to dynamically access mail from a mailbox server. This RFC specifies a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvement. This memo is a revision of RFC-918.
このRFCはワークステーションがメールボックスサーバからメールにダイナミックにアクセスする簡単なメソッドを勧めます。このRFCはARPA-インターネットコミュニティ、要求議論、および改善提案に提案されたプロトコルを指定します。 このメモはRFC-918の改正です。
Westine & Postel [Page 14] RFC 999 March 1987
Westineとポステル[14ページ]RFC999 1987年3月
936 Karels Feb 85 Another Internet Subnet Addressing
Scheme
936Karels2月85日 別のインターネットサブネットアドレシング体系
There have been several proposals for schemes to allow the use of a single Internet network number to refer to a collection of physical networks under common administration which are reachable from the rest of the Internet by a common route. Such schemes allow a simplified view of an otherwise complicated topology from hosts and gateways outside of this collection. They allow the complexity of the number and type of these networks, and routing to them, to be localized. Additions and changes in configuration thus cause no detectable change, and no interruption of service, due to slow propagation of routing and other information outside of the local environment. These schemes also simplify the administration of the network, as changes do not require allocation of new network numbers for each new cable installed. This proposal discusses an alternative scheme, one that has been in use at the University of California, Berkeley since April 1984. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements.
ただ一つのインターネットネットワーク・ナンバーの使用が体系で一般的な管理の下における一般的なルートによるインターネットの残りによって届いている物理ネットワークの収集を参照できるといういくつかの提案がありました。 そのような体系はこの収集の外にホストとゲートウェイからそうでなければ、複雑なトポロジーの簡易型の視点を許容します。 彼らは、ローカライズされるために数の複雑さを許容して、これらのネットワーク、およびルーティングをそれらにタイプします。 その結果、構成における追加と変化は地方の環境の外でルーティングと他の情報の遅い伝播による検出可能な変化がなく、および停電を全く引き起こしません。 また、これらの体系はネットワークの管理を簡素化します、変化がインストールされたそれぞれの新しいケーブルの新しいネットワーク・ナンバーの配分を必要としないとき。 この提案は代替の体系(1984年4月以来カリフォルニア大学バークレイ校で使用中であるもの)について議論します。 このRFCは改良のためにARPA-インターネットコミュニティ、要求議論、および提案のための提案されたプロトコルを勧めます。
935 Robinson Jan 85 Reliable Link Layer Protocols
935 信頼できるロビンソン1月85日は層のプロトコルをリンクします。
This RFC discusses protocols proposed recently in RFCs 914 and 916, and suggests a proposed protocol that could meet the same needs addressed in those memos. The stated need is reliable communication between two programs over a full-duplex, point-to-point communication link, and in particular the RFCs address the need for such communication over an asynchronous link at relatively low speeds. The suggested protocol uses the methods of existing national and international data link layer standards. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements.
このRFCは最近RFCs914と916で提案されたプロトコルについて議論して、同じであるそれらのメモで扱われた需要のを満たすことができた提案されたプロトコルを勧めます。 述べられた必要性は全二重の上の2つのプログラムの信頼できるコミュニケーションです、二地点間通信リンク、そして、特に、RFCsが比較的低い速度で非同期なリンクの上のそのようなコミュニケーションの必要性を扱います。 提案されたプロトコルは既存の国家的、そして、国際的なデータ・リンク層規格のメソッドを使用します。 このRFCは改良のためにARPA-インターネットコミュニティ、要求議論、および提案のための提案されたプロトコルを勧めます。
934 Rose Jan 85 Proposed Standard for Message
Encapsulation
934 メッセージカプセル化のバラ1月85日の提案された標準
This memo concerns itself with message forwarding. Forwarding can be thought of as encapsulating one or more messages inside another. Although this is useful for transfer of past correspondence to new recipients, without a decapsulation process (which this memo terms "bursting"), the forwarded messages are of little use to the recipients because they can not be distributed, forwarded, replied-to, or otherwise processed as separate individual messages. In order to burst a message it is necessary to know how the component messages were encapsulated in the draft. At present there is no unambiguous standard for interest group digests. This RFC proposes a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements.
このメモはメッセージ推進に携わります。 別のものの中の1つ以上のメッセージをカプセル化すると推進を考えることができます。 これは新しい受取人への過去の通信の転送の役に立ちますが、被膜剥離術プロセス(このメモが「はち切れ」ながら呼ぶ)がなければ、転送されたメッセージは、彼らを分配できませんし、進めることができませんし、答えることができませんし、また別の方法で別々の個々のメッセージとして処理できないので、ほとんど受取人の役に立ちません。 メッセージを押し破くために、コンポーネントメッセージが草稿でどのようにカプセル化されたかを知るのが必要です。 現在のところ、営利団体ダイジェストのどんな明白な規格もありません。 このRFCは改良のためにARPA-インターネットコミュニティ、要求議論、および提案のための提案されたプロトコルを提案します。
Westine & Postel [Page 15] RFC 999 March 1987
Westineとポステル[15ページ]RFC999 1987年3月
933 Silverman Jan 85 Output Marking Telnet Option
933 telnetオプションをマークするシルバーマン1月85日のOutput
This proposed option would allow a Server-Telnet to send a banner to a User-Telnet so that this banner would be displayed on the workstation screen independently of the application software running in the Server-Telnet.
この提案されたオプションで、Server-telnetは、アプリケーション・ソフトの如何にかかわらずServer-telnetへ駆け込みながらワークステーションスクリーンにこのバナーを表示するようにUser-telnetにバナーを送ることができるでしょう。
932 Clark Jan 85 A Subnetwork Addressing Scheme
932 サブネットワークアドレシング体系あたりのクラーク1月85日
This RFC proposes an alternative addressing scheme for subnets which, in most cases, requires no modification to host software whatsoever. The drawbacks of this scheme are that the total number of subnets in any one network are limited, and that modification is required to all gateways.
このRFCはサブネットの多くの場合、全くソフトウェアをホスティングするために変更を全く必要としない代替のアドレシング体系を提案します。この体系の欠点はどんなネットワークでも、サブネットの総数が限られていて、変更がすべてのゲートウェイに必要であるということです。
931 StJohns Jan 85 Authentication Server
931StJohns1月85日認証サーバ
This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements. This is the second draft of this proposal (superseding RFC-912) and incorporates a more formal description of the syntax for the request and response dialog, as well as a change to specify the type of user identification returned.
このRFCは改良のためにARPA-インターネットコミュニティ、要求議論、および提案のための提案されたプロトコルを勧めます。 これは、この提案(RFC-912に取って代わる)の第2草案であり、返されたユーザ登録名のタイプを指定するために要求と応答対話のための構文の、より正式な記述、および変化を取り入れます。
930 Solomon Jan 85 Telnet Terminal Type Option
930 ソロモンの1月85日のtelnet端末タイプオプション
This RFC specifies a standard for the ARPA Internet community. Hosts on the ARPA Internet that exchange terminal type information within the Telnet protocol are expected to adopt and implement this standard. This standard supersedes RFC-884. The only change is to specify that the TERMINAL-TYPE IS sub-negotiation should be sent only in response to the TERMINAL-TYPE SEND sub-negotiation.
このRFCはARPAインターネットコミュニティの規格を指定します。 ARPAインターネットのTelnetプロトコルの中で端末のタイプ情報を交換するホストは、この規格を採用して、実装すると予想されます。 この規格はRFC-884に取って代わります。 唯一の変化が、TERMINAL-TYPE ISサブ交渉が単にTERMINAL-TYPE SENDサブ交渉に対応して送られるべきであると指定することになっています。
929 Lilienkamp Dec 84 Proposed Host-Front End Protocol
929 Lilienkamp12月84日はホストフロントエンドプロトコルを提案しました。
The Host-Front End Protocol introduced in RFC-928 is described in detail in this memo. The first order of business is to declare that THIS IS A PROPOSAL, NOT A FINAL STANDARD, and the second order of business is to request that any readers of these documents who are able to do test implementations (a) do so and (b) coordinate their efforts with the author. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements.
RFC-928で紹介されたHost-前部Endプロトコルはこのメモで詳細に説明されます。 最初の議題がA FINAL STANDARD、および2番目の議題ではなく、THIS IS A PROPOSALが、実装(a)をテストできるこれらのドキュメントのどんな読者もそうするよう要求することになっていると宣言することであり、(b) 座標は作者がいるそれらの取り組みです。 このRFCは改良のためにARPA-インターネットコミュニティ、要求議論、および提案のための提案されたプロトコルを勧めます。
928 Padlipsky Dec 84 Introduction to Proposed DOD Standard
H-FP
928 提案されたDOD標準のH-fpへのPadlipsky12月84日の序論
The broad outline of the Host-Front End Protocol introduced here and described in RFC-929 is the result of the deliberations of a number of experienced H-FP designers, who sat as a committee of the DoD Protocol Standards Technical Panel. It is the intent of the designers that the protocol be subjected to multiple test implementations and probable iteration before being agreed upon as any sort of "standard".
ここで紹介されて、RFC-929で説明されたHost-前部Endプロトコルの広いアウトラインは多くの経験豊富なH-FPデザイナーの熟考の結果です。(そのデザイナーは、DoDプロトコルStandards Technical Panelの委員会として座りました)。 それはデザイナーの意図です。どんな種類の「標準」としても同意される前にプロトコルは複数のテスト実装とありえそうな繰り返しにかけられます。
Westine & Postel [Page 16] RFC 999 March 1987
Westineとポステル[16ページ]RFC999 1987年3月
Therefore, the first order of business is to declare that THIS IS A PROPOSAL, NOT A FINAL STANDARD, and the second order of business is to request that any readers of these documents who are able to do test implementations (a) do so and (b) coordinate their efforts with the author. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements.
したがって、最初の議題がA FINAL STANDARD、および2番目の議題ではなく、THIS IS A PROPOSALが、実装(a)をテストできるこれらのドキュメントのどんな読者もそうするよう要求することになっていると宣言することであり、(b) 座標は作者がいるそれらの取り組みです。 このRFCは改良のためにARPA-インターネットコミュニティ、要求議論、および提案のための提案されたプロトコルを勧めます。
927 Anderson Dec 84 TACACS User Identification Telnet
Option
927 アンダーソン12月84日のTACACSユーザ登録名telnetオプション
The following is the description of a TELNET option designed to facilitate double login avoidance. It is intended primarily for TAC connections to target hosts on behalf of TAC users, but it can be used between any two consenting hosts. For example, all hosts at one site (e.g., BBN) can use this option to avoid double login when TELNETing to one another. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements.
↓これは二重ログイン回避を容易にするように設計されたTELNETオプションの記述です。 それはTAC接続が主としてTACユーザを代表してホストを狙うことを意図しますが、どんな2人の同意しているホストの間でもそれを使用できます。 例えば、1つのサイト(例えば、BBN)のすべてのホストが、お互いへのTELNETingであるときに、二重ログインを避けるのにこのオプションを使用できます。 このRFCは改良のためにARPA-インターネットコミュニティ、要求議論、および提案のための提案されたプロトコルを勧めます。
926 ISO Dec 84 Protocol for Providing the
Connectionless-Mode Network Services
926 コネクションレスなモードネットワーク・サービスを提供するためのISO12月84日のプロトコル
This note is the draft ISO protocol roughly similar to the DOD Internet Protocol. This document has been prepared by retyping the text of ISO DIS 8473 of May 1984, which is currently undergoing voting within ISO as a Draft International Standard (DIS). This document is distributred as an RFC for information only. It does not specify a standard for the ARPA-Internet.
この注意はおよそDODインターネットプロトコルと同様の草稿ISOプロトコルです。 このドキュメントは、1984年5月のISO DIS8473のテキストを再びタイプで打つことによって、準備されました。5月は現在、国際規格案(DIS)としてISOの中の票を受けています。 このドキュメントは情報だけのためのRFCとしてdistributredされます。 それはARPA-インターネットの規格を指定しません。
925 Postel Oct 84 Multi-LAN Address Resolution
925 ポステル10月84日のマルチLANアドレス解決
The problem of treating a set of local area networks (LANs) as one Internet network has generated some interest and concern. It is inappropriate to give each LAN within an site a distinct Internet network number. It is desirable to hide the details of the interconnections between the LANs within an site from people, gateways, and hosts outside the site. The question arises on how to best do this, and even how to do it at all. In RFC-917 Jeffery Mogul makes a case for the use of "explicit subnets" in a multi-LAN environment. The explicit subnet scheme is a call to recursively apply the mechanisms the Internet uses to manage networks to the problem of managing LANs within one network. In this note I urge another approach: the use of "transparent subnets" supported by a multi-LAN extension of the Address Resolution Protocol. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements.
1つのインターネット網として1セットのローカル・エリア・ネットワーク(LAN)を扱うという問題は何らかの関心と関心を生みました。 サイトの中の各LANに異なったインターネットネットワーク・ナンバーを与えるのは不適当です。 サイトの外に人々、ゲートウェイ、およびホストからインタコネクトの詳細をサイトの中のLANの間に隠すのは望ましいです。 全くどのようにそれをするかというさえ質問は起こります。 RFC-917ジェフェリーでは、ムガール人はマルチLAN環境における「明白なサブネット」の使用のために主張します。 明白なサブネット体系はインターネットが1つのネットワークの中でLANを管理するという問題にネットワークを経営するのに使用するメカニズムを再帰的に適用するという要求です。 この注意では、私は別のアプローチを主張します: Address ResolutionプロトコルのマルチLAN拡大でサポートされた「透明なサブネット」の使用。 このRFCは改良のためにARPA-インターネットコミュニティ、要求議論、および提案のための提案されたプロトコルを勧めます。
924 Reynolds Oct 84 Official ARPA-Internet Protocols
924 レイノルズ10月84日の公式のアルパインターネットプロトコル
This RFC identifies the documents specifying the official protocols used in the Internet. This edition of Official ARPA-Internet Protocols obsoletes RFC-900 and earlier editions. This memo is an official status report on the protocols used in the ARPA-Internet community. See RFC-991.
このRFCはインターネットで使用される公式のプロトコルを指定するドキュメントを特定します。 Official ARPA-インターネットプロトコルのこの版はRFC-900と以前の版を時代遅れにします。 このメモはARPA-インターネットコミュニティで使用されるプロトコルに関する公式の現状報告です。 RFC-991を見てください。
Westine & Postel [Page 17] RFC 999 March 1987
Westineとポステル[17ページ]RFC999 1987年3月
923 Reynolds Oct 84 Assigned Numbers
923 レイノルズ10月84日は数を割り当てました。
This RFC documents the currently assigned values from several series of numbers used in network protocol implementations. This edition of Assigned Numbers obsoletes RFC-900 and earlier editions. This memo is an official status report on the numbers used in protocols in the ARPA-Internet community. See RFC-990, and 997.
このRFCはネットワーク・プロトコル実装に使用されるいくつかのシリーズの数から現在割り当てられた値を記録します。 Assigned民数記のこの版はRFC-900と以前の版を時代遅れにします。 このメモはARPA-インターネットコミュニティのプロトコルに使用される数に関する公式の現状報告です。 RFC-990、および997を見てください。
922 Mogul Oct 84 Broadcasting Internet Datagrams in the
Presence of Subnets
922 サブネットがあるときインターネットデータグラムを放送するムガール人10月84日
We propose simple rules for broadcasting Internet datagrams on local networks that support broadcast, for addressing broadcasts, and for how gateways should handle them. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements.
サポートが放送を扱うために放送した企業内情報通信網でインターネットデータグラムを放送して、ゲートウェイがどうそれらを扱うはずであるように、私たちは簡単な規則を提案するか。 このRFCは改良のためにARPA-インターネットコミュニティ、要求議論、および提案のための提案されたプロトコルを勧めます。
921 Postel Oct 84 Domain Name System Implementation
Schedule - Revised
921 ポステル10月84日のドメインネームシステム遂行スケジュール--復習します。
This memo is a policy statement on the implementation of the Domain Style Naming System in the Internet. This memo is an update of RFC-881, and RFC-897. This is an official policy statement of the IAB and the DARPA. The intent of this memo is to detail the schedule for the implementation for the Domain Style Naming System. The explanation of how this system works is to be found in the references.
このメモはインターネットのDomain様式Naming Systemの実装に関する施政方針です。 このメモはRFC-881、およびRFC-897の最新版です。 これはIABとDARPAの公式方針声明です。 このメモの意図はDomain様式Naming Systemのために実装のためのスケジュールを詳しく述べることです。 このシステムがどう動作するかに関する説明は参照で見つけられることです。
920 Postel Oct 84 Domain Requirements
920 ポステル10月84日のドメイン要求性
This memo states the requirements on establishing a Domain, and introduces the limited set of top level domains. This memo is a policy statement on the requirements of establishing a new domain in the ARPA-Internet and the DARPA research community. This is an official policy statement of the IAB and the DARPA.
このメモは、Domainを設立することに関する要件を述べて、限られたセットのトップ・レベル・ドメインを導入します。 このメモはARPA-インターネットとDARPA研究団体に新しいドメインを確立する要件に関する施政方針です。 これはIABとDARPAの公式方針声明です。
919 Mogul Oct 84 Broadcasting Internet Datagrams
919 インターネットデータグラムを放送するムガール人10月84日
This RFC proposes simple rules for broadcasting Internet datagrams on local networks that support broadcast, for addressing broadcasts, and for how gateways should handle them. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements.
サポートが放送を扱うために放送した企業内情報通信網でインターネットデータグラムを放送して、ゲートウェイがどうそれらを扱うはずであるように、このRFCは簡単な規則を提案するか。 このRFCは改良のためにARPA-インターネットコミュニティ、要求議論、および提案のための提案されたプロトコルを勧めます。
918 Reynolds Oct 84 Post Office Protocol (POP)
918 レイノルズ10月84日のPOP(ポップス)です。
This RFC suggests a simple method for workstations to dynamically access mail from a mailbox server. The intent of the Post Office Protocol (POP) is to allow a user's workstation to access mail from a mailbox server. It is expected that mail will be posted from the workstation to the mailbox server via the Simple Mail Transfer Protocol (SMTP). This RFC specifies a proposed protocol for the ARPA-Internet community, and
このRFCはワークステーションがメールボックスサーバからメールにダイナミックにアクセスする簡単なメソッドを示します。ポストオフィスプロトコル(POP)の意図はユーザのワークステーションがメールボックスサーバからメールにアクセスするのを許容することです。シンプルメールトランスファプロトコル(SMTP)でメールがワークステーションからメールボックスサーバまで掲示されると予想されます。 そしてこのRFCがARPA-インターネットコミュニティに提案されたプロトコルを指定する。
Westine & Postel [Page 18] RFC 999 March 1987
Westineとポステル[18ページ]RFC999 1987年3月
requests discussion and suggestions for improvement. The status of this protocol is experimental, and this protocol is dependent upon TCP.
議論と改善提案を要求します。 このプロトコルの状態は実験しています、そして、このプロトコルはTCPに依存しています。
917 Mogul Oct 84 Internet Subnets
917 要人10月84日のインターネットサブネット
This memo discusses subnets and proposes procedures for the use of subnets, including approaches to solving the problems that arise, particularly that of routing. A subnet of an Internet network is a logically visible sub-section of a single Internet network. For administrative or technical reasons, many organizations have chosen to divide one Internet network into several subnets, instead of acquiring a set of Internet network numbers. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements.
このメモは、サブネットの使用のためにサブネットについて議論して、手順を提案します、起こる問題を解決することへのアプローチ、特にルーティングのものを含んでいて。 インターネット網のサブネットはただ一つのインターネット網の論理的に目に見える小区分です。 管理的、または、技術的な理由で、多くの組織が、1つのインターネット網をいくつかのサブネットに分割するのを選びました、1セットのインターネットネットワーク・ナンバーを取得することの代わりに。 このRFCは改良のためにARPA-インターネットコミュニティ、要求議論、および提案のための提案されたプロトコルを勧めます。
916 Finn Oct 84 Reliable Asynchronous Transfer Protocol
(RATP)
916 フィンランド人10月84日の信頼できる非同期な転送プロトコル(RATP)
This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements. This paper proposes and specifies a protocol which allows two programs to reliably communicate over a communication link. It ensures that the data entering one end of the link if received arrives at the other end intact and unaltered. The protocol, named RATP, is designed to operate over a full duplex point-to-point connection. It contains some features which tailor it to the RS-232 links now in common use.
このRFCは改良のためにARPA-インターネットコミュニティ、要求議論、および提案のための提案されたプロトコルを勧めます。 この論文は、2つのプログラムが通信リンクの上で確かに伝えるプロトコルを、提案して、指定します。 それは、受け取るならリンクの片端に入るデータが他の終わりの完全で非変更に到着するのを確実にします。 RATPというプロトコルは、全二重二地点間接続の上で作動するように設計されています。 それは現在共用のRS-232リンクにそれを仕立てるいくつかの特徴を含んでいます。
915 Elvy Dec 84 Network Mail Path Service
915 Elvy12月84日のネットワークメール経路サービス
This RFC proposed a new service for the ARPA-Internet community and requests discussion and suggestions for improvements. The network mail path service fills the current need of people to determine mailbox addresses for hosts that are not part of the ARPA-Internet but can be reached by one or more relay hosts that have Unix to Unix Copy (UUCP) mail, CSNET mail, MAILNET mail, BITNET mail, etc. Anyone can use the service if they have TCP/TELENET to one of the hosts with a mail path server.
このRFCは改良のためのARPA-インターネットコミュニティ、要求議論、および提案のための新しいサービスを提案しました。 ネットワークメール経路サービスにARPA-インターネットの一部でないホストのために人々がメールボックスアドレスを決定する現在の必要性をいっぱいにしていますが、Unix Copy(UUCP)メール、CSNETメール、MAILNETメール、BitnetメールなどにUnixを持っている1人以上の中継ホストが連絡できます。 彼らがメール経路サーバでTCP/テレネットをホストのひとりに持っているなら、だれでもサービスを利用できます。
914 Farber Sep 84 A Thinwire Protocol
914 Thinwireプロトコルあたりのファーバー9月84日
This RFC focuses discussion on the particular problems in the ARPA-Internet of low speed network interconnection with personal computers, and possible methods of solution. None of the proposed solutions in this document are intended as standards for the ARPA-Internet. Rather, it is hoped that a general consensus will emerge as to the appropriate solution to the problems, leading eventually to the adoption of standards.
このRFCはパーソナルコンピュータがある低速ネットワーク相互接続のARPA-インターネット、およびソリューションの可能なメソッドで特定の問題に議論の焦点を合わせます。 提案されたソリューションのいずれもARPA-インターネットの規格として本書では意図しません。 むしろ、全体的な合意が適切なソリューションに関して問題に現れることが望まれています、結局規格の採用に通じて。
Westine & Postel [Page 19] RFC 999 March 1987
Westineとポステル[19ページ]RFC999 1987年3月
913 Lottor Sep 84 Simple File Transfer Protocol
913 Lottor9月84日の簡単なファイル転送プロトコル
This memo describes a proposed Simple File Transfer Protocol (SFTP). It fills the need of people wanting a protocol that is more useful than TFTP but easier to implement (and less powerful) than FTP. SFTP supports user access control, file transfers, directory listing, directory changing, file renaming and deleting. Discussion of this proposal is encouraged, and suggestions for improvements may be sent to the author.
このメモは提案されたSimple File Transferプロトコル(SFTP)について説明します。 それはTFTPより役に立ちますが、FTPより実装しやすくて(それほど強力でない)であるプロトコルが欲しい人々の必要性をいっぱいにしています。 SFTPはコントロール、ファイル転送、ディレクトリリスト、ディレクトリ変化、ファイル改名、および削除をユーザアクセスに支えます。 この提案の議論を奨励します、そして、改良のための提案を作者に送るかもしれません。
912 StJohns Sep 84 Authentication Service
912StJohns9月84日認証サービス
This memo describes a proposed authentication protocol for verifying the identity of a user of a TCP connection. Given a TCP port number pair, it returns a character string which identifies the owner of that connection on the server's system. Suggested uses include automatic identification and verification of a user during an FTP session, additional verification of a TAC dial up user, and access verification for a generalized network file server.
このメモは、TCP接続のユーザのアイデンティティについて確かめるために提案された認証プロトコルについて説明します。 TCPポートナンバー組を考えて、それはサーバのシステムの上でその接続の所有者を特定する文字列を返します。 提案された用途はFTPセッション、TACのダイヤルアップユーザの追加検証、および一般化されたネットワークファイルサーバのためのアクセス検証の間、ユーザの自動識別と検証を含んでいます。
911 Kirton Aug 84 EGP Gateway under Berkeley Unix 4.2
911 バークレーunix4.2の下におけるカートン8月84日のEGPゲートウェイ
This memo describes an implementation of the Exterior Gateway Protocol (EGP) (in that sense it is a status report). The memo also discusses some possible extentions and some design issues (in that sense it is an invitation for further discussion).
このメモはExteriorゲートウェイプロトコル(EGP)の実装について説明します(その意味で、それは現状報告です)。 また、メモはいくつかの可能なextentionsといくつかのデザイン問題について議論します(その意味で、それはさらなる議論のための招待状です)。
910 Forsdick Aug 84 Multimedia Mail Meeting Notes
910 注意を満たすForsdick8月84日のマルチメディアメール
This memo is a report on a meeting about the experimental multimedia mail system (and in a sense a status report on that experiment). The meeting was held at Bolt Beranek and Newman on 23-24 July 1984 to discuss recent progress by groups who are building multimedia mail systems and to discuss a variety of issues related to the further development of multimedia systems. Representatives were present from BBN, ISI, SRI and Linkabit.
このメモは実験用マルチメディアメールシステム(そして、ある意味でその実験に関する現状報告)の周りのミーティングに関するレポートです。 会合が、1984年7月23日から24日にマルチメディアメールシステムを構築しているグループで最近の進歩について議論して、マルチメディア・システムのさらなる開発に関連するさまざまな問題について議論するためにBolt Beranekとニューマンで行われました。代表はBBN、ISI、SRI、およびLinkabitから出席していました。
909 Welles Jul 84 Loader Debugger Protocol
909 ウェルズ7月84日の荷物を積む人デバッガプロトコル
The Loader Debugger Protocol (LDP) is an application layer protocol for loading, dumping, and debugging target machines from hosts in a network environment. This RFC specifies a proposed protocol for the ARPA-Internet and DARPA research community, and requests discussion and suggestions for improvemts.
Loader Debuggerプロトコル(自由民主党)は、ホストからネットワーク環境でターゲットマシンを積み込んで、捨てて、デバッグするための応用層プロトコルです。 このRFCはARPA-インターネットとDARPA研究団体に提案されたプロトコルを指定して、improvemtsのために議論と提案を要求します。
908 Velten Jul 84 Reliable Data Protocol
908 フェルテン7月84日の確実な資料プロトコル
The Reliable Data Protocol (RDP) is designed to provide a reliable data transport service for packet-based applications. This RFC specifies a proposed protocol for the ARPA-Internet and DARPA research community, and requests discussion and suggestions for improvemts.
Reliable Dataプロトコル(RDP)は、パケットベースのアプリケーションのための確実な資料輸送サービスを提供するように設計されています。 このRFCはARPA-インターネットとDARPA研究団体に提案されたプロトコルを指定して、improvemtsのために議論と提案を要求します。
Westine & Postel [Page 20] RFC 999 March 1987
Westineとポステル[20ページ]RFC999 1987年3月
907 Storch Jul 84 Host Access Protocol Specification
907 シュトルヒ7月84日のホストアクセスプロトコル仕様
This document specifies the Host Access Protocol (HAP). Although HAP was originally designed as the network-access level protocol for the DARPA/DCA sponsored Wideband Packet Satellite Network, it is intended that it evolve into a standard interface SATNET and TACNET (aka MATNET) as well as the Wideband Network. HAP is an experimental protocol, and will undergo further revision as new capabilities are added and/or different satellite networks are suported. Implementations of HAP should be performed in coordination with satellite network development and operations personnel.
このドキュメントはHost Accessプロトコル(HAP)を指定します。 DARPA/DCAのためのネットワークアクセスの平らなプロトコルがWideband Packet Satellite Networkを後援したとき、HAPは元々設計されましたが、それがWideband Networkと同様に標準インターフェースSATNETとTACNET(通称MATNET)に発展することを意図します。 HAPは実験プロトコルであり、新しい能力が加えられるとき、さらなる改正を受けるでしょう、そして、異なった衛星ネットワークはsuportedされます。 HAPの実装は衛星ネットワーク開発と業務職員と共にコーディネートで実行されるべきです。
906 Finlayson Jun 84 Bootstrap Loading Using TFTP
906 TFTPを使用して、フィンリースン6月84日はローディングを独力で進みます。
It is often convenient to be able to bootstrap a computer system from a communications network. This RFC proposes the use of the IP TFTP protocol for bootstrap loading in this case.
通信網からコンピュータ・システムを独力で進むことができるのはしばしば便利です。 このRFCがIP TFTPプロトコルの使用を提案する、この場合ローディングを独力で進んでください。
905 ISO Apr 84 ISO Transport Protocol Specification
(ISO DP 8073)
905 ISO4月84日のISO輸送プロトコル仕様(ISO DP8073)
This is the current specification of the ISO Transport Protocol. This document is the text of ISO/TC97/SC16/N1576 as corrected by ISO/TC97/SC16/N1695. This is the specification currently being voted on in ISO as a Draft International Standard (DIS). This document is distributed as an RFC for your information only, it does not specify a standard for the ARPA-Internet or DARPA research community. Our thanks to Alex McKenzie of BBN for making this online version available. Please note the size of this document, the file contains 258,729 characters.
これはISO Transportプロトコルの現在の仕様です。 ISO/TC97/SC16/N1695によって修正されるようにこのドキュメントはISO/TC97/SC16/N1576のテキストです。 これは国際規格案(DIS)として現在ISOで投票される仕様です。 このドキュメントはあなたの情報だけのためのRFCとして配布されて、それはARPA-インターネットかDARPA研究団体の規格を指定しません。 このオンラインバージョンを利用可能にするためのBBNのアレックス・マッケンジーへの私たちの感謝。 このドキュメントのサイズに注意してください、そして、ファイルは25万8729文字を含んでいます。
904 Mills Apr 84 Exterior Gateway Protocol Formal
Specification
904工場の4月84日の外のゲートウェイは形式仕様を議定書の中で述べます。
RFC-904 is the specification of the Exterior Gateway Protocol (EGP). This memo updates portions of RFC-888 and RFC-827. This RFC specifies an official protocol of the DARPA community for use between gateways of different autonomous systems in the ARPA-Internet.
RFC-904はExteriorゲートウェイプロトコル(EGP)の仕様です。 このメモはRFC-888とRFC-827の一部をアップデートします。 このRFCはARPA-インターネットで異なった自律システムのゲートウェイの間の使用にDARPA共同体の公式のプロトコルを指定します。
903 Finlayson Jun 84 A Reverse Address Resolution Protocol
903 1逆アドレス解決プロトコルあたりのフィンリースン6月84日
This RFC suggests a method for workstations to dynamically find their protocol address (e.g., their Internet Address), when they know only their hardware address (e.g., their attached physical network address). This RFC specifies a proposed protocol for the ARPA Internet community, and requests discussion and suggestions for improvements.
このRFCはワークステーションがそれらのプロトコルがアドレス(例えば、それらのインターネットAddress)であることがダイナミックにわかるメソッドを勧めます、彼らが自分達のハードウェア・アドレス(例えば、彼らの添付の物理ネットワークアドレス)だけを知っているとき。 このRFCはARPAインターネットコミュニティ、要求議論、および提案のための提案されたプロトコルを改良に指定します。
Westine & Postel [Page 21] RFC 999 March 1987
Westineとポステル[21ページ]RFC999 1987年3月
902 Postel Jul 84 ARPA-Internet Protocol Policy
902 ポステル7月84日のアルパインターネットプロトコル方針
The purpose of this memo is to explain how protocol standards are adopted for the ARPA-Internet and the DARPA research community. There are three important aspects to be discussed: the process, the authority, and the complex relationship between the DARPA community and the DDN community. This memo is a policy statement on how protocols become official standards for the ARPA-Internet and the DARPA research community. This is an official policy statement of the ICCB and the DARPA.
このメモの目的はプロトコル標準がどうARPA-インターネットとDARPA研究団体に採用されるかを説明することです。 議論するために、3つの重要な一面があります: DARPA共同体とDDN共同体とのプロセス、権威、および複雑な関係。 このメモはプロトコルがどうARPA-インターネットとDARPA研究団体の公式の規格になるかの施政方針です。 これはICCBとDARPAの公式方針声明です。
901 Reynolds Jun 84 Official ARPA-Internet Protocols
901 レイノルズ6月84日の公式のアルパインターネットプロトコル
This RFC identifies the documents specifying the official protocols used in the ARPA-Internet. Annotations identify any revisions or changes planned. This memo is an official status report on the protocols used in the DARPA research community. See RFC-991.
このRFCはARPA-インターネットで使用される公式のプロトコルを指定するドキュメントを特定します。 注釈がどんな改正も特定するか、または変化は計画されていました。 このメモはDARPA研究団体で使用されるプロトコルに関する公式の現状報告です。 RFC-991を見てください。
900 Reynolds Jun 84 Assigned Numbers
900 レイノルズ6月84日は数を割り当てました。
This RFC specifies parameter values use in the Internet family of protocols, such as network numbers, well known ports, protocol types, and version numbers. This memo is an official status report on the protocol parameters used in the Internet protocol system. See RFC-990 and 997.
このRFCは値がプロトコルのインターネットファミリーに使用するパラメタを指定します、ネットワーク・ナンバーや、よく知られているポートや、プロトコルタイプや、バージョン番号などのように。 このメモはインターネットプロトコルシステムで使用されるプロトコルパラメタに関する公式の現状報告です。 RFC-990と997を見てください。
Westine & Postel [Page 22]
Westineとポステル[22ページ]
一覧
スポンサーリンク
