RFC1011 日本語訳
1011 Official Internet protocols. J.K. Reynolds, J. Postel. May 1987. (Format: TXT=74593 bytes) (Obsoletes RFC0991) (Status: UNKNOWN)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group J. Reynolds
Request for Comments: 1011 J. Postel
ISI
Obsoletes: RFCs 991, 961, 943, 924, 901, 880, 840 May 1987
コメントを求めるワーキンググループJ.レイノルズの要求をネットワークでつないでください: 1011J.ポステルISIは以下を時代遅れにします。 RFCs991、961、943、924、901、880、840 1987年5月
OFFICIAL INTERNET PROTOCOLS
公式のインターネットプロトコル
STATUS OF THIS MEMO
このメモの状態
This memo is an official status report on the protocols used in the Internet community. Distribution of this memo is unlimited.
このメモはインターネットコミュニティで使用されるプロトコルに関する公式の現状報告です。 このメモの分配は無制限です。
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 specified in the "DDN Protocol Handbook" (DPH), dated December 1985 (this is a three volume set with a total thickness of about 5 inches).
最初に、オーダーに、公式のプロトコルは「DDNプロトコルハンドブック」(DPH)(時代遅れの1985(これはおよそ5インチの総厚さがある3ボリューム・セットである)年12月)で指定されたものです。
Older collections that include many of these specifications are the "Internet Protocol Transition Workbook" (IPTW), dated March 1982; the "Internet Mail Protocols", dated November 1982; and the "Internet Telnet Protocols and Options", dated June 1983. There is also a volume of protocol related information called the "Internet Protocol Implementers Guide" (IPIG) dated August 1982. An even older collection is the "ARPANET Protocol Handbook" (APH) dated January 1978. Nearly all the relevant material from these collections has been reproduced in the current DPH.
これらの仕様の多くを含んでいるより古い収集は1982年3月付けの「インターネットプロトコル変遷ワークブック」(IPTW)です。 1982年11月付けの「インターネットメールプロトコル」。 1983年6月付けの「インターネットテルネット・プロトコルとオプション。」 また、1982年8月付けの「インターネットプロトコルImplementersガイド」(IPIG)と呼ばれるプロトコル関連情報のボリュームがあります。 さらに古い収集は1978年1月付けの「アルパネットプロトコルハンドブック」(APH)です。 これらの収集からのほとんどすべての関連材料が現在のDPHで再生しました。
The following material 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,
experimental, or none.
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はプロトコルについて批評するか、または詳述するドキュメントを特定します。
Reynolds & Postel [Page 1]
レイノルズとポステル[1ページ]
RFC 1011 - Official Internet Protocols May 1987
RFC1011--公式のインターネットプロトコル1987年5月
The DEPENDENCIES indicate what other protocols are called upon by
this protocol.
DEPENDENCIESは、どんな他のプロトコルがこのプロトコルによって訪問されるかを示します。
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 K. Reynolds
USC - Information Sciences Institute
4676 Admiralty Way
Marina del Rey, California 90292-6695
ジョイスK.レイノルズUSC--情報Sciences Institute4676海軍本部Wayマリナデルレイ、カリフォルニア90292-6695
Phone: (213) 822-1511
以下に電話をしてください。 (213) 822-1511
Electronic mail: JKREYNOLDS@ISI.EDU
電子メール: JKREYNOLDS@ISI.EDU
Reynolds & Postel [Page 2]
レイノルズとポステル[2ページ]
RFC 1011 - Official Internet Protocols May 1987
RFC1011--公式のインターネットプロトコル1987年5月
OVERVIEW
概要
Catenet Model ------------------------------------------------------
Catenetモデル------------------------------------------------------
STATUS: None
状態: なし
SPECIFICATION: IEN 48 (in DPH)
仕様: IEN48(DPHの)
COMMENTS:
コメント:
Gives an overview of the organization and principles of the
Internet.
組織の概要とインターネットの原則を与えます。
Could be revised and expanded.
改訂して、広げることができました。
OTHER REFERENCES:
他の参照:
Leiner, B., Cole R., Postel, J., and D. Mills, "The DARPA
Protocol Suite", IEEE INFOCOM 85, Washington, D.C., March 1985.
Also in IEEE Communications Magazine, and as ISI/RS-85-153,
March 1985.
1985年のLeinerとB.とコールR.とポステル、J.とD.工場、「DARPAプロトコル群」IEEE INFOCOM85、ワシントンDC行進。 IEEEコミュニケーション雑誌と、ISI/RS-85-153、1985年3月としても。
Postel, J., "Internetwork Applications Using the DARPA Protocol
Suite", IEEE INFOCOM 85, Washington, D.C., March 1985. Also in
IEEE Communications Magazine, and as ISI/RS-85-151, April 1985.
1985年のJ.「インターネットワークアプリケーションはDARPAプロトコル群を使用すること」でのIEEE INFOCOM85、ワシントンDC行進のポステル。 IEEEコミュニケーション雑誌と、ISI/RS-85-151、1985年4月としても。
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。
RFC 871 - A Perspective on the ARPANET Reference Model
RFC871--アルパネット規範モデルの上の見解
DEPENDENCIES:
依存:
CONTACT: Postel@ISI.EDU
接触: Postel@ISI.EDU
Reynolds & Postel [Page 3]
レイノルズとポステル[3ページ]
RFC 1011 - Official Internet Protocols May 1987
RFC1011--公式のインターネットプロトコル1987年5月
NETWORK LEVEL
ネットワークレベル
Internet Protocol --------------------------------------------- (IP)
インターネットプロトコル--------------------------------------------- (IP)
STATUS: Required
状態: 必要です。
SPECIFICATION: RFC 791 (in DPH)
仕様: RFC791(DPHの)
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. The MIL-STD description of source routing is wrong in
some of the details.
最も重大であるのは、ルートオプションで少しの混乱です。 ルートオプションには、ルートのどの八重奏が使用されるべき次であるかを示す指針があります。 「指針はこのオプションに比例してい」て「指針のための最も小さい正当な値は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の実装を完成していません。
The subnet procedures defined in RFC 950 are now considered an
essential part of the IP architecture and must be implemented
by all hosts and gateways.
RFC950で定義されたサブネット手順を、現在、IPアーキテクチャの不可欠の部分であると考えられて、すべてのホストとゲートウェイで実装しなければなりません。
OTHER REFERENCES:
他の参照:
RFC 815 (in DPH) - IP Datagram Reassembly Algorithms
RFC815(DPHの)--IPデータグラムReassemblyアルゴリズム
RFC 814 (in DPH) - Names, Addresses, Ports, and Routes
RFC814(DPHの)--名前、アドレス、ポート、およびルート
RFC 816 (in DPH) - Fault Isolation and Recovery
RFC816(DPHの)--欠点分離と回復
Reynolds & Postel [Page 4]
レイノルズとポステル[4ページ]
RFC 1011 - Official Internet Protocols May 1987
RFC1011--公式のインターネットプロトコル1987年5月
RFC 817 (in DPH) - Modularity and Efficiency in Protocol
Implementation
RFC817(DPHの)--プロトコル実装におけるモジュール方式と効率
MIL-STD-1777 (in DPH) - Military Standard Internet Protocol
軍規格-1777(DPHの)--軍事の標準のインターネットプロトコル
RFC 963 - Some Problems with the Specification of the Military
Standard Internet Protocol
RFC963--軍事の標準のインターネットプロトコルの仕様に関するいくつかの問題
DEPENDENCIES:
依存:
CONTACT: Postel@ISI.EDU
接触: Postel@ISI.EDU
Internet Control Message Protocol --------------------------- (ICMP)
インターネット・コントロール・メッセージ・プロトコル--------------------------- (ICMP)
STATUS: Required
状態: 必要です。
SPECIFICATION: RFC 792 (in DPH)
仕様: RFC792(DPHの)
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.
ドキュメントにおけるいくつかの軽い過失が注意されました。 追加タイプの再直接のメッセージと追加送信不可能メッセージのために提案をしました。
Two additional ICMP message types are defined in RFC 950
"Internet Subnets", Address Mask Request (A1=17), and Address
Mask Reply (A2=18).
2つの追加ICMPメッセージタイプがRFC950「インターネットサブネット」、Address Mask Request(A1=17)、およびAddress Mask Reply(A2=18)で定義されます。
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 950
他の参照: RFC950
DEPENDENCIES: Internet Protocol
依存: インターネットプロトコル
CONTACT: Postel@ISI.EDU
接触: Postel@ISI.EDU
Reynolds & Postel [Page 5]
レイノルズとポステル[5ページ]
RFC 1011 - Official Internet Protocols May 1987
RFC1011--公式のインターネットプロトコル1987年5月
Internet Group Multicast Protocol --------------------------- (IGMP)
インターネットグループマルチキャストプロトコル--------------------------- (IGMP)
STATUS: Recommended
状態: 推薦されます。
SPECIFICATION: RFC 988
仕様: RFC988
COMMENTS:
コメント:
This protocol specifies the extensions required of a host
implementation of the Internet Protocol (IP) to support
internetwork multicasting. This specification supersedes that
given in RFC 966, and constitutes a proposed protocol standard
for IP multicasting in the Internet. Reference RFC 966 for a
discussion of the motivation and rationale behind the
multicasting extension specified here.
このプロトコルはインターネットワークマルチキャスティングをサポートするのにインターネットプロトコル(IP)のホスト導入について必要である拡大を指定します。 この仕様は、RFC966で与えられたそれに取って代わって、インターネットのIPマルチキャスティングの提案されたプロトコル標準を構成します。 マルチキャスティング拡大の後ろの動機と原理の議論のためのRFC966がここで指定した参照。
OTHER REFERENCES: RFC 966
他の参照: RFC966
DEPENDENCIES: Internet Protocol
依存: インターネットプロトコル
CONTACT: Deering@PESCADERO.STANFORD.EDU
接触: Deering@PESCADERO.STANFORD.EDU
Reynolds & Postel [Page 6]
レイノルズとポステル[6ページ]
RFC 1011 - Official Internet Protocols May 1987
RFC1011--公式のインターネットプロトコル1987年5月
HOST LEVEL
ホストレベル
User Datagram Protocol --------------------------------------- (UDP)
ユーザー・データグラム・プロトコル--------------------------------------- (UDP)
STATUS: Recommended
状態: 推薦されます。
SPECIFICATION: RFC 768 (in DPH)
仕様: RFC768(DPHの)
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@ISI.EDU
接触: Postel@ISI.EDU
Transmission Control Protocol -------------------------------- (TCP)
通信制御プロトコル-------------------------------- (TCP)
STATUS: Recommended
状態: 推薦されます。
SPECIFICATION: RFC 793 (in DPH)
仕様: RFC793(DPHの)
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.
以下を押してください。 まだ、ドキュメントの「レコード・マーク」風味をプッシュに与える数個の句があります。 これらはさらにはっきりさせられるべきです。 プッシュはレコード・マークではありません。
Reynolds & Postel [Page 7]
レイノルズとポステル[7ページ]
RFC 1011 - Official Internet Protocols May 1987
RFC1011--公式のインターネットプロトコル1987年5月
Urgent: Page 17 is wrong. The urgent pointer points to the
last octet of urgent data (not to the first octet of non-urgent
data).
緊急: 17ページは間違っています。 緊急の指針は緊急のデータ(不急のデータの最初の八重奏でないことへの)の最後の八重奏を示します。
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 is 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は彼であるならあきらめたがっています。
Reynolds & Postel [Page 8]
レイノルズとポステル[8ページ]
RFC 1011 - Official Internet Protocols May 1987
RFC1011--公式のインターネットプロトコル1987年5月
OTHER REFERENCES:
他の参照:
RFC 813 (in DPH) - Window and Acknowledgement Strategy in TCP
RFC813(DPHの)--TCPの窓と承認戦略
RFC 814 (in DPH) - Names, Addresses, Ports, and Routes
RFC814(DPHの)--名前、アドレス、ポート、およびルート
RFC 816 (in DPH) - Fault Isolation and Recovery
RFC816(DPHの)--欠点分離と回復
RFC 817 (in DPH) - Modularity and Efficiency in Protocol
Implementation
RFC817(DPHの)--プロトコル実装におけるモジュール方式と効率
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 (in DPH) - Military Standard Transmission Control
Protocol
軍規格-1778(DPHの)--軍事の標準の通信制御プロトコル
RFC 964 - Some Problems with the Specification of the Military
Standard Transmission Control Protocol
RFC964--軍事の標準の通信制御プロトコルの仕様に関するいくつかの問題
Zhang, Lixia, "Why TCP Timers Don't Work Well", Communications
Architectures and Protocols, ACM SIGCOMM Proceedings, Computer
Communications Review, V.16, N.3, August 1986.
チャンとLixiaと「TCPタイマがうまくいかない理由」とコミュニケーションアーキテクチャとプロトコル、ACM SIGCOMM議事、コンピュータコミュニケーションは再検討されます、V.16、N.3、1986年8月。
DEPENDENCIES: Internet Protocol
依存: インターネットプロトコル
CONTACT: Postel@ISI.EDU
接触: Postel@ISI.EDU
Bulk Data Transfer Protocol ------------------------------- (NETBLT)
バルク・データ転送プロトコル------------------------------- (NETBLT)
STATUS: Experimental
状態: 実験的
SPECIFICATION: RFC 998
仕様: RFC998
COMMENTS:
コメント:
This is a revised RFC on the discussion of the Network Block
Transfer (NETBLT) protocol.
これはNetwork Block Transfer(NETBLT)プロトコルの議論での改訂されたRFCです。
NETBLT (NETwork BLock Transfer) is a transport level protocol
intended for the rapid transfer of a large quantity of data
between computers. It provides a transfer that is reliable and
flow controlled, and is designed to provide maximum throughput
over a wide variety of networks. Although NETBLT currently
NETBLT(NETwork BLock Transfer)は平らなプロトコルがコンピュータの間の多量のデータの迅速な移転のために意図した輸送です。 それが信頼できる転送を供給して、流れは、制御して、さまざまなネットワークの上に最大のスループットを提供するように設計されています。 NETBLTである、現在
Reynolds & Postel [Page 9]
レイノルズとポステル[9ページ]
RFC 1011 - Official Internet Protocols May 1987
RFC1011--公式のインターネットプロトコル1987年5月
runs on top of the Internet Protocol (IP), it should be able to
operate on top of any datagram protocol similar in function to
IP.
インターネットプロトコル(IP)の上の走行、それは機能においてIPと同様のどんなデータグラムプロトコルの上でも作動できるべきです。
This document is published for discussion and comment, and does
not constitute a standard. The proposal may change and certain
parts of the protocol have not yet been specified;
implementation of this document is therefore not advised.
このドキュメントは、議論とコメントのために発行されて、規格を構成しません。 提案は変化するかもしれません、そして、プロトコルのある部分はまだ指定されていません。 したがって、このドキュメントの実装は教えられません。
OTHER REFERENCES: RFC 969
他の参照: RFC969
DEPENDENCIES: Transmission Control Protocol, User Datagram
Protocol
依存: 通信制御プロトコル、ユーザー・データグラム・プロトコル
CONTACT: markl@PTT.LCS.MIT.EDU
接触: markl@PTT.LCS.MIT.EDU
Exterior Gateway Protocol ------------------------------------ (EGP)
外のゲートウェイプロトコル------------------------------------ (EGP)
STATUS: Recommended for Gateways
状態: ゲートウェイに推薦されます。
SPECIFICATION: RFC 888, RFC 904 (in DPH), RFC 975, RFC 985
仕様: RFC888、RFC904(DPHの)、RFC975、RFC985
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@UDEL.EDU
接触: Mills@UDEL.EDU
Reynolds & Postel [Page 10]
レイノルズとポステル[10ページ]
RFC 1011 - Official Internet Protocols May 1987
RFC1011--公式のインターネットプロトコル1987年5月
Gateway Gateway Protocol ------------------------------------- (GGP)
ゲートウェイゲートウェイプロトコル------------------------------------- (GGP)
STATUS: Experimental
状態: 実験的
SPECIFICATION: RFC 823 (in DPH)
仕様: RFC823(DPHの)
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.COM
接触: Brescia@BBN.COM
Host Monitoring Protocol ------------------------------------- (HMP)
モニターしているプロトコルをホスティングしてください。------------------------------------- (HMP)
STATUS: Elective
状態: 選択科目
SPECIFICATION: RFC 869 (in DPH)
仕様: RFC869(DPHの)
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.COM
接触: Hinden@BBN.COM
Reynolds & Postel [Page 11]
レイノルズとポステル[11ページ]
RFC 1011 - Official Internet Protocols May 1987
RFC1011--公式のインターネットプロトコル1987年5月
Reliable Data Protocol --------------------------------------- (RDP)
確実な資料プロトコル--------------------------------------- (RDP)
STATUS: Experimental
状態: 実験的
SPECIFICATION: RFC 908 (in DPH)
仕様: RFC908(DPHの)
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.
このプロトコルは、嵩がロードするか、またはどさっと落とすようなホストモニターと制御アプリケーションのためのデータ転送とリモートデバッグであると効率的にサポートするように設計されています。 メッセージ・セグメントの長いトランスミッション遅れと損失か非連続した配送があるかもしれないところで環境でまだ効率的であるのを除いて、実装するのがプロトコルが簡単であることを意図します。
Please discuss any plans for implementation or use of this
protocol with the contact.
このプロトコルの実装か使用のためのあらゆるプランについて接触と議論してください。
OTHER REFERENCES:
他の参照:
DEPENDENCIES: Internet Protocol
依存: インターネットプロトコル
CONTACT: CWelles@BBN.COM
接触: CWelles@BBN.COM
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 Internet community, they may be interesting to a number
of researchers and implementors.
このプロトコルはレベルがインターネット環境のために設計されたホストプロトコルに主催する輸送です。 議論した問題が直接インターネットコミュニティの研究課題に関連していないかもしれない間、多くの研究者と作成者にとって、それらはおもしろいかもしれません。
OTHER REFERENCES:
他の参照:
DEPENDENCIES: Internet Protocol
依存: インターネットプロトコル
CONTACT: Trudy@ACC.ARPA
接触: Trudy@ACC.ARPA
Reynolds & Postel [Page 12]
レイノルズとポステル[12ページ]
RFC 1011 - Official Internet Protocols May 1987
RFC1011--公式のインターネットプロトコル1987年5月
Cross Net Debugger ------------------------------------------ (XNET)
ネットのデバッガに交差してください。------------------------------------------ (XNET)
STATUS: Elective
状態: 選択科目
SPECIFICATION: IEN 158 (in DPH)
仕様: IEN158(DPHの)
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@ISI.EDU
接触: Postel@ISI.EDU
Multiplexing Protocol ---------------------------------------- (MUX)
マルチプレクシングプロトコル---------------------------------------- (多重化装置)
STATUS: Experimental
状態: 実験的
SPECIFICATION: IEN 90 (in DPH)
仕様: IEN90(DPHの)
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@ISI.EDU
接触: Postel@ISI.EDU
Reynolds & Postel [Page 13]
レイノルズとポステル[13ページ]
RFC 1011 - Official Internet Protocols May 1987
RFC1011--公式のインターネットプロトコル1987年5月
Stream Protocol ----------------------------------------------- (ST)
ストリームプロトコル----------------------------------------------- (ST)
STATUS: Experimental
状態: 実験的
SPECIFICATION: IEN 119 (in DPH)
仕様: IEN119(DPHの)
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
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 (in DPH)
他の参照: RFC741(DPHの)
DEPENDENCIES: Internet Protocol, Stream Protocol
依存: インターネットプロトコル、ストリームプロトコル
CONTACT: Casner@ISI.EDU
接触: Casner@ISI.EDU
Reynolds & Postel [Page 14]
レイノルズとポステル[14ページ]
RFC 1011 - Official Internet Protocols May 1987
RFC1011--公式のインターネットプロトコル1987年5月
APPLICATION LEVEL
アプリケーションレベル
Telnet Protocol ------------------------------------------- (TELNET)
テルネット・プロトコル------------------------------------------- (telnet)
STATUS: Recommended
状態: 推薦されます。
SPECIFICATION: RFC 854 (in DPH)
仕様: RFC854(DPHの)
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 (in DPH) - Telnet Protocol
軍規格-1782(DPHの)--テルネット・プロトコル
DEPENDENCIES: Transmission Control Protocol
依存: 通信制御プロトコル
CONTACT: Postel@ISI.EDU
接触: Postel@ISI.EDU
Reynolds & Postel [Page 15]
レイノルズとポステル[15ページ]
RFC 1011 - Official Internet Protocols May 1987
RFC1011--公式のインターネットプロトコル1987年5月
Telnet Options ------------------------------------ (TELNET-OPTIONS)
telnetオプション------------------------------------ (telnetオプション)
STATUS: Elective
状態: 選択科目
SPECIFICATION: General description of options: RFC 855 (in DPH)
仕様: オプションの概説: RFC855(DPHの)
Number Name RFC NIC DPH USE
------ --------------------------------- --- ----- --- ---
0 Binary Transmission 856 ----- yes yes
1 Echo 857 ----- yes yes
2 Reconnection ... 15391 yes no
3 Suppress Go Ahead 858 ----- yes yes
4 Approx Message Size Negotiation ... 15393 yes no
5 Status 859 ----- yes yes
6 Timing Mark 860 ----- 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 yes no
23 Send Location 779 ----- yes no
24 Terminal Type 930 ----- yes no
25 End of Record 885 ----- yes no
26 TACACS User Identification 927 ----- yes no
27 Output Marking 933 ----- yes no
28 Terminal Location Number 946 ----- no no
255 Extended-Options-List 861 ----- yes yes
数の名前RFC NIC DPH使用------ --------------------------------- --- ----- --- --- 0 2進のトランスミッション856----- はいはい1のEcho857----- はい、はい、2Reconnection… 15391 はいノー3Suppress Go Ahead858----- はい、はい、4Approx Message Size Negotiation… 15393 はいノー5Status859----- はいはい6のTimingマーク860----- はい、はい、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はいノー23Send Location779----- はいノー24Terminal Type930----- Record885のはいノー25End----- はいノー26TACACS User Identification927----- はいノー27Output Marking933----- はいノー28Terminal Location Number946----- Extendedオプションが記載されたいいえ255、861がありません。----- はい、はい
The DHP column indicates if the specification is included in the
DDN Protocol Handbook. The USE column of the table above
indicates which options are in general use.
DHPコラムは、仕様がDDNプロトコルHandbookに含まれているかどうかを示します。 上のテーブルに関するUSEコラムは、オプションがどれであるかを示します。一般に、使用します。
COMMENTS:
コメント:
The Binary Transmission, Echo, Suppress Go Ahead, Status,
2進のトランスミッション(エコー)は先の碁、状態を抑圧します。
Reynolds & Postel [Page 16]
レイノルズとポステル[16ページ]
RFC 1011 - Official Internet Protocols May 1987
RFC1011--公式のインターネットプロトコル1987年5月
Timing Mark, and Extended Options List options have been
recently updated and reissued. These are the most frequently
implemented options.
最近、アップデートして、再発行するマーク、および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@ISI.EDU
接触: Postel@ISI.EDU
SUPDUP Protocol ------------------------------------------- (SUPDUP)
SUPDUPプロトコル------------------------------------------- (SUPDUP)
STATUS: Elective
状態: 選択科目
SPECIFICATION: RFC 734 (in DPH)
仕様: RFC734(DPHの)
COMMENTS:
コメント:
A special Telnet like protocol for display terminals.
ディスプレー装置のためのプロトコルのような特別なTelnet。
OTHER REFERENCES:
他の参照:
DEPENDENCIES: Transmission Control Protocol
依存: 通信制御プロトコル
CONTACT: Crispin@SU-SCORE.STANFORD.EDU
接触: Crispin@SU-SCORE.STANFORD.EDU
File Transfer Protocol --------------------------------------- (FTP)
ファイル転送プロトコル--------------------------------------- (FTP)
STATUS: Recommended
状態: 推薦されます。
SPECIFICATION: RFC 959 (in DPH)
仕様: RFC959(DPHの)
COMMENTS:
コメント:
The protocol for moving files between Internet hosts. Provides
for access control and negotiation of file parameters.
移行するためのプロトコルはインターネット・ホストの間にファイルされます。 ファイルパラメタのアクセスコントロールと交渉に備えます。
The following new optional commands are included in this
edition of the specification: Change to Parent Directory
以下の新しい任意のコマンドは仕様のこの版に含まれています: 親ディレクトリに変化してください。
Reynolds & Postel [Page 17]
レイノルズとポステル[17ページ]
RFC 1011 - Official Internet Protocols May 1987
RFC1011--公式のインターネットプロトコル1987年5月
(CDUP), Structure Mount (SMNT), Store Unique (STOU), Remove
Directory (RMD), Make Directory (MKD), Print Directory (PWD),
and System (SYST). Note that this specification is compatible
with the previous edition (RFC 765).
(CDUP)、構造山の(SMNT)、ユニークな(STOU)を保存してください、そして、ディレクトリ(RMD)を取り除いてください、そして、ディレクトリ(MKD)、印刷ディレクトリ(PWD)、およびシステム(SYST)を作ってください。 この仕様は前の版(RFC765)と互換性があることに注意してください。
A discrepancy has been found in the specification in the
examples of Appendix II. On page 63, a response code of 200 is
shown as the response to a CWD command. Under the list of
Command-Reply Sequences cited on page 50, CWD is shown to only
accept a 250 response code. Therefore, if one would interpret
a CWD command as being excluded from the File System functional
category, one may assume that the response code of 200 is
correct, since CDUP as a special case of CWD does use 200.
食い違いはAppendix IIに関する例の仕様で見つけられました。 63ページでは、200の応答コードはCWDコマンドへの応答として示されます。 50ページで引用されたCommand-回答Sequencesのリストの下では、CWDは、250応答コードを受け入れるだけであるために見せられます。 したがって、人がFile Systemの機能的なカテゴリから除かれます、CDUP以来200の応答コードが特殊なものとしてCWDで正しいと仮定するかもしれないということであることが解釈するようにCWDコマンドを解釈するなら、200を使用してください。
OTHER REFERENCES:
他の参照:
RFC 678 (in DPH) - Document File Format Standards
RFC678(DPHの)--ドキュメントファイル形式規格
MIL-STD-1780 (in DPH) - File Transfer Protocol
軍規格-1780(DPHの)--ファイル転送プロトコル
DEPENDENCIES: Transmission Control Protocol
依存: 通信制御プロトコル
CONTACT: Postel@ISI.EDU
接触: Postel@ISI.EDU
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.
いくつかの転送モードの解釈におけるあいまいさをはっきりさせるべきでした、そして、追加転送モードを定義できました。 より明確に問題を特定するために追加エラーコードを定義できました。
Note: The DPH contains IEN-133, which is an obsolete version of
this protocol.
以下に注意してください。 DPHはIEN-133を含んでいます。(IEN-133はこのプロトコルの時代遅れのバージョンです)。
OTHER REFERENCES:
他の参照:
Reynolds & Postel [Page 18]
レイノルズとポステル[18ページ]
RFC 1011 - Official Internet Protocols May 1987
RFC1011--公式のインターネットプロトコル1987年5月
DEPENDENCIES: User Datagram Protocol
依存: ユーザー・データグラム・プロトコル
CONTACT: Postel@ISI.EDU
接触: Postel@ISI.EDU
Simple File Transfer Protocol ------------------------------- (SFTP)
簡単なファイル転送プロトコル------------------------------- (SFTP)
STATUS: Experimental
状態: 実験的
SPECIFICATION: RFC 913 (in DPH)
仕様: RFC913(DPHの)
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
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).
バイト・ストリームが適応させたどんな信頼できる8ビットプロトコルでもSFTPを実装することができて、このドキュメントは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@SRI-NIC.ARPA
接触: MKL@SRI-NIC.ARPA
Simple Mail Transfer Protocol ------------------------------- (SMTP)
シンプルメールトランスファプロトコル------------------------------- (SMTP)
STATUS: Recommended
状態: 推薦されます。
SPECIFICATION: RFC 821 (in DPH)
仕様: RFC821(DPHの)
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の)は時代遅れです。
Reynolds & Postel [Page 19]
レイノルズとポステル[19ページ]
RFC 1011 - Official Internet Protocols May 1987
RFC1011--公式のインターネットプロトコル1987年5月
There have been many misunderstandings and errors in the early
implementations. Some documentation of these problems can be
found in the file [C.ISI.EDU]<SMTP>MAIL.ERRORS.
早めの実装には多くの誤解と誤りがありました。 ファイル[C. ISI.EDU]<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のさらなる改正が、仕様の細目におけるいくつかの軽い過失を修正するのに必要です。
Note: RFC 822 is not included in the DPH (an accident, it
should have been).
以下に注意してください。 RFC822はDPHに含まれていません(事故であり、それはそうあるべきでした)。
MIL-STD-1781 (in DPH) - Simple Mail Transfer Protocol (SMTP)
軍規格-1781(DPHの)--簡単なメール転送プロトコル(SMTP)
DEPENDENCIES: Transmission Control Protocol
依存: 通信制御プロトコル
CONTACT: Postel@ISI.EDU
接触: Postel@ISI.EDU
Network News Transfer Protocol ------------------------------ (NNTP)
ネットワークの電子情報を転送するプロトコル------------------------------ (NNTP)
STATUS: Experimental
状態: 実験的
SPECIFICATION: RFC 977
仕様: RFC977
COMMENTS:
コメント:
NNTP specifies a protocol for the distribution, inquiry,
retrieval, and posting of news articles using a reliable
stream-based transmission of news among the Internet community.
NNTP is designed so that news articles are stored in a central
database allowing a subscriber to select only those items he
wishes to read. Indexing, cross-referencing, and expiration of
aged messages are also provided.
NNTPは、インターネットコミュニティの中でニュースの信頼できるストリームベースの伝達を使用することでニュース記事の分配、問い合せ、検索、および任命にプロトコルを指定します。 NNTPは、加入者が彼が読みたがっているそれらの項目だけを選択するのを許容しながらニュース記事が主要なデータベースに保存されるように、設計されています。 また、老いているメッセージのインデックス、十字参照箇所、および満了を提供します。
Please discuss any plans for implementation or use of this
protocol with the contact.
このプロトコルの実装か使用のためのあらゆるプランについて接触と議論してください。
OTHER REFERENCES:
他の参照:
Reynolds & Postel [Page 20]
レイノルズとポステル[20ページ]
RFC 1011 - Official Internet Protocols May 1987
RFC1011--公式のインターネットプロトコル1987年5月
DEPENDENCIES: Internet Protocol
依存: インターネットプロトコル
CONTACT: Brian@SDCSVAX.UCSD.EDU
接触: Brian@SDCSVAX.UCSD.EDU
Post Office Protocol - Version 2 ---------------------------- (POP2)
POP--バージョン2---------------------------- (POP2)
STATUS: Experimental
状態: 実験的
SPECIFICATION: RFC 937 (in DPH)
仕様: RFC937(DPHの)
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@ISI.EDU
接触: JKReynolds@ISI.EDU
NetBIOS Services Protocol -------------------------------- (NETBIOS)
NetBIOSサービスプロトコル-------------------------------- (NETBIOS)
STATUS: Recommended
状態: 推薦されます。
SPECIFICATION: RFC 1001, 1002
仕様: RFC1001、1002
COMMENTS:
コメント:
These documents define a proposed standard protocol to support
NetBIOS services in a TCP/IP environment. Both local network
and internet operation are supported. Various node types are
defined to accomodate local and internet topologies and to
allow operation with or without the use of IP broadcast
これらのドキュメントは、NetBIOSがTCP/IP環境でサービスであるとサポートするために提案された標準プロトコルを定義します。 企業内情報通信網とインターネット操作の両方がサポートされます。 様々なノード種別はaccomodate地方とインターネットtopologiesと定義されました、そして、IPの使用のあるなしにかかわらず操作を許すのは放送されました。
RFC 1001 describes the NetBIOS-over-TCP protocols in a general
manner, with emphasis on the underlying ideas and techniques.
RFC 1002 gives the detailed specifications of the
NetBIOS-over-TCP packets, protocols, and defined constants and
variables.
RFC1001は基本的な考えとテクニックへの強調で一般的な方法でNetBIOS過剰TCPプロトコルについて説明します。 RFC1002はNetBIOS過剰TCPパケット、プロトコル、定義された定数、および変数の仕様詳細を与えます。
Reynolds & Postel [Page 21]
レイノルズとポステル[21ページ]
RFC 1011 - Official Internet Protocols May 1987
RFC1011--公式のインターネットプロトコル1987年5月
OTHER REFERENCES:
他の参照:
DEPENDENCIES: Transmission Control Protocol, User Datagram
Protocol
依存: 通信制御プロトコル、ユーザー・データグラム・プロトコル
CONTACT: Auerbach@CSL.SRI.COM
接触: Auerbach@CSL.SRI.COM
Bootstrap Protocol ----------------------------------------- (BOOTP)
プロトコルを独力で進んでください。----------------------------------------- (BOOTP)
STATUS: Experimental
状態: 実験的
SPECIFICATION: RFC 951
仕様: RFC951
COMMENTS:
コメント:
This proposed protocol provides an IP/UDP bootstrap protocol
which allows a diskless client machine to discover its own IP
address, the address of a server host, and the name of a file
to be loaded into memory and executed.
この提案されたプロトコルはディスクレスクライアントマシンが、それ自身のIPアドレス、サーバー・ホストのアドレス、およびファイルの名前がメモリにロードされると発見できるプロトコルを独力で進んで、実行されたIP/UDPを提供します。
Please discuss any plans for implementation or use of this
protocol with the contact.
このプロトコルの実装か使用のためのあらゆるプランについて接触と議論してください。
OTHER REFERENCES:
他の参照:
DEPENDENCIES: Internet Protocol, User Datagram Protocol
依存: インターネットプロトコル、ユーザー・データグラム・プロトコル
CONTACT: Croft@SUMEX-AIM.STANFORD.EDU
接触: Croft@SUMEX-AIM.STANFORD.EDU
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タイプに対応するように設計されています。 それは強力なデバッグサービスを提供します、それが同時に、プレミアムには効率とスペースがあるところでロードしながらブーツのようなアプリケーションで簡単な部分集合を実装することができるように構造化されますが。
Please discuss any plans for implementation or use of this
protocol with the contact.
このプロトコルの実装か使用のためのあらゆるプランについて接触と議論してください。
Reynolds & Postel [Page 22]
レイノルズとポステル[22ページ]
RFC 1011 - Official Internet Protocols May 1987
RFC1011--公式のインターネットプロトコル1987年5月
OTHER REFERENCES:
他の参照:
DEPENDENCIES: Reliable Data Protocol
依存: 確実な資料プロトコル
CONTACT: Hinden@BBN.COM
接触: Hinden@BBN.COM
Resource Location Protocol ----------------------------------- (RLP)
リソース位置のプロトコル----------------------------------- (RLP)
STATUS: Elective
状態: 選択科目
SPECIFICATION: RFC 887 (in DPH)
仕様: RFC887(DPHの)
COMMENTS:
コメント:
A resource location protocol for use in the Internet. This
protocol utilizes the User Datagram Protocol (UDP) which in
turn calls on the Internet Protocol to deliver its datagrams.
インターネットでの使用のためのリソース位置のプロトコル。 このプロトコルはインターネットプロトコルがデータグラムを提供するよう順番に呼びかけるユーザー・データグラム・プロトコル(UDP)を利用します。
OTHER REFERENCES:
他の参照:
DEPENDENCIES: User Datagram Protocol
依存: ユーザー・データグラム・プロトコル
CONTACT: Accetta@A.CS.CMU.EDU
接触: Accetta@A.CS.CMU.EDU
Remote Job Entry --------------------------------------------- (RJE)
リモートジョブエントリ--------------------------------------------- (RJE)
STATUS: Elective
状態: 選択科目
SPECIFICATION: RFC 407 (in DPH)
仕様: RFC407(DPHの)
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@ISI.EDU
接触: Postel@ISI.EDU
Reynolds & Postel [Page 23]
レイノルズとポステル[23ページ]
RFC 1011 - Official Internet Protocols May 1987
RFC1011--公式のインターネットプロトコル1987年5月
Remote Job Service ---------------------------------------- (NETRJS)
リモート・ジョブサービス---------------------------------------- (NETRJS)
STATUS: Elective
状態: 選択科目
SPECIFICATION: RFC 740 (in DPH)
仕様: RFC740(DPHの)
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@ISI.EDU
接触: Braden@ISI.EDU
Remote Telnet Service ------------------------------------ (RTELNET)
リモートtelnetサービス------------------------------------ (RTELNET)
STATUS: Elective
状態: 選択科目
SPECIFICATION: RFC 818 (in DPH)
仕様: RFC818(DPHの)
COMMENTS:
コメント:
Provides special access to user Telnet on a remote system.
リモートシステムの上でユーザTelnetへの特別なアクセスを提供します。
OTHER REFERENCES:
他の参照:
DEPENDENCIES: Telnet, Transmission Control Protocol
依存: telnet、通信制御プロトコル
CONTACT: Postel@ISI.EDU
接触: Postel@ISI.EDU
Reynolds & Postel [Page 24]
レイノルズとポステル[24ページ]
RFC 1011 - Official Internet Protocols May 1987
RFC1011--公式のインターネットプロトコル1987年5月
Graphics Protocol --------------------------------------- (GRAPHICS)
グラフィックスプロトコル--------------------------------------- (グラフィックス)
STATUS: Elective
状態: 選択科目
SPECIFICATION: NIC 24308 (in DPH)
仕様: NIC24308(DPHの)
COMMENTS:
コメント:
The protocol for vector graphics.
ベクタグラフィックスのためのプロトコル。
Very minor changes needed for use with TCP.
TCPとの使用に必要であるまさしくそのマイナーチェンジ。
No known active implementations.
知られているアクティブな実装がありません。
Note: The DPH claims that this is RFC 493, but RFC 493 is
actually a different earlier specification.
以下に注意してください。 DPHは、これがRFC493であると主張しますが、RFC493は実際に異なった以前の仕様です。
OTHER REFERENCES:
他の参照:
DEPENDENCIES: Telnet, Transmission Control Protocol
依存: telnet、通信制御プロトコル
CONTACT: Postel@ISI.EDU
接触: Postel@ISI.EDU
Echo Protocol ----------------------------------------------- (ECHO)
エコープロトコル----------------------------------------------- (エコー)
STATUS: Recommended
状態: 推薦されます。
SPECIFICATION: RFC 862 (in DPH)
仕様: RFC862(DPHの)
COMMENTS:
コメント:
Debugging protocol, sends back whatever you send it.
デバッグは、議定書を作って、あなたがそれを送るものなら何でも返送します。
OTHER REFERENCES:
他の参照:
DEPENDENCIES: Transmission Control Protocol
or User Datagram Protocol
依存: 通信制御プロトコルかユーザー・データグラム・プロトコル
CONTACT: Postel@ISI.EDU
接触: Postel@ISI.EDU
Reynolds & Postel [Page 25]
レイノルズとポステル[25ページ]
RFC 1011 - Official Internet Protocols May 1987
RFC1011--公式のインターネットプロトコル1987年5月
Discard Protocol ----------------------------------------- (DISCARD)
プロトコルを捨ててください。----------------------------------------- (破棄)
STATUS: Elective
状態: 選択科目
SPECIFICATION: RFC 863 (in DPH)
仕様: RFC863(DPHの)
COMMENTS:
コメント:
Debugging protocol, throws away whatever you send it.
プロトコルをデバッグして、遠くでの一投はあなたが何であってもそれを送ります。
OTHER REFERENCES:
他の参照:
DEPENDENCIES: Transmission Control Protocol
or User Datagram Protocol
依存: 通信制御プロトコルかユーザー・データグラム・プロトコル
CONTACT: Postel@ISI.EDU
接触: Postel@ISI.EDU
Character Generator Protocol ----------------------------- (CHARGEN)
文字発生機構プロトコル----------------------------- (CHARGEN)
STATUS: Elective
状態: 選択科目
SPECIFICATION: RFC 864 (in DPH)
仕様: RFC864(DPHの)
COMMENTS:
コメント:
Debugging protocol, sends you ASCII data.
デバッグは、議定書を作って、ASCIIデータをあなたに送ります。
OTHER REFERENCES:
他の参照:
DEPENDENCIES: Transmission Control Protocol
or User Datagram Protocol
依存: 通信制御プロトコルかユーザー・データグラム・プロトコル
CONTACT: Postel@ISI.EDU
接触: Postel@ISI.EDU
Reynolds & Postel [Page 26]
レイノルズとポステル[26ページ]
RFC 1011 - Official Internet Protocols May 1987
RFC1011--公式のインターネットプロトコル1987年5月
Quote of the Day Protocol ---------------------------------- (QUOTE)
今日の名言プロトコル---------------------------------- (引用文)
STATUS: Elective
状態: 選択科目
SPECIFICATION: RFC 865 (in DPH)
仕様: RFC865(DPHの)
COMMENTS:
コメント:
Debugging protocol, sends you a short ASCII message.
デバッグは、議定書を作って、短いASCIIメッセージをあなたに送ります。
OTHER REFERENCES:
他の参照:
DEPENDENCIES: Transmission Control Protocol
or User Datagram Protocol
依存: 通信制御プロトコルかユーザー・データグラム・プロトコル
CONTACT: Postel@ISI.EDU
接触: Postel@ISI.EDU
Statistics Server ---------------------------------------- (STATSRV)
統計サーバ---------------------------------------- (STATSRV)
STATUS: Recommended
状態: 推薦されます。
SPECIFICATION: RFC 996
仕様: RFC996
COMMENTS:
コメント:
This RFC specifies a standard for the Internet community.
Hosts and gateways on the Internet that choose to implement a
remote statistics monitoring facility may use this protocol to
send statistics data upon request to a monitoring center or
debugging host.
このRFCはインターネットコミュニティの規格を指定します。 インターネットのリモート統計モニターが施設であると実装するのを選ぶホストとゲートウェイは、モニターしているセンターかデバッグホストへの要求に統計データを送るのにこのプロトコルを使用するかもしれません。
OTHER REFERENCES:
他の参照:
DEPENDENCIES: Internet Protocol
依存: インターネットプロトコル
CONTACT: Mills@UDEL.EDU
接触: Mills@UDEL.EDU
Reynolds & Postel [Page 27]
レイノルズとポステル[27ページ]
RFC 1011 - Official Internet Protocols May 1987
RFC1011--公式のインターネットプロトコル1987年5月
Active Users Protocol -------------------------------------- (USERS)
アクティブなユーザプロトコル-------------------------------------- (ユーザ)
STATUS: Elective
状態: 選択科目
SPECIFICATION: RFC 866 (in DPH)
仕様: RFC866(DPHの)
COMMENTS:
コメント:
Lists the currently active users.
現在活発なユーザを記載します。
OTHER REFERENCES:
他の参照:
DEPENDENCIES: Transmission Control Protocol
or User Datagram Protocol
依存: 通信制御プロトコルかユーザー・データグラム・プロトコル
CONTACT: Postel@ISI.EDU
接触: Postel@ISI.EDU
Finger Protocol ------------------------------------------- (FINGER)
指のプロトコル------------------------------------------- (指)
STATUS: Elective
状態: 選択科目
SPECIFICATION: RFC 742 (in DPH)
仕様: RFC742(DPHの)
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に必要です。
OTHER REFERENCES:
他の参照:
DEPENDENCIES: Transmission Control Protocol
依存: 通信制御プロトコル
CONTACT: Postel@ISI.EDU
接触: Postel@ISI.EDU
Reynolds & Postel [Page 28]
レイノルズとポステル[28ページ]
RFC 1011 - Official Internet Protocols May 1987
RFC1011--公式のインターネットプロトコル1987年5月
WhoIs Protocol ------------------------------------------- (NICNAME)
WhoIsプロトコル------------------------------------------- (NICNAME)
STATUS: Elective
状態: 選択科目
SPECIFICATION: RFC 954 (in DPH)
仕様: RFC954(DPHの)
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
CSNET Mailbox Name Server Protocol ---------------------- (CSNET-NS)
CSNETメールボックスネームサーバプロトコル---------------------- (CSNET-ナノ秒)
STATUS: Experimental
状態: 実験的
SPECIFICATION: CS-DN-2 (in DPH)
仕様: Cs-DN-2(DPHの)
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@WISC.EDU
接触: Solomon@WISC.EDU
Reynolds & Postel [Page 29]
レイノルズとポステル[29ページ]
RFC 1011 - Official Internet Protocols May 1987
RFC1011--公式のインターネットプロトコル1987年5月
Domain Name Protocol -------------------------------------- (DOMAIN)
ドメイン名プロトコル-------------------------------------- (ドメイン)
STATUS: Recommended
状態: 推薦されます。
SPECIFICATION: RFC 881, RFC 882, RFC 883 (in DPH)
仕様: RFC881、RFC882、RFC883(DPHの)
COMMENTS:
コメント:
OTHER REFERENCES:
他の参照:
RFC 920 - Domain Requirements
RFC920--ドメイン要求性
RFC 921 - Domain Name Implementation Schedule - Revised
RFC921(ドメイン名遂行スケジュール)は復習しました。
RFC 973 - Domain System Changes and Observations
RFC973--ドメインシステム変更と観測
RFC 974 - Mail Routing and the Domain System
RFC974--ルート設定とドメインシステムを郵送してください。
DEPENDENCIES: Transmission Control Protocol
or User Datagram Protocol
依存: 通信制御プロトコルかユーザー・データグラム・プロトコル
CONTACT: Mockapetris@ISI.EDU
接触: Mockapetris@ISI.EDU
HOSTNAME Protocol --------------------------------------- (HOSTNAME)
ホスト名プロトコル--------------------------------------- (ホスト名)
STATUS: Elective
状態: 選択科目
SPECIFICATION: RFC 953 (in DPH)
仕様: RFC953(DPHの)
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 952 - Host Table Specification
RFC952--ホストテーブル仕様
DEPENDENCIES: Transmission Control Protocol
依存: 通信制御プロトコル
CONTACT: Feinler@SRI-NIC.ARPA
接触: Feinler@SRI-NIC.ARPA
Reynolds & Postel [Page 30]
レイノルズとポステル[30ページ]
RFC 1011 - Official Internet Protocols May 1987
RFC1011--公式のインターネットプロトコル1987年5月
Host Name Server Protocol ----------------------------- (NAMESERVER)
ホスト名サーバプロトコル----------------------------- (ネームサーバ)
STATUS: Experimental
状態: 実験的
SPECIFICATION: IEN 116 (in DPH)
仕様: IEN116(DPHの)
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 abandoned 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@ISI.EDU
接触: Postel@ISI.EDU
Daytime Protocol ----------------------------------------- (DAYTIME)
昼間のプロトコル----------------------------------------- (昼間)
STATUS: Elective
状態: 選択科目
SPECIFICATION: RFC 867 (in DPH)
仕様: RFC867(DPHの)
COMMENTS:
コメント:
Provides the day and time in ASCII character string.
日、時間をASCII文字列に提供します。
OTHER REFERENCES:
他の参照:
DEPENDENCIES: Transmission Control Protocol
or User Datagram Protocol
依存: 通信制御プロトコルかユーザー・データグラム・プロトコル
CONTACT: Postel@ISI.EDU
接触: Postel@ISI.EDU
Reynolds & Postel [Page 31]
レイノルズとポステル[31ページ]
RFC 1011 - Official Internet Protocols May 1987
RFC1011--公式のインターネットプロトコル1987年5月
Network Time Protocol ---------------------------------------- (NTP)
ネットワーク時間プロトコル---------------------------------------- (NTP)
STATUS: Experimental
状態: 実験的
SPECIFICATION: RFC 958
仕様: RFC958
COMMENTS:
コメント:
A proposed protocol for synchronizing a set of network clocks
using a set of distributed clients and servers.
1セットのネットワークを同期させるための提案されたプロトコルは、1セットの分配されたクライアントとサーバを使用することで時間を計ります。
Please discuss any plans for implementation or use of this
protocol with the contact.
このプロトコルの実装か使用のためのあらゆるプランについて接触と議論してください。
OTHER REFERENCES: RFC 778, RFC 891, RFC 956, and RFC 957.
他の参照: RFC778、RFC891、RFC956、およびRFC957。
DEPENDENCIES: User Datagram Protocol
依存: ユーザー・データグラム・プロトコル
CONTACT: Mills@UDEL.EDU
接触: Mills@UDEL.EDU
Time Server Protocol ---------------------------------------- (TIME)
時間サーバプロトコル---------------------------------------- (時間)
STATUS: Elective
状態: 選択科目
SPECIFICATION: RFC 868 (in DPH)
仕様: RFC868(DPHの)
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@ISI.EDU
接触: Postel@ISI.EDU
Reynolds & Postel [Page 32]
レイノルズとポステル[32ページ]
RFC 1011 - Official Internet Protocols May 1987
RFC1011--公式のインターネットプロトコル1987年5月
DCNET Time Server Protocol --------------------------------- (CLOCK)
DCNET時間サーバプロトコル--------------------------------- (時計)
STATUS: Experimental
状態: 実験的
SPECIFICATION: RFC 778
仕様: RFC778
COMMENTS:
コメント:
Provides a mechanism for keeping synchronized clocks.
連動している時計を保つのにメカニズムを提供します。
Please discuss any plans for implementation or use of this
protocol with the contact.
このプロトコルの実装か使用のためのあらゆるプランについて接触と議論してください。
OTHER REFERENCES:
他の参照:
DEPENDENCIES: Internet Control Message Protocol
依存: インターネット・コントロール・メッセージ・プロトコル
CONTACT: Mills@UDEL.EDU
接触: Mills@UDEL.EDU
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@SRI-NIC.ARPA
接触: StJohns@SRI-NIC.ARPA
Reynolds & Postel [Page 33]
レイノルズとポステル[33ページ]
RFC 1011 - Official Internet Protocols May 1987
RFC1011--公式のインターネットプロトコル1987年5月
Authentication Scheme --------------------------------- (COOKIE-JAR)
認証体系--------------------------------- (クッキー用の瓶)
STATUS: Experimental
状態: 実験的
SPECIFICATION: RFC 1004
仕様: RFC1004
COMMENTS:
コメント:
This RFC focuses its discussion on authentication problems in
the Internet and possible methods of solution.
このRFCはインターネットの認証問題とソリューションの可能なメソッドに議論の焦点を合わせます。
Please discuss any plans for implementation or use of this
protocol with the contact.
このプロトコルの実装か使用のためのあらゆるプランについて接触と議論してください。
OTHER REFERENCES:
他の参照:
DEPENDENCIES:
依存:
CONTACT: Mills@UDEL.EDU
接触: Mills@UDEL.EDU
Internet Message Protocol ------------------------------------ (MPM)
インターネットメッセージプロトコル------------------------------------ (mpm)
STATUS: Experimental
状態: 実験的
SPECIFICATION: RFC 759 (in DPH)
仕様: RFC759(DPHの)
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@ISI.EDU
接触: Postel@ISI.EDU
Reynolds & Postel [Page 34]
レイノルズとポステル[34ページ]
RFC 1011 - Official Internet Protocols May 1987
RFC1011--公式のインターネットプロトコル1987年5月
Network Standard Text Editor ------------------------------- (NETED)
標準のテキストエディタをネットワークでつないでください。------------------------------- (NETED)
STATUS: Elective
状態: 選択科目
SPECIFICATION: RFC 569 (in DPH)
仕様: RFC569(DPHの)
COMMENTS:
コメント:
Describes a simple line editor which could be provided by every
Internet host.
すべてのインターネット・ホストが提供できた純真なラインエディタについて説明します。
OTHER REFERENCES:
他の参照:
DEPENDENCIES:
依存:
CONTACT: Postel@ISI.EDU
接触: Postel@ISI.EDU
Reynolds & Postel [Page 35]
レイノルズとポステル[35ページ]
RFC 1011 - Official Internet Protocols May 1987
RFC1011--公式のインターネットプロトコル1987年5月
APPENDICES
付録
Internet Numbers ---------------------------------------------------
インターネット番号---------------------------------------------------
STATUS: None
状態: なし
SPECIFICATION: RFC 997
仕様: RFC997
COMMENTS:
コメント:
Describes the fields of network numbers and autonomous system
numbers that are assigned specific values for actual use, and
lists the currently assigned values.
特定の値が実際の使用のために割り当てられるネットワーク・ナンバーと自律システム番号の分野について説明して、現在割り当てられた値を記載します。
Issued March 1987, replaces RFC 990, RFC 790 in IPTW, and
RFC 960.
1987年3月を発行して、RFC990、IPTWのRFC790、およびRFC960を取り替えます。
OTHER REFERENCES:
他の参照:
CONTACT: Hostmaster@SRI-NIC.ARPA
接触: Hostmaster@SRI-NIC.ARPA
Assigned Numbers ---------------------------------------------------
規定番号---------------------------------------------------
STATUS: None
状態: なし
SPECIFICATION: RFC 1010
仕様: RFC1010
COMMENTS:
コメント:
Describes the fields of various protocols that are assigned
specific values for actual use, and lists the currently
assigned values.
特定の値が実際の使用のために割り当てられる様々なプロトコルの分野について説明して、現在割り当てられた値を記載します。
Issued May 1987, replaces RFC 990, RFC 790 in IPTW, and
RFC 960.
1987年5月を発行して、RFC990、IPTWのRFC790、およびRFC960を取り替えます。
OTHER REFERENCES:
他の参照:
CONTACT: JKREYNOLDS@ISI.EDU
接触: JKREYNOLDS@ISI.EDU
Reynolds & Postel [Page 36]
レイノルズとポステル[36ページ]
RFC 1011 - Official Internet Protocols May 1987
RFC1011--公式のインターネットプロトコル1987年5月
Pre-emption --------------------------------------------------------
先取り--------------------------------------------------------
STATUS: Elective
状態: 選択科目
SPECIFICATION: RFC 794 (in DPH)
仕様: RFC794(DPHの)
COMMENTS:
コメント:
Describes how to do pre-emption of TCP connections.
TCP接続の先取りをする方法を説明します。
OTHER REFERENCES:
他の参照:
CONTACT: Postel@ISI.EDU
接触: Postel@ISI.EDU
Service Mappings ---------------------------------------------------
サービス対応表---------------------------------------------------
STATUS: None
状態: なし
SPECIFICATION: RFC 795 (in DPH)
仕様: RFC795(DPHの)
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@ISI.EDU
接触: Postel@ISI.EDU
Address Mappings ---------------------------------------------------
アドレス・マッピング---------------------------------------------------
STATUS: None
状態: なし
SPECIFICATION: RFC 796 (in DPH)
仕様: RFC796(DPHの)
COMMENTS:
コメント:
Describes the mapping between Internet Addresses and the
addresses of some specific networks.
いくつかの特定のネットワークのインターネットAddressesとアドレスの間のマッピングについて説明します。
Out of date, needs revision.
時代遅れの必要性改正。
OTHER REFERENCES:
他の参照:
CONTACT: Postel@ISI.EDU
接触: Postel@ISI.EDU
Reynolds & Postel [Page 37]
レイノルズとポステル[37ページ]
RFC 1011 - Official Internet Protocols May 1987
RFC1011--公式のインターネットプロトコル1987年5月
Document Formats ---------------------------------------------------
ドキュメント・フォーマット---------------------------------------------------
STATUS: None
状態: なし
SPECIFICATION: RFC 678 (in DPH)
仕様: RFC678(DPHの)
COMMENTS:
コメント:
Describes standard format rules for several types of documents.
いくつかのタイプのドキュメントのために標準書式規則について説明します。
OTHER REFERENCES:
他の参照:
CONTACT: Postel@ISI.EDU
接触: Postel@ISI.EDU
Equations Representation -------------------------------------------
方程式表現-------------------------------------------
STATUS: None
状態: なし
SPECIFICATION: RFC 1003
仕様: RFC1003
COMMENTS:
コメント:
Identifies and explores issues in defining a standard for the
exchange of mathematical equations.
数学の方程式の交換の規格を定義する際に問題を特定して、探ります。
OTHER REFERENCES:
他の参照:
CONTACT: Katz@ISI.EDU
接触: Katz@ISI.EDU
Bitmap Formats -----------------------------------------------------
ビットマップ形式-----------------------------------------------------
STATUS: None
状態: なし
SPECIFICATION: RFC 797 (in DPH)
仕様: RFC797(DPHの)
COMMENTS:
コメント:
Describes a standard format for bitmap data.
ビットマップデータのために標準書式について説明します。
OTHER REFERENCES:
他の参照:
CONTACT: Postel@ISI.EDU
接触: Postel@ISI.EDU
Reynolds & Postel [Page 38]
レイノルズとポステル[38ページ]
RFC 1011 - Official Internet Protocols May 1987
RFC1011--公式のインターネットプロトコル1987年5月
Facsimile Formats --------------------------------------------------
ファクシミリ形式--------------------------------------------------
STATUS: None
状態: なし
SPECIFICATION: RFC 804
仕様: RFC804
COMMENTS:
コメント:
Describes a standard format for facsimile data.
ファクシミリデータのために標準書式について説明します。
OTHER REFERENCES: RFC 769 (in DPH)
他の参照: RFC769(DPHの)
CONTACT: Postel@ISI.EDU
接触: Postel@ISI.EDU
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@ISI.EDU
接触: Padlipsky@ISI.EDU
Internet Protocol on ARPANET ----------------------------- (IP-ARPA)
アルパネットに関するインターネットプロトコル----------------------------- (IP-アルパ)
STATUS: Recommended
状態: 推薦されます。
SPECIFICATION: BBN Report 1822
仕様: BBNレポート1822
COMMENTS:
コメント:
Describes the interface between a Host and an IMP, and by
implication the transmission of IP Datagrams over the ARPANET.
アルパネットの上でHostとIMPとのインタフェース、および含意によるIPデータグラムの送信について説明します。
OTHER REFERENCES: RFC 851, RFC 852, RFC 878 (in DPH), RFC 979,
RFC 1005
他の参照: RFC851、RFC852、RFC878(DPHの)、RFC979、RFC1005
CONTACT: Malis@BBN.COM
接触: Malis@BBN.COM
Reynolds & Postel [Page 39]
レイノルズとポステル[39ページ]
RFC 1011 - Official Internet Protocols May 1987
RFC1011--公式のインターネットプロトコル1987年5月
Internet Protocol on WBNET --------------------------------- (IP-WB)
WBNETの上のインターネットプロトコル--------------------------------- (IP-Wb)
STATUS: Recommended
状態: 推薦されます。
SPECIFICATION: RFC 907 (in DPH)
仕様: RFC907(DPHの)
COMMENTS:
コメント:
Describes a standard for the transmission of IP Datagrams over
the Wideband Net.
Widebandネットの上でIPデータグラムの送信の規格について説明します。
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:
他の参照:
CONTACT: Blumenthal@BBN.COM
接触: Blumenthal@BBN.COM
Internet Protocol on Wideband Network ---------------------- (IP-WB)
広帯域ネットワークのインターネットプロトコル---------------------- (IP-Wb)
STATUS: Recommended
状態: 推薦されます。
SPECIFICATION: RFC 907 (in DPH)
仕様: RFC907(DPHの)
COMMENTS:
コメント:
Describes a standard for the transmission of IP Datagrams over
the WBNET.
WBNETの上でIPデータグラムの送信の規格について説明します。
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.COM
接触: Schoen@BBN.COM
Reynolds & Postel [Page 40]
レイノルズとポステル[40ページ]
RFC 1011 - Official Internet Protocols May 1987
RFC1011--公式のインターネットプロトコル1987年5月
Internet Protocol on X.25 Networks ------------------------ (IP-X25)
X.25ネットワークのインターネットプロトコル------------------------ (IP-X25)
STATUS: Recommended
状態: 推薦されます。
SPECIFICATION: RFC 877 (in DPH)
仕様: RFC877(DPHの)
COMMENTS:
コメント:
Describes a standard for the transmission of IP Datagrams over
Public Data Networks.
Public Data Networksの上でIPデータグラムの送信の規格について説明します。
OTHER REFERENCES:
他の参照:
CONTACT: jtk@PURDUE.EDU
接触: jtk@PURDUE.EDU
Internet Protocol on DC Networks --------------------------- (IP-DC)
DCネットワークのインターネットプロトコル--------------------------- (IP-DC)
STATUS: Elective
状態: 選択科目
SPECIFICATION: RFC 891 (in DPH)
仕様: RFC891(DPHの)
COMMENTS:
コメント:
OTHER REFERENCES:
他の参照:
RFC 778 - DCNET Internet Clock Service
RFC778--DCNETインターネットクロック・サービス
CONTACT: Mills@UDEL.EDU
接触: Mills@UDEL.EDU
Internet Protocol on Ethernet Networks ---------------------- (IP-E)
イーサネットネットワークのインターネットプロトコル---------------------- (IP-E)
STATUS: Recommended
状態: 推薦されます。
SPECIFICATION: RFC 894 (in DPH)
仕様: RFC894(DPHの)
COMMENTS:
コメント:
OTHER REFERENCES: RFC 893
他の参照: RFC893
CONTACT: Postel@ISI.EDU
接触: Postel@ISI.EDU
Reynolds & Postel [Page 41]
レイノルズとポステル[41ページ]
RFC 1011 - Official Internet Protocols May 1987
RFC1011--公式のインターネットプロトコル1987年5月
Internet Protocol on Experimental Ethernet Networks -------- (IP-EE)
実験イーサネットネットワークのインターネットプロトコル-------- (IP-EE)
STATUS: Recommended
状態: 推薦されます。
SPECIFICATION: RFC 895 (in DPH)
仕様: RFC895(DPHの)
COMMENTS:
コメント:
OTHER REFERENCES:
他の参照:
CONTACT: Postel@ISI.EDU
接触: Postel@ISI.EDU
Internet Protocol on IEEE 802 ---------------------------- (IP-IEEE)
IEEE802の上のインターネットプロトコル---------------------------- (IP-IEEE)
STATUS: Recommended
状態: 推薦されます。
SPECIFICATION: see comments
仕様: コメントを見てください。
COMMENTS:
コメント:
At an ad hoc special session on "IEEE 802 Networks and ARP"
held during the TCP Vendors Workshop (August 1986), an approach
to a consistent way to sent DOD-IP datagrams and other IP
related protocols on 802 networks was developed.
TCP Vendors Workshop(1986年8月)の間に保持された「IEEE802ネットワークとARP」の臨時の特別なセッションのときに、802のネットワークの送られたDOD-IPデータグラムと他のIPの関連するプロトコルへの一貫した道へのアプローチは開発されました。
Due to some evolution of the IEEE 802.2 standards and the need
to provide for a standard way to do additional DOD-IP related
protocols (such as Address Resolution Protocol (ARP)) on IEEE
802 networks, the following new policy is established, which
will replace the current policy (see RFC-990 section on IEEE
802 Numbers of Interest, and RFC-948).
IEEEのいくらかの発展のため、802.2の規格と追加DOD-IPをする標準の方法に備える必要性はプロトコル(Address Resolutionプロトコル(ARP)などの)をIEEE802ネットワークに関係づけて、以下の新しい政策(通貨政策(Interest、およびRFC-948のIEEE802民数記のRFC-990部を見る)を置き換える)は確立されます。
The policy is for DDN and Internet community to use IEEE 802.2
encapsulation on 802.3, 802.4, and 802.5 networks by using the
SNAP with an organization code indicating that the following 16
bits specify the Ethertype code (where IP = 2048 (0800 hex),
see RFC-1010 section on Ethernet Numbers of Interest).
方針はDDNとインターネットコミュニティが組織コードが、以下の16ビットがEthertypeコードを指定するのを示しているSNAPを使用することによって802.3、802.4、および802.5のネットワークのIEEE802.2カプセル化を使用する(IPが2048(0800年の十六進法)と等しいところでは、Interestのイーサネット民数記のRFC-1010部を見てください)ことです。
Header
ヘッダー
...--------+--------+--------+
MAC Header| Length | 802.{3/4/5} MAC
...--------+--------+--------+
...--------+--------+--------+ MACヘッダー| 長さ| 802. 3/4/5、Mac…--------+--------+--------+
+--------+--------+--------+
| Dsap=K1| Ssap=K1| control| 802.2 SAP
+--------+--------+--------+
+--------+--------+--------+ | Dsap=K1| Ssap=K1| コントロール| 802.2 SAP+--------+--------+--------+
Reynolds & Postel [Page 42]
レイノルズとポステル[42ページ]
RFC 1011 - Official Internet Protocols May 1987
RFC1011--公式のインターネットプロトコル1987年5月
+--------+--------+---------+--------+--------+
|protocol id or org code =K2| Ether Type | 802.2 SNAP
+--------+--------+---------+--------+--------+
+--------+--------+---------+--------+--------+ |プロトコルイドかorgコードがケーツーと等しいです。| エーテル型| 802.2 スナップ+--------+--------+---------+--------+--------+
The total length of the SAP Header and the SNAP header is
8-octets, making the 802.2 protocol overhead come out on a nice
boundary.
SAP HeaderとSNAPヘッダーの全長は8八重奏です、802.2プロトコルオーバーヘッドを良い境界で出て来させて。
K1 is 170. The IEEE like to talk about things in bit
transmission order and specifies this value as 01010101. In
big-endian order, as used in Internet specifications, this
becomes 10101010 binary, or AA hex, or 170 decimal.
K1は170歳です。 IEEEは01010101としてビット伝送命令でものに関して話すのが好きであり、この値を指定します。 ビッグエンディアンオーダーでは、インターネット仕様で使用されるように、これは10101010の2進の小数、AA十六進法、または170小数になります。
K2 is 0 (zero).
ケーツーは0(ゼロ)です。
Note: The method described in RFC 948 (in DPH) is no longer to
be used.
以下に注意してください。 RFC948(DPHの)で説明されたメソッドがもう使用されるのがありません。
OTHER REFERENCES:
他の参照:
CONTACT: Postel@ISI.EDU
接触: Postel@ISI.EDU
Internet Subnet Protocol ---------------------------------- (IP-SUB)
インターネットサブネットプロトコル---------------------------------- (IP-潜水艦)
STATUS: Required
状態: 必要です。
SPECIFICATION: RFC 950
仕様: RFC950
COMMENTS:
コメント:
This is a very important feature and must be included in all IP
implementations.
これを非常に重要な特徴であり、すべてのIP実装に含まなければなりません。
Specifies procedures for the use of subnets, which are logical
sub-sections of a single Internet network.
ただ一つのインターネット網の論理的な小区分であるサブネットの使用のための手順を指定します。
OTHER REFERENCES: RFC 940, RFC 917, RFC 925, RFC 932, RFC 936,
RFC 922
他の参照: RFC940、RFC917、RFC925、RFC932、RFC936、RFC922
DEPENDENCIES:
依存:
CONTACT: Mogul@SU-SCORE.STANFORD.EDU
接触: Mogul@SU-SCORE.STANFORD.EDU
Reynolds & Postel [Page 43]
レイノルズとポステル[43ページ]
RFC 1011 - Official Internet Protocols May 1987
RFC1011--公式のインターネットプロトコル1987年5月
Address Resolution Protocol ---------------------------------- (ARP)
アドレス解決プロトコル---------------------------------- (アルプ)
STATUS: Recommended
状態: 推薦されます。
SPECIFICATION: RFC 826 (IN DPH)
仕様: RFC826(DPHの)
COMMENTS:
コメント:
This is a procedure for finding the network hardware address
corresponding to an Internet Address.
これは、インターネットAddressに対応するハードウェア・アドレスをネットワークに見つけるための手順です。
OTHER REFERENCES:
他の参照:
CONTACT: Postel@ISI.EDU
接触: Postel@ISI.EDU
A Reverse Address Resolution Protocol ----------------------- (RARP)
逆アドレス解決プロトコル----------------------- (RARP)
STATUS: Elective
状態: 選択科目
SPECIFICATION: RFC 903 (IN DPH)
仕様: RFC903(DPHの)
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.STANFORD.EDU
接触: Mogul@SU-SCORE.STANFORD.EDU
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.
このプロトコルの実装か使用のためのあらゆるプランについて接触と議論してください。
OTHER REFERENCES: RFC 917, RFC 826
他の参照: RFC917、RFC826
Reynolds & Postel [Page 44]
レイノルズとポステル[44ページ]
RFC 1011 - Official Internet Protocols May 1987
RFC1011--公式のインターネットプロトコル1987年5月
DEPENDENCIES:
依存:
CONTACT: Postel@ISI.EDU
接触: Postel@ISI.EDU
Broadcasting Internet Datagrams ------------------------- (IP-BROAD)
インターネットデータグラムを放送します。------------------------- (IP広い)です。
STATUS: Recommended
状態: 推薦されます。
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.
サポートが放送を扱うために放送した企業内情報通信網でインターネットデータグラムを放送して、ゲートウェイがどうそれらを扱うはずであるか簡単な規則の提案されたプロトコル。
Recommended in the sense of "if you do broadcasting at all then
do it this way".
「放送するなら全く、このようにそれをしてください」の意味で、お勧めです。
Please discuss any plans for implementation or use of this
protocol with the contact.
このプロトコルの実装か使用のためのあらゆるプランについて接触と議論してください。
OTHER REFERENCES: RFC 922
他の参照: RFC922
DEPENDENCIES:
依存:
CONTACT: Mogul@SU-SCORE.STANFORD.EDU
接触: Mogul@SU-SCORE.STANFORD.EDU
Broadcasting Internet Datagrams with Subnets --------- (IP-SUB-BROAD)
サブネットでインターネットデータグラムを放送します。--------- (IPサブ女)
STATUS: Recommended
状態: 推薦されます。
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.
サポートが放送を扱うために放送した企業内情報通信網でインターネットデータグラムを放送して、ゲートウェイがどうそれらを扱うはずであるか簡単な規則の提案されたプロトコル。
Recommended in the sense of "if you do broadcasting with
subnets at all then do it this way".
「全くサブネットで放送するなら、このようにそれをしてください」の意味で、お勧めです。
Please discuss any plans for implementation or use of this
protocol with the contact.
このプロトコルの実装か使用のためのあらゆるプランについて接触と議論してください。
OTHER REFERENCES: RFC 919
他の参照: RFC919
Reynolds & Postel [Page 45]
レイノルズとポステル[45ページ]
RFC 1011 - Official Internet Protocols May 1987
RFC1011--公式のインターネットプロトコル1987年5月
DEPENDENCIES:
依存:
CONTACT: Mogul@SU-SCORE.STANFORD.EDU
接触: Mogul@SU-SCORE.STANFORD.EDU
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@ISI.EDU
接触: Finn@ISI.EDU
Thinwire Protocol --------------------------------------- (THINWIRE)
Thinwireプロトコル--------------------------------------- (THINWIRE)
STATUS: Experimental
状態: 実験的
SPECIFICATION: RFC 914
仕様: RFC914
COMMENTS:
コメント:
This paper discusses a Thinwire Protocol for connecting
personal computers to the Internet. It primarily focuses on
the particular problems in the Internet of low speed network
interconnection with personal computers, and possible methods
of solution.
この論文は接続パーソナルコンピュータのためにThinwireプロトコルについてインターネットと議論します。 それはパーソナルコンピュータがある低速ネットワーク相互接続、およびソリューションの可能なメソッドのインターネットで主として特定の問題に焦点を合わせます。
Please discuss any plans for implementation or use of this
protocol with the contact.
このプロトコルの実装か使用のためのあらゆるプランについて接触と議論してください。
OTHER REFERENCES:
他の参照:
Reynolds & Postel [Page 46]
レイノルズとポステル[46ページ]
RFC 1011 - Official Internet Protocols May 1987
RFC1011--公式のインターネットプロトコル1987年5月
DEPENDENCIES:
依存:
CONTACT: Farber@UDEL.EDU
接触: Farber@UDEL.EDU
Reynolds & Postel [Page 47]
レイノルズとポステル[47ページ]
RFC 1011 - Official Internet Protocols May 1987
RFC1011--公式のインターネットプロトコル1987年5月
ISO and CCITT PROTOCOLS
ISOとCCITTプロトコル
The International Standards Organization (ISO) and the International Telegraph and Telephone Consultative Committee (CCITT) are defining a set of protocols that may be of interest to the Internet community. Some of these have been published as RFCs for information purposes. This section lists these protocols.
国際Standards Organization(ISO)と国際電信電話諮問委員会(CCITT)は1セットのインターネットコミュニティに興味があるかもしれないプロトコルを定義しています。 これらの或るものは情報目的のためのRFCsとして発行されました。 このセクションはこれらのプロトコルを記載します。
End System to Intermediate System Routing Exchange Protocol --------
中間システムルート設定交換プロトコルへのエンドシステム--------
STATUS:
状態:
SPECIFICATION: RFC 995
仕様: RFC995
COMMENTS:
コメント:
This protocol is one of a set of International Standards
produced to facilitate the interconnection of open systems.
The set of standards covers the services and protocols required
to achieve such interconnection. This protocol is positioned
with respect to other related standards by the layers defined
in the Reference Model for Open Systems Interconnection (ISO
7498) and by the structure defined in the Internal Organization
of the Network Layer (DIS 8648). In particular, it is a
protocol of the Network Layer. This protocol permits End
Systems and Intermediate Systems to exchange configuration and
routing information to facilitate the operation of the routing
and relaying functions of the Network Layer.
このプロトコルはオープンシステムのインタコネクトを容易にするために生産された国際Standardsの1セットの1つです。規格のセットはサービスをカバーしています、そして、プロトコルがそのようなインタコネクトを達成するのが必要です。 オープン・システム・インターコネクションのためにReference Modelで定義された層(ISO7498)とNetwork LayerのInternal Organizationで定義された構造(DIS8648)によってこのプロトコルは他の関連する規格に関して置かれます。 それは特に、Network Layerのプロトコルです。 このプロトコルは、End SystemsとIntermediate SystemsがNetwork Layerのルーティングとリレー機能の操作を容易にするために構成とルーティング情報を交換することを許可します。
OTHER REFERENCES: RFC 994
他の参照: RFC994
DEPENDENCIES:
依存:
CONTACT: ANSI
接触: ANSI
Connectionless Mode Network Service --------------------- (ISO-8473)
コネクションレスなモードネットワーク・サービス--------------------- (ISO-8473)
STATUS:
状態:
SPECIFICATION: RFC 994
仕様: RFC994
COMMENTS:
コメント:
This Protocol Standard is one of a set of International
Standards produced to facilitate the interconnection of open
systems. The set of standards covers the services and
protocols required to achieve such interconnection. This
このプロトコルStandardはオープンシステムのインタコネクトを容易にするために生産された国際Standardsの1セットの1つです。規格のセットはサービスをカバーしています、そして、プロトコルがそのようなインタコネクトを達成するのが必要です。 これ
Reynolds & Postel [Page 48]
レイノルズとポステル[48ページ]
RFC 1011 - Official Internet Protocols May 1987
RFC1011--公式のインターネットプロトコル1987年5月
Protocol Standard is positioned with respect to other related
standards by the layers defined in the Reference Model for Open
Systems Interconnection (ISO 7498). In particular, it is a
protocol of the Network Layer. This Protocol may be used
between network-entities in end systems or in Network Layer
relay systems (or both). It provides the Connectionless-mode
Network Service as defined in Addendum 1 to the Network Service
Definition Covering Connectionless-mode Transmission (ISO
8348/AD1).
プロトコルStandardはオープン・システム・インターコネクション(ISO7498)のためにReference Modelで定義された層のそばに他の関連する規格に関して置かれます。 それは特に、Network Layerのプロトコルです。 このプロトコルはエンドシステムかNetwork Layerリレー方式のネットワーク実体(ともに)の間で使用されるかもしれません。 それはAddendum1でNetwork Service Definition Covering Connectionless-モードTransmission(ISO8348/AD1)と定義されるようにConnectionless-モードNetwork Serviceを提供します。
OTHER REFERENCES: RFC 926
他の参照: RFC926
DEPENDENCIES:
依存:
CONTACT: ANSI
接触: ANSI
Internet-IP Addressing in ISO-IP -----------------------------------
ISO-IPのインターネットIPアドレシング-----------------------------------
STATUS:
状態:
SPECIFICATION: RFC 986
仕様: RFC986
COMMENTS:
コメント:
This RFC suggests a method to allow the existing IP addressing,
including the IP protocol field, to be used for the ISO
Connectionless Network Protocol (CLNP). This is a draft
solution to one of the problems inherent in the use of
"ISO-grams" in the DoD Internet. Related issues will be
discussed in subsequent RFCs. This RFC suggests a proposed
protocol for the Internet community, and requests discussion
and suggestions for improvements.
このRFCは既存のIPアドレシングを許容するメソッドを勧めます、ISO Connectionless Networkプロトコル(CLNP)に使用されるためにIPプロトコル分野を含んでいて。 これはDoDインターネットでの「等値線」の使用の固有である問題の1つへの草稿ソリューションです。 その後のRFCsで関連問題について議論するでしょう。 このRFCは改良のためにインターネットコミュニティ、要求議論、および提案のための提案されたプロトコルを勧めます。
Please discuss any plans for implementation or use of this
protocol with the contact.
このプロトコルの実装か使用のためのあらゆるプランについて接触と議論してください。
OTHER REFERENCES:
他の参照:
DEPENDENCIES:
依存:
CONTACT: RCallon@BBN.COM
接触: RCallon@BBN.COM
Reynolds & Postel [Page 49]
レイノルズとポステル[49ページ]
RFC 1011 - Official Internet Protocols May 1987
RFC1011--公式のインターネットプロトコル1987年5月
Network Layer Addressing -------------------------------------------
ネットワーク層アドレシング-------------------------------------------
STATUS:
状態:
SPECIFICATION: RFC 941
仕様: RFC941
COMMENTS:
コメント:
This Addendum to the Network Service Definition Standard, ISO
8348, defines the abstract syntax and semantics of the Network
Address (Network Service Access Point Address). The Network
Address defined in this Addendum is the address that appears in
the primitives of the connection-mode Network Service as the
calling address, called address, and responding address
parameters, and in the primitives of the connectionless-mode
Network Service as the source address and destination
address parameters.
Network Service Definition StandardへのこのAddendum(ISO8348)はNetwork Address(ネットワークService Access Point Address)の抽象構文と意味論を定義します。 このAddendumで定義されたNetwork Addressは呼ぶアドレス、着呼アドレス、および応じるのがパラメタを扱う、およびソースアドレスと目的地アドレスパラメタとしてのコネクションレスなモードNetwork Serviceに関する基関数に接続モードNetwork Serviceに関する基関数に現れるアドレスです。
Please discuss any plans for implementation or use of this
protocol with the contact.
このプロトコルの実装か使用のためのあらゆるプランについて接触と議論してください。
OTHER REFERENCES:
他の参照:
DEPENDENCIES:
依存:
CONTACT: ISO
接触: ISO
Transport Protocol Specification ------------------------ (ISO-8073)
トランスポート・プロトコル仕様------------------------ (ISO-8073)
STATUS:
状態:
SPECIFICATION: RFC 905
仕様: RFC905
COMMENTS:
コメント:
This is the current specification of the ISO Transport
Protocol. This document is the text of ISO/TC97/SC16/N1576 as
corrected by ISO/TC97/SC16/N1695. This is the specification
currently being voted on in ISO as a Draft International
Standard (DIS).
これはISO Transportプロトコルの現在の仕様です。 ISO/TC97/SC16/N1695によって修正されるようにこのドキュメントはISO/TC97/SC16/N1576のテキストです。 これは国際規格案(DIS)として現在ISOで投票される仕様です。
OTHER REFERENCES: RFC 892
他の参照: RFC892
DEPENDENCIES:
依存:
CONTACT: ISO
接触: ISO
Reynolds & Postel [Page 50]
レイノルズとポステル[50ページ]
RFC 1011 - Official Internet Protocols May 1987
RFC1011--公式のインターネットプロトコル1987年5月
ISO Transport Services on Top of the TCP ---------------------------
TCPの上のISO輸送サービス---------------------------
STATUS:
状態:
SPECIFICATION: RFC 1006
仕様: RFC1006
COMMENTS:
コメント:
This memo describes a proposed protocol standard for the
Internet community. The CCITT and the ISO have defined various
session, presentation, and application recommendations which
have been adopted by the international community and numerous
vendors. To the largest extent possible, it is desirable to
offer these higher level services directly to the Internet,
without disrupting existing facilities. This permits users to
develop expertise with ISO and CCITT applications which
previously were not available in the Internet. The intention
is that hosts within the Internet that choose to implement ISO
TSAP services on top of the TCP be expected to adopt and
implement this standard. Suggestions for improvement are
encouraged.
このメモはインターネットコミュニティの提案されたプロトコル標準について説明します。 CCITTとISOは国際社会によって採用された様々なセッション、プレゼンテーション、およびアプリケーション推薦と多数のベンダーを定義しました。 可能な最も大きい範囲に、直接インターネットに対するこれらのより高い平らなサービスを提供するのは望ましいです、既存の施設を混乱させないで。 これは、ユーザが以前にインターネットで利用可能でなかったISOとCCITTアプリケーションで専門知識を伸ばすことを許可します。 意志はインターネットの中のTCPの上でISO TSAPにサービスを実装するのを選ぶホストがこの規格を採用して、実装すると予想されるということです。 改善提案は奨励されます。
Please discuss any plans for implementation or use of this
protocol with the contact.
このプロトコルの実装か使用のためのあらゆるプランについて接触と議論してください。
OTHER REFERENCES: RFC 983
他の参照: RFC983
DEPENDENCIES:
依存:
CONTACT: DCass@NRTC.NORTHROP.COM
接触: DCass@NRTC.NORTHROP.COM
Mapping Between X.400 and RFC 822 -------------------------- (X.400)
X.400とRFC822の間のマッピング-------------------------- (X.400)
STATUS:
状態:
SPECIFICATION: RFC 987
仕様: RFC987
COMMENTS:
コメント:
The X.400 series of protocols have been defined by CCITT to
provide an Interpersonal Messaging Service (IPMS), making use
of a store and forward Message Transfer Service. It is
expected that this standard will be implemented very widely.
This document describes a set of mappings which will enable
interworking between systems operating the X.400 protocols and
systems using RFC 822 mail protocol or protocols derived from
RFC 822.
プロトコルのX.400シリーズはInterpersonalメッセージサービス(IPMS)を提供するためにCCITTによって定義されました、店と前進のMessage Transfer Serviceを利用して。 この規格が非常に広く実装されると予想されます。 このドキュメントはRFC822メールプロトコルかRFC822から得られたプロトコルを使用することでX.400プロトコルとシステムを操作するシステムの間の織り込むことを可能にする1セットのマッピングについて説明します。
Reynolds & Postel [Page 51]
レイノルズとポステル[51ページ]
RFC 1011 - Official Internet Protocols May 1987
RFC1011--公式のインターネットプロトコル1987年5月
Please discuss any plans for implementation or use of this
protocol with the contact.
このプロトコルの実装か使用のためのあらゆるプランについて接触と議論してください。
OTHER REFERENCES:
他の参照:
DEPENDENCIES:
依存:
CONTACT: Kille@CS.UCL.AC.UK
接触: Kille@CS.UCL.AC.UK
Reynolds & Postel [Page 52]
レイノルズとポステル[52ページ]
一覧
スポンサーリンク
