RFC840 日本語訳
0840 Official protocols. J. Postel. April 1983. (Format: TXT=33534 bytes) (Obsoleted by RFC0880) (Status: HISTORIC)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group J. Postel
Request for Comments: 840 ISI
April 1983
コメントを求めるワーキンググループJ.ポステルの要求をネットワークでつないでください: 840 ISI1983年4月
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 these are noted here. In particular, the mail protocols have been revised and issued as a volume titled "Internet Mail Protocols" dated November 1982. There is a volume of protocol related information called the Internet Protocol Implementers Guide (IPIG) dated August 1982. A few of the protocols (in particular the Telnet Options) have not been revised for many years, these are found in the old ARPANET Protocol Handbook (APH) dated January 1978.
最初に、オーダーに、公式のプロトコルは1982年3月付けのインターネットプロトコルTransition Workbook(IPTW)のそれらです。 IPTWにない使用中のいくつかのプロトコルがあります。 IPTWのプロトコルのいくつかは改訂されたこれらがここに述べられるということです。 ボリュームが1982年11月付けの「インターネットメールプロトコル」を題をつけたので、メールプロトコルを特に、改訂して、発行しました。 ガイド(IPIG)が1982年8月にデートしたインターネットプロトコルImplementersと呼ばれるプロトコル関連情報のボリュームがあります。 プロトコル(特にTelnet Options)のいくつかは何年間も改訂されていなくて、これらは1978年1月付けの古いアルパネットプロトコルHandbook(APH)で見つけられます。
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.
接触はプロトコルに関する質問に答えることができる人を示します。
Postel [Page 1]
ポステル[1ページ]
RFC 840 April 1983
Official Protocols
RFC840 1983年4月公式のプロトコル
In particular, the status may need some further clarification:
特に、状態はさらなる何らかの明確化を必要とするかもしれません:
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:
他の参照:
DEPENDENCIES:
依存:
CONTACT: Postel@USC-ISIF
接触: Postel@USC-ISIF
Postel [Page 2]
ポステル[2ページ]
RFC 840 April 1983
Official Protocols
RFC840 1983年4月公式のプロトコル
Network Level
ネットワークレベル
Internet Protocol (IP)
インターネットプロトコル(IP)
STATUS: Required
状態: 必要です。
SPECIFICATION: RFC 791 (in IPTW)
仕様: RFC791(IPTWの)
COMMENTS:
コメント:
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
Postel [Page 3]
ポステル[3ページ]
RFC 840 April 1983
Official Protocols
RFC840 1983年4月公式のプロトコル
Internet Control Message Protocol (ICMP)
インターネット・コントロール・メッセージ・プロトコル(ICMP)
STATUS: Required
状態: 必要です。
SPECIFICATION: RFC 792 (in IPTW)
仕様: RFC792(IPTWの)
COMMENTS:
コメント:
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.
ドキュメントにおけるいくつかの軽い過失が注意されました。 追加タイプの再直接のメッセージと追加送信不可能メッセージのために提案をしました。
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:
コメント:
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
Postel [Page 4]
ポステル[4ページ]
RFC 840 April 1983
Official Protocols
RFC840 1983年4月公式のプロトコル
Transmission Control Protocol (TCP)
通信制御プロトコル(TCP)
STATUS: Recommended
状態: 推薦されます。
SPECIFICATION: RFC 793 (in IPTW)
仕様: RFC793(IPTWの)
COMMENTS:
コメント:
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
received by the TCP but not yet passed to the user,
particularly when the connection is being closed. In general,
閉鎖に関する列に並ばせられた受信データ: 数ポイントがTCPによって受け取られますが、まだユーザに渡されていなかったデータに関して何をしたらよいかが記述によって明確でないところにあります、特に接続が閉店しているとき。 一般に
Postel [Page 5]
ポステル[5ページ]
RFC 840 April 1983
Official Protocols
RFC840 1983年4月公式のプロトコル
the data is to be kept to give to the user if he does a RECV
call.
データは彼が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
Host Monitoring Protocol (HMP)
モニターしているプロトコルをホスティングしてください。(HMP)
STATUS: Elective
状態: 選択科目
SPECIFICATION: IEN 197
仕様: IEN197
COMMENTS:
コメント:
This is a good tool for debuging protocol implementations in
small remotely located computers.
これは、小さい離れて見つけられたコンピュータでプロトコル実装をdebugingするための良いツールです。
This protocol is used to monitor Internet gateways and the
TACs.
このプロトコルは、インターネット・ゲートウェイとTACsをモニターするのに使用されます。
OTHER REFERENCES:
他の参照:
DEPENDENCIES: Internet Protocol
依存: インターネットプロトコル
CONTACT: Hinden@BBN-UNIX
接触: Hinden@BBN-UNIX
Postel [Page 6]
ポステル[6ページ]
RFC 840 April 1983
Official Protocols
RFC840 1983年4月公式のプロトコル
Cross Net Debugger (XNET)
ネットのデバッガに交差してください。(XNET)
STATUS: Elective
状態: 選択科目
SPECIFICATION: IEN 158
仕様: IEN158
COMMENTS:
コメント:
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
Exterior Gateway Protocol (EGP)
外のゲートウェイプロトコル(EGP)
STATUS: Experimental
状態: 実験的
SPECIFICATION: RFC 827
仕様: RFC827
COMMENTS:
コメント:
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
Postel [Page 7]
ポステル[7ページ]
RFC 840 April 1983
Official Protocols
RFC840 1983年4月公式のプロトコル
Gateway Gateway Protocol (GGP)
ゲートウェイゲートウェイプロトコル(GGP)
STATUS: Experimental
状態: 実験的
SPECIFICATION: RFC 823
仕様: RFC823
COMMENTS:
コメント:
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
Multiplexing Protocol
マルチプレクシングプロトコル
STATUS: Experimental
状態: 実験的
SPECIFICATION: IEN 90
仕様: IEN90
COMMENTS:
コメント:
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
Postel [Page 8]
ポステル[8ページ]
RFC 840 April 1983
Official Protocols
RFC840 1983年4月公式のプロトコル
Stream Protocol (ST)
ストリームプロトコル(ST)
STATUS: Experimental
状態: 実験的
SPECIFICATION: IEN 119
仕様: IEN119
COMMENTS:
コメント:
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
Network Voice Protocol (NVP-II)
ネットワーク声のプロトコル(NVP-II)
STATUS: Experimental
状態: 実験的
SPECIFICATION: RFC xxx
仕様: RFC xxx
COMMENTS:
コメント:
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
Postel [Page 9]
ポステル[9ページ]
RFC 840 April 1983
Official Protocols
RFC840 1983年4月公式のプロトコル
Application Level
アプリケーションレベル
Telnet Protocol (TELNET)
テルネット・プロトコル(telnet)
STATUS: Recommended
状態: 推薦されます。
SPECIFICATION: RFC 764 (in IPTW)
仕様: RFC764(IPTWの)
COMMENTS:
コメント:
A few minor typographical errors should be corrected and some
clarification of the SYNCH mechanism should be made.
いくつかの小さい方の誤字を修正するべきです、そして、SYNCHメカニズムの何らかの明確化をするべきです。
OTHER REFERENCES:
他の参照:
DEPENDENCIES: Transmission Control Protocol
依存: 通信制御プロトコル
CONTACT: Postel@USC-ISIF
接触: Postel@USC-ISIF
Telnet Options (TELNET)
telnetオプション(telnet)
Number Name RFC NIC APH USE
------ ------------------------------------ --- ----- --- ---
0 Binary Transmission ... 15389 yes yes
1 Echo ... 15390 yes yes
2 Reconnection ... 15391 yes no
3 Suppress Go Ahead ... 15392 yes yes
4 Approximate Message Size Negotiation ... 15393 yes no
5 Status 651 31154 yes yes
6 Timing Mark ... 16238 yes yes
7 Remote Controlled Trans and Echo 726 39237 yes no
8 Output Line Width ... 20196 yes no
9 Output Page Size ... 20197 yes no
10 Output Carriage-Return Disposition 652 31155 yes no
11 Output Horizontal Tabstops 653 31156 yes no
12 Output Horizontal Tab Disposition 654 31157 yes no
13 Output Formfeed Disposition 655 31158 yes no
14 Output Vertical Tabstops 656 31159 yes no
15 Output Vertical Tab Disposition 657 31160 yes no
16 Output Linefeed Disposition 658 31161 yes no
17 Extended ASCII 698 32964 yes no
18 Logout 727 40025 yes no
19 Byte Macro 735 42083 yes no
20 Data Entry Terminal 732 41762 yes no
21 SUPDUP 734 736 42213 yes no
22 SUPDUP Output 749 45449 no no
23 Send Location 779 ----- no no
255 Extended-Options-List ... 16239 yes yes
数の名前RFC NIC APH使用------ ------------------------------------ --- ----- --- --- 0 2進のトランスミッション… 15389 はい、はい、1Echo… 15390 はい、はい、2Reconnection… 15391 はい、いいえ、3Suppress Go Ahead… 15392 はい、はい、4Approximate Message Size Negotiation… 15393 はい、いいえ、5Status651 31154はいはい6のTimingマーク… 16238 はい、はい、Outputの線の7Remote Controlled TransとEcho726 39237はいノー8Width… 20196 はい、いいえ、9OutputページSize… 20197 Output Carriage-リターンのはいノー10Disposition652 31155はいノー11Output Horizontal Tabstops653 31156はいノー12Output Horizontal Tab Disposition654 31157はいノー13Output Formfeed Disposition655 31158はいノー14Output Vertical Tabstops656 31159はいノー15Output Vertical Tab; Extendedの気質657 31160はいノー16Output Linefeed Disposition658 31161はいノー17ASCII698 32964はいノー18Logout727 40025はいノー19Byte Macro735 42083はいノー20Data Entry Terminal732 41762はいノー21SUPDUP734 736 42213はいノー22SUPDUP Output749 45449ノーいいえ23、Send Location779----- いいえ255、Extendedオプションリストがありません… 16239 はい、はい
Postel [Page 10]
ポステル[10ページ]
RFC 840 April 1983
Official Protocols
RFC840 1983年4月公式のプロトコル
STATUS: Elective
状態: 選択科目
SPECIFICATION: (in APH)
仕様: (APHの)
COMMENTS:
コメント:
There is an open question about some of these. Most of the
options are implemented by so few hosts that perhaps they
should be eliminated. These should all be studied and the
useful ones reissued as RFCs.
これらのいくつかに関する未決問題があります。 排除されて、オプションの大部分は恐らく、彼らがそうであるべきであるとてもわずかなホストによってしか実装されません。 これらは、すべて、研究されていてRFCsとして再発行された役に立つものであるべきです。
The last column (USE) of the table above indicates which
options are in general use.
上のテーブルに関する最後のコラム(USE)は、オプションがどれであるかを示します。一般に、使用します。
The following are recommended: Binary Transmission, Echo,
Suppress Go Ahead, Status, Timing Mark, and Extended Options
List.
以下はお勧めです: 状態、タイミング・マーク、および拡張オプションは、トランスミッション(エコー)が抑圧するバイナリーが前に進んでいると記載します。
Many of these must be revised for use with TCP.
TCPとの使用のためにこれらの多くを改訂しなければなりません。
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:
コメント:
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)を含んでいるのを提案をしました。
Eventhough 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.
Eventhough、メール機能は本書では定義されて、それらは使用されていることになっていません。 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だけが非デフォルトポートの使用を開始するかもしれません。
Postel [Page 11]
ポステル[11ページ]
RFC 840 April 1983
Official Protocols
RFC840 1983年4月公式のプロトコル
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
commands to use new ports on both ends of the data
connection.
b。 非デフォルトデータを交渉すると、以下は移植されます。 User-PIは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は他の承認、「再-トランスミッション」または多くとの取引に一度もそうしたことがありませんでした。
Postel [Page 12]
ポステル[12ページ]
RFC 840 April 1983
Official Protocols
RFC840 1983年4月公式のプロトコル
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、および返すのが適切であることに関して何らかの混乱があります。 これらのコマンドに関する何らかの明確化と動機が仕様に追加されるべきです。
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:
コメント:
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
仕様: RFC821
COMMENTS:
コメント:
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
多くの誤解と誤りが早さにありました。
Postel [Page 13]
ポステル[13ページ]
RFC 840 April 1983
Official Protocols
RFC840 1983年4月公式のプロトコル
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のさらなる改正が、仕様の細目におけるいくつかの軽い過失を修正するのに必要です。
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:
コメント:
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
Postel [Page 14]
ポステル[14ページ]
RFC 840 April 1983
Official Protocols
RFC840 1983年4月公式のプロトコル
Remote Job Service (NETRJS)
リモート・ジョブサービス(NETRJS)
STATUS: Elective
状態: 選択科目
SPECIFICATION: RFC 740 (in APH)
仕様: RFC740(APHの)
COMMENTS:
コメント:
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
リモートtelnetサービス
STATUS: Elective
状態: 選択科目
SPECIFICATION: RFC 818
仕様: RFC818
COMMENTS:
コメント:
OTHER REFERENCES:
他の参照:
DEPENDENCIES: Telnet, Transmission Control Protocol
依存: telnet、通信制御プロトコル
CONTACT: Postel@USC-ISIF
接触: Postel@USC-ISIF
Graphics Protocol
グラフィックスプロトコル
STATUS: Elective
状態: 選択科目
SPECIFICATION: NIC 24308 (in APH)
仕様: NIC24308(APHの)
COMMENTS:
コメント:
Very minor changes needed for use with TCP.
TCPとの使用に必要であるまさしくそのマイナーチェンジ。
No known active implementations.
知られているアクティブな実装がありません。
OTHER REFERENCES:
他の参照:
Postel [Page 15]
ポステル[15ページ]
RFC 840 April 1983
Official Protocols
RFC840 1983年4月公式のプロトコル
DEPENDENCIES: Telnet, Transmission Control Protocol
依存: telnet、通信制御プロトコル
CONTACT: Postel@USC-ISIF
接触: Postel@USC-ISIF
Echo Protocol
エコープロトコル
STATUS: Recommended
状態: 推薦されます。
SPECIFICATION: RFC 347
仕様: RFC347
COMMENTS:
コメント:
This specification should be revised for use with TCP and
reissued.
この仕様は、TCPとの使用のために改訂されて、再発行されるべきです。
OTHER REFERENCES:
他の参照:
DEPENDENCIES: Transmission Control Protocol
or User Datagram Protocol
依存: 通信制御プロトコルかユーザー・データグラム・プロトコル
CONTACT: Postel@USC-ISIF
接触: Postel@USC-ISIF
Discard Protocol
プロトコルを捨ててください。
STATUS: Elective
状態: 選択科目
SPECIFICATION: RFC 348
仕様: RFC348
COMMENTS:
コメント:
This specification should be revised for use with TCP and
reissued.
この仕様は、TCPとの使用のために改訂されて、再発行されるべきです。
OTHER REFERENCES:
他の参照:
DEPENDENCIES: Transmission Control Protocol
or User Datagram Protocol
依存: 通信制御プロトコルかユーザー・データグラム・プロトコル
CONTACT: Postel@USC-ISIF
接触: Postel@USC-ISIF
Postel [Page 16]
ポステル[16ページ]
RFC 840 April 1983
Official Protocols
RFC840 1983年4月公式のプロトコル
Character Generator Protocol
文字発生機構プロトコル
STATUS: Elective
状態: 選択科目
SPECIFICATION: RFC 429
仕様: RFC429
COMMENTS:
コメント:
This specification should be revised for use with TCP and
reissued.
この仕様は、TCPとの使用のために改訂されて、再発行されるべきです。
OTHER REFERENCES:
他の参照:
DEPENDENCIES: Transmission Control Protocol
or User Datagram Protocol
依存: 通信制御プロトコルかユーザー・データグラム・プロトコル
CONTACT: Postel@USC-ISIF
接触: Postel@USC-ISIF
Quote of the Day Protocol
今日の名言プロトコル
STATUS: Elective
状態: 選択科目
SPECIFICATION: RFC xxx
仕様: RFC xxx
COMMENTS:
コメント:
Open a connection to this server, it sends you a quote (as a
character string), and closes the connection. This should be
described in an RFC.
このサーバに接続を開いてください、それは、見積り(文字列としての)をあなたに送って、接続を終えます。 これはRFCで説明されるべきです。
OTHER REFERENCES:
他の参照:
DEPENDENCIES: Transmission Control Protocol
or User Datagram Protocol
依存: 通信制御プロトコルかユーザー・データグラム・プロトコル
CONTACT: Postel@USC-ISIF
接触: Postel@USC-ISIF
Active Users Protocol
アクティブなユーザプロトコル
STATUS: Elective
状態: 選択科目
SPECIFICATION: RFC xxx
仕様: RFC xxx
COMMENTS:
コメント:
Open a connection to this server, it sends you a list of the
currently logged in users (as a character string), and closes
the connection. This should be described in an RFC.
このサーバに接続を開いてください、それは、現在ユーザ(文字列としての)に登録されていることのリストをあなたに送って、接続を終えます。 これはRFCで説明されるべきです。
Postel [Page 17]
ポステル[17ページ]
RFC 840 April 1983
Official Protocols
RFC840 1983年4月公式のプロトコル
OTHER REFERENCES:
他の参照:
DEPENDENCIES: Transmission Control Protocol
or User Datagram Protocol
依存: 通信制御プロトコルかユーザー・データグラム・プロトコル
CONTACT: Postel@USC-ISIF
接触: Postel@USC-ISIF
Finger Protocol
指のプロトコル
STATUS: Elective
状態: 選択科目
SPECIFICATION: RFC 742 (in APH)
仕様: RFC742(APHの)
COMMENTS:
コメント:
Some extensions have been suggested.
いくつかの拡大が示されました。
Some changes are are needed for TCP.
いくつかの変化がそうです。TCPに必要です。
OTHER REFERENCES:
他の参照:
DEPENDENCIES: Transmission Control Protocol
依存: 通信制御プロトコル
CONTACT: Postel@USC-ISIF
接触: Postel@USC-ISIF
NICNAME Protocol
NICNAMEプロトコル
STATUS: Elective
状態: 選択科目
SPECIFICATION: RFC 812 (in IPTW)
仕様: RFC812(IPTWの)
COMMENTS:
コメント:
Accesses the ARPANET Directory database.
アルパネットディレクトリデータベースにアクセスします。
OTHER REFERENCES:
他の参照:
DEPENDENCIES: Transmission Control Protocol
依存: 通信制御プロトコル
CONTACT: Feinler@SRI-NIC
接触: Feinler@SRI-NIC
Postel [Page 18]
ポステル[18ページ]
RFC 840 April 1983
Official Protocols
RFC840 1983年4月公式のプロトコル
HOSTNAME Protocol
ホスト名プロトコル
STATUS: Elective
状態: 選択科目
SPECIFICATION: RFC 811 (in IPTW)
仕様: RFC811(IPTWの)
COMMENTS:
コメント:
Accesses the Registered Internet Hosts database (HOSTS.TXT).
RegisteredインターネットHostsデータベース(HOSTS.TXT)にアクセスします。
OTHER REFERENCES:
他の参照:
RFC 810 - Host Table Specification
RFC810--ホストテーブル仕様
DEPENDENCIES: Transmission Control Protocol
依存: 通信制御プロトコル
CONTACT: Feinler@SRI-NIC
接触: Feinler@SRI-NIC
Host Name Server Protocol
ホスト名サーバプロトコル
STATUS: Experimental
状態: 実験的
SPECIFICATION: IEN 116 (in IPTW)
仕様: IEN116(IPTWの)
COMMENTS:
コメント:
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
Postel [Page 19]
ポステル[19ページ]
RFC 840 April 1983
Official Protocols
RFC840 1983年4月公式のプロトコル
CSNET Mailbox Name Server Protocol
CSNETメールボックスネームサーバプロトコル
STATUS: Experimental
状態: 実験的
SPECIFICATION: CS-DN-2
仕様: Cs-DN-2
COMMENTS:
コメント:
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
Daytime Protocol
昼間のプロトコル
STATUS: Elective
状態: 選択科目
SPECIFICATION: RFC xxx
仕様: RFC xxx
COMMENTS:
コメント:
Open a connection to this server, it sends you the date and
time (as a character string), and closes the connection. This
should be described in an RFC.
このサーバに接続を開いてください、それは、日時(文字列としての)をあなたに送って、接続を終えます。 これはRFCで説明されるべきです。
OTHER REFERENCES:
他の参照:
DEPENDENCIES: Transmission Control Protocol
or User Datagram Protocol
依存: 通信制御プロトコルかユーザー・データグラム・プロトコル
CONTACT: Postel@USC-ISIF
接触: Postel@USC-ISIF
Time Server Protocol
時間サーバプロトコル
STATUS: Recommended
状態: 推薦されます。
SPECIFICATION: IEN 142
仕様: IEN142
COMMENTS:
コメント:
Open a connection to this server, it sends you the date and
time (as a 32-bit number), and closes the connection. Or send
a user datagram and it send back a datagram containing the date
and time (as a 32-bit number).
このサーバに接続を開いてください、それは、日時(32ビットの数としての)をあなたに送って、接続を終えます。 または、ユーザデータグラムを送ってください。そうすれば、それは日時(32ビットの数としての)を含むデータグラムを返送します。
Postel [Page 20]
ポステル[20ページ]
RFC 840 April 1983
Official Protocols
RFC840 1983年4月公式のプロトコル
No known problems. Specification should be reissued as an RFC.
いいえ既知の問題仕様はRFCとして再発行されるべきです。
OTHER REFERENCES:
他の参照:
DEPENDENCIES: Transmission Control Protocol
or User Datagram Protocol
依存: 通信制御プロトコルかユーザー・データグラム・プロトコル
CONTACT: Postel@USC-ISIF
接触: Postel@USC-ISIF
DCNET Time Server Protocol (Internet Clock Service)
DCNET時間サーバプロトコル(インターネットクロック・サービス)
STATUS: Elective
状態: 選択科目
SPECIFICATION: RFC 778
仕様: RFC778
COMMENTS:
コメント:
OTHER REFERENCES:
他の参照:
DEPENDENCIES: Internet Control Message Protocol
依存: インターネット・コントロール・メッセージ・プロトコル
CONTACT: Mills@LINKABIT-DCN6
接触: Mills@LINKABIT-DCN6
SUPDUP Protocol
SUPDUPプロトコル
STATUS: Elective
状態: 選択科目
SPECIFICATION: RFC 734 (in APH)
仕様: RFC734(APHの)
COMMENTS:
コメント:
OTHER REFERENCES:
他の参照:
DEPENDENCIES: Transmission Control Protocol
依存: 通信制御プロトコル
CONTACT: Admin.MRC@SU-SCORE
接触: Admin.MRC@SU-SCORE
Internet Message Protocol (MPM)
インターネットメッセージプロトコル(mpm)
STATUS: Experimental
状態: 実験的
SPECIFICATION: RFC 753
仕様: RFC753
COMMENTS:
コメント:
This is an experimental multimedia mail transfer protocol. The
implementation is called a Message Processing Module or MPM.
これは実験マルチメディアメール転送プロトコルです。 実装はMessage Processing ModuleかMPMと呼ばれます。
Postel [Page 21]
ポステル[21ページ]
RFC 840 April 1983
Official Protocols
RFC840 1983年4月公式のプロトコル
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
接触: Postel@USC-ISIF
Appendices
付録
Assigned Numbers
規定番号
STATUS: None
状態: なし
SPECIFICATION: RFC 820
仕様: RFC820
COMMENTS:
コメント:
Describes the fields of various protocols that are assigned
specific values for actual use, and lists the currently
assigned values.
特定の値が実際の使用のために割り当てられる様々なプロトコルの分野について説明して、現在割り当てられた値を記載します。
Issued January 1983, replaces RFC 790 in IPTW.
1983年1月を発行して、IPTWでRFC790を取り替えます。
OTHER REFERENCES:
他の参照:
CONTACT: Postel@USC-ISIF
接触: Postel@USC-ISIF
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
Postel [Page 22]
ポステル[22ページ]
RFC 840 April 1983
Official Protocols
RFC840 1983年4月公式のプロトコル
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 of the IP address field onto the address
field of some specific networks.
いくつかの特定のネットワークのアドレス・フィールドにIPアドレス・フィールドに関するマッピングについて説明します。
Out of date, needs revision.
時代遅れの必要性改正。
OTHER REFERENCES:
他の参照:
CONTACT: Postel@USC-ISIF
接触: Postel@USC-ISIF
Postel [Page 23]
ポステル[23ページ]
一覧
スポンサーリンク
