RFC944 日本語訳
0944 Official ARPA-Internet protocols. J.K. Reynolds, J. Postel. April 1 1985. (Format: TXT=61373 bytes) (Obsoletes RFC0924) (Obsoleted by RFC0961) (Status: UNKNOWN)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group J. Reynolds
Request for Comments: 944 J. Postel
ISI
Obsoletes: RFCs 924, 901, 880, 840 April 1985
コメントを求めるワーキンググループJ.レイノルズの要求をネットワークでつないでください: 944 J.ポステルISIは以下を時代遅れにします。 RFCs924、901、880、840 1985年4月
OFFICIAL ARPA-INTERNET PROTOCOLS
公式のアルパインターネットプロトコル
STATUS OF THIS MEMO
このメモの状態
This memo is an official status report on the protocols used in the ARPA-Internet community. Distribution of this memo is unlimited.
このメモはARPA-インターネットコミュニティで使用されるプロトコルに関する公式の現状報告です。 このメモの分配は無制限です。
INTRODUCTION
序論
This RFC identifies the documents specifying the official protocols used in the Internet. Comments indicate any revisions or changes planned.
このRFCはインターネットで使用される公式のプロトコルを指定するドキュメントを特定します。 コメントは、どんな改正や変化も計画されていたのを示します。
To first order, the official protocols are those in the "Internet Protocol Transition Workbook" (IPTW) dated March 1982. There are several protocols in use that are not in the IPTW. A few of the protocols in the IPTW have been revised. Notably, the mail protocols have been revised and issued as a volume titled "Internet Mail Protocols" dated November 1982. Telnet and the most useful Telnet options have been revised and issued as a volume titled "Internet Telnet Protocol and Options" (ITP) dated June 1983. Some protocols have not been revised for many years, these are found in the old "ARPANET Protocol Handbook" (APH) dated January 1978. There is also a volume of protocol related information called the "Internet Protocol Implementers Guide" (IPIG) dated August 1982.
最初に、オーダーに、公式のプロトコルは1982年3月付けの「インターネットプロトコル変遷ワークブック」(IPTW)のそれらです。 IPTWにない使用中のいくつかのプロトコルがあります。 IPTWのプロトコルのいくつかは改訂されました。 ボリュームが1982年11月付けの「インターネットメールプロトコル」を題をつけたので、メールプロトコルを著しく、改訂して、発行しました。 ボリュームが1983年6月付けの(ITP)と「インターネットテルネット・プロトコルとオプション」を題をつけたので、telnetと最も役に立つTelnetオプションを改訂して、発行しました。 いくつかのプロトコルは何年間も改訂されていなくて、これらは古い1978年1月付けの「アルパネットプロトコルハンドブック」(APH)で見つけられます。 また、1982年8月付けの「インターネットプロトコルImplementersガイド」(IPIG)と呼ばれるプロトコル関連情報のボリュームがあります。
This document is organized as a sketchy outline. The entries are protocols (e.g., Transmission Control Protocol). In each entry there are notes on status, specification, comments, other references, dependencies, and contact.
このドキュメントは不完全なアウトラインとしてまとめられます。 エントリーはプロトコル(例えば、通信制御プロトコル)です。 各エントリーに、注意が状態、仕様、コメント、他の参照、依存、および接触にあります。
The STATUS is one of: required, recommended, elective, or
experimental.
STATUS、以下が1つがあります。 必要であるか、お勧め的か、選挙的か、または実験的です。
The SPECIFICATION identifies the protocol defining documents.
SPECIFICATIONはプロトコル定義文書を特定します。
The COMMENTS describe any differences from the specification or
problems with the protocol.
COMMENTSはプロトコルに関する仕様か問題からどんな違いについても説明します。
The OTHER REFERENCES identify documents that comment on or expand
on the protocol.
OTHER REFERENCESはプロトコルについて批評するか、または詳述するドキュメントを特定します。
The DEPENDENCIES indicate what other protocols are called upon by
this protocol.
DEPENDENCIESは、どんな他のプロトコルがこのプロトコルによって訪問されるかを示します。
Reynolds & Postel [Page 1]
レイノルズとポステル[1ページ]
Official ARPA-Internet Protocols RFC 944
公式のアルパインターネットプロトコルRFC944
The CONTACT indicates a person who can answer questions about the
protocol.
CONTACTはプロトコルに関する質問に答えることができる人を示します。
In particular, the status may be:
状態は特に、以下の通りです。
required
必要です。
- all hosts must implement the required protocol,
- すべてのホストが必要なプロトコルを実装しなければなりません。
recommended
推薦されます。
- all hosts are encouraged to implement the recommended
protocol,
- すべてのホストがお勧めのプロトコルを実装するよう奨励されます。
elective
選択科目
- hosts may implement or not the elective protocol,
- ホストは実装するかもしれませんが、選挙のプロトコルが実装しないかもしれません。
experimental
実験的
- hosts should not implement the experimental protocol
unless they are participating in the experiment and have
coordinated their use of this protocol with the contact
person, and
- そしてホストが彼らが実験に参加していない場合実験プロトコルを実装するべきでなくて、連絡窓口との彼らのこのプロトコルの使用を調整した。
none
なし
- this is not a protocol.
- これはプロトコルではありません。
For further information about protocols in general, please
contact:
一般に、プロトコルに関する詳細に関しては、以下に連絡してください。
Joyce Reynolds
USC - Information Sciences Institute
4676 Admiralty Way
Marina del Rey, California 90292-6695
ジョイスレイノルズUSC--情報Sciences Institute4676海軍本部Wayマリナデルレイ、カリフォルニア90292-6695
Phone: (213) 822-1511
以下に電話をしてください。 (213) 822-1511
ARPA mail: JKREYNOLDS@USC-ISIF.ARPA
ARPAメール: JKREYNOLDS@USC-ISIF.ARPA
Reynolds & Postel [Page 2]
レイノルズとポステル[2ページ]
Official ARPA-Internet Protocols RFC 944
公式のアルパインターネットプロトコルRFC944
OVERVIEW
概要
Catenet Model ------------------------------------------------------
Catenetモデル------------------------------------------------------
STATUS: None
状態: なし
SPECIFICATION: IEN 48 (in IPTW)
仕様: IEN48(IPTWの)
COMMENTS:
コメント:
Gives an overview of the organization and principles of the
Internet.
組織の概要とインターネットの原則を与えます。
Could be revised and expanded.
改訂して、広げることができました。
OTHER REFERENCES:
他の参照:
RFC 871 - A Perspective on the ARPANET Reference Model
RFC871--アルパネット規範モデルの上の見解
Padlipsky, M.A., "The Elements of Networking Style and other
Essays and Animadversions on the Art of Intercomputer
Networking", Prentice-Hall, New Jersey, 1985.
Padlipsky、M.A.、「Intercomputer NetworkingのArtの上のNetworking様式、他のEssays、およびAnimadversionsのElements」、Prentice-ホール、ニュージャージー、1985。
Leiner, Barry, Robert Cole, Jon Postel and Dave Mills, "The
DARPA Protocol Suite", IEEE INFOCOM 85, Washington, D.C.,
March 1985. Also in IEEE Communications Magazine, March 1985.
Leinerとバリーとロバート・コールとジョン・ポステルとデーヴ工場、「DARPAプロトコル群」、1985年のIEEE INFOCOM85、ワシントンDC行進。 IEEEコミュニケーション雑誌、1985年3月にも。
DEPENDENCIES:
依存:
CONTACT: Postel@USC-ISIF.ARPA
接触: Postel@USC-ISIF.ARPA
Reynolds & Postel [Page 3]
レイノルズとポステル[3ページ]
Official ARPA-Internet Protocols RFC 944
公式のアルパインターネットプロトコルRFC944
NETWORK LEVEL
ネットワークレベル
Internet Protocol --------------------------------------------- (IP)
インターネットプロトコル--------------------------------------------- (IP)
STATUS: Required
状態: 必要です。
SPECIFICATION: RFC 791 (in IPTW)
仕様: RFC791(IPTWの)
COMMENTS:
コメント:
This is the universal protocol of the Internet. This datagram
protocol provides the universal addressing of hosts in the
Internet.
これはインターネットの普遍的なプロトコルです。 このデータグラムプロトコルはホストの普遍的なアドレシングをインターネットに提供します。
A few minor problems have been noted in this document.
いくつかの小さな問題が本書では注意されました。
The most serious is a bit of confusion in the route options.
The route options have a pointer that indicates which octet of
the route is the next to be used. The confusion is between the
phrases "the pointer is relative to this option" and "the
smallest legal value for the pointer is 4". If you are
confused, forget about the relative part, the pointer begins
at 4.
最も重大であるのは、ルートオプションで少しの混乱です。 ルートオプションには、ルートのどの八重奏が使用されるべき次であるかを示す指針があります。 「指針はこのオプションに比例してい」て「指針のための最も小さい正当な値は4インチである」という句の間には、混乱があります。 混乱するなら、相対的な部分を忘れてください、そして、指針は4時に始まります。
Another important point is the alternate reassembly procedure
suggested in RFC 815.
重要なもう1ポイントはRFC815に示された代替の再アセンブリ手順です。
Some changes are in the works for the security option.
セキュリティオプションにおいて、いくつかの変化が計画中です。
Note that ICMP is defined to be an integral part of IP. You
have not completed an implementation of IP if it does not
include ICMP.
ICMPがIPの不可欠の部分になるように定義されることに注意してください。 それがICMPを含んでいないなら、あなたはIPの実装を完成していません。
OTHER REFERENCES:
他の参照:
RFC 815 (in IPIG) - IP Datagram Reassembly Algorithms
RFC815(IPIGの)--IPデータグラムReassemblyアルゴリズム
RFC 814 (in IPIG) - Names, Addresses, Ports, and Routes
RFC814(IPIGの)--名前、アドレス、ポート、およびルート
RFC 816 (in IPIG) - Fault Isolation and Recovery
RFC816(IPIGの)--欠点分離と回復
RFC 817 (in IPIG) - Modularity and Efficiency in Protocol
Implementation
RFC817(IPIGの)--プロトコル実装におけるモジュール方式と効率
MIL-STD-1777 - Military Standard Internet Protocol
軍規格-1777--軍事の標準のインターネットプロトコル
DEPENDENCIES:
依存:
CONTACT: Postel@USC-ISIF.ARPA
接触: Postel@USC-ISIF.ARPA
Reynolds & Postel [Page 4]
レイノルズとポステル[4ページ]
Official ARPA-Internet Protocols RFC 944
公式のアルパインターネットプロトコルRFC944
Internet Control Message Protocol --------------------------- (ICMP)
インターネット・コントロール・メッセージ・プロトコル--------------------------- (ICMP)
STATUS: Required
状態: 必要です。
SPECIFICATION: RFC 792 (in IPTW)
仕様: RFC792(IPTWの)
COMMENTS:
コメント:
The control messages and error reports that go with the
Internet Protocol.
インターネットプロトコルを伴うコントロールメッセージとエラー・レポート。
A few minor errors in the document have been noted.
Suggestions have been made for additional types of redirect
message and additional destination unreachable messages.
ドキュメントにおけるいくつかの軽い過失が注意されました。 追加タイプの再直接のメッセージと追加送信不可能メッセージのために提案をしました。
A proposal for two additional ICMP message types is made in
RFC 917 "Internet Subnets", Address Format Request (A1=17), and
Address Format Reply (A2=18). The details of these ICMP types
are subject to change. Use of these ICMP types is
experimental.
RFC917「インターネットサブネット」、Address Format Request(A1=17)、およびAddress Format Reply(A2=18)で2つの追加ICMPメッセージタイプのための提案をします。 ICMPタイプを条件としているこれらの詳細は変化します。 これらのICMPタイプの使用は実験的です。
Note that ICMP is defined to be an integral part of IP. You
have not completed an implementation of IP if it does not
include ICMP.
ICMPがIPの不可欠の部分になるように定義されることに注意してください。 それがICMPを含んでいないなら、あなたはIPの実装を完成していません。
OTHER REFERENCES: RFC 917
他の参照: RFC917
DEPENDENCIES: Internet Protocol
依存: インターネットプロトコル
CONTACT: Postel@USC-ISIF.ARPA
接触: Postel@USC-ISIF.ARPA
Reynolds & Postel [Page 5]
レイノルズとポステル[5ページ]
Official ARPA-Internet Protocols RFC 944
公式のアルパインターネットプロトコルRFC944
HOST LEVEL
ホストレベル
User Datagram Protocol --------------------------------------- (UDP)
ユーザー・データグラム・プロトコル--------------------------------------- (UDP)
STATUS: Recommended
状態: 推薦されます。
SPECIFICATION: RFC 768 (in IPTW)
仕様: RFC768(IPTWの)
COMMENTS:
コメント:
Provides a datagram service to applications. Adds port
addressing to the IP services.
アプリケーションへのデータグラムサービスを提供します。 IPにサービスを扱うポートを加えます。
The only change noted for the UDP specification is a minor
clarification that if in computing the checksum a padding octet
is used for the computation it is not transmitted or counted in
the length.
UDP仕様で有名である唯一の変化はチェックサムを計算する際に、詰め物八重奏が計算に使用されるなら、長さで伝わらなかったか、または重要でなかった小さい方の明確化です。
OTHER REFERENCES:
他の参照:
DEPENDENCIES: Internet Protocol
依存: インターネットプロトコル
CONTACT: Postel@USC-ISIF.ARPA
接触: Postel@USC-ISIF.ARPA
Transmission Control Protocol -------------------------------- (TCP)
通信制御プロトコル-------------------------------- (TCP)
STATUS: Recommended
状態: 推薦されます。
SPECIFICATION: RFC 793 (in IPTW)
仕様: RFC793(IPTWの)
COMMENTS:
コメント:
Provides reliable end-to-end data stream service.
終わりから終わりに対するデータ・ストリーム信頼できるサービスを提供します。
Many comments and corrections have been received for the TCP
specification document. These are primarily document bugs
rather than protocol bugs.
TCP仕様ドキュメントのために多くのコメントと修正を受けました。 これらは主としてプロトコルバグよりむしろドキュメントバグです。
Event Processing Section: There are many minor corrections and
clarifications needed in this section.
イベント処理部: 多くの小さい方の修正とこのセクションで必要である明確化があります。
Push: There are still some phrases in the document that give a
"record mark" flavor to the push. These should be further
clarified. The push is not a record mark.
以下を押してください。 まだ、ドキュメントの「レコード・マーク」風味をプッシュに与える数個の句があります。 これらはさらにはっきりさせられるべきです。 プッシュはレコード・マークではありません。
Urgent: Page 17 is wrong. The urgent pointer points to the
last octet of urgent data (not to the first octet of non-ungent
data).
緊急: 17ページは間違っています。 緊急の指針は緊急のデータ(非「非-紳士」データの最初の八重奏でないことへの)の最後の八重奏を示します。
Reynolds & Postel [Page 6]
レイノルズとポステル[6ページ]
Official ARPA-Internet Protocols RFC 944
公式のアルパインターネットプロトコルRFC944
Listening Servers: Several comments have been received on
difficulties with contacting listening servers. There should
be some discussion of implementation issues for servers, and
some notes on alternative models of system and process
organization for servers.
聴取サーバ: 聴取サーバに連絡する困難でいくつかのコメントを受けました。 サーバのための導入問題の何らかの議論、およびサーバのためのシステムとプロセス組織の代替のモデルに関するいくつかの注があるべきです。
Maximum Segment Size: The maximum segment size option should
be generalized and clarified. It can be used to either
increase or decrease the maximum segment size from the default.
The TCP Maximum Segment Size is the IP Maximum Datagram Size
minus forty. The default IP Maximum Datagram Size if 576. The
default TCP Maximum Segment Size is 536. For further
discussion, see RFC 879.
最大のセグメントサイズ: 最大のセグメントサイズオプションは、広められて、はっきりさせられるべきです。 デフォルトから最大のセグメントサイズを増強するか、または減少させるのにそれを使用できます。 TCP Maximum Segment Sizeは40を引いたIP MaximumデータグラムSizeです。 デフォルトIP MaximumデータグラムSize、576です。 デフォルトTCP Maximum Segment Sizeは536歳です。 さらなる議論に関しては、RFC879を見てください。
Idle Connections: There have been questions about
automatically closing idle connections. Idle connections are
ok, and should not be closed. There are several cases where
idle connections arise, for example, in Telnet when a user is
thinking for a long time following a message from the server
computer before his next input. There is no TCP "probe"
mechanism, and none is needed.
コネクションズを空費してください: およそ自動的に無駄な接続を終える質問がありました。 無駄な接続は、間違いなく、閉店するべきではありません。 彼の次の入力の前に長い間サーバー・コンピュータからのメッセージに従って、ユーザが考えているとき、数個のケースが例えば無駄な接続がTelnetで起きるところにあります。 TCP「徹底的調査」メカニズムが全くありません、そして、なにも必要ではありません。
Queued Receive Data on Closing: There are several points where
it is not clear from the description what to do about data
received by the TCP but not yet passed to the user,
particularly when the connection is being closed. In general,
the data is to be kept to give to the user if he does a RECV
call.
閉鎖に関する列に並ばせられた受信データ: 数ポイントがTCPによって受け取られますが、まだユーザに渡されていなかったデータに関して何をしたらよいかが記述によって明確でないところにあります、特に接続が閉店しているとき。 一般に、データは彼がRECV呼び出しをするならユーザに与えるために保たれることです。
Out of Order Segments: The description says that segments that
arrive out of order, that is, are not exactly the next segment
to be processed, may be kept on hand. It should also point out
that there is a very large performance penalty for not doing
so.
不適切なセグメント: 記述は、処理されるためにすなわち、故障していた状態で到着するセグメントがまさに次のセグメントでないと言って、あるように保たれるかもしれません。 また、それは、そうしないための非常に大きいパフォーマンスに不利な条件があると指摘するべきです。
User Time Out: This is the time out started on an open or send
call. If this user time out occurs the user should be
notified, but the connection should not be closed or the TCB
deleted. The user should explicitly ABORT the connection if he
wants to give up.
ユーザタイムアウト: これは戸外に始められたタイムアウトであるか呼び出しを送ってください。 このユーザタイムアウトが起こるなら、ユーザは通知されるべきですが、接続が閉じられるべきではありませんか、またはTCBは削除されています。 ユーザは明らかにあきらめるべきです。接続のABORTは彼であるならあきらめたがっています。
OTHER REFERENCES:
他の参照:
RFC 813 (in IPIG) - Window and Acknowledgement Strategy in TCP
RFC813(IPIGの)--TCPの窓と承認戦略
RFC 814 (in IPIG) - Names, Addresses, Ports, and Routes
RFC814(IPIGの)--名前、アドレス、ポート、およびルート
RFC 816 (in IPIG) - Fault Isolation and Recovery
RFC816(IPIGの)--欠点分離と回復
Reynolds & Postel [Page 7]
レイノルズとポステル[7ページ]
Official ARPA-Internet Protocols RFC 944
公式のアルパインターネットプロトコルRFC944
RFC 817 (in IPIG) - Modularity and Efficiency in Protocol
Implementation
RFC817(IPIGの)--プロトコル実装におけるモジュール方式と効率
RFC 879 - TCP Maximum Segment Size
RFC879--TCPの最大のセグメントサイズ
RFC 889 - Internet Delay Experiments
RFC889--インターネット遅れ実験
RFC 896 - TCP/IP Congestion Control
RFC896--TCP/IP輻輳制御
MIL-STD-1778 - Military Standard Transmission Control Protocol
軍規格-1778--軍事の標準の通信制御プロトコル
DEPENDENCIES: Internet Protocol
依存: インターネットプロトコル
CONTACT: Postel@USC-ISIF.ARPA
接触: Postel@USC-ISIF.ARPA
Host Monitoring Protocol ------------------------------------- (HMP)
モニターしているプロトコルをホスティングしてください。------------------------------------- (HMP)
STATUS: Elective
状態: 選択科目
SPECIFICATION: RFC 869
仕様: RFC869
COMMENTS:
コメント:
This is a good tool for debugging protocol implementations in
remotely located computers.
これは、離れて見つけられたコンピュータでプロトコル実装をデバッグするための良いツールです。
This protocol is used to monitor Internet gateways and the
TACs.
このプロトコルは、インターネット・ゲートウェイとTACsをモニターするのに使用されます。
OTHER REFERENCES:
他の参照:
DEPENDENCIES: Internet Protocol
依存: インターネットプロトコル
CONTACT: Hinden@BBN-UNIX.ARPA
接触: Hinden@BBN-UNIX.ARPA
Cross Net Debugger ------------------------------------------ (XNET)
ネットのデバッガに交差してください。------------------------------------------ (XNET)
STATUS: Elective
状態: 選択科目
SPECIFICATION: IEN 158
仕様: IEN158
COMMENTS:
コメント:
A debugging protocol, allows debugger like access to remote
systems.
デバッグは、リモートシステムへのアクセスのように議定書を作って、デバッガを許容します。
This specification should be updated and reissued as an RFC.
RFCとしてこの仕様をアップデートして、再発行するべきです。
OTHER REFERENCES: RFC 643
他の参照: RFC643
Reynolds & Postel [Page 8]
レイノルズとポステル[8ページ]
Official ARPA-Internet Protocols RFC 944
公式のアルパインターネットプロトコルRFC944
DEPENDENCIES: Internet Protocol
依存: インターネットプロトコル
CONTACT: Postel@USC-ISIF.ARPA
接触: Postel@USC-ISIF.ARPA
"Stub" Exterior Gateway Protocol ----------------------------- (EGP)
「スタッブ」外のゲートウェイプロトコル----------------------------- (EGP)
STATUS: Recommended for Gateways
状態: ゲートウェイに推薦されます。
SPECIFICATION: RFC 888, RFC 904
仕様: RFC888、RFC904
COMMENTS:
コメント:
The protocol used between gateways of different administrations
to exchange routing information.
プロトコルは交換ルーティングへの異なった政権のゲートウェイの間で情報を使用しました。
Please discuss any plans for implementation or use of this
protocol with the contact.
このプロトコルの実装か使用のためのあらゆるプランについて接触と議論してください。
OTHER REFERENCES: RFC 827, RFC 890
他の参照: RFC827、RFC890
DEPENDENCIES: Internet Protocol
依存: インターネットプロトコル
CONTACT: Mills@USC-ISID.ARPA
接触: Mills@USC-ISID.ARPA
Gateway Gateway Protocol ------------------------------------- (GGP)
ゲートウェイゲートウェイプロトコル------------------------------------- (GGP)
STATUS: Experimental
状態: 実験的
SPECIFICATION: RFC 823
仕様: RFC823
COMMENTS:
コメント:
The gateway protocol now used in the core gateways.
ゲートウェイプロトコルは今や、コアでゲートウェイを使用しました。
Please discuss any plans for implementation or use of this
protocol with the contact.
このプロトコルの実装か使用のためのあらゆるプランについて接触と議論してください。
OTHER REFERENCES:
他の参照:
DEPENDENCIES: Internet Protocol
依存: インターネットプロトコル
CONTACT: Brescia@BBN-UNIX.ARPA
接触: Brescia@BBN-UNIX.ARPA
Reynolds & Postel [Page 9]
レイノルズとポステル[9ページ]
Official ARPA-Internet Protocols RFC 944
公式のアルパインターネットプロトコルRFC944
Multiplexing Protocol ---------------------------------------- (MUX)
マルチプレクシングプロトコル---------------------------------------- (多重化装置)
STATUS: Experimental
状態: 実験的
SPECIFICATION: IEN 90
仕様: IEN90
COMMENTS:
コメント:
Defines a capability to combine several segments from different
higher level protocols in one IP datagram.
1個のIPデータグラムの異なったより高い平らなプロトコルからいくつかのセグメントを結合する能力を定義します。
No current experiment in progress. There is some question as
to the extent to which the sharing this protocol envisions can
actually take place. Also, there are some issues about the
information captured in the multiplexing header being (a)
insufficient, or (b) over specific.
進行中の現在の実験がありません。 このプロトコルが思い描く共有が実際に行われることができる範囲に関して何らかの質問があります。 また、特定な上にマルチプレクシングヘッダー存在(a)で不十分な状態で得られた情報、または(b)に関するいくつかの問題があります。
Please discuss any plans for implementation or use of this
protocol with the contact.
このプロトコルの実装か使用のためのあらゆるプランについて接触と議論してください。
OTHER REFERENCES:
他の参照:
DEPENDENCIES: Internet Protocol
依存: インターネットプロトコル
CONTACT: Postel@USC-ISIF.ARPA
接触: Postel@USC-ISIF.ARPA
Stream Protocol ----------------------------------------------- (ST)
ストリームプロトコル----------------------------------------------- (ST)
STATUS: Experimental
状態: 実験的
SPECIFICATION: IEN 119
仕様: IEN119
COMMENTS:
コメント:
A gateway resource allocation protocol designed for use in
multihost real time applications.
ゲートウェイ資源配分プロトコルは使用のために「マルチ-ホスト」でリアルタイムのアプリケーションを設計しました。
The implementation of this protocol has evolved and may no
longer be consistent with this specification. The document
should be updated and issued as an RFC.
このプロトコルの実装は、発展して、もうこの仕様と一致していないかもしれません。 RFCとしてドキュメントをアップデートして、発行するべきです。
Please discuss any plans for implementation or use of this
protocol with the contact.
このプロトコルの実装か使用のためのあらゆるプランについて接触と議論してください。
OTHER REFERENCES:
他の参照:
DEPENDENCIES: Internet Protocol
依存: インターネットプロトコル
CONTACT: jwf@LL-EN.ARPA
接触: jwf@LL-EN.ARPA
Reynolds & Postel [Page 10]
レイノルズとポステル[10ページ]
Official ARPA-Internet Protocols RFC 944
公式のアルパインターネットプロトコルRFC944
Network Voice Protocol ------------------------------------ (NVP-II)
ネットワーク声のプロトコル------------------------------------ (NVP-II)
STATUS: Experimental
状態: 実験的
SPECIFICATION: ISI Internal Memo
仕様: ISI社内メモ
COMMENTS:
コメント:
Defines the procedures for real time voice conferencing.
リアルタイムの音声会議のために手順を定義します。
The specification is an ISI Internal Memo which should be
updated and issued as an RFC.
仕様はRFCとしてアップデートして、発行するべきであるISI Internal Memoです。
Please discuss any plans for implementation or use of this
protocol with the contact.
このプロトコルの実装か使用のためのあらゆるプランについて接触と議論してください。
OTHER REFERENCES: RFC 741
他の参照: RFC741
DEPENDENCIES: Internet Protocol, Stream Protocol
依存: インターネットプロトコル、ストリームプロトコル
CONTACT: Casner@USC-ISIB.ARPA
接触: Casner@USC-ISIB.ARPA
Reliable Data Protocol --------------------------------------- (RDP)
確実な資料プロトコル--------------------------------------- (RDP)
STATUS: Experimental
状態: 実験的
SPECIFICATION: RFC 908
仕様: RFC908
COMMENTS:
コメント:
This protocol is designed to efficiently support the bulk
transfer of data for such host monitoring and control
applications as loading/dumping and remote debugging. The
protocol is intended to be simple to implement but still be
efficient in environments where there may be long transmission
delays and loss or non-sequential delivery of message segments.
このプロトコルは、嵩がロードするか、またはどさっと落とすようなホストモニターと制御アプリケーションのためのデータ転送とリモートデバッグであると効率的にサポートするように設計されています。 メッセージ・セグメントの長いトランスミッション遅れと損失か非連続した配送があるかもしれないところで環境でまだ効率的であるのを除いて、実装するのがプロトコルが簡単であることを意図します。
OTHER REFERENCES:
他の参照:
DEPENDENCIES: Internet Protocol
依存: インターネットプロトコル
CONTACT: CWelles@BBN-UNIX.ARPA
接触: CWelles@BBN-UNIX.ARPA
Reynolds & Postel [Page 11]
レイノルズとポステル[11ページ]
Official ARPA-Internet Protocols RFC 944
公式のアルパインターネットプロトコルRFC944
Internet Reliable Transaction Protocol ---------------------- (IRTP)
インターネットの信頼できるトランザクションプロトコル---------------------- (IRTP)
STATUS: Experimental
状態: 実験的
SPECIFICATION: RFC 938
仕様: RFC938
COMMENTS:
コメント:
This protocol is a transport level host to host protocol
designed for an internet environment. 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.
このプロトコルはレベルがインターネット環境のために設計されたホストプロトコルに主催する輸送です。 議論した問題が直接DARPA共同体の研究課題に関連していないかもしれない間、多くの研究者と作成者にとって、それらはおもしろいかもしれません。
OTHER REFERENCES:
他の参照:
DEPENDENCIES: Internet Protocol
依存: インターネットプロトコル
CONTACT: Trudy@ACC.ARPA
接触: Trudy@ACC.ARPA
Reynolds & Postel [Page 12]
レイノルズとポステル[12ページ]
Official ARPA-Internet Protocols RFC 944
公式のアルパインターネットプロトコルRFC944
APPLICATION LEVEL
アプリケーションレベル
Telnet Protocol ------------------------------------------- (TELNET)
テルネット・プロトコル------------------------------------------- (telnet)
STATUS: Recommended
状態: 推薦されます。
SPECIFICATION: RFC 854 (in "Internet Telnet Protocol and
Options")
仕様: RFC854(「インターネットテルネット・プロトコルとオプション」における)
COMMENTS:
コメント:
The protocol for remote terminal access.
遠隔端末アクセサリーのためのプロトコル
This has been revised since the IPTW. RFC 764 in IPTW is now
obsolete.
IPTW以来これは改訂されています。 IPTWのRFC764は現在、時代遅れです。
OTHER REFERENCES:
他の参照:
MIL-STD-1782 - Telnet Protocol
軍規格-1782--テルネット・プロトコル
DEPENDENCIES: Transmission Control Protocol
依存: 通信制御プロトコル
CONTACT: Postel@USC-ISIF.ARPA
接触: Postel@USC-ISIF.ARPA
Reynolds & Postel [Page 13]
レイノルズとポステル[13ページ]
Official ARPA-Internet Protocols RFC 944
公式のアルパインターネットプロトコルRFC944
Telnet Options ------------------------------------ (TELNET-OPTIONS)
telnetオプション------------------------------------ (telnetオプション)
STATUS: Elective
状態: 選択科目
SPECIFICATION: General description of options: RFC 855
(in "Internet Telnet Protocol and Options")
仕様: オプションの概説: RFC855(「インターネットテルネット・プロトコルとオプション」における)
Number Name RFC NIC ITP APH USE
------ --------------------------------- --- ----- --- --- ---
0 Binary Transmission 856 ----- yes obs yes
1 Echo 857 ----- yes obs yes
2 Reconnection ... 15391 no yes no
3 Suppress Go Ahead 858 ----- yes obs yes
4 Approx Message Size Negotiation ... 15393 no yes no
5 Status 859 ----- yes obs yes
6 Timing Mark 860 ----- yes obs yes
7 Remote Controlled Trans and Echo 726 39237 no yes no
8 Output Line Width ... 20196 no yes no
9 Output Page Size ... 20197 no yes no
10 Output Carriage-Return Disposition 652 31155 no yes no
11 Output Horizontal Tabstops 653 31156 no yes no
12 Output Horizontal Tab Disposition 654 31157 no yes no
13 Output Formfeed Disposition 655 31158 no yes no
14 Output Vertical Tabstops 656 31159 no yes no
15 Output Vertical Tab Disposition 657 31160 no yes no
16 Output Linefeed Disposition 658 31161 no yes no
17 Extended ASCII 698 32964 no yes no
18 Logout 727 40025 no yes no
19 Byte Macro 735 42083 no yes no
20 Data Entry Terminal 732 41762 no yes no
21 SUPDUP 734 736 42213 no yes no
22 SUPDUP Output 749 45449 no no no
23 Send Location 779 ----- no no no
24 Terminal Type 930 ----- no no no
25 End of Record 885 ----- no no no
26 TACACS User Identification 927 ----- no no no
27 Output Marking 933 ----- no no no
255 Extended-Options-List 861 ----- yes obs yes
数の名前RFC NIC ITP APH使用------ --------------------------------- --- ----- --- --- --- 0 2進のトランスミッション856----- はいobsはい1のEcho857----- はい、obsはい2のReconnection… 15391 いいえ、はい、いいえ、3Suppress Go Ahead858----- はい、obsはい4のApprox Message Size Negotiation… 15393 いいえ、はい、いいえ、5Status859----- はいobsはい6のTimingマーク860----- はいobsはい7のRemote Controlled TransとEcho726 39237 8Output線のはいノーないWidth… 20196 いいえ、はい、いいえ、9OutputページSize… 20197ノー、はいノー10、はDisposition652 31155ノーはいノー11Output Horizontal Tabstops653 31156ノーはいノー12Output Horizontal Tab Disposition654 31157ノーはいノー13Output Formfeed Disposition655 31158ノーはいノー14Output Vertical Tabstops656 31159ノー、にはいノー15Output Vertical Tab DispositionをOutput Carriage返します; 657 31160ノーはいノー16Output Linefeed Disposition658 31161ノーExtendedのはいノー17ASCII698 32964ノーはいノー18Logout727 40025ノーはいノー19Byte Macro735 42083ノーはいノー20Data Entry Terminal732 41762ノーはいノー21SUPDUP734 736 42213ノーはいノー22SUPDUP Output749 45449ノーいいえいいえ23、Send Location779----- いいえ、いいえ、いいえ、24Terminal Type930----- いいえ、いいえ、いいえ、Record885の25End----- いいえ、いいえ、いいえ、26TACACS User Identification927----- いいえ、いいえ、いいえ、27Output Marking933----- いいえ255、Extendedオプションリストがない861がありません。----- はいobsはい
(obs = obsolete)
(obs=時代遅れ)です。
The ITP column indicates if the specification is included in the
Internet Telnet Protocol and Options. The APH column indicates if
the specification is included in the ARPANET Protocol Handbook.
The USE column of the table above indicates which options are in
general use.
ITPコラムは、仕様がインターネットテルネット・プロトコルとOptionsに含まれているかどうかを示します。 APHコラムは、仕様がアルパネットプロトコルHandbookに含まれているかどうかを示します。 上のテーブルに関するUSEコラムは、オプションがどれであるかを示します。一般に、使用します。
Reynolds & Postel [Page 14]
レイノルズとポステル[14ページ]
Official ARPA-Internet Protocols RFC 944
公式のアルパインターネットプロトコルRFC944
COMMENTS:
コメント:
The Binary Transmission, Echo, Suppress Go Ahead, Status,
Timing Mark, and Extended Options List options have been
recently updated and reissued. These are the most frequently
implemented options.
Binary Transmission、Echo、Suppress Go Ahead、Status、Timingマーク、およびExtended Options Listオプションを最近、アップデートして、再発行しました。 これらはオプションであると最も頻繁に実装されます。
The remaining options should be reviewed and the useful ones
should be revised and reissued. The others should be
eliminated.
残っているオプションが見直されるべきであり、役に立つ改訂されて、再発行されるべきです。 他のものは排除されるべきです。
The following are recommended: Binary Transmission, Echo,
Suppress Go Ahead, Status, Timing Mark, and Extended Options
List.
以下はお勧めです: 状態、タイミング・マーク、および拡張オプションは、トランスミッション(エコー)が抑圧するバイナリーが前に進んでいると記載します。
OTHER REFERENCES:
他の参照:
DEPENDENCIES: Telnet
依存: telnet
CONTACT: Postel@USC-ISIF.ARPA
接触: Postel@USC-ISIF.ARPA
File Transfer Protocol --------------------------------------- (FTP)
ファイル転送プロトコル--------------------------------------- (FTP)
STATUS: Recommended
状態: 推薦されます。
SPECIFICATION: RFC 765 (in IPTW)
仕様: RFC765(IPTWの)
COMMENTS:
コメント:
The protocol for moving files between Internet hosts. Provides
for access control and negotiation of file parameters.
移行するためのプロトコルはインターネット・ホストの間にファイルされます。 ファイルパラメタのアクセスコントロールと交渉に備えます。
There are a number of minor corrections to be made. A major
change is the deletion of the mail commands, and a major
clarification is needed in the discussion of the management of
the data connection. Also, a suggestion has been made to
include some directory manipulation commands (RFC 775).
される多くの小さい方の修正があります。 大きな変化はメールコマンドの削除です、そして、主要な明確化がデータ接続の管理の議論で必要です。 また、いくつかのディレクトリ操作命令(RFC775)を含んでいるのを提案をしました。
Even though the MAIL features are defined in this document,
they are not to be used. The SMTP protocol is to be used for
all mail service in the Internet.
メール機能は本書では定義されますが、それらは使用されていることになっていません。 SMTPプロトコルはインターネットでのすべてのメールサービスに使用されることです。
Data Connection Management:
データ接続管理:
a. Default Data Connection Ports: All FTP implementations
must support use of the default data connection ports, and
only the User-PI may initiate the use of non-default ports.
a。 デフォルトデータ接続ポート: すべてのFTP実装がデフォルトデータ接続ポートの使用をサポートしなければなりません、そして、User-PIだけが非デフォルトポートの使用を開始するかもしれません。
b. Negotiating Non-Default Data Ports: The User-PI may
b。 非デフォルトデータを交渉すると、以下は移植されます。 ユーザパイはそうするかもしれません。
Reynolds & Postel [Page 15]
レイノルズとポステル[15ページ]
Official ARPA-Internet Protocols RFC 944
公式のアルパインターネットプロトコルRFC944
specify a non-default user side data port with the PORT
command. The User-PI may request the server side to
identify a non-default server side data port with the PASV
command. Since a connection is defined by the pair of
addresses, either of these actions is enough to get a
different data connection, still it is permitted to do both
commands to use new ports on both ends of the data
connection.
PORTコマンドで非デフォルトユーザサイドデータポートを指定してください。 User-PIは、PASVコマンドで非標準サーバーサイドデータポートを特定するようサーバ側に要求するかもしれません。 接続がアドレスの組によって定義されるので、これらの動作のどちらかが異なったデータ接続を得るために十分である、それでも、データ接続の両端の新しいポートを使用する両方のコマンドをすることが許可されています。
c. Reuse of the Data Connection: When using the stream
mode of data transfer the end of the file must be indicated
by closing the connection. This causes a problem if
multiple files are to be transfered in the session, due to
need for TCP to hold the connection record for a time out
period to guarantee the reliable communication. Thus the
connection can not be reopened at once.
c。 データ接続の再利用: データ転送のストリームモードを使用するとき、接続を終えることによって、ファイルの端を示さなければなりません。 これは複数のファイルがセッションのときにtransferedされることであるなら問題を引き起こします、TCPが信頼できるコミュニケーションを保証するためにタイムアウトの期間、接続記録を保持するのが必要であることで、当然です。 したがって、接続はすぐに、再開できません。
There are two solutions to this problem. The first is to
negotiate a non-default port (as in (b) above). The
second is to use another transfer mode.
この問題への2つの解決があります。 1番目は非デフォルトポートを交渉する(上の(b)のように)ことです。 2番目は別の転送モードを使用することです。
A comment on transfer modes. The stream transfer mode is
inherently unreliable, since one can not determine if the
connection closed prematurely or not. The other transfer
modes (Block, Compressed) do not close the connection to
indicate the end of file. They have enough FTP encoding
that the data connection can be parsed to determine the
end of the file. Thus using these modes one can leave
the data connection open for multiple file transfers.
転送モードのコメント。 人が、接続が早まって閉じたかどうか決定できないで、ストリーム転送モードは本来頼り無いです。 他の転送モード(ブロック、Compressed)は、ファイルの終りを示すために接続を終えません。 データ接続がそうであることができる十分なFTPがコード化されて、ファイルの端を決定するために分析されて、それらはそうしました。 したがって、これらのモード1を使用すると、複数のファイル転送に、オープンな接続にデータを残すことができます。
Why this was not a problem with the old NCP FTP:
これが古いNCP FTPに関する問題でなかった理由:
The NCP was designed with only the ARPANET in mind.
The ARPANET provides very reliable service, and the
NCP counted on it. If any packet of data from an NCP
connection were lost or damaged by the network the NCP
could not recover. It is a tribute to the ARPANET
designers that the NCP FTP worked so well.
NCPはアルパネットだけで念頭に設計されました。 アルパネットは非常に信頼できるサービス、およびそれで数えられたNCPを提供します。 ネットワークが何かNCP接続からのデータのパケットを失われているか、または破損させるなら、NCPは回復できないでしょうに。それはNCP FTPがそれほどよく働かせたアルパネットデザイナーへの捧げ物です。
The TCP is designed to provide reliable connections
over many different types of networks and
interconnections of networks. TCP must cope with a
set of networks that can not promise to work as well
as the ARPANET. TCP must make its own provisions for
end-to-end recovery from lost or damaged packets.
This leads to the need for the connection phase-down
time-out. The NCP never had to deal with
acknowledgements or retransmissions or many other
TCPは、多くの異なったタイプのネットワークとネットワークのインタコネクトの上に頼もしい接続を提供するように設計されています。 TCPはアルパネットと同様に働くと約束できない1セットのネットワークを切り抜けなければなりません。 TCPは無くなっているか破損しているパケットからの終わりから終わりへの回復のためのそれ自身の条項を作らなければなりません。 これは接続の必要性に休止時間を段階的に廃止した状態で通じます。 NCPは他の承認、「再-トランスミッション」または多くとの取引に一度もそうしたことがありませんでした。
Reynolds & Postel [Page 16]
レイノルズとポステル[16ページ]
Official ARPA-Internet Protocols RFC 944
公式のアルパインターネットプロトコルRFC944
things the TCP must do to make connection reliable in
a more complex world.
TCPが、より複雑な世界で接続を信頼できるようにするようにしなければならないこと。
LIST and NLST:
リストとNLST:
There is some confusion about the LIST an NLST commands, and
what is appropriate to return. Some clarification and
motivation for these commands should be added to the
specification.
NLSTが命令するLIST、および返すのが適切であることに関して何らかの混乱があります。 これらのコマンドに関する何らかの明確化と動機が仕様に追加されるべきです。
Multiple 1xx Replies:
複数の1xxが返答します:
There is some difference of opinion about the use of
multiple 1xx responses during command processing. This
issue comes up particularly in processing the RETR and STOR
commands. The two opinions are summarized below.
複数の1xx応答の使用に関して何らかの意見の相違がコマンド処理の間、あります。 この問題は特に処理でRETRとSTORコマンドを来ます。 2つの意見が以下へまとめられます。
For Exactly One 1xx Response:
まさに1つの1xx応答のために:
When a RETR or SEND command is started, the server is
supposed to give an "intermediate reply" of 1xx when it
is opening the data connection. Currently, some FTP
servers give two 1xx messages. This causes problems for
single-thread FTP user implementations. After reading
the first intermediate reply, they go off to do the
transfer. The second 1xx message is not seen until the
end of the transfer. The RFC gives a state diagram of
the form:
RETRかSENDコマンドが始動されるとき、データ接続を開いているとき、サーバは1xxの「中間的回答」を与えるべきです。 現在、いくつかのFTPサーバが2つの1xxメッセージを与えます。 これはシングルスレッドFTPユーザ実装のために問題を起こします。 最初の中間的回答を読んだ後に、彼らは、転送をするために去ります。 2番目の1xxメッセージは転送の終わりまで見られません。 RFCは形式の州のダイヤグラムを与えます:
--------->Wait--------->
/ \
^ |
| V
\ /
<-----
--------->待ち---------> / \ ^ | | V\/<。-----
This implies any number of 1xx's (including 0). There is
a suspicion that this is just sloppy diagraming, and that
the intent is clear from other parts of the RFC.
これは1xxのいろいろなものを含意します(0を含んでいて)。 これがまさしくずさんなdiagramingであり、意図がRFCの他の部分から明確であるという容疑があります。
The FTP specification states that the reason for
intermediate replies is to allow implementations that
can't do any better to know when to stop listening to the
control channel and switch their attention to the data
channel. Given this intent, it seems clear that there
should be exactly one 1xx reply at the start of the
transfer.
FTP仕様は、中間的回答の理由が制御チャンネルとスイッチの言うことを聞くのをいつ止めるかを知るために少しもより上手にできない実装にデータ・チャンネルへの彼らの注意を許すことであると述べます。 この意図を考えて、1つの1xx回答がまさに転送の始めにあるべきであるのは明確に見えます。
The FTP specification is ambiguous in this regard. The
FTP仕様はこの点であいまいです。 The
Reynolds & Postel [Page 17]
レイノルズとポステル[17ページ]
Official ARPA-Internet Protocols RFC 944
公式のアルパインターネットプロトコルRFC944
state diagrams appear to sanction any number of
responses. But the charts before them do not. And from
the intent, it seems obvious that exactly one is the
right thing.
州のダイヤグラムはいろいろな応答を認可するように見えます。 しかし、それらの前のヒットチャートはそうしません。 そして、意図から、ちょうど1つが正しいものであることは明白に見えます。
Consider an implementation on a PC. It is fairly hard to
do parallel processing there. It should be possible for
a PC implementation to stop paying attention to the
control channel and start reading the file from the data
channel when he sees the 1xx response. The only way this
can work is if there is only one 1xx response.
PCの上で実装を考えてください。 かなりそこで並列処理をしにくいです。 PC実装が制御チャンネルに注意を向けるのを止めて、彼が1xx応答を見るときデータ・チャンネルからファイルを読み始めるのは、可能であるべきです。 1つの1xx応答しかなければ、これが働くことができる唯一の方法がそうです。
Of course, one could make it a requirement that every FTP
implementation must be based on good enough interrupt
technology so that it can field extra responses during
the transfer. But what would such a constraint buy?
Just the ability to have both a 125 and a 150 response.
It doesn't seem worth the price. You could just as well
combine the information in those responses into a single
one.
もちろん、1つはそれを転送の間、付加的な応答をさばくことができるようにあらゆるFTP実装を十分良い中断技術に基礎づけなければならないという要件にするかもしれません。 しかし、そのような規制は何を買うでしょうか? 125と150応答の両方を持つまさしく能力。 それは価格の価値があるように見えません。 また、ちょうどあなたはそれらの応答における情報をただ一つのものに結合できました。
For Multiple 1xx Responses:
複数の1xx応答のために:
The multiple 1xx messages arose because the new TCP
specification omitted the 050 spontaneous reply code. A
solution was to change an 050 informational message to a
1xx message, creating both a 125 and a 150.
新しいTCP仕様が050の自然発生的な回答コードを省略したので、複数の1xxメッセージが起こりました。 ソリューションは125と150の両方を作成して、050通報メッセージを1xxメッセージに変えることでした。
The state diagrams clearly allow this, and the
"Command-Reply Sequences" section does not contradict it.
A multiple 1xx implementation is in accord with the
formal reply specifications.
州のダイヤグラムは明確にこれを許容します、そして、「コマンド回答系列」セクションはそれに矛盾しません。 複数の1xx実装が正式な回答仕様に合っています。
A multiple 1xx implementation works with the TOPS-20
FTP's and with a number of different UNIX
implementations, and the LOCUS system. So, a lot of
implementors must follow state diagrams in preference to
prose.
1xx実装がTOPS-20 FTP、多くの異なったUNIX実装、およびLOCUSシステムで扱う倍数。 それで、多くの作成者が散文に優先して州のダイヤグラムに従わなければなりません。
However, the observation is certainly correct that
page 34 of the specification suggests that 1xx replies
can be used by single-thread user implementations to
switch attention to the data connection. This would
allow only a single 1xx message, in contradiction to the
state diagrams. It seems a bit strong, however, to call
the one sentence on page 34 "the intent" of the
specification, since it is contradicted by the format
specification of replies.
しかしながら、確かに、34の仕様ページが1xx回答がシングルスレッドユーザ実装によって使用されて、データ接続への注意を切り換えることができるのを示すという観測は正しいです。 これはただ一つの1xxメッセージだけを許容するでしょう、州のダイヤグラムに反して。しかしながら、34ページの1つの文を仕様の「意図」と呼ぶように少し強く思えます、それが回答の書式仕様によって矛盾されるので。
Reynolds & Postel [Page 18]
レイノルズとポステル[18ページ]
Official ARPA-Internet Protocols RFC 944
公式のアルパインターネットプロトコルRFC944
A side discussion favoring more status information:
より多くの状態情報を支持するサイド議論:
One view has always assumed a two-thread
implementation. In this view, most user
implementations are deficient because they do not
allow the user to enter a STATUS command during data
transfer. A cynic might say that is because the
Computer Scientists who did these implementations only
do "Toy" file transfers, and often use "Toy" operating
systems.
1つの視点がいつも2スレッドの実装を仮定していました。 この視点では、それらがユーザにデータ転送の間、STATUSコマンドを入力させないので、ほとんどのユーザ実装が欠けています。 これらの実装をしたコンピュータScientistsが「おもちゃ」ファイル転送をするだけであり、しばしば「おもちゃ」オペレーティングシステムを使用するので、皮肉屋は、それがそうであると言うかもしれません。
There has been some complaints from the Toy systems
crowd recently that FTP is too complicated. Well, it
may be too complicated for Toy systems, but in fact it
is too simple for many Real file systems. For
example, it has no way to encode a "library" (i.e., a
named collection of subfiles). It is (barely)
adequate for shipping around files of text, but not
much more.
最近、Toyシステム群衆からのいくつかの苦情がありました。FTPは複雑過ぎます。 さて、Toyシステムには複雑過ぎるかもしれませんが、多くのレアルファイルシステムには、事実上、それは簡単過ぎます。例えば、「ライブラリ」(すなわち、「副-ファイル」の命名された収集)をコード化する方法が全くありません。 それは、テキストのファイルの周りで乗船するには(ほとんど)適切ではありませんが、はるかに適切であるというわけではありません。
With the notable exception of Multics and UNIX, many
operating systems support complex file structures of
which the user must be aware. One is not doing the
user a favor by hiding details that may reach out and
bite him. That is the reason some FTPs put out a
large informative message at the beginning of the
transfer, specifying the file baroqueness that is
involved. As a Computer Scientist, you may find that
message annoying, but if you had to use MVS very much,
you would find it helpful, informative, and maybe even
reassuring. Some believe that as DARPA technology
moves into the production environment of DDN, there
will be user requirements for such informative
messages for a variety of vendor operating systems.
MulticsとUNIXの注目に値する例外で、多くのオペレーティングシステムがユーザが意識しているに違いない複雑なファイル構造を支えます。 1つは、彼を前に伸ばして、噛み付くかもしれない詳細を隠すことによって、ユーザに親切なことをしていません。 それはいくつかのFTPが転送の始めに大きい通知メッセージを出す理由です、かかわるファイルバロックを指定して。 コンピュータScientistとして、あなたは、そのメッセージが煩わしいのがわかることができますが、あなたがMVSをたいへん使用しなければならないなら、それが役立っていて、有益で、多分心強くさえあることがわかるでしょうに。 或るものは、DARPA技術がDDNの実稼動環境に移行するのでさまざまなベンダーオペレーティングシステムのためのそのような通知メッセージのためのユーザ要件があると信じています。
To provide important information to the user the
specification should either allow multiple 1xx messages,
or restore the old spontaneous reply category. In fact,
the latter is preferable; this information should be
displayed to the user, but a user FTP might swallow 1xx
messages without displaying their text.
重要情報をユーザに提供するために、仕様は、複数の1xxメッセージを許容するべきであるか、または古い自然発生的な回答カテゴリを回復するべきです。 事実上、後者は望ましいです。 この情報をユーザに表示するべきですが、それらのテキストを表示しないで、ユーザFTPは1xxメッセージを飲み込むかもしれません。
The Answer:
答え:
Following the Robustness Principle (a protocol
implementation ought to inflict minimal pain and accept
maximal pain) there should be only one 1xx response.
That is, those FTP servers that now issue two 1xx
responses should combine them.
Robustness Principle(プロトコル実装は、最小量の痛みを負って、最大限度の痛みを受け入れるべきである)にそこに続くのが、1つの1xx応答であるにすぎないべきです。 すなわち、現在2つの1xx応答を発行するそれらのFTPサーバはそれらを結合するべきです。
Reynolds & Postel [Page 19]
レイノルズとポステル[19ページ]
Official ARPA-Internet Protocols RFC 944
公式のアルパインターネットプロトコルRFC944
OTHER REFERENCES:
他の参照:
RFC 678 - Document File Format Standards
RFC678--ドキュメントファイル形式規格
MIL-STD-1780 - File Transfer Protocol
軍規格-1780--ファイル転送プロトコル
DEPENDENCIES: Transmission Control Protocol
依存: 通信制御プロトコル
CONTACT: Postel@USC-ISIF.ARPA
接触: Postel@USC-ISIF.ARPA
Trivial File Transfer Protocol ------------------------------ (TFTP)
トリビアル・ファイル転送プロトコル------------------------------ (TFTP)
STATUS: Elective
状態: 選択科目
SPECIFICATION: RFC 783 (in IPTW)
仕様: RFC783(IPTWの)
COMMENTS:
コメント:
A very simple file moving protocol, no access control is
provided.
プロトコル、コントロールが提供されるアクセスを全く動かさない非常に簡単なファイル。
This is in use in several local networks.
これはいくつかの企業内情報通信網で使用中です。
Ambiguities in the interpretation of several of the transfer
modes should be clarified, and additional transfer modes could
be defined. Additional error codes could be defined to more
clearly identify problems.
いくつかの転送モードの解釈におけるあいまいさをはっきりさせるべきでした、そして、追加転送モードを定義できました。 より明確に問題を特定するために追加エラーコードを定義できました。
OTHER REFERENCES:
他の参照:
DEPENDENCIES: User Datagram Protocol
依存: ユーザー・データグラム・プロトコル
CONTACT: Postel@USC-ISIF.ARPA
接触: Postel@USC-ISIF.ARPA
Simple File Transfer Protocol ------------------------------- (SFTP)
簡単なファイル転送プロトコル------------------------------- (SFTP)
STATUS: Experimental
状態: 実験的
SPECIFICATION: RFC 913
仕様: RFC913
COMMENTS:
コメント:
SFTP is a simple file transfer protocol. 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.
SFTPは簡単なファイル転送プロトコルです。 それはTFTPより役に立ちますが、FTPより実装しやすくて(それほど強力でない)であるプロトコルが欲しい人々の必要性をいっぱいにしています。 SFTPはコントロール、ファイル転送、ディレクトリリスト、ディレクトリ変化、ファイル改名、および削除をユーザアクセスに支えます。
SFTP can be implemented with any reliable 8-bit byte stream
どんな信頼できる8ビットのバイト・ストリームでもSFTPを実装することができます。
Reynolds & Postel [Page 20]
レイノルズとポステル[20ページ]
Official ARPA-Internet Protocols RFC 944
公式のアルパインターネットプロトコルRFC944
oriented protocol, this document describes its TCP
specification. SFTP uses only one TCP connection; whereas TFTP
implements a connection over UDP, and FTP uses two TCP
connections (one using the TELNET protocol).
指向のプロトコル、このドキュメントはTCP仕様を説明します。 SFTPは1つのTCP接続だけを使用します。 TFTPは2つのTCP接続(TELNETプロトコルを使用する1つ)をUDP、およびFTP用途の上の関係に実装しますが。
Please discuss any plans for implementation or use of this
protocol with the contact.
このプロトコルの実装か使用のためのあらゆるプランについて接触と議論してください。
OTHER REFERENCES:
他の参照:
DEPENDENCIES: Transmission Control Protocol
依存: 通信制御プロトコル
CONTACT: MKL@MIT-XX.ARPA
接触: MKL@MIT-XX.ARPA
Simple Mail Transfer Protocol ------------------------------- (SMTP)
シンプルメールトランスファプロトコル------------------------------- (SMTP)
STATUS: Recommended
状態: 推薦されます。
SPECIFICATION: RFC 821 (in "Internet Mail Protocols")
仕様: RFC821(「インターネットメールプロトコル」による)
COMMENTS:
コメント:
The procedure for transmitting computer mail between hosts.
コンピュータメールをホストの間に伝えるための手順。
This has been revised since the IPTW, it is in the "Internet
Mail Protocols" volume of November 1982. RFC 788 (in IPTW) is
obsolete.
IPTW以来これは改訂されていて、1982年11月の「インターネットメールプロトコル」ボリュームにはそれがあります。 RFC788(IPTWの)は時代遅れです。
There have been many misunderstandings and errors in the early
implementations. Some documentation of these problems can be
found in the file [ISIF]<SMTP>MAIL.ERRORS.
早めの実装には多くの誤解と誤りがありました。 ファイル[ISIF]<SMTP>MAIL.ERRORSでこれらの問題の何らかのドキュメンテーションを見つけることができます。
Some minor differences between RFC 821 and RFC 822 should be
resolved.
RFC821とRFC822の間のいくつかの小異が決議されるべきです。
OTHER REFERENCES:
他の参照:
RFC 822 - Mail Header Format Standards
RFC822--メールヘッダ形式規格
This has been revised since the IPTW, it is in the "Internet
Mail Protocols" volume of November 1982. RFC 733 (in IPTW)
is obsolete. Further revision of RFC 822 is needed to
correct some minor errors in the details of the
specification.
IPTW以来これは改訂されていて、1982年11月の「インターネットメールプロトコル」ボリュームにはそれがあります。 RFC733(IPTWの)は時代遅れです。 RFC822のさらなる改正が、仕様の細目におけるいくつかの軽い過失を修正するのに必要です。
MIL-STD-1781 - Simple Mail Transfer Protocol (SMTP)
軍規格-1781--簡単なメール転送プロトコル(SMTP)
DEPENDENCIES: Transmission Control Protocol
依存: 通信制御プロトコル
Reynolds & Postel [Page 21]
レイノルズとポステル[21ページ]
Official ARPA-Internet Protocols RFC 944
公式のアルパインターネットプロトコルRFC944
CONTACT: Postel@USC-ISIF.ARPA
接触: Postel@USC-ISIF.ARPA
Resource Location Protocol ----------------------------------- (RLP)
リソース位置のプロトコル----------------------------------- (RLP)
STATUS: Elective
状態: 選択科目
SPECIFICATION: RFC 887
仕様: RFC887
COMMENTS:
コメント:
A resource location protocol for use in the ARPA-Internet.
This protocol utilizes the User Datagram Protocol (UDP) which
in turn calls on the Internet Protocol to deliver its
datagrams.
ARPA-インターネットでの使用のためのリソース位置のプロトコル。 このプロトコルはインターネットプロトコルがデータグラムを提供するよう順番に呼びかけるユーザー・データグラム・プロトコル(UDP)を利用します。
OTHER REFERENCES:
他の参照:
DEPENDENCIES: User Datagram Protocol
依存: ユーザー・データグラム・プロトコル
CONTACT: Accetta@CMU-CS-A.ARPA
接触: Accetta@CMU-CS-A.ARPA
Loader Debugger Protocol ------------------------------------- (LDP)
荷物を積む人デバッガプロトコル------------------------------------- (自由民主党)
STATUS: Experimental
状態: 実験的
SPECIFICATION: RFC 909
仕様: RFC909
COMMENTS:
コメント:
Specifies a protocol for loading, dumping and debugging target
machines from hosts in a network environment. It is also
designed to accommodate a variety of target CPU types. It
provides a powerful set of debugging services, while at the
same time, it is structured so that a simple subset may be
implemented in applications like boot loading where efficiency
and space are at a premium.
ホストからネットワーク環境でターゲットマシンを積み込んで、捨てて、デバッグするのにプロトコルを指定します。 また、それは、さまざまな目標CPUタイプに対応するように設計されています。 それは強力なデバッグサービスを提供します、それが同時に、プレミアムには効率とスペースがあるところでロードしながらブーツのようなアプリケーションで簡単な部分集合を実装することができるように構造化されますが。
OTHER REFERENCES:
他の参照:
DEPENDENCIES: Reliable Data Protocol
依存: 確実な資料プロトコル
CONTACT: Hinden@BBN-UNIX.ARPA
接触: Hinden@BBN-UNIX.ARPA
Reynolds & Postel [Page 22]
レイノルズとポステル[22ページ]
Official ARPA-Internet Protocols RFC 944
公式のアルパインターネットプロトコルRFC944
Remote Job Entry --------------------------------------------- (RJE)
リモートジョブエントリ--------------------------------------------- (RJE)
STATUS: Elective
状態: 選択科目
SPECIFICATION: RFC 407 (in APH)
仕様: RFC407(APHの)
COMMENTS:
コメント:
The general protocol for submitting batch jobs and retrieving
the results.
バッチ・ジョブを提出して、結果を検索するための一般的なプロトコル。
Some changes needed for use with TCP.
TCPとの使用に必要であるいくつかの変化。
No known active implementations.
知られているアクティブな実装がありません。
OTHER REFERENCES:
他の参照:
DEPENDENCIES: File Transfer Protocol
Transmission Control Protocol
依存: ファイル転送プロトコルトランスミッション制御プロトコル
CONTACT: Postel@USC-ISIF.ARPA
接触: Postel@USC-ISIF.ARPA
Remote Job Service ---------------------------------------- (NETRJS)
リモート・ジョブサービス---------------------------------------- (NETRJS)
STATUS: Elective
状態: 選択科目
SPECIFICATION: RFC 740 (in APH)
仕様: RFC740(APHの)
COMMENTS:
コメント:
A special protocol for submitting batch jobs and retrieving the
results used with the UCLA IBM OS system.
バッチ・ジョブを提出して、UCLA IBM OSシステムと共に使用される結果を検索するための特別なプロトコル。
Please discuss any plans for implementation or use of this
protocol with the contact.
このプロトコルの実装か使用のためのあらゆるプランについて接触と議論してください。
Revision in progress.
進行中の改正。
OTHER REFERENCES:
他の参照:
DEPENDENCIES: Transmission Control Protocol
依存: 通信制御プロトコル
CONTACT: Braden@UCLA-CCN.ARPA
接触: Braden@UCLA-CCN.ARPA
Reynolds & Postel [Page 23]
レイノルズとポステル[23ページ]
Official ARPA-Internet Protocols RFC 944
公式のアルパインターネットプロトコルRFC944
Remote Telnet Service ------------------------------------ (RTELNET)
リモートtelnetサービス------------------------------------ (RTELNET)
STATUS: Elective
状態: 選択科目
SPECIFICATION: RFC 818
仕様: RFC818
COMMENTS:
コメント:
Provides special access to user Telnet on a remote system.
リモートシステムの上でユーザTelnetへの特別なアクセスを提供します。
OTHER REFERENCES:
他の参照:
DEPENDENCIES: Telnet, Transmission Control Protocol
依存: telnet、通信制御プロトコル
CONTACT: Postel@USC-ISIF.ARPA
接触: Postel@USC-ISIF.ARPA
Graphics Protocol --------------------------------------- (GRAPHICS)
グラフィックスプロトコル--------------------------------------- (グラフィックス)
STATUS: Elective
状態: 選択科目
SPECIFICATION: NIC 24308 (in APH)
仕様: NIC24308(APHの)
COMMENTS:
コメント:
The protocol for vector graphics.
ベクタグラフィックスのためのプロトコル。
Very minor changes needed for use with TCP.
TCPとの使用に必要であるまさしくそのマイナーチェンジ。
No known active implementations.
知られているアクティブな実装がありません。
OTHER REFERENCES:
他の参照:
DEPENDENCIES: Telnet, Transmission Control Protocol
依存: telnet、通信制御プロトコル
CONTACT: Postel@USC-ISIF.ARPA
接触: Postel@USC-ISIF.ARPA
Reynolds & Postel [Page 24]
レイノルズとポステル[24ページ]
Official ARPA-Internet Protocols RFC 944
公式のアルパインターネットプロトコルRFC944
Echo Protocol ----------------------------------------------- (ECHO)
エコープロトコル----------------------------------------------- (エコー)
STATUS: Recommended
状態: 推薦されます。
SPECIFICATION: RFC 862
仕様: RFC862
COMMENTS:
コメント:
Debugging protocol, sends back whatever you send it.
デバッグは、議定書を作って、あなたがそれを送るものなら何でも返送します。
OTHER REFERENCES:
他の参照:
DEPENDENCIES: Transmission Control Protocol
or User Datagram Protocol
依存: 通信制御プロトコルかユーザー・データグラム・プロトコル
CONTACT: Postel@USC-ISIF.ARPA
接触: Postel@USC-ISIF.ARPA
Discard Protocol ----------------------------------------- (DISCARD)
プロトコルを捨ててください。----------------------------------------- (破棄)
STATUS: Elective
状態: 選択科目
SPECIFICATION: RFC 863
仕様: RFC863
COMMENTS:
コメント:
Debugging protocol, throws away whatever you send it.
プロトコルをデバッグして、遠くでの一投はあなたが何であってもそれを送ります。
OTHER REFERENCES:
他の参照:
DEPENDENCIES: Transmission Control Protocol
or User Datagram Protocol
依存: 通信制御プロトコルかユーザー・データグラム・プロトコル
CONTACT: Postel@USC-ISIF.ARPA
接触: Postel@USC-ISIF.ARPA
Character Generator Protocol ----------------------------- (CHARGEN)
文字発生機構プロトコル----------------------------- (CHARGEN)
STATUS: Elective
状態: 選択科目
SPECIFICATION: RFC 864
仕様: RFC864
COMMENTS:
コメント:
Debugging protocol, sends you ASCII data.
デバッグは、議定書を作って、ASCIIデータをあなたに送ります。
OTHER REFERENCES:
他の参照:
DEPENDENCIES: Transmission Control Protocol
or User Datagram Protocol
依存: 通信制御プロトコルかユーザー・データグラム・プロトコル
Reynolds & Postel [Page 25]
レイノルズとポステル[25ページ]
Official ARPA-Internet Protocols RFC 944
公式のアルパインターネットプロトコルRFC944
CONTACT: Postel@USC-ISIF.ARPA
接触: Postel@USC-ISIF.ARPA
Quote of the Day Protocol ---------------------------------- (QUOTE)
今日の名言プロトコル---------------------------------- (引用文)
STATUS: Elective
状態: 選択科目
SPECIFICATION: RFC 865
仕様: RFC865
COMMENTS:
コメント:
Debugging protocol, sends you a short ASCII message.
デバッグは、議定書を作って、短いASCIIメッセージをあなたに送ります。
OTHER REFERENCES:
他の参照:
DEPENDENCIES: Transmission Control Protocol
or User Datagram Protocol
依存: 通信制御プロトコルかユーザー・データグラム・プロトコル
CONTACT: Postel@USC-ISIF.ARPA
接触: Postel@USC-ISIF.ARPA
Active Users Protocol -------------------------------------- (USERS)
アクティブなユーザプロトコル-------------------------------------- (ユーザ)
STATUS: Elective
状態: 選択科目
SPECIFICATION: RFC 866
仕様: RFC866
COMMENTS:
コメント:
Lists the currently active users.
現在活発なユーザを記載します。
OTHER REFERENCES:
他の参照:
DEPENDENCIES: Transmission Control Protocol
or User Datagram Protocol
依存: 通信制御プロトコルかユーザー・データグラム・プロトコル
CONTACT: Postel@USC-ISIF.ARPA
接触: Postel@USC-ISIF.ARPA
Finger Protocol ------------------------------------------- (FINGER)
指のプロトコル------------------------------------------- (指)
STATUS: Elective
状態: 選択科目
SPECIFICATION: RFC 742 (in APH)
仕様: RFC742(APHの)
COMMENTS:
コメント:
Provides information on the current or most recent activity of
a user.
ユーザの現在の、または、最新の活動の情報を提供します。
Some extensions have been suggested.
いくつかの拡大が示されました。
Reynolds & Postel [Page 26]
レイノルズとポステル[26ページ]
Official ARPA-Internet Protocols RFC 944
公式のアルパインターネットプロトコルRFC944
Some changes are are needed for TCP.
いくつかの変化がそうです。TCPに必要です。
OTHER REFERENCES:
他の参照:
DEPENDENCIES: Transmission Control Protocol
依存: 通信制御プロトコル
CONTACT: Postel@USC-ISIF.ARPA
接触: Postel@USC-ISIF.ARPA
WhoIs Protocol ------------------------------------------- (NICNAME)
WhoIsプロトコル------------------------------------------- (NICNAME)
STATUS: Elective
状態: 選択科目
SPECIFICATION: RFC 812 (in IPTW)
仕様: RFC812(IPTWの)
COMMENTS:
コメント:
Accesses the ARPANET Directory database. Provides a way to
find out about people, their addresses, phone numbers,
organizations, and mailboxes.
アルパネットディレクトリデータベースにアクセスします。 人々、彼らのアドレス、電話番号、組織、およびメールボックスを見つける方法を提供します。
OTHER REFERENCES:
他の参照:
DEPENDENCIES: Transmission Control Protocol
依存: 通信制御プロトコル
CONTACT: Feinler@SRI-NIC.ARPA
接触: Feinler@SRI-NIC.ARPA
Domain Name Protocol -------------------------------------- (DOMAIN)
ドメイン名プロトコル-------------------------------------- (ドメイン)
STATUS: Experimental
状態: 実験的
SPECIFICATION: RFC 881, 882, 883
仕様: RFC881、882、883
COMMENTS:
コメント:
OTHER REFERENCES:
他の参照:
RFC 920 - Domain Requirements
RFC920--ドメイン要求性
RFC 921 - Domain Name Implementation Schedule - Revised
RFC921(ドメイン名遂行スケジュール)は復習しました。
DEPENDENCIES: Transmission Control Protocol
or User Datagram Protocol
依存: 通信制御プロトコルかユーザー・データグラム・プロトコル
CONTACT: Mockapetris@USC-ISIF.ARPA
接触: Mockapetris@USC-ISIF.ARPA
Reynolds & Postel [Page 27]
レイノルズとポステル[27ページ]
Official ARPA-Internet Protocols RFC 944
公式のアルパインターネットプロトコルRFC944
HOSTNAME Protocol --------------------------------------- (HOSTNAME)
ホスト名プロトコル--------------------------------------- (ホスト名)
STATUS: Elective
状態: 選択科目
SPECIFICATION: RFC 811 (in IPTW)
仕様: RFC811(IPTWの)
COMMENTS:
コメント:
Accesses the Registered Internet Hosts database (HOSTS.TXT).
Provides a way to find out about a host in the Internet, its
Internet Address, and the protocols it implements.
RegisteredインターネットHostsデータベース(HOSTS.TXT)にアクセスします。 インターネット、インターネットAddress、およびそれが実装するプロトコルでホストを見つける方法を提供します。
OTHER REFERENCES:
他の参照:
RFC 810 - Host Table Specification
RFC810--ホストテーブル仕様
DEPENDENCIES: Transmission Control Protocol
依存: 通信制御プロトコル
CONTACT: Feinler@SRI-NIC.ARPA
接触: Feinler@SRI-NIC.ARPA
Host Name Server Protocol ----------------------------- (NAMESERVER)
ホスト名サーバプロトコル----------------------------- (ネームサーバ)
STATUS: Experimental
状態: 実験的
SPECIFICATION: IEN 116 (in IPTW)
仕様: IEN116(IPTWの)
COMMENTS:
コメント:
Provides machine oriented procedure for translating a host name
to an Internet Address.
インターネットAddressにホスト名を翻訳するためのマシンの指向の手順を提供します。
This specification has significant problems: 1) The name
syntax is out of date. 2) The protocol details are ambiguous,
in particular, the length octet either does or doesn't include
itself and the op code. 3) The extensions are not supported by
any known implementation.
この仕様には、重大な問題があります: 1) 名前構文は時代遅れです。 2) プロトコルの詳細があいまいである、長さの八重奏は特に、するか、またはそれ自体とオペコードを含んでいません。 3) 拡大はどんな知られている実装でも後押しされていません。
This protocol is now abandon in favor of the DOMAIN protocol.
Further implementations of this protocol are not advised.
現在、このプロトコルはDOMAINプロトコルを支持して放棄です。 このプロトコルのさらなる実装は教えられません。
Please discuss any plans for implementation or use of this
protocol with the contact.
このプロトコルの実装か使用のためのあらゆるプランについて接触と議論してください。
OTHER REFERENCES:
他の参照:
DEPENDENCIES: User Datagram Protocol
依存: ユーザー・データグラム・プロトコル
CONTACT: Postel@USC-ISIF.ARPA
接触: Postel@USC-ISIF.ARPA
Reynolds & Postel [Page 28]
レイノルズとポステル[28ページ]
Official ARPA-Internet Protocols RFC 944
公式のアルパインターネットプロトコルRFC944
CSNET Mailbox Name Server Protocol ---------------------- (CSNET-NS)
CSNETメールボックスネームサーバプロトコル---------------------- (CSNET-ナノ秒)
STATUS: Experimental
状態: 実験的
SPECIFICATION: CS-DN-2
仕様: Cs-DN-2
COMMENTS:
コメント:
Provides access to the CSNET data base of users to give
information about users names, affiliations, and mailboxes.
ユーザ名、提携、およびメールボックスに関して知らせるためにユーザのCSNETデータベースへのアクセスを提供します。
Please discuss any plans for implementation or use of this
protocol with the contact.
このプロトコルの実装か使用のためのあらゆるプランについて接触と議論してください。
OTHER REFERENCES:
他の参照:
DEPENDENCIES: Transmission Control Protocol
依存: 通信制御プロトコル
CONTACT: Solomon@UWISC.ARPA
接触: Solomon@UWISC.ARPA
Daytime Protocol ----------------------------------------- (DAYTIME)
昼間のプロトコル----------------------------------------- (昼間)
STATUS: Elective
状態: 選択科目
SPECIFICATION: RFC 867
仕様: RFC867
COMMENTS:
コメント:
Provides the day and time in ASCII character string.
日、時間をASCII文字列に提供します。
OTHER REFERENCES:
他の参照:
DEPENDENCIES: Transmission Control Protocol
or User Datagram Protocol
依存: 通信制御プロトコルかユーザー・データグラム・プロトコル
CONTACT: Postel@USC-ISIF.ARPA
接触: Postel@USC-ISIF.ARPA
Time Server Protocol ---------------------------------------- (TIME)
時間サーバプロトコル---------------------------------------- (時間)
STATUS: Elective
状態: 選択科目
SPECIFICATION: RFC 868
仕様: RFC868
COMMENTS:
コメント:
Provides the time as the number of seconds from a specified
reference time.
秒数として指定された参照時間から時間を提供します。
OTHER REFERENCES:
他の参照:
Reynolds & Postel [Page 29]
レイノルズとポステル[29ページ]
Official ARPA-Internet Protocols RFC 944
公式のアルパインターネットプロトコルRFC944
DEPENDENCIES: Transmission Control Protocol
or User Datagram Protocol
依存: 通信制御プロトコルかユーザー・データグラム・プロトコル
CONTACT: Postel@USC-ISIF.ARPA
接触: Postel@USC-ISIF.ARPA
DCNET Time Server Protocol --------------------------------- (CLOCK)
DCNET時間サーバプロトコル--------------------------------- (時計)
STATUS: Elective
状態: 選択科目
SPECIFICATION: RFC 778
仕様: RFC778
COMMENTS:
コメント:
Provides a mechanism for keeping synchronized clocks.
連動している時計を保つのにメカニズムを提供します。
OTHER REFERENCES:
他の参照:
DEPENDENCIES: Internet Control Message Protocol
依存: インターネット・コントロール・メッセージ・プロトコル
CONTACT: Mills@USC-ISID.ARPA
接触: Mills@USC-ISID.ARPA
SUPDUP Protocol ------------------------------------------- (SUPDUP)
SUPDUPプロトコル------------------------------------------- (SUPDUP)
STATUS: Elective
状態: 選択科目
SPECIFICATION: RFC 734 (in APH)
仕様: RFC734(APHの)
COMMENTS:
コメント:
A special Telnet like protocol for display terminals.
ディスプレー装置のためのプロトコルのような特別なTelnet。
OTHER REFERENCES:
他の参照:
DEPENDENCIES: Transmission Control Protocol
依存: 通信制御プロトコル
CONTACT: Crispin@SU-SCORE.ARPA
接触: Crispin@SU-SCORE.ARPA
Reynolds & Postel [Page 30]
レイノルズとポステル[30ページ]
Official ARPA-Internet Protocols RFC 944
公式のアルパインターネットプロトコルRFC944
Internet Message Protocol ------------------------------------ (MPM)
インターネットメッセージプロトコル------------------------------------ (mpm)
STATUS: Experimental
状態: 実験的
SPECIFICATION: RFC 759
仕様: RFC759
COMMENTS:
コメント:
This is an experimental multimedia mail transfer protocol. The
implementation is called a Message Processing Module or MPM.
これは実験マルチメディアメール転送プロトコルです。 実装はMessage Processing ModuleかMPMと呼ばれます。
Please discuss any plans for implementation or use of this
protocol with the contact.
このプロトコルの実装か使用のためのあらゆるプランについて接触と議論してください。
OTHER REFERENCES:
他の参照:
RFC 767 - Structured Document Formats
RFC767--構造化されたドキュメント・フォーマット
DEPENDENCIES: Transmission Control Protocol
依存: 通信制御プロトコル
CONTACT: Postel@USC-ISIF.ARPA
接触: Postel@USC-ISIF.ARPA
Post Office Protocol - Version 2 ---------------------------- (POP2)
POP--バージョン2---------------------------- (POP2)
STATUS: Experimental
状態: 実験的
SPECIFICATION: RFC 937
仕様: RFC937
COMMENTS:
コメント:
The intent of the Post Office Protocol - Version 2 (POP2) 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).
バージョン2(POP2)はユーザのワークステーションがメールボックスサーバからメールにアクセスするのを許容することです。ポストオフィスプロトコルの意図--シンプルメールトランスファプロトコル(SMTP)でメールがワークステーションからメールボックスサーバまで掲示されると予想されます。
Please discuss any plans for implementation or use of this
protocol with the contact.
このプロトコルの実装か使用のためのあらゆるプランについて接触と議論してください。
OTHER REFERENCES: Obsoletes RFC 918
他の参照: RFC918を時代遅れにします。
DEPENDENCIES: Transmission Control Protocol
依存: 通信制御プロトコル
CONTACT: JKReynolds@USC-ISIF.ARPA
接触: JKReynolds@USC-ISIF.ARPA
Reynolds & Postel [Page 31]
レイノルズとポステル[31ページ]
Official ARPA-Internet Protocols RFC 944
公式のアルパインターネットプロトコルRFC944
Network Standard Text Editor ------------------------------- (NETED)
標準のテキストエディタをネットワークでつないでください。------------------------------- (NETED)
STATUS: Elective
状態: 選択科目
SPECIFICATION: RFC 569
仕様: RFC569
COMMENTS:
コメント:
Describes a simple line editor which could be provided by every
Internet host.
すべてのインターネット・ホストが提供できた純真なラインエディタについて説明します。
OTHER REFERENCES:
他の参照:
DEPENDENCIES:
依存:
CONTACT: Postel@USC-ISIF.ARPA
接触: Postel@USC-ISIF.ARPA
Authentication Service -------------------------------------- (AUTH)
認証サービス-------------------------------------- (AUTH)
STATUS: Experimental
状態: 実験的
SPECIFICATION: RFC 931
仕様: RFC931
COMMENTS:
コメント:
This server provides a means to determine the identity of a
user of a particular 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.
このサーバは特定のTCP接続のユーザのアイデンティティを決定する手段を提供します。 TCPポートナンバー組を考えて、それはサーバのシステムの上でその接続の所有者を特定する文字列を返します。
Please discuss any plans for implementation or use of this
protocol with the contact.
このプロトコルの実装か使用のためのあらゆるプランについて接触と議論してください。
OTHER REFERENCES: Supercedes RFC 912
他の参照: Supercedes RFC912
DEPENDENCIES: Transmission Control Protocol
依存: 通信制御プロトコル
CONTACT: StJohns@MIT-Multics.ARPA
接触: StJohns@MIT-Multics.ARPA
Reynolds & Postel [Page 32]
レイノルズとポステル[32ページ]
Official ARPA-Internet Protocols RFC 944
公式のアルパインターネットプロトコルRFC944
APPENDICES
付録
Assigned Numbers ---------------------------------------------------
規定番号---------------------------------------------------
STATUS: None
状態: なし
SPECIFICATION: RFC 943
仕様: RFC943
COMMENTS:
コメント:
Describes the fields of various protocols that are assigned
specific values for actual use, and lists the currently
assigned values.
特定の値が実際の使用のために割り当てられる様々なプロトコルの分野について説明して、現在割り当てられた値を記載します。
Issued April 1985, replaces RFC 923, RFC 790 in IPTW, and
RFC 900.
1985年4月を発行して、RFC923、IPTWのRFC790、およびRFC900を取り替えます。
OTHER REFERENCES:
他の参照:
CONTACT: JKReynolds@USC-ISIF.ARPA
接触: JKReynolds@USC-ISIF.ARPA
Pre-emption --------------------------------------------------------
先取り--------------------------------------------------------
STATUS: Elective
状態: 選択科目
SPECIFICATION: RFC 794 (in IPTW)
仕様: RFC794(IPTWの)
COMMENTS:
コメント:
Describes how to do pre-emption of TCP connections.
TCP接続の先取りをする方法を説明します。
OTHER REFERENCES:
他の参照:
CONTACT: Postel@USC-ISIF.ARPA
接触: Postel@USC-ISIF.ARPA
Reynolds & Postel [Page 33]
レイノルズとポステル[33ページ]
Official ARPA-Internet Protocols RFC 944
公式のアルパインターネットプロトコルRFC944
Service Mappings ---------------------------------------------------
サービス対応表---------------------------------------------------
STATUS: None
状態: なし
SPECIFICATION: RFC 795 (in IPTW)
仕様: RFC795(IPTWの)
COMMENTS:
コメント:
Describes the mapping of the IP type of service field onto the
parameters of some specific networks.
サービス分野のIPタイプに関するマッピングについていくつかの特定のネットワークのパラメタに説明します。
Out of date, needs revision.
時代遅れの必要性改正。
OTHER REFERENCES:
他の参照:
CONTACT: Postel@USC-ISIF.ARPA
接触: Postel@USC-ISIF.ARPA
Address Mappings ---------------------------------------------------
アドレス・マッピング---------------------------------------------------
STATUS: None
状態: なし
SPECIFICATION: RFC 796 (in IPTW)
仕様: RFC796(IPTWの)
COMMENTS:
コメント:
Describes the mapping between Internet Addresses and the
addresses of some specific networks.
いくつかの特定のネットワークのインターネットAddressesとアドレスの間のマッピングについて説明します。
Out of date, needs revision.
時代遅れの必要性改正。
OTHER REFERENCES:
他の参照:
CONTACT: Postel@USC-ISIF.ARPA
接触: Postel@USC-ISIF.ARPA
Document Formats ---------------------------------------------------
ドキュメント・フォーマット---------------------------------------------------
STATUS: None
状態: なし
SPECIFICATION: RFC 678
仕様: RFC678
COMMENTS:
コメント:
Describes standard format rules for several types of documents.
いくつかのタイプのドキュメントのために標準書式規則について説明します。
OTHER REFERENCES:
他の参照:
CONTACT: Postel@USC-ISIF.ARPA
接触: Postel@USC-ISIF.ARPA
Reynolds & Postel [Page 34]
レイノルズとポステル[34ページ]
Official ARPA-Internet Protocols RFC 944
公式のアルパインターネットプロトコルRFC944
Bitmap Formats -----------------------------------------------------
ビットマップ形式-----------------------------------------------------
STATUS: None
状態: なし
SPECIFICATION: RFC 797
仕様: RFC797
COMMENTS:
コメント:
Describes a standard format for bitmap data.
ビットマップデータのために標準書式について説明します。
OTHER REFERENCES:
他の参照:
CONTACT: Postel@USC-ISIF.ARPA
接触: Postel@USC-ISIF.ARPA
Facsimile Formats --------------------------------------------------
ファクシミリ形式--------------------------------------------------
STATUS: None
状態: なし
SPECIFICATION: RFC 804
仕様: RFC804
COMMENTS:
コメント:
Describes a standard format for facsimile data.
ファクシミリデータのために標準書式について説明します。
OTHER REFERENCES:
他の参照:
CONTACT: Postel@USC-ISIF.ARPA
接触: Postel@USC-ISIF.ARPA
Host-Front End Protocol ------------------------------------- (HFEP)
ホストフロントエンドプロトコル------------------------------------- (HFEP)
STATUS: Experimental
状態: 実験的
SPECIFICATION: RFC 929
仕様: RFC929
COMMENTS:
コメント:
Please discuss any plans for implementation or use of this
protocol with the contact.
このプロトコルの実装か使用のためのあらゆるプランについて接触と議論してください。
OTHER REFERENCES: RFC 928
他の参照: RFC928
DEPENDENCIES:
依存:
CONTACT: Padlipsky@USC-ISI.ARPA
接触: Padlipsky@USC-ISI.ARPA
Reynolds & Postel [Page 35]
レイノルズとポステル[35ページ]
Official ARPA-Internet Protocols RFC 944
公式のアルパインターネットプロトコルRFC944
Internet Protocol on X.25 Networks ------------------------ (IP-X25)
X.25ネットワークのインターネットプロトコル------------------------ (IP-X25)
STATUS: Recommended
状態: 推薦されます。
SPECIFICATION: RFC 877
仕様: RFC877
COMMENTS:
コメント:
Describes a standard for the transmission of IP Datagrams over
Public Data Networks.
Public Data Networksの上でIPデータグラムの送信の規格について説明します。
OTHER REFERENCES:
他の参照:
CONTACT: jtk@PURDUE.ARPA
接触: jtk@PURDUE.ARPA
Internet Protocol on DC Networks --------------------------- (IP-DC)
DCネットワークのインターネットプロトコル--------------------------- (IP-DC)
STATUS: Elective
状態: 選択科目
SPECIFICATION: RFC 891
仕様: RFC891
COMMENTS:
コメント:
OTHER REFERENCES:
他の参照:
RFC 778 - DCNET Internet Clock Service
RFC778--DCNETインターネットクロック・サービス
CONTACT: Mills@USC-ISID.ARPA
接触: Mills@USC-ISID.ARPA
Internet Protocol on Ethernet Networks ---------------------- (IP-E)
イーサネットネットワークのインターネットプロトコル---------------------- (IP-E)
STATUS: Recommended
状態: 推薦されます。
SPECIFICATION: RFC 894
仕様: RFC894
COMMENTS:
コメント:
OTHER REFERENCES: RFC 893
他の参照: RFC893
CONTACT: Postel@USC-ISIF.ARPA
接触: Postel@USC-ISIF.ARPA
Reynolds & Postel [Page 36]
レイノルズとポステル[36ページ]
Official ARPA-Internet Protocols RFC 944
公式のアルパインターネットプロトコルRFC944
Internet Protocol on Experimental Ethernet Networks -------- (IP-EE)
実験イーサネットネットワークのインターネットプロトコル-------- (IP-EE)
STATUS: Recommended
状態: 推薦されます。
SPECIFICATION: RFC 895
仕様: RFC895
COMMENTS:
コメント:
OTHER REFERENCES:
他の参照:
CONTACT: Postel@USC-ISIF.ARPA
接触: Postel@USC-ISIF.ARPA
Internet Subnets Protocol --------------------------------- (IP-SUB)
インターネットサブネットプロトコル--------------------------------- (IP-潜水艦)
STATUS: Experimental
状態: 実験的
SPECIFICATION: RFC 940
仕様: RFC940
COMMENTS:
コメント:
Discussion of the various problems and potential solutions of
"explicit subnets" in a multi-LAN environment.
マルチLAN環境における、「明白なサブネット」の様々な問題と潜在的ソリューションの議論。
Please discuss any plans for implementation or use of this
protocol with the contact.
このプロトコルの実装か使用のためのあらゆるプランについて接触と議論してください。
OTHER REFERENCES: RFC 917, RFC 925, RFC 932, RFC 936, RFC 922
他の参照: RFC917、RFC925、RFC932、RFC936、RFC922
DEPENDENCIES:
依存:
CONTACT: Mills@USC-ISID.ARPA
接触: Mills@USC-ISID.ARPA
Broadcasting Internet Datagrams ------------------------- (IP-BROAD)
インターネットデータグラムを放送します。------------------------- (IP広い)です。
STATUS: Experimental
状態: 実験的
SPECIFICATION: RFC 919
仕様: RFC919
COMMENTS:
コメント:
A proposed protocol of simple rules for broadcasting Internet
datagrams on local networks that support broadcast, for
addressing broadcasts, and for how gateways should handle them.
サポートが放送を扱うために放送した企業内情報通信網でインターネットデータグラムを放送して、ゲートウェイがどうそれらを扱うはずであるか簡単な規則の提案されたプロトコル。
Please discuss any plans for implementation or use of this
protocol with the contact.
このプロトコルの実装か使用のためのあらゆるプランについて接触と議論してください。
OTHER REFERENCES: RFC 922
他の参照: RFC922
Reynolds & Postel [Page 37]
レイノルズとポステル[37ページ]
Official ARPA-Internet Protocols RFC 944
公式のアルパインターネットプロトコルRFC944
DEPENDENCIES:
依存:
CONTACT: Mogul@SU-SCORE.ARPA
接触: Mogul@SU-SCORE.ARPA
Address Resolution Protocol ---------------------------------- (ARP)
アドレス解決プロトコル---------------------------------- (アルプ)
STATUS: Recommended
状態: 推薦されます。
SPECIFICATION: RFC 826
仕様: RFC826
COMMENTS:
コメント:
This is a procedure for finding the network hardware address
corresponding to an Internet Address.
これは、インターネットAddressに対応するハードウェア・アドレスをネットワークに見つけるための手順です。
OTHER REFERENCES:
他の参照:
CONTACT: Postel@USC-ISIF.ARPA
接触: Postel@USC-ISIF.ARPA
A Reverse Address Resolution Protocol ----------------------- (RARP)
逆アドレス解決プロトコル----------------------- (RARP)
STATUS: Elective
状態: 選択科目
SPECIFICATION: RFC 903
仕様: RFC903
COMMENTS:
コメント:
This is a procedure for workstations to dynamically find their
protocol address (e.g., their Internet Address), when they only
only know their hardware address (e.g., their attached physical
network address).
これはワークステーションがそれらのプロトコルがアドレス(例えば、それらのインターネットAddress)であることがダイナミックにわかる手順です、彼らが自分達のハードウェア・アドレス(例えば、彼らの添付の物理ネットワークアドレス)を知っているだけであるとき。
OTHER REFERENCES:
他の参照:
CONTACT: Mogul@SU-SCORE.ARPA
接触: Mogul@SU-SCORE.ARPA
Multi-LAN Address Resolution Protocol ----------------------- (MARP)
マルチLANアドレス解決プロトコル----------------------- (MARP)
STATUS: Experimental
状態: 実験的
SPECIFICATION: RFC 925
仕様: RFC925
COMMENTS:
コメント:
Discussion of the various problems and potential solutions of
"transparent subnets" in a multi-LAN environment.
マルチLAN環境における、「透明なサブネット」の様々な問題と潜在的ソリューションの議論。
Please discuss any plans for implementation or use of this
protocol with the contact.
このプロトコルの実装か使用のためのあらゆるプランについて接触と議論してください。
Reynolds & Postel [Page 38]
レイノルズとポステル[38ページ]
Official ARPA-Internet Protocols RFC 944
公式のアルパインターネットプロトコルRFC944
OTHER REFERENCES: RFC 917, RFC 826
他の参照: RFC917、RFC826
DEPENDENCIES:
依存:
CONTACT: Postel@USC-ISIF.ARPA
接触: Postel@USC-ISIF.ARPA
Broadcasting Internet Datagrams with Subnets --------- (IP-SUB-BROAD)
サブネットでインターネットデータグラムを放送します。--------- (IPサブ女)
STATUS: Experimental
状態: 実験的
SPECIFICATION: RFC 922
仕様: RFC922
COMMENTS:
コメント:
A proposed protocol of simple rules for broadcasting Internet
datagrams on local networks that support broadcast, for
addressing broadcasts, and for how gateways should handle them.
サポートが放送を扱うために放送した企業内情報通信網でインターネットデータグラムを放送して、ゲートウェイがどうそれらを扱うはずであるか簡単な規則の提案されたプロトコル。
Please discuss any plans for implementation or use of this
protocol with the contact.
このプロトコルの実装か使用のためのあらゆるプランについて接触と議論してください。
OTHER REFERENCES:
他の参照:
DEPENDENCIES:
依存:
CONTACT: Mogul@SU-SCORE.ARPA
接触: Mogul@SU-SCORE.ARPA
Host Access Protocol ----------------------------------------- (HAP)
ホストアクセス・プロトコル----------------------------------------- (機会)
STATUS: Recommended
状態: 推薦されます。
SPECIFICATION: RFC 907
仕様: RFC907
COMMENTS:
コメント:
This protocol specifies the network-access level communication
between an arbitrary computer, called a host, and a
packet-switched satellite network, e.g., SATNET or WBNET.
このプロトコルは例えばホストと呼ばれる、任意のコンピュータと、パケットで切り換えられた衛星ネットワークとのネットワークアクセスの平らなコミュニケーションを指定します。SATNETかWBNET。
Note: Implementations of HAP should be performed in
coordination with satellite network development and operations
personnel.
以下に注意してください。 HAPの実装は衛星ネットワーク開発と業務職員と共にコーディネートで実行されるべきです。
OTHER REFERENCES:
他の参照:
DEPENDENCIES:
依存:
CONTACT: Schoen@BBN-UNIX.ARPA
接触: Schoen@BBN-UNIX.ARPA
Reynolds & Postel [Page 39]
レイノルズとポステル[39ページ]
Official ARPA-Internet Protocols RFC 944
公式のアルパインターネットプロトコルRFC944
Reliable Asynchronous Transfer Protocol --------------------- (RATP)
信頼できる非同期な転送プロトコル--------------------- (RATP)
STATUS: Experimental
状態: 実験的
SPECIFICATION: RFC 916
仕様: RFC916
COMMENTS:
コメント:
This paper 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. This proposed protocol
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 current use.
この紙は2つのプログラムが通信リンクの上で確かに伝えるプロトコルを指定します。 それは、受け取るならリンクの片端に入るデータが他の終わりの完全で非変更に到着するのを確実にします。 この提案されたプロトコルは、全二重二地点間接続の上で作動するように設計されています。 それは今RS-232リンクに現在の使用でそれを仕立てるいくつかの特徴を含んでいます。
Please discuss any plans for implementation or use of this
protocol with the contact.
このプロトコルの実装か使用のためのあらゆるプランについて接触と議論してください。
OTHER REFERENCES:
他の参照:
DEPENDENCIES: Transmission Control Protocol
依存: 通信制御プロトコル
CONTACT: Finn@USC-ISIF.ARPA
接触: Finn@USC-ISIF.ARPA
Thinwire Protocol --------------------------------------- (THINWIRE)
Thinwireプロトコル--------------------------------------- (THINWIRE)
STATUS: Experimental
状態: 実験的
SPECIFICATION: RFC 914
仕様: RFC914
COMMENTS:
コメント:
This paper discusses a Thinwire Protocol for connecting
personal computers to the ARPA-Internet. It primarily focuses
on the particular problems in the ARPA-Internet of low speed
network interconnection with personal computers, and possible
methods of solution.
この論文は接続パーソナルコンピュータのためにARPA-インターネットとThinwireプロトコルについて議論します。 それはパーソナルコンピュータがある低速ネットワーク相互接続、およびソリューションの可能なメソッドのARPA-インターネットで主として特定の問題に焦点を合わせます。
Please discuss any plans for implementation or use of this
protocol with the contact.
このプロトコルの実装か使用のためのあらゆるプランについて接触と議論してください。
OTHER REFERENCES:
他の参照:
DEPENDENCIES:
依存:
CONTACT: Farber@ROCHESTER.ARPA
接触: Farber@ROCHESTER.ARPA
Reynolds & Postel [Page 40]
レイノルズとポステル[40ページ]
一覧
スポンサーリンク
