RFC880 日本語訳
0880 Official protocols. J.K. Reynolds, J. Postel. October 1983. (Format: TXT=37332 bytes) (Obsoletes RFC0840) (Obsoleted by RFC0901) (Status: HISTORIC)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group J. Reynolds
Request for Comments: 880 J. Postel
ISI
Obsoletes: RFC 840 October 1983
コメントを求めるワーキンググループJ.レイノルズの要求をネットワークでつないでください: 880 J.ポステルISIは以下を時代遅れにします。 RFC840 1983年10月
OFFICIAL PROTOCOLS
公式のプロトコル
This RFC identifies the documents specifying the official protocols used in the Internet. Annotations identify 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 option protocols were issued by the NIC in a booklet entitled "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月付けの「インターネットメールプロトコル」を題をつけたので、メールプロトコルを著しく、改訂して、発行しました。 telnetと最も役に立つオプションプロトコルは「インターネットテルネット・プロトコルとオプション」(ITP)と題する小冊子でNICによって発行されました、1983年6月に、時代遅れです。 いくつかのプロトコルは何年間も改訂されていなくて、これらは古い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.
状態、以下が1つがあります。 必要であるか、お勧め的か、選挙的か、または実験的です。
The specification identifies the protocol defining documents.
仕様はプロトコル定義文書を特定します。
The comments describe any differences from the specification or problems with the protocol.
コメントはプロトコルに関する仕様か問題からどんな違いについても説明します。
The other references identify documents that comment on or expand on the protocol.
他の参照はプロトコルについて批評するか、または詳述するドキュメントを特定します。
The dependencies indicate what other protocols are called upon by this protocol.
依存は、どんな他のプロトコルがこのプロトコルによって訪問されるかを示します。
The contact indicates a person who can answer questions about the protocol.
接触はプロトコルに関する質問に答えることができる人を示します。
Reynolds & Postel [Page 1]
レイノルズとポステル[1ページ]
Official Protocols RFC 880
公式のプロトコルRFC880
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.
- これはプロトコルではありません。
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--アルパネット規範モデルの上の見解
DEPENDENCIES:
依存:
CONTACT: Postel@USC-ISIF
接触: Postel@USC-ISIF
Reynolds & Postel [Page 2]
レイノルズとポステル[2ページ]
Official Protocols RFC 880
公式のプロトコルRFC880
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に示された代替の再アセンブリ手順です。
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の)--プロトコル実装におけるモジュール方式と効率
DEPENDENCIES:
依存:
CONTACT: Postel@USC-ISIF
接触: Postel@USC-ISIF
Reynolds & Postel [Page 3]
レイノルズとポステル[3ページ]
Official Protocols RFC 880
公式のプロトコルRFC880
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.
ドキュメントにおけるいくつかの軽い過失が注意されました。 追加タイプの再直接のメッセージと追加送信不可能メッセージのために提案をしました。
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:
他の参照:
DEPENDENCIES: Internet Protocol
依存: インターネットプロトコル
CONTACT: Postel@USC-ISIF
接触: Postel@USC-ISIF
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
接触: Postel@USC-ISIF
Reynolds & Postel [Page 4]
レイノルズとポステル[4ページ]
Official Protocols RFC 880
公式のプロトコルRFC880
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.
以下を押してください。 まだ、ドキュメントの「レコード・マーク」風味をプッシュに与える数個の句があります。 これらはさらにはっきりさせられるべきです。 プッシュはレコード・マークではありません。
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 default should be established more clearly. The default is
based on the default maximum Internet Datagram size which is
576 octets counting the IP and TCP headers. The option counts
only the segment data. For each of IP and TCP the minimum
header is 20 octets and the maximum header is 60 octets. So the
default maximum data segment is could be anywhere from 456 to
536 octets. The current proposal is to set it at 536 data
octets.
最大のセグメントサイズ: 最大のセグメントサイズオプションは、広められて、はっきりさせられるべきです。 デフォルトから最大のセグメントサイズを増強するか、または減少させるのにそれを使用できます。 デフォルトは、より明確に確立されるべきです。 デフォルトはIPを数える576の八重奏とTCPヘッダーであるデフォルトの最大のインターネットデータグラムサイズに基づいています。 オプションはセグメントデータだけを数えます。 それぞれのIPとTCPに関しては、最小のヘッダーは20の八重奏です、そして、最大のヘッダーは60の八重奏です。 それで、デフォルトの最大のデータ・セグメントは456〜536八重奏からどこでもあるかもしれないということです。 現在の提案は536のデータ八重奏のときにそれを設定することです。
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
閉鎖に関する列に並ばせられた受信データ: 数ポイントがデータに関して何をしたらよいかが記述によって明確でないところにあります。
Reynolds & Postel [Page 5]
レイノルズとポステル[5ページ]
Official Protocols RFC 880
公式のプロトコルRFC880
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の)--欠点分離と回復
RFC 817 (in IPIG) - Modularity and Efficiency in Protocol
Implementation
RFC817(IPIGの)--プロトコル実装におけるモジュール方式と効率
DEPENDENCIES: Internet Protocol
依存: インターネットプロトコル
CONTACT: Postel@USC-ISIF
接触: Postel@USC-ISIF
Reynolds & Postel [Page 6]
レイノルズとポステル[6ページ]
Official Protocols RFC 880
公式のプロトコルRFC880
Host Monitoring Protocol (HMP) -------------------------------------
ホストのモニターしているプロトコル(HMP)-------------------------------------
STATUS: Elective
状態: 選択科目
SPECIFICATION: IEN 197
仕様: IEN197
COMMENTS:
コメント:
This is a good tool for debugging protocol implementations in
small remotely located computers.
これは、小さい離れて見つけられたコンピュータでプロトコル実装をデバッグするための良いツールです。
This protocol is used to monitor Internet gateways and the
TACs.
このプロトコルは、インターネット・ゲートウェイとTACsをモニターするのに使用されます。
OTHER REFERENCES:
他の参照:
DEPENDENCIES: Internet Protocol
依存: インターネットプロトコル
CONTACT: Hinden@BBN-UNIX
接触: Hinden@BBN-UNIX
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
DEPENDENCIES: Internet Protocol
依存: インターネットプロトコル
CONTACT: Postel@USC-ISIF
接触: Postel@USC-ISIF
Reynolds & Postel [Page 7]
レイノルズとポステル[7ページ]
Official Protocols RFC 880
公式のプロトコルRFC880
Exterior Gateway Protocol (EGP) ------------------------------------
外のゲートウェイプロトコル(EGP)------------------------------------
STATUS: Experimental
状態: 実験的
SPECIFICATION: RFC 827
仕様: RFC827
COMMENTS:
コメント:
The gateway protocol now under development.
現在、開発でのゲートウェイプロトコル。
Please discuss any plans for implementation or use of this
protocol with the contact.
このプロトコルの実装か使用のためのあらゆるプランについて接触と議論してください。
OTHER REFERENCES:
他の参照:
DEPENDENCIES: Internet Protocol
依存: インターネットプロトコル
CONTACT: Mills@USC-ISID
接触: Mills@USC-ISID
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
接触: Brescia@BBN-UNIX
Reynolds & Postel [Page 8]
レイノルズとポステル[8ページ]
Official Protocols RFC 880
公式のプロトコルRFC880
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
接触: Postel@USC-ISIF
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: Forgie@BBN
接触: Forgie@BBN
Reynolds & Postel [Page 9]
レイノルズとポステル[9ページ]
Official Protocols RFC 880
公式のプロトコルRFC880
Network Voice Protocol (NVP-II) ------------------------------------
ネットワーク声のプロトコル(NVP-II)------------------------------------
STATUS: Experimental
状態: 実験的
SPECIFICATION: RFC xxx
仕様: RFC xxx
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:
他の参照:
DEPENDENCIES: Internet Protocol, Stream Protocol
依存: インターネットプロトコル、ストリームプロトコル
CONTACT: Casner@USC-ISIB
接触: Casner@USC-ISIB
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:
他の参照:
DEPENDENCIES: Transmission Control Protocol
依存: 通信制御プロトコル
CONTACT: Postel@USC-ISIF
接触: Postel@USC-ISIF
Reynolds & Postel [Page 10]
レイノルズとポステル[10ページ]
Official Protocols RFC 880
公式のプロトコルRFC880
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
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----- いいえ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コラムは、オプションがどれであるかを示します。一般に、使用します。
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オプションを最近、アップデートして、再発行しました。 これらはオプションであると最も頻繁に実装されます。
Reynolds & Postel [Page 11]
レイノルズとポステル[11ページ]
Official Protocols RFC 880
公式のプロトコルRFC880
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
接触: Postel@USC-ISIF
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
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
b。 非デフォルトデータを交渉すると、以下は移植されます。 User-PIはPORTコマンドで非デフォルトユーザサイドデータポートを指定するかもしれません。 User-PIは、PASVコマンドで非標準サーバーサイドデータポートを特定するようサーバ側に要求するかもしれません。 接続がアドレスの組によって定義されるので、これらの動作のどちらかが異なったデータ接続を得るために十分である、それでも、両方をすることが許可されています。
Reynolds & Postel [Page 12]
レイノルズとポステル[12ページ]
Official Protocols RFC 880
公式のプロトコルRFC880
commands to use new ports on both ends of the data
connection.
データ接続の両端の新しいポートを使用するコマンド。
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
things the TCP must do to make connection reliable in
a more complex world.
TCPは、多くの異なったタイプのネットワークとネットワークのインタコネクトの上に頼もしい接続を提供するように設計されています。 TCPはアルパネットと同様に働くと約束できない1セットのネットワークを切り抜けなければなりません。 TCPは無くなっているか破損しているパケットからの終わりから終わりへの回復のためのそれ自身の条項を作らなければなりません。 これは接続の必要性に休止時間を段階的に廃止した状態で通じます。 NCPは承認、「再-トランスミッション」またはTCPが、より複雑な世界で接続を信頼できるようにするようにしなければならない他の多くのことに決して、対処する必要はありませんでした。
LIST and NLST:
リストとNLST:
There is some confusion about the LIST an NLST commands, and
what is appropriate to return. Some clarification and
NLSTが命令するLIST、および返すのが適切であることに関して何らかの混乱があります。 そして何らかの明確化。
Reynolds & Postel [Page 13]
レイノルズとポステル[13ページ]
Official Protocols RFC 880
公式のプロトコルRFC880
motivation for these commands should be added to the
specification.
これらのコマンドに関する動機は仕様に追加されるべきです。
OTHER REFERENCES:
他の参照:
RFC 678 - Document File Format Standards
RFC678--ドキュメントファイル形式規格
DEPENDENCIES: Transmission Control Protocol
依存: 通信制御プロトコル
CONTACT: Postel@USC-ISIF
接触: Postel@USC-ISIF
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.
プロトコル、コントロールが提供されるアクセスを全く動かさない非常に簡単なファイル。
No known problems with this specification. This is in use in
several local networks.
この仕様の既知の問題がありません。 これはいくつかの企業内情報通信網で使用中です。
OTHER REFERENCES:
他の参照:
DEPENDENCIES: User Datagram Protocol
依存: ユーザー・データグラム・プロトコル
CONTACT: Postel@USC-ISIF
接触: Postel@USC-ISIF
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でこれらの問題の何らかのドキュメンテーションを見つけることができます。
Reynolds & Postel [Page 14]
レイノルズとポステル[14ページ]
Official Protocols RFC 880
公式のプロトコルRFC880
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のさらなる改正が、仕様の細目におけるいくつかの軽い過失を修正するのに必要です。
DEPENDENCIES: Transmission Control Protocol
依存: 通信制御プロトコル
CONTACT: Postel@USC-ISIF
接触: Postel@USC-ISIF
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
接触: Postel@USC-ISIF
Reynolds & Postel [Page 15]
レイノルズとポステル[15ページ]
Official Protocols RFC 880
公式のプロトコルRFC880
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@USC-ISIA
接触: Braden@USC-ISIA
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
接触: Postel@USC-ISIF
Reynolds & Postel [Page 16]
レイノルズとポステル[16ページ]
Official Protocols RFC 880
公式のプロトコルRFC880
Graphics Protocol (GRAPHICS) ---------------------------------------
グラフィックスプロトコル(グラフィックス)---------------------------------------
STATUS: Elective
状態: 選択科目
SPECIFICATION: NIC 24308 (in APH)
仕様: NIC24308(APHの)
COMMENTS:
コメント:
The protocols 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
接触: Postel@USC-ISIF
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
接触: Postel@USC-ISIF
Reynolds & Postel [Page 17]
レイノルズとポステル[17ページ]
Official Protocols RFC 880
公式のプロトコルRFC880
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
接触: Postel@USC-ISIF
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
依存: 通信制御プロトコルかユーザー・データグラム・プロトコル
CONTACT: Postel@USC-ISIF
接触: Postel@USC-ISIF
Reynolds & Postel [Page 18]
レイノルズとポステル[18ページ]
Official Protocols RFC 880
公式のプロトコルRFC880
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
接触: Postel@USC-ISIF
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
接触: Postel@USC-ISIF
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.
いくつかの拡大が示されました。
Some changes are are needed for TCP.
いくつかの変化がそうです。TCPに必要です。
Reynolds & Postel [Page 19]
レイノルズとポステル[19ページ]
Official Protocols RFC 880
公式のプロトコルRFC880
OTHER REFERENCES:
他の参照:
DEPENDENCIES: Transmission Control Protocol
依存: 通信制御プロトコル
CONTACT: Postel@USC-ISIF
接触: Postel@USC-ISIF
NICNAME Protocol (NICNAME) -----------------------------------------
NICNAMEプロトコル(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
接触: Feinler@SRI-NIC
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
接触: Feinler@SRI-NIC
Reynolds & Postel [Page 20]
レイノルズとポステル[20ページ]
Official Protocols RFC 880
公式のプロトコルRFC880
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) 拡大はどんな知られている実装でも後押しされていません。
Work is in progress on a significant revision. Further
implementations of this protocol are not advised.
仕事は重要な改正のときに進行しています。 このプロトコルのさらなる実装は教えられません。
Please discuss any plans for implementation or use of this
protocol with the contact.
このプロトコルの実装か使用のためのあらゆるプランについて接触と議論してください。
OTHER REFERENCES:
他の参照:
DEPENDENCIES: User Datagram Protocol
依存: ユーザー・データグラム・プロトコル
CONTACT: Postel@USC-ISIF
接触: Postel@USC-ISIF
CSNET Mailbox Name Server Protocol (CSNET-NAMESERVER) --------------
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
接触: Solomon@UWISC
Reynolds & Postel [Page 21]
レイノルズとポステル[21ページ]
Official Protocols RFC 880
公式のプロトコルRFC880
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
接触: Postel@USC-ISIF
Time Server Protocol (TIME) ----------------------------------------
時間サーバプロトコル(時間)----------------------------------------
STATUS: Recommended
状態: 推薦されます。
SPECIFICATION: RFC 868
仕様: RFC868
COMMENTS:
コメント:
Provides the time as the number of seconds from a specified
reference time.
秒数として指定された参照時間から時間を提供します。
OTHER REFERENCES:
他の参照:
DEPENDENCIES: Transmission Control Protocol
or User Datagram Protocol
依存: 通信制御プロトコルかユーザー・データグラム・プロトコル
CONTACT: Postel@USC-ISIF
接触: Postel@USC-ISIF
Reynolds & Postel [Page 22]
レイノルズとポステル[22ページ]
Official Protocols RFC 880
公式のプロトコルRFC880
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
接触: Mills@USC-ISID
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: Admin.MRC@SU-SCORE
接触: Admin.MRC@SU-SCORE
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--構造化されたドキュメント・フォーマット
Reynolds & Postel [Page 23]
レイノルズとポステル[23ページ]
Official Protocols RFC 880
公式のプロトコルRFC880
DEPENDENCIES: Transmission Control Protocol
依存: 通信制御プロトコル
CONTACT: Postel@USC-ISIF
接触: Postel@USC-ISIF
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
接触: Postel@USC-ISIF
Appendices
付録
Assigned Numbers ---------------------------------------------------
規定番号---------------------------------------------------
STATUS: None
状態: なし
SPECIFICATION: RFC 870
仕様: RFC870
COMMENTS:
コメント:
Describes the fields of various protocols that are assigned
specific values for actual use, and lists the currently
assigned values.
特定の値が実際の使用のために割り当てられる様々なプロトコルの分野について説明して、現在割り当てられた値を記載します。
Issued October 1983, replaces RFC 790 in IPTW, and RFC 820 of
January 1983.
1983年10月を発行して、IPTWのRFC790、および1983年1月のRFC820を取り替えます。
OTHER REFERENCES:
他の参照:
CONTACT: JKReynolds@USC-ISIF
接触: JKReynolds@USC-ISIF
Reynolds & Postel [Page 24]
レイノルズとポステル[24ページ]
Official Protocols RFC 880
公式のプロトコルRFC880
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
接触: Postel@USC-ISIF
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
接触: Postel@USC-ISIF
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
接触: Postel@USC-ISIF
Reynolds & Postel [Page 25]
レイノルズとポステル[25ページ]
Official Protocols RFC 880
公式のプロトコルRFC880
Internet Protocol on X.25 Networks ---------------------------------
X.25ネットワークのインターネットプロトコル---------------------------------
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
接触: jtk@PURDUE
Reynolds & Postel [Page 26]
レイノルズとポステル[26ページ]
一覧
スポンサーリンク
