RFC899 日本語訳

Network Working Group                                          J. Postel
Request for Comments: 899                                     A. Westine
                                                                     ISI
                                                                May 1984

コメントを求めるワーキンググループJ.ポステルの要求をネットワークでつないでください: 899 A.Westine ISI1984年5月

                     Requests For Comments Summary
                             Notes: 800-899

概要が注意するコメントを求める要求: 800-899

Status of this Memo

このMemoの状態

   This RFC is a slightly annotated list of the 100 RFCs from RFC 800
   through RFC 899.  This is a status report on these RFCs.

このRFCはRFC800からRFC899の100RFCsのわずかに注釈されたリストです。 これはこれらのRFCsに関する現状報告です。

RFC     Author       Date        Title
---     ------       ----        -----

RFC作者日付のタイトル--- ------ ---- -----

899     Postel       Apr 84      Requests For Comments Summary

899 コメント概要に関するポステル4月84日のRequests

   This memo.

このメモ。

898     Hinden       Apr 84      Gateway Special Interest Group Meeting
                                 Notes

898 注意を満たすHinden4月84日のゲートウェイ特殊利益集団

   This memo is a report on the Gateway Special Interest Group Meeting
   that was held at ISI on 28 and 29 February 1984.  Robert Hinden of
   BBNCC chaired, and Jon Postel of ISI hosted the meeting.
   Approximately 35 gateway designers and implementors attended.  These
   notes are based on the recollections of Jon Postel and Mike Muuss.
   Under each topic area are Jon Postel's brief notes, and additional
   details from Mike Muuss.  This memo is a report on a meeting.  No
   conclusions, decisions, or policy statements are documented in this
   note.

このメモは28と1984年2月29日にISIで持たれていたゲートウェイ特別利益団体Group Meetingに関するレポートです。 ロバートHinden、BBNCCでは、ISIのまとめられるのとジョン・ポステルはミーティングを主催しました。 およそ35人のゲートウェイデザイナーと作成者が出席しました。 これらの注意はジョン・ポステルとマイクMuussの回想に基づいています。 それぞれの話題領域の下では、ジョン・ポステルの短信、およびマイクMuussから追加詳細があります。 このメモはミーティングに関するレポートです。 どんな結論、決定も、または施政方針もこの注意に記録されません。

897     Postel       Feb 84      Domain Name System Implementation
                                 Schedule

897 ポステル2月84日のドメインネームシステム遂行スケジュール

   This memo is a policy statement on the implementation of the Domain
   Style Naming System in the Internet.  This memo is a partial update
   of RFC 881.  The intent of this memo is to detail the schedule for
   the implementation for the Domain Style Naming System.  The names of
   hosts will be changed to domain style names.  Hosts will begin to use
   domain style names on 14-Mar-84, and the use of old style names will
   be completely phased out before 2-May-84.  This applies to both the
   ARPA research hosts and the DDN operational hosts.  This is an
   official policy statement of the ICCB and the DARPA.

このメモはインターネットのDomain様式Naming Systemの実装に関する施政方針です。 このメモはRFC881の部分的な最新版です。 このメモの意図はDomain様式Naming Systemのために実装のためのスケジュールを詳しく述べることです。 ホストの名前はドメインスタイル名に変わるでしょう。 ホストは1984年3月14日にドメインスタイル名を使用し始めるでしょう、そして、古いスタイル名の使用は1984年5月2日の前に完全に段階的に廃止されるでしょう。 これはARPA研究ホストとDDNの操作上のホストの両方に適用されます。 これはICCBとDARPAの公式方針声明です。

Postel & Westine                                                [page 1]

ポステルとWestine[1ページ]

RFC 899                                                         May 1984

RFC899 1984年5月

896     Nagle        Jan 84      Congestion Control in IP/TCP
                                 Internetworks

896 IP/TCPインターネットワークにおけるネーグルの1月84日の輻輳制御

   This memo discusses some aspects of congestion control in IP/TCP
   Internetworks.  It is intended to stimulate thought and further
   discussion of this topic.  While some specific suggestions are made
   for improved congestion control implementation, this memo does not
   specify any standards.

このメモはIP/TCP Internetworksで輻輳制御のいくつかの局面について議論します。 思考を刺激して、この話題の議論を促進するのは意図しています。 改良された輻輳制御実装のためにいくつかの特定の提案をしている間、このメモはどんな規格も指定しません。

895     Postel       Apr 84      A Standard for the Transmission of
                                 IP Datagrams over Experimental Ethernet
                                 Networks

895 実験的なイーサネットの上のIPデータグラムの送信の規格がネットワークでつなぐポステル4月84日

   This RFC specifies a standard method of encapsulating Internet
   Protocol (IP) datagrams on an Experimental Ethernet.  This RFC
   specifies a standard protocol for the ARPA Internet community.

このRFCはExperimentalイーサネットでインターネットプロトコル(IP)がデータグラムであるとカプセル化する標準方法を指定します。 このRFCはARPAインターネットコミュニティに標準プロトコルを指定します。

894     Hornig       Apr 84      A Standard for the Transmission of
                                 IP Datagrams over Ethernet Networks

894 イーサネットの上のIPデータグラムの送信の規格がネットワークでつなぐホーニッグ4月84日

   This RFC specifies a standard method of encapsulating Internet
   Protocol (IP) datagrams on an Ethernet.  This RFC specifies a
   standard protocol for the ARPA-Internet community.

このRFCはイーサネットでインターネットプロトコル(IP)がデータグラムであるとカプセル化する標準方法を指定します。 このRFCはARPA-インターネットコミュニティに標準プロトコルを指定します。

893     Leffler      Apr 84      Trailer Encapsulations

893 レフラー4月84日のトレーラカプセル化

   This RFC discusses the motivation for use of "trailer encapsulations"
   on local-area networks and describes the implementation of such an
   encapsulation on various media.  This document is for information
   only.  This is NOT an official protocol for the ARPA Internet
   community.

このRFCはローカル・エリア・ネットワークで「トレーラカプセル化」の使用に関する動機について議論して、様々なメディアでそのようなカプセル化の実装について説明します。 このドキュメントは情報だけのためのものです。 これはARPAインターネットコミュニティのための公式のプロトコルではありません。

892     ISO          Dec 83      ISO Transport Protocol Specification

892 ISO12月83日のISO輸送プロトコル仕様

   This is a draft version of the transport protocol being standardized
   by the ISO.  This version also appeared in the ACM SIGCOMM Computer
   Communication Review (V.12, N.3-4) July-October 1982.  This version
   is now out of date.

これはISOによって標準化されるトランスポート・プロトコルの草案バージョンです。 また、このバージョンは1982年7月-10月にACM SIGCOMMコンピュータCommunication Review(V.12、N.3-4)に現れました。 このバージョンは現在、時代遅れです。

891     Mills        Dec 83      DCN Local-Network Protocols

891の工場12月83日DCN企業内情報通信網プロトコル

   This RFC provides a description of the DCN protocols for maintaining
   connectivity, routing, and clock information in a local network.
   These procedures may be of interest to the designers and implementers
   of other local networks.

このRFCは企業内情報通信網で接続性、ルーティング、および時計情報を保守するのにDCNプロトコルの記述を提供します。 これらの手順は他の企業内情報通信網のデザイナーとimplementersに興味があるかもしれません。

Postel & Westine                                                [page 2]

ポステルとWestine[2ページ]

RFC 899                                                         May 1984

RFC899 1984年5月

890     Postel       Feb 84      Exterior Gateway Protocol
                                 Implementation Schedule

890 ポステル2月84日の外のゲートウェイプロトコル遂行スケジュール

   This memo is a policy statement on the implementation of the Exterior
   Gateway Protocol in the Internet.  This is an official policy
   statement of ICCB and DARPA.  After 1-Aug-84 there shall be no dumb
   gateways in the Internet. Every gateway must be a member of some
   autonomous system.  Some gateway of each autonomous system must
   exchange routing information with some gateway of the core autonomous
   system using the Exterior Gateway Protocol.

このメモはインターネットのExteriorゲートウェイプロトコルの実装に関する施政方針です。 これはICCBとDARPAの公式方針声明です。 1984年8月1日以降、どんな馬鹿なゲートウェイもインターネットにないでしょう。 あらゆるゲートウェイがいくつかの自律システムのメンバーであるに違いありません。 それぞれの自律システムのあるゲートウェイが、Exteriorゲートウェイプロトコルを使用することでコア自律システムのあるゲートウェイとルーティング情報を交換しなければなりません。

889     Mills        Dec 83      Internet Delay Experiments

12月83日のインターネット遅れが実験する889の工場

   This memo reports on some measurements of round-trip times in the
   Internet and suggests some possible improvements to the TCP
   retransmission timeout calculation.  This memo is both a status
   report on the Internet and advice to TCP implementers.

このメモは、インターネットで往復の回のいくつかの測定値に関して報告して、TCP再送タイムアウト計算へのいくつかの可能な改良を示します。 このメモはインターネットに関する現状報告とTCP implementersへのアドバイスの両方です。

888     Seamonson    Jan 84      "Stub" Exterior Gateway Protocol

888 Seamonson1月84日の「スタッブ」外のゲートウェイプロトコル

   This RFC describes the Exterior Gateway Protocol used to connect Stub
   Gateways to an Autonomous System of core Gateways.  This document
   specifies the working protocol, and defines an ARPA official
   protocol.  All implementers of Gateways should carefully review this
   document.

このRFCはコアGatewaysのAutonomous SystemにStub Gatewaysを接続するのに使用されるExteriorゲートウェイプロトコルについて説明します。 このドキュメントは、働くプロトコルを指定して、ARPAの公式のプロトコルを定義します。 Gatewaysのすべてのimplementersが慎重にこのドキュメントを再検討するはずです。

887     Accetta      Dec 83      Resource Location Protocol

887 Accetta12月83日のリソース位置のプロトコル

   This RFC specifies a draft standard for the ARPA Internet community.
   It describes a resource location protocol for use in the ARPA
   Internet.  It is most useful on networks employing technologies which
   support some method of broadcast addressing, however it may also be
   used on other types of networks.  For maximum benefit, all hosts
   which provide significant resources or services to other hosts on the
   Internet should implement this protocol.  Hosts failing to implement
   the Resource Location Protocol risk being ignored by other hosts
   which are attempting to locate resources on the Internet.

このRFCはARPAインターネットコミュニティの草稿規格を指定します。 それはARPAインターネットでの使用のためにリソース位置のプロトコルについて説明します。 ブロードキャスト・アドレッシングの何らかのメソッドをサポートする技術を使うネットワークで最も役に立つ、しかしながら、また、それは他のタイプのネットワークで使用されるかもしれません。 最大限の利益、どれが重要なリソースを提供するか、そして、インターネットの他のホストに対するサービスがこのプロトコルであると実装するべきであるすべてのホストのために。 Resource Locationがプロトコルであると実装しないホストは、他のホストによって無視される危険を冒します(インターネットにリソースの場所を見つけるのを試みています)。

886     Rose         Dec 83      Proposed Standard for Message Header
                                 Munging

886 メッセージヘッダーの変更を加えることのバラ12月83日の提案された標準

   This RFC specifies a draft standard for the ARPA Internet community.
   It describes the rules to be used when transforming mail from the
   conventions of one message system to those of another message system.
   In particular, the treatment of header fields, and recipient
   addresses is specified.

このRFCはARPAインターネットコミュニティの草稿規格を指定します。 それは、メールを1台のメッセージシステムのコンベンションから別のメッセージシステムのものに変えるとき、使用されるために規則について説明します。 中では、事項、ヘッダーフィールドの処理、および受取人アドレスは指定されます。

Postel & Westine                                                [page 3]

ポステルとWestine[3ページ]

RFC 899                                                         May 1984

RFC899 1984年5月

885     Postel       Dec 83      Telnet End of Record Option

記録的なオプションの885ポステル12月83日のtelnet終わり

   This RFC specifies a standard for the ARPA Internet community.  It
   specifies a method for marking the end of records in data transmitted
   on Telnet connections.

このRFCはARPAインターネットコミュニティの規格を指定します。 それはTelnet接続のときに送られたデータでの記録の終わりを示すためのメソッドを指定します。

884     Solomon      Dec 83      Telnet Terminal Type Option

884 ソロモンの12月83日のtelnet端末タイプオプション

   This RFC specifies a standard for the ARPA Internet community.  It
   specifies a method for exchanging terminal type information in the
   Telnet protocol.

このRFCはARPAインターネットコミュニティの規格を指定します。 それはTelnetプロトコルの端末のタイプ情報を交換するためのメソッドを指定します。

883     Mockapetris  Nov 83      Domain Names - Implementation and
                                 Specification

883Mockapetris11月83日ドメイン名--実装と仕様

   This RFC discusses the implementation of domain name servers and
   resolvers, specifies the format of transactions, and discusses the
   use of domain names in the context of existing mail systems and other
   network software.

このRFCはドメイン名サーバとレゾルバの実装について議論して、トランザクションの形式を指定して、既存のメールシステムと他のネットワークソフトウェアの文脈におけるドメイン名の使用について議論します。

882     Mockapetris  Nov 83      Domain Names - Concepts and Facilities

882Mockapetris11月83日ドメイン名--概念と施設

   This RFC introduces domain style names, their use for ARPA Internet
   mail and host address support, and the protocol and servers used to
   implement domain name facilities.

このRFCはドメイン名施設を実装するのに使用されるドメインスタイル名、彼らのARPAインターネット・メールとホスト・アドレスサポートの使用、プロトコル、およびサーバを紹介します。

881     Postel       Nov 83      The Domain Names Plan and Schedule

881 ドメイン名が計画して、計画をするポステル11月83日

   This RFC outlines a plan and schedule for the implementation of
   domain style names throughout the DDN/ARPA Internet community.  The
   introduction of domain style names will impact all hosts on the
   DDN/ARPA Internet.

このRFCはDDN/ARPAインターネットコミュニティ中にドメインスタイル名の実装のためのプランとスケジュールについて概説します。 ドメインスタイル名の導入はDDN/ARPAインターネットですべてのホストに影響を与えるでしょう。

880     Reynolds     Oct 83      Official Protocols

880 レイノルズ10月83日の公式のプロトコル

   This RFC identifies the documents specifying the official protocols
   used in the ARPA Internet.  Annotations identify any revisions or
   changes planned.  Obsoletes RFC 840.

このRFCはARPAインターネットで使用される公式のプロトコルを指定するドキュメントを特定します。 注釈がどんな改正も特定するか、または変化は計画されていました。 RFC840を時代遅れにします。

879     Postel       Nov 83      The TCP Maximum Segment Size and
                                 Related Topics

879ポステル11月83日のTCPの最大のセグメントサイズの、そして、関連の話題

   This RFC discusses the TCP Maximum Segment Size Option and related
   topics.  The purposes is to clarify some aspects of TCP and its
   interaction with IP.  This memo is a clarification to the TCP
   specification, and contains information that may be considered as
   "advice to implementers".

このRFCはTCP Maximum Segment Size Optionと関連した話題について議論します。 目的はTCPのいくつかの局面とIPとのその相互作用をはっきりさせることです。 このメモは、TCP仕様への明確化であり、「implementersへのアドバイス」であるとみなされるかもしれない情報を含んでいます。

Postel & Westine                                                [page 4]

ポステルとWestine[4ページ]

RFC 899                                                         May 1984

RFC899 1984年5月

878     Malis        Dec 83      The ARPANET 1822L Host Access Protocol

878 アルパネット1822Lが接待するMalis12月83日はプロトコルにアクセスします。

   This RFC specifies the ARPANET 1822L Host Access Protocol, which is a
   successor to the existing 1822 Host Access Protocol.  The 1822L
   procedure allows ARPANET hosts to use logical identifiers as well as
   1822 physical interface identifiers to address each other.

このRFCはアルパネット1822L Host Accessプロトコルを指定します。(それは、1822年の既存のHost Accessプロトコルの後継者です)。 1822L手順は、アルパネットホストが論理的な識別子を使用するのを許容して、1822の物理インターフェース識別子が互いに演説するのを許容します。

877     Korb         Sep 83      A Standard for the Transmission of IP
                                 Datagrams Over Public Data Networks

877 公衆データの上のIPデータグラムの送信の規格がネットワークでつなぐコルプ9月83日

   This RFC specifies a standard adopted by CSNET, the VAN gateway, and
   other organizations for the transmission of IP datagrams over the
   X.25-based public data networks.

このRFCはX.25を拠点とする公衆データネットワークの上でCSNET、VANゲートウェイによって採用された規格、およびIPデータグラムのトランスミッションのための他の組織を指定します。

876     Smallberg    Sep 83      Survey of SMTP Implementations

876 SMTP実装のSmallberg9月83日の調査

   This RFC is a survey of implementation status.  It does not specify
   an official protocol, but rather notes the status of implementation
   of aspects of a protocol.  It is expected that the status of the
   hosts reported on will change.  This information must be treated as a
   snapshot of the state of these implemetations.

このRFCは実装状態の調査です。 それは、公式のプロトコルを指定しませんが、むしろプロトコルの局面の実装の状態に注意します。 オンであると報告されたホストの状態が変化すると予想されます。 これらのimplemetationsの状態のスナップとしてこの情報を扱わなければなりません。

875     Padlipsky    Sep 82      Gateways, Architectures, and Heffalumps

875 Padlipsky9月の82門、アーキテクチャ、およびHeffalumps

   This RFC is a discussion about the role of gateways in an
   internetwork, especially the problems of translating or mapping
   protocols between different protocol suites.  The discussion notes
   possible functionality mis-matches, undesirable routing "singularity
   points", flow control issues, and high cost of translating gateways.
   Originally published as M82-51 by the MITRE Corporation, Bedford,
   Massachusetts.

このRFCはインターネットワークにおけるゲートウェイの役割が議論です、異なったプロトコル群の間のプロトコルを翻訳するか、または写像するという特に問題。 議論はゲートウェイを翻訳する可能な機能性誤マッチ、望ましくないルーティング「特異性ポイント」、フロー制御問題、および高い費用に注意します。 元々、M82-51としてMITRE社、ベッドフォード、マサチューセッツによって発行されています。

874     Padlipsky    Sep 82      A Critique of X.25

874Padlipsky9月82日 X.25の批評

   This RFC is an analysis of X.25 pointing out some problems in the
   conceptual model, particularly the conflict between the interface
   aspects and the end-to-end aspects.  The memo also touches on
   security, and implementation issues.  Originally published as M82-50
   by the MITRE Corporation, Bedford, Massachusetts.

このRFCは概念モデルのいくつかの問題を指摘するX.25の分析と、特にインタフェース局面の間の闘争と終わりから端への局面です。 また、メモはセキュリティ、および導入問題に触れます。 元々、M82-50としてMITRE社、ベッドフォード、マサチューセッツによって発行されています。

873     Padlipsky    Sep 82      The Illusion of Vendor Support

873Padlipsky9月82日 ベンダーサポートの幻想

   This memo takes issue with the claim that international standards in
   computer protocols presently provide a basis for low cost vendor
   supported protocol implementations.  Originally published as M82-49
   by the MITRE Corporation, Bedford, Massachusetts.

このメモはコンピュータプロトコルの世界規格が現在プロトコル実装であるとサポートされた低価格ベンダーの基礎を提供するというクレームに反対します。 元々、M82-49としてMITRE社、ベッドフォード、マサチューセッツによって発行されています。

Postel & Westine                                                [page 5]

ポステルとWestine[5ページ]

RFC 899                                                         May 1984

RFC899 1984年5月

872     Padlipsky    Sep 82      TCP-ON-A-LAN

872 LANのPadlipsky9月82日のTCP

   This memo attacks the notion that TCP cannot be appropriate for use
   on a Local Area Network.  Originally published as M82-48 by the MITRE
   Corporation, Bedford Massachusetts.

このメモはローカル・エリア・ネットワークにおける使用に、TCPが適切であるはずがないという概念を攻撃します。 元々、M82-48としてMITRE社、ベッドフォード・マサチューセッツによって発行されています。

871     Padlipsky    Sep 82      A Perspective on the Arpanet Reference
                                 Model

871 Arpanet規範モデルの上の1見解あたりのPadlipsky9月82日

   This RFC is primarily intended as a perspective on the ARM and points
   out some of the differences between the ARM and the ISORM  which were
   expressed by members in NWG general meetings, NWG protocol design
   committee meetings, the ARPA Internet Working Group, and private
   conversations over the intervening years.  Originally published as
   M82-47 by the MITRE Corporation, Bedford, Massachusetts.

このRFCは見解としてARMで主として意図して、介入している数年間のNWG総会でメンバーによって急送されたARMとISORMの違い、NWGプロトコルデザイン委員会、ARPAインターネット作業部会、および密談のいくつかを指摘します。 元々、M82-47としてMITRE社、ベッドフォード、マサチューセッツによって発行されています。

870     Reynolds     Oct 83      Assigned Numbers

870 レイノルズ10月83日は数を割り当てました。

   This RFC documents the list of numbers assigned for networks,
   protocols, etc.  Obsoletes RFCs 820, 790, 776, 770, 762, 758, 755,
   750, 739, 604.

このRFCはネットワーク、プロトコルなどのために割り当てられた数のリストを記録します。 RFCs820、790、776、770、762、758、755、750、739、604を時代遅れにします。

869     Hinden       Dec 83      A Host Monitoring Protocol

869は12月83日にホストのモニターしているプロトコルをHindenします。

   This RFC specifies the Host Monitoring Protocol used to collect
   information from various types of hosts in the Internet.  Designers
   of Internet communications software are encouraged to consider this
   protocol as a means of monitoring the behavior of their creations.

このRFCはインターネットに様々なタイプのホストから情報を集めるのに使用されるHost Monitoringプロトコルを指定します。 インターネット通信ソフトウェアのデザイナーが、このプロトコルがそれらの作成の振舞いをモニターする手段であるとみなすよう奨励されます。

868     Postel       May 83      Time Protocol

868 ポステル5月83日の時間プロトコル

   This RFC specifies a standard for the ARPA Internet community.  Hosts
   on the ARPA Internet that choose to implement a Time Protocol are
   expected to adopt and implement this standard.  This protocol
   provides a site-independent, machine readable date and time.  The
   Time service sends back to the originating source the time in seconds
   since midnight on January first 1900.

このRFCはARPAインターネットコミュニティの規格を指定します。 ARPAインターネットのTimeプロトコルを実装するのを選ぶホストは、この規格を採用して、実装すると予想されます。 このプロトコルはサイトから独立していて、マシン読み込み可能な日時を提供します。 Timeサービスは1900年1月1日真夜中以来の秒の時に起因しているソースを送り返します。

867     Postel       May 83      Daytime Protocol

867 ポステル5月83日の昼間のプロトコル

   This RFC specifies a standard for the ARPA Internet community.  Hosts
   on the ARPA Internet that choose to implement a Daytime Protocol are
   expected to adopt and implement this standard.  The Daytime service
   simply sends the current date and time as a character string without
   regard to the input.

このRFCはARPAインターネットコミュニティの規格を指定します。 ARPAインターネットのDaytimeプロトコルを実装するのを選ぶホストは、この規格を採用して、実装すると予想されます。 Daytimeサービスは文字列として関係なしで現在の日時を入力に単に送ります。

Postel & Westine                                                [page 6]

ポステルとWestine[6ページ]

RFC 899                                                         May 1984

RFC899 1984年5月

866     Postel       May 83      Active Users

866 ポステル5月83日Activeのユーザ

   This RFC specifies a standard for the ARPA Internet community.  Hosts
   on the ARPA Internet that choose to implement an Active Users
   Protocol are expected to adopt and implement this standard.  The
   Active Users service simply sends a list of the currently active
   users on the host without regard to the input.

このRFCはARPAインターネットコミュニティの規格を指定します。 ARPAインターネットのActive Usersがプロトコルであると実装するのを選ぶホストは、この規格を採用して、実装すると予想されます。 Active Usersサービスは関係なしでホストの上の現在活発なユーザのリストを入力に単に送ります。

865     Postel       May 83      Quote of the Day Protocol

865 ポステル5月83日の今日の名言プロトコル

   This RFC specifies a standard for the ARPA Internet community.  Hosts
   on the ARPA Internet that choose to implement a Quote of the Day
   Protocol are expected to adopt and implement this standard.   The
   Quote of the Day service simply sends a short message without regard
   to the input.

このRFCはARPAインターネットコミュニティの規格を指定します。 ARPAインターネットのデープロトコルのQuoteを実装するのを選ぶホストは、この規格を採用して、実装すると予想されます。 デーサービスのQuoteは関係なしで短いメッセージを入力に単に送ります。

864     Postel       May 83      Character Generator Protocol

864 ポステル5月83日の文字発生機構プロトコル

   This RFC specifies a standard for the ARPA Internet community.  Hosts
   on the ARPA Internet that choose to implement a Character Generator
   Protocol are expected to adopt and implement this standard.  The
   Character Generator service simply sends data without regard to the
   input.

このRFCはARPAインターネットコミュニティの規格を指定します。 ARPAインターネットのキャラクターGeneratorプロトコルを実装するのを選ぶホストは、この規格を採用して、実装すると予想されます。 キャラクターGeneratorサービスは関係なしでデータを入力に単に送ります。

863     Postel       May 83      Discard Protocol

863 ポステル5月83日はプロトコルを捨てます。

   This RFC specifies a standard for the ARPA Internet community.  Hosts
   on the ARPA Internet that choose to implement a Discard Protocol are
   expected to adopt and implement this standard.  The Discard service
   simply throws away any data it receives.

このRFCはARPAインターネットコミュニティの規格を指定します。 ARPAインターネットのDiscardプロトコルを実装するのを選ぶホストは、この規格を採用して、実装すると予想されます。 Discardサービスは単にそれが受け取るどんなデータも無駄にします。

862     Postel       May 83      Echo Protocol

862 ポステル5月83日のエコープロトコル

   This RFC specifies a standard for the ARPA Internet community.  Hosts
   on the ARPA Internet that choose to implement a Echo Protocol are
   expected to adopt and implement this standard.  The Echo service
   simply sends back to the originating source any data it receives.

このRFCはARPAインターネットコミュニティの規格を指定します。 ARPAインターネットのEchoプロトコルを実装するのを選ぶホストは、この規格を採用して、実装すると予想されます。 Echoサービスは単にそれが受け取るどんなデータも起因しているソースに送り返します。

861     Postel       May 83      Telnet Extended Options - List Option

861ポステル5月83日のtelnetはオプションを広げました--オプションを記載してください。

   This Telnet Option provides a mechanism for extending the set of
   possible options.  This RFC specifies a standard for the ARPA
   Internet community.  Hosts on the ARPA Internet are expected to adopt
   and implement this standard.  Obsoletes NIC 16239.

このTelnet Optionは可能なオプションのセットを広げるのにメカニズムを提供します。 このRFCはARPAインターネットコミュニティの規格を指定します。 ARPAインターネットのホストは、この規格を採用して、実装すると予想されます。 NIC16239を時代遅れにします。

Postel & Westine                                                [page 7]

ポステルとWestine[7ページ]

RFC 899                                                         May 1984

RFC899 1984年5月

860     Postel       May 83      Telnet Timing Mark Option

860 ポステルの5月83日のtelnetタイミング・マークオプション

   This Telnet Option provides a way to check the roundtrip path between
   two Telnet modules.  This RFC specifies a standard for the ARPA
   Internet community.  Hosts on the ARPA Internet are expected to adopt
   and implement this standard.  Obsoletes NIC 16238.

このTelnet Optionは2つのTelnetモジュールの間の往復の経路をチェックする方法を提供します。 このRFCはARPAインターネットコミュニティの規格を指定します。 ARPAインターネットのホストは、この規格を採用して、実装すると予想されます。 NIC16238を時代遅れにします。

859     Postel       May 83      Telnet Status Option

859 ポステルの5月83日のtelnet状態オプション

   This Telnet Option provides a way to determine the other Telnet
   module's view of the status of options.  This RFC specifies a
   standard for the ARPA Internet community.  Hosts on the ARPA Internet
   are expected to adopt and implement this standard.  Obsoletes RFC 651
   (NIC 31154).

このTelnet Optionはもう片方のTelnetモジュールのオプションの状態の視点を決定する方法を提供します。 このRFCはARPAインターネットコミュニティの規格を指定します。 ARPAインターネットのホストは、この規格を採用して、実装すると予想されます。 RFC651(NIC31154)を時代遅れにします。

858     Postel       May 83      Telnet Suppress Go Ahead Option

ポステル5月83日のTelnetが抑圧する858はオプションに前方に行きます。

   This Telnet Option disables the exchange of go-ahead signals between
   the Telnet modules.  This RFC specifies a standard for the ARPA
   Internet community.  Hosts on the ARPA Internet are expected to adopt
   and implement this standard.  Obsoletes NIC 15392.

このTelnet OptionはTelnetモジュールの間の開始の合図の交換を無効にします。 このRFCはARPAインターネットコミュニティの規格を指定します。 ARPAインターネットのホストは、この規格を採用して、実装すると予想されます。 NIC15392を時代遅れにします。

857     Postel       May 83      Telnet Echo Option

857 ポステルの5月83日のtelnetエコーオプション

   This Telnet Option enables remote echoing by the other Telnet module.
   This RFC specifies a standard for the ARPA Internet community.  Hosts
   on the ARPA Internet are expected to adopt and implement this
   standard.  Obsoletes NIC 15390.

このTelnet Optionはもう片方のTelnetモジュールによるリモート反響を可能にします。 このRFCはARPAインターネットコミュニティの規格を指定します。 ARPAインターネットのホストは、この規格を採用して、実装すると予想されます。 NIC15390を時代遅れにします。

856     Postel       May 83      Telnet Binary Transmission

856 ポステルの5月83日のtelnetバイナリー送信

   This Telnet Option enables a binary data mode between the Telnet
   modules.  This RFC specifies a standard for the ARPA Internet
   community.  Hosts on the ARPA Internet are expected to adopt and
   implement this standard.  Obsoletes NIC 15389.

このTelnet OptionはTelnetモジュールの間のバイナリ・データモードを可能にします。 このRFCはARPAインターネットコミュニティの規格を指定します。 ARPAインターネットのホストは、この規格を採用して、実装すると予想されます。 NIC15389を時代遅れにします。

855     Postel       May 83      Telnet Option Specifications

855 ポステル5月83日のtelnetオプション仕様

   This memo specifies the general form for Telnet options and the
   directions for their specification.  This RFC specifies a standard
   for the ARPA Internet community.  Hosts on the ARPA Internet are
   expected to adopt and implement this standard.  Obsoletes RFC 651,
   NIC 18640.

このメモはTelnetオプションのための一般的なフォームとそれらの仕様のための方向を指定します。 このRFCはARPAインターネットコミュニティの規格を指定します。 ARPAインターネットのホストは、この規格を採用して、実装すると予想されます。 RFC651、NIC18640を時代遅れにします。

Postel & Westine                                                [page 8]

ポステルとWestine[8ページ]

RFC 899                                                         May 1984

RFC899 1984年5月

854     Postel       May 83      Telnet Protocol Specifications

854 ポステル5月83日のtelnetプロトコル仕様

   This is the specification of the Telnet protocol used for remote
   terminal access in the ARPA Internet.  The purpose of the TELNET
   Protocol is to provide a fairly general, bi-directional, eight-bit
   byte oriented communications facility.  Its primary goal is to allow
   a standard method of interfacing terminal devices and
   terminal-oriented processes to each other.  It is envisioned that the
   protocol may also be used for terminal-terminal communication
   ("linking") and process-process communication (distributed
   computation).   This RFC specifies a standard for the ARPA Internet
   community.  Hosts on the ARPA Internet are expected to adopt and
   implement this standard.  Obsoletes NIC 18639.

これはARPAインターネットでの遠隔端末アクセスに使用されるTelnetプロトコルの仕様です。 TELNETプロトコルの目的はかなり一般的で、双方向の、そして、8ビットのバイト指向のコミュニケーション施設を提供することです。 プライマリ目標は端末装置と端末指向のプロセスを互いに連結する標準方法を許容することです。 それは思い描かれます。また、プロトコルは端末間通信(「リンク」)とプロセス間通信(分散型計算方式)に使用されるかもしれません。 このRFCはARPAインターネットコミュニティの規格を指定します。 ARPAインターネットのホストは、この規格を採用して、実装すると予想されます。 NIC18639を時代遅れにします。

853     Not issued yet.

853 まだ発行されていません。

852     Malis        Apr 83      The ARPANET Short Blocking Feature

852Malis4月83日 アルパネットの短いブロッキング機能

   This RFC specifies the ARPANET Short Blocking Feature, which will
   allow ARPANET  hosts to optionally shorten the IMP's host blocking
   timer.  This Feature is a replacement of the ARPANET non-blocking
   host interface, which was never implemented, and will be available to
   hosts using either the 1822 or 1822L Host Access Protocol.  This RFC
   is also being presented as a solicitation of comments on the Short
   Blocking Feature, especially from host network software implementers
   and maintainers.

このRFCはアルパネットShort Blocking Featureを指定します。(Short Blocking FeatureはアルパネットホストにIMPのホストブロッキングタイマを任意に短くさせるでしょう)。 このFeatureはアルパネット非ブロッキングホスト・インターフェースの交換であり、1822を使用しているホストか1822L Host Accessプロトコルに利用可能になるでしょう。(ホスト・インターフェースは決して実装されませんでした)。 また、Short Blocking Featureにおけるコメントの懇願としてこのRFCを寄贈しています、特にホストネットワークソフトウェアimplementersと維持装置から。

851     Malis        Apr 83      The ARPANET 1822L Host Access Protocol

851 アルパネット1822Lが接待するMalis4月83日はプロトコルにアクセスします。

   This RFC specifies the ARPANET 1822L Host Access Protocol, which is a
   successor to the existing 1822 Host Access Protocol.  1822L allows
   ARPANET hosts to use logical names as well as 1822's physical port
   locations to address each other.  This RFC is also being presented as
   a solicitation of comments on 1822L, especially from host network
   software implementers and maintainers.  Obsoletes RFC 802.

このRFCはアルパネット1822L Host Accessプロトコルを指定します。(それは、1822年の既存のHost Accessプロトコルの後継者です)。 1822Lは、アルパネットホストが論理的な名前を使用するのを許容して、1822年代の物理的なポート位置が互いに演説するのを許容します。 また、1822Lにおけるコメントの懇願としてこのRFCを寄贈しています、特にホストネットワークソフトウェアimplementersと維持装置から。 RFC802を時代遅れにします。

850     Horton       Jun 83      Standard for Interchange of USENET
                                 Messages

850 USENETメッセージの置き換えのホートン6月83日の規格

   This memo is distributed as an RFC only to make this information
   easily accessible to researchers in the ARPA community.  It does not
   specify an Internet standard.  This RFC defines the standard format
   for interchange of Network News articles among USENET sites.  It
   describes the format for articles themselves, and gives partial
   standards for transmission of news.  The news transmission is not
   entirely standardized in order to give a good deal of flexibility to
   the individual hosts to choose transmission hardware and software,
   whether to batch news and so on.

このメモはRFCとして配布されますが、ARPA共同体でこの情報を研究者には容易にアクセスしやすくします。 それはインターネット標準を指定しません。 このRFCはNetwork News記事の置き換えのためにUSENETサイトの中で標準書式を定義します。 それは、記事自体のために形式について説明して、ニュースの伝達の部分的な規格を与えます。 ニュース放送はトランスミッションハードウェアとソフトウェアを選ぶために多くの柔軟性を個々のホストに与えるために完全に標準化されません、バッチニュースなどにか否かに関係なく。

Postel & Westine                                                [page 9]

ポステルとWestine[9ページ]

RFC 899                                                         May 1984

RFC899 1984年5月

849     Crispin      May 83      Suggestions for Improved Host Table
                                 Distribution

849 改良されたホストテーブル分配のためのクリスピン5月83日の提案

   This RFC actually is a request for comments.  The issue dealt with is
   that of a naming registry update procedure, both as exists currently
   and what could exist in the future.  None of the proposed solutions
   are intended as standards at this time; rather it is hoped that a
   general consensus will emerge as the appropriate solution, leaving
   eventually to the adoption of standards.

コメントを求めてこのRFCは実際に要求です。 ともに現在存在するとき、対処された問題は命名登録アップデート手順のものです、そして、何が将来、存在できますか? 提案されたソリューションのいずれもこのとき、規格として意図しません。 結局規格の採用にいなくなって、むしろ、全体的な合意が適切なソリューションとして現れることが望まれています。

848     Smallberg    Mar 83      Who provides the "Little" TCP Services?

848 3月83日のWhoが「小さい」TCP Servicesを供給するSmallberg?

   This RFC lists those hosts which provide any of these "little" TCP
   services:  The list of hosts were taken from the NIC hostname table
   of 24-Feb-83.  The tests were run on February 23 and 24, and March 3
   and 5 from ISI-VAXA.ARPA.

このRFCはそれらのホストを記載します(これらの「小さい」TCPサービスのどれかを提供します): 1983年2月24日のNICホスト名テーブルからホストのリストを取りました。 テストは2月23日と24日、3月3日、および5日にISI-VAXA.ARPAから実行されました。

847     Westine      Feb 83      Summary of Smallberg Surveys

847 Smallberg調査のWestine2月83日の概要

   This is a summary of the surveys of Telnet, FTP and Mail (SMTP)
   servers conducted by David Smallberg in December 1982, January and
   February 1983 as reported in RFC 832-843, 845-846.  This memo
   extracts the number of hosts that accepted the connection to their
   server for each of Telnet, FTP, and SMTP, and compares it to the
   total host in the Internet (not counting TACs or ECHOS).

これは、RFC832-843(845-846)で報告されるようにTelnetの調査の概要と、1982年12月にデヴィッドSmallbergによって行われたFTPとメール(SMTP)サーバと、1983年1月、2月です。 このメモはそれぞれのTelnet、FTP、およびSMTPのために彼らのサーバに接続を受け入れて、インターネットで総ホストとそれを比較するホストの数を抽出します(TACsかECHOSを数えないで)。

846     Smallberg    Feb 83      Who Talks TCP? -- Survey of 22 February
                                 1983

846 TCPについて話すSmallberg2月83日? -- 1983年2月22日の調査

   This RFC is a survey of hosts to identify the implementation status
   of Telnet, FTP, and Mail on TCP.  The list of hosts was taken from
   the NIC hostname table of 18-Feb-83.  The tests were run on 22-Feb-83
   from ISI-VAXA.ARPA.

このRFCはTCPでTelnet、FTP、およびメールの実装状態を特定するホストの調査です。 1983年2月18日のNICホスト名テーブルからホストのリストを取りました。 テストはISI-VAXA.ARPAからの1983年2月22日に実行されました。

845     Smallberg    Feb 83      Who Talks TCP? -- Survey of 15 February
                                 1983

845 TCPについて話すSmallberg2月83日? -- 1983年2月15日の調査

   This RFC is a survey of hosts to identify the implementation status
   of Telnet, FTP, and Mail on TCP.  The list of hosts was taken from
   the NIC hostname table of 3-Feb-83.  The tests were run on 15-Feb-83
   from ISI-VAXA.ARPA.

このRFCはTCPでTelnet、FTP、およびメールの実装状態を特定するホストの調査です。 1983年2月3日のNICホスト名テーブルからホストのリストを取りました。 テストはISI-VAXA.ARPAからの1983年2月15日に実行されました。

Postel & Westine                                               [page 10]

ポステルとWestine[10ページ]

RFC 899                                                         May 1984

RFC899 1984年5月

844     Clements    Feb 83      Who Talks ICMP, too?  Survey of 18
                                 February 1983

844 また、クレメンツ2月83日のWho Talks ICMP? 1983年2月18日の調査

   This survey determines how many hosts are able to respond to TELENET
   connections from a user at a class C site.  This requires, in
   addition to IP and TCP, participation in gateway routing via ICMP and
   handling of Class C addresses.  The list of hosts was taken from RFC
   843, extracting only those hosts which are listed there as accepting
   TELNET connection.  The tests were run on 18-Feb-83.

この調査は、何人のホストがクラスCサイトのユーザからテレネット接続に応じることができるかを決定します。 これはClass CアドレスのICMPと取り扱いでIPとTCPに加えてゲートウェイルーティングへの参加を必要とします。 RFC843からホストのリストを取りました、TELNET接続を受け入れるとしてそこに記載されているそれらのホストだけを抽出して。 テストは1983年2月18日に実行されました。

843     Smallberg    Feb 83      Who Talks TCP? -- Survey of 8 February
                                 1983

843 TCPについて話すSmallberg2月83日? -- 1983年2月8日の調査

   This RFC is a survey of hosts to identify the implementation status
   of Telnet, FTP, and Mail on TCP.  The list of hosts was taken from
   the NIC hostname table of 3-Feb-83.  The tests were run on 8-Feb-83
   and on 9-Feb-83 from ISI-VAXA.ARPA.

このRFCはTCPでTelnet、FTP、およびメールの実装状態を特定するホストの調査です。 1983年2月3日のNICホスト名テーブルからホストのリストを取りました。 テストは1983年2月8日とISI-VAXA.ARPAからの1983年2月9日に実行されました。

842     Smallberg    Feb 83      Who Talks TCP? -- Survey of 1 February
                                 1983

842 TCPについて話すSmallberg2月83日? -- 1983年2月1日の調査

   This RFC is a survey of hosts to identify the implementation status
   of Telnet, FTP, and Mail on TCP.  The list of hosts was taken from
   the NIC hostname table of 28-Jan-83.  The tests were run on 1-Feb-83
   and on 2-Feb-83 ISI-VAXA.ARPA.

このRFCはTCPでTelnet、FTP、およびメールの実装状態を特定するホストの調査です。 1983年1月28日のNICホスト名テーブルからホストのリストを取りました。 テストは1983年2月1日の上と、そして、1983年2月2日ISI-VAXA.ARPAの上に実行されました。

841     FIPS PUB 98  Jan 83      Specification for Message Format for
                                 Computer Based Message Systems

コンピュータのベースのメッセージシステムのためのメッセージ・フォーマットのための841FIPSパブ98 1月83日仕様

   This RFC is FIPS 98.  The purpose of distributing this document as an
   RFC is to make it easily accessible to the ARPA research community.
   This RFC does not specify a standard for the ARPA Internet.
   Obsoletes RFC 806.

このRFCはFIPS98です。 RFCとしてこのドキュメントを配布する目的はそれを容易にARPA研究団体にアクセスしやすくすることです。 このRFCはARPAインターネットの規格を指定しません。 RFC806を時代遅れにします。

840     Postel       Apr 83      Official Protocols

840ポステル4月83日の公式のプロトコル

   This RFC has been revised, see RFC 880.

RFC880は、このRFCが改訂されたのを見ます。

839     Smallberg    Jan 83      Who Talks TCP?

839 TCPについて話すSmallberg1月83日?

   This RFC is a survey of hosts to identify the implementation status
   of Telnet, FTP, and Mail on TCP.  The list of hosts was taken from
   the NIC hostname table of 31-Dec-82.  The tests were run on
   25-Jan-83.

このRFCはTCPでTelnet、FTP、およびメールの実装状態を特定するホストの調査です。 1982年12月31日のNICホスト名テーブルからホストのリストを取りました。 テストは1983年1月25日に実行されました。

Postel & Westine                                               [page 11]

ポステルとWestine[11ページ]

RFC 899                                                         May 1984

RFC899 1984年5月

838     Smallberg    Jan 83      Who Talks TCP?

838 TCPについて話すSmallberg1月83日?

   This RFC is a survey of hosts to identify the implementation status
   of Telnet, FTP, and Mail on TCP.  The list of hosts was taken from
   the NIC hostname table of 31-Dec-82.  The tests were run on
   18-Jan-83.

このRFCはTCPでTelnet、FTP、およびメールの実装状態を特定するホストの調査です。 1982年12月31日のNICホスト名テーブルからホストのリストを取りました。 テストは1983年1月18日に実行されました。

837     Smallberg    Jan 83      Who Talks TCP?

837 TCPについて話すSmallberg1月83日?

   This RFC is a survey of hosts to identify the implementation status
   of Telnet, FTP, and Mail on TCP.  The list of hosts was taken from
   the NIC hostname table of 31-Dec-82.  The tests were run on
   11-Jan-83.

このRFCはTCPでTelnet、FTP、およびメールの実装状態を特定するホストの調査です。 1982年12月31日のNICホスト名テーブルからホストのリストを取りました。 テストは1983年1月11日に実行されました。

836     Smallberg    Jan 83      Who Talks TCP?

836 TCPについて話すSmallberg1月83日?

   This RFC is a survey of hosts to identify the implementation status
   of Telnet, FTP, and Mail on TCP.  The list of hosts was taken from
   the NIC hostname table of 20-Dec-82.  The tests were run on 4-Jan-83
   through 5-Jan-83.

このRFCはTCPでTelnet、FTP、およびメールの実装状態を特定するホストの調査です。 1982年12月20日のNICホスト名テーブルからホストのリストを取りました。 テストは1983年1月4日から1983年1月5日まで動かれました。

835     Smallberg    Dec 82      Who Talks TCP?

835 TCPについて話すSmallberg12月82日?

   This RFC is a survey of hosts to identify the implementation status
   of Telnet, FTP, and Mail on TCP.  The list of hosts was taken from
   the NIC hostname table of 2-Dec-82.  The tests were run on 28-Dec-82
   through 5-Jan-83.

このRFCはTCPでTelnet、FTP、およびメールの実装状態を特定するホストの調査です。 1982年12月2日のNICホスト名テーブルからホストのリストを取りました。 テストは1982年12月28日から1983年1月5日まで動かれました。

834     Smallberg    Dec 82      Who Talks TCP?

834 TCPについて話すSmallberg12月82日?

   This RFC is a survey of hosts to identify the implementation status
   of Telnet, FTP, and Mail on TCP.  The list of hosts was taken from
   the NIC hostname table of 2-Dec-82.  The tests were run on 22-Dec-82.

このRFCはTCPでTelnet、FTP、およびメールの実装状態を特定するホストの調査です。 1982年12月2日のNICホスト名テーブルからホストのリストを取りました。 テストは1982年12月22日に実行されました。

833     Smallberg    Dec 82      Who Talks TCP?

833 TCPについて話すSmallberg12月82日?

   This RFC is a survey of hosts to identify the implementation status
   of Telnet, FTP, and Mail on TCP.  The list of hosts was taken from
   the NIC hostname table of 2-Dec-82.  The tests were run on 14-Dec-82.

このRFCはTCPでTelnet、FTP、およびメールの実装状態を特定するホストの調査です。 1982年12月2日のNICホスト名テーブルからホストのリストを取りました。 テストは1982年12月14日に実行されました。

832     Smallberg    Dec 82      Who Talks TCP?

832 TCPについて話すSmallberg12月82日?

   This RFC is a survey of hosts to identify the implementation status
   of Telnet, FTP, and Mail on TCP.  The list of hosts was taken from
   the NIC hostname table of 2-Dec-82.  The tests were run on 7-Dec-82.

このRFCはTCPでTelnet、FTP、およびメールの実装状態を特定するホストの調査です。 1982年12月2日のNICホスト名テーブルからホストのリストを取りました。 テストは1982年12月7日に実行されました。

Postel & Westine                                               [page 12]

ポステルとWestine[12ページ]

RFC 899                                                         May 1984

RFC899 1984年5月

831     Braden       Dec 82      Backup Access to the European Side of
                                 SATNET

831 SATNETのヨーロッパの側面へのブレーデン12月82日のバックアップアクセス

   The purpose of this RFC is to focus discussion on a particular
   Internet problem:  a backup path for software maintenance of the
   European sector of the Internet, for use when SATNET is partitioned.
   We propose a mechanism, based upon the Source Routing option of IP,
   to reach European Internet sites via the VAN Gateway and UCL.  This
   proposal is not intended as a standard at this time.

このRFCの目的は特定のインターネット問題に議論の焦点を合わせることです: インターネットのヨーロッパのセクターのソフトウェア・メンテナンス、SATNETが仕切られるときの使用のためのバックアップ道。 私たちは、VANゲートウェイとUCLを通してヨーロッパのインターネット・サイトに達するようにIPのSourceルート設定オプションに基づくメカニズムを提案します。 この提案はこのとき、規格として意図しません。

830     Zaw-Sing Su  Oct 82      A Distributed System for Internet Name
                                 Service

830はSu10月82日にインターネット名前サービスのための分散システムをZaw歌います。

   This RFC proposes a distributed name service for DARPA Internet.  Its
   purpose is to focus discussion on the subject.  It is hoped that a
   general consensus will emerge leading eventually to the adoption of
   standards.

このRFCはDARPAインターネットのための分配された名前サービスを提案します。 目的は話題に議論の焦点を合わせることです。 全体的な合意が結局規格の採用に通じながら現れることが望まれています。

829     Cerf         Oct 82      Packet Satellite Technology Reference
                                 Sources

829 サーフ10月82日のパケット人工衛星の科学技術照合線源

   This RFC describes briefly the packet satellite technology developed
   by the Defense Advanced Research Projects Agency and several other
   participating organizations in the U.K. and Norway and provides a
   bibliography of relevant papers for researchers interested in
   experimental and operational experience with this dynamic
   satellite-sharing technique.

このRFCはイギリスとノルウェーで簡潔に国防高等研究計画庁と他のいくつかの参加組織によって開発されたパケット人工衛星の科学技術を説明して、このダイナミックな衛星を共有するテクニックの実験的で操作上の経験に興味を持っている研究者に関連書類の図書目録を提供します。

828     Owen         Aug 82      Data Communications:  IFIP's
                                 International "Network" of Experts

828 オーエン8月82日のData Communications: IFIPの専門家の国際「ネットワーク」

   This RFC is distributed to inform the ARPA Internet community of the
   activities of the IFIP technical committee on Data Communications,
   and to encourage participation in those activities.

このRFCは、Data CommunicationsにおけるIFIP専門委員会の活動のARPAインターネットコミュニティを知らせて、それらの活動への参加を奨励するために分配されます。

827     Rosen        Oct 82      Exterior Gateway Protocol (EGP)

827 ローゼン10月82日の外のゲートウェイプロトコル(EGP)

   This RFC is proposed to establish a standard for Gateway to Gateway
   procedures that allow the Gateways to be mutually suspicious.  This
   document is a DRAFT for that standard.  Your comments are strongly
   encouraged.

このRFCは、ゲートウェイのためにGatewaysが互いに疑わしげであることを許容するゲートウェイ手順に基準を設定するために提案されます。 このドキュメントはその規格のためのDRAFTです。 あなたのコメントは強く奨励されます。

826     Plummer      Nov 82      An Ethernet Address Resolution Protocol

826 イーサネットが解決プロトコルを扱うプラマー11月82日

   The purpose of this RFC is to present a method of Converting Protocol
   Addresses (e.g., IP addresses) to Local Network Addresses (e.g.,
   Ethernet addresses).  This is an issue of general concern in the ARPA
   Internet Community at this time.  The method proposed here is
   presented for your consideration and comment.  This is not the
   specification of an Internet Standard.

このRFCの目的はConvertingプロトコルAddresses(例えば、IPアドレス)のメソッドをLocal Network Addresses(例えば、イーサネット・アドレス)に提示することです。 このとき、これはARPAインターネット共同体の一般的な関心の問題です。 ここで提案されたメソッドはあなたの考慮とコメントのために提示されます。 これはインターネットStandardの仕様ではありません。

Postel & Westine                                               [page 13]

ポステルとWestine[13ページ]

RFC 899                                                         May 1984

RFC899 1984年5月

825     Postel       Nov 82      Request for Comments on Requests for
                                 Comments

825 コメントを求める要求のコメントを求めるポステル11月82日のRequest

   This RFC is intended to clarify the status of RFCs and to provide
   some guidance for the authors of RFCs in the future.  It is in a
   sense a specification for RFCs.

このRFCはRFCsの状態をはっきりさせて、将来RFCsの作者のための何らかの指導を提供することを意図します。 それはある意味でRFCsのための仕様です。

824     MacGregor    Aug 82      The Cronus Virtual Local Network

824 クロノスのマクレガー8月82日の仮想の企業内情報通信網

   The purpose of this note is to describe the CRONUS Virtual Local
   Network, especially the addressing related features.  These features
   include a method for mapping between Internet Addresses and Local
   Network addresses.  This is a topic of current concern in the ARPA
   Internet community.  This note is intended to stimulate discussion.
   This is not a specification of an Internet Standard.

この注意の目的がクロノスVirtual Local Networkについて説明することであり、特にアドレシングは特徴について話しました。 これらの特徴はインターネットAddressesとLocal Networkの間でアドレスを写像するためのメソッドを含んでいます。 これはARPAインターネットコミュニティの現在の関心の話題です。 この注意が議論を刺激することを意図します。 これはインターネットStandardの仕様ではありません。

823     Hinden       Sep 82      The DARPA Internet Gateway

823は9月82日にDARPAインターネットゲートウェイをHindenします。

   This RFC is a status report on the Internet Gateway developed by BBN.
   It describes the Internet Gateway as of September 1982.  This memo
   presents detailed descriptions of message formats and gateway
   procedures, however, this is not an implementation specification, and
   such details are subject to change.

このRFCはBBNが発展させたインターネットゲートウェイに関する現状報告です。 それは1982年9月現在、インターネットゲートウェイについて説明します。 このメモはメッセージ・フォーマットとゲートウェイ手順の詳述を提示します、そして、しかしながら、これは実装仕様ではありません、そして、そのような詳細は変化を被りやすいです。

822     Crocker      Aug 82      Standard for the Format of ARPA
                                 Internet Text Messages

822 アルパインターネットテキスト・メッセージの形式の医者8月82日の規格

   This document revises the specifications in RFC 733, in order to
   serve the needs of the larger and more complex ARPA Internet.  Some
   of RFC 733's features failed to gain adequate acceptance.  In order
   to simplify the standard and the software that follows it, these
   features have been removed.  A different addressing scheme is used,
   to handle the case of internetwork mail; and the concept of
   re-transmission has been introduced.  Obsoletes RFC 733, NIC 41952.

このドキュメントはRFC733の仕様を改訂します、より大きくて、より複雑なARPAインターネットの必要性に役立つように。 RFC733の特徴のいくつかが適切な承認を獲得しませんでした。 それに続く規格とソフトウェアを簡素化するために、これらの特徴を取り除いてあります。 異なったアドレシング体系はインターネットワークメールに関するケースを扱うのに使用されます。 そして、再トランスミッションの概念は紹介されました。 RFC733、NIC41952を時代遅れにします。

821     Postel       Aug 82      Simple Mail Transfer Protocol

821 ポステル8月82日のSimple Mail Transfer Protocol

   The objective of Simple Mail Transfer Protocol (SMTP) is to transfer
   mail reliably and efficiently.  SMTP is independent of the particular
   transmission subsystem and requires only a reliable ordered data
   stream channel.  Obsoletes RFC 788, 780, and 772.

シンプルメールトランスファプロトコル(SMTP)の目的は確かに効率的にメールを移すことです。 SMTPは特定のトランスミッションサブシステムから独立していて、高信頼の規則正しいデータストリーム・チャンネルだけを必要とします。 RFC788、780、および772を時代遅れにします。

820     Postel       Jan 82      Assigned Numbers

820 ポステル1月82日は数を割り当てました。

   This RFC is an old version, see RFC 870.

RFC870は、このRFCが古いバージョンであると考えます。

Postel & Westine                                               [page 14]

ポステルとWestine[14ページ]

RFC 899                                                         May 1984

RFC899 1984年5月

819     Zaw-Sing Su  Aug 82      The Domain Naming Convention for
                                 Internet User Applications

819はインターネットユーザアプリケーションのためのドメイン命名規則をSu8月82日にZaw歌います。

   This RFC is an attempt to clarify the generalization of the Domain
   Naming Convention, the Internet Naming Convention, and to explore the
   implications of its adoption for Internet name service and user
   applications.

このRFCはDomain Naming Convention、インターネットNaming Conventionの一般化をはっきりさせて、インターネット名前サービスとユーザアプリケーションへの採用の含意を探る試みです。

818     Postel       Nov 82      The Remote User Telnet Service

818 リモート・ユーザーのポステル11月82日のtelnetサービス

   This RFC is the specification of an application protocol.  Any host
   that implements this application level service must follow this
   protocol.

このRFCはアプリケーション・プロトコルの仕様です。 このアプリケーションレベルサービスを実装するどんなホストもこのプロトコルに従わなければなりません。

817     Clark        Jul 82      Modularity and Efficiency in Protocol
                                 Implementation

817 プロトコル実装におけるクラーク7月82日のModularityと効率

   This RFC will discuss some of the commonly encountered reasons why
   protocol implementations seem to run slowly.

このRFCはプロトコル実装がゆっくり実行するように思える一般的に遭遇した理由のいくつかについて議論するでしょう。

816     Clark        Jul 82      Fault Isolation and Recovery

816 クラーク7月82日の欠点分離と回復

   This RFC describes the portion of fault isolation and recovery which
   is the responsibility of the host.

このRFCはホストの責任である欠点分離と回復の部分について説明します。

815     Clark        Jul 82      IP Datagram Reassembly Algorithms

815 クラーク7月82日のIPデータグラムReassemblyアルゴリズム

   This RFC describes an alternate approach of dealing with reassembly
   which reduces the bookkeeping problem to a minimum, and requires only
   one buffer for storage equal in size to the final datagram being
   reassembled, which can reassemble a datagram from any number of
   fragments arriving in any order with any possible pattern of overlap
   and duplication, and which is appropriate for almost any sort of
   operating system.

このRFCはサイズにおいて組み立て直される最終的なデータグラムと等しいストレージのために簿記問題を最小限まで減少させて、1つのバッファだけを必要としている、オーバラップと複製のどんな可能なパターンと共にも順不同に届くいろいろな断片からデータグラムを組み立て直すことができる、ほとんどどんな種類のオペレーティングシステムにも、適切な再アセンブリに対処する代替のアプローチについて説明します。

814     Clark        Jul 82      Name, Addresses, Ports, and Routes

814 クラーク7月82日の名、アドレス、ポート、およびルート

   This RFC gives suggestions and guidance for the design of the tables
   and algorithms necessary to keep track of these various sorts of
   identifiers inside a host implementation of TCP/IP.

このRFCはTCP/IPのホスト導入でこれらの様々な種類に関する識別子の動向をおさえるのに必要にテーブルとアルゴリズムのデザインのための提案と指導を与えます。

813     Clark        Jul 82      Window and Acknowledgement Strategy in
                                 TCP

813 TCPのクラーク7月82日のWindowと承認戦略

   This RFC describes implementation strategies to deal with two
   mechanisms in TCP, the window and the acknowledgement.  It also
   presents a particular set of algorithms which have received testing
   in the field, and which appear to work properly with each other.
   With more experience, these algorithms may become part of the formal
   specification, until such time their use is recommended.

このRFCは、TCP、窓、および承認で2つのメカニズムに対処するために実装戦略を説明します。 また、それはその分野でテストしながら受信して、互いと共に適切に働くように見える特定のセットのアルゴリズムを提示します。 より多くの経験によると、これらのアルゴリズムは形式仕様の一部に彼らの使用がお勧めであるそのような時までなるかもしれません。

Postel & Westine                                               [page 15]

ポステルとWestine[15ページ]

RFC 899                                                         May 1984

RFC899 1984年5月

812     Harrenstien   Mar 82     NICNAME/WHOIS

812は3月82日にNICNAME/WHOISをHarrenstienします。

   This RFC gives a description of what the NICNAME/WHOIS Server is and
   how to access it.  This server together with the corresponding
   Identification Data Base provides online directory look-up equivalent
   to the ARPANET Directory.

このRFCはNICNAME/WHOIS Serverが何であるか、そして、どのようにそれにアクセスするかに関する記述を与えます。 対応するIdentification Data基地に伴うこのサーバはアルパネットディレクトリに同等なオンラインディレクトリルックアップを提供します。

811     Harrenstien   Mar 82      Hostnames Server

811Harrenstien3月82日のホスト名サーバ

   This RFC gives a description of what the Hostnames Server is and how
   to access it.  The function of this particular server is to deliver
   machine-readable name/address information describing networks,
   gateways, hosts, and eventually domains, within the internet
   environment.

このRFCはHostnames Serverが何であるか、そして、どのようにそれにアクセスするかに関する記述を与えます。 この特定のサーバの機能はネットワーク、ゲートウェイ、ホスト、および結局ドメインについて説明する機械可読な名前/アドレス情報を提供することです、インターネット環境の中で。

810     Feinler      Mar 82      DoD Internet Host Table Specification

810 Feinler3月82日のDoDインターネットホストテーブル仕様

   This RFC specifies a new host table format applicable to both ARPANET
   and Internet needs.  In addition to host name to host address
   translation and selected protocol information, we have also included
   network and gateway name to address correspondence, and host
   operating system information.  This RFC obsoletes the host table
   described in RFC 608.

このRFCはアルパネットとインターネットの必要性の両方に適切な新しいホストテーブル形式を指定します。 また、ホスト・アドレス翻訳と選択されたプロトコル情報へのホスト名に加えて、私たちは、通信、およびホスト・オペレーティング・システムが情報であると扱うためにネットワークとゲートウェイ名を入れました。 このRFCはRFC608で説明されたホストテーブルを時代遅れにします。

809     Chang        Feb 82      UCL Facsimile System

809 チャン2月82日のUCLファクシミリシステム

   This RFC describes the features of the computerised facsimile system
   developed in the Department of Computer Science at UCL.  First its
   functions are considered and the related experimental work are
   reported.  Then the disciplines for system design are discussed.
   Finally, the implementation of the system are described, while
   detailed description are given as appendices.

このRFCはUCLでコンピュータScienceの部で開発された計算機化されたファクシミリシステムの特徴について説明します。 まず最初に、機能は考えられます、そして、関連する実験研究は報告されます。 そして、システム設計のための規律について議論します。 最終的に、システムの実装について説明しますが、付録として詳述を与えます。

808     Postel       Mar 82      Summary of Computer Mail Services
                                 Meeting Held at BBN on 10 January 1979

808 1979年1月10日にBBNで行われたコンピュータメールサービス会合のポステル3月82日Summary

   This RFC is a very belated attempt to document a meeting that was
   held three years earlier to discuss the state of computer mail in the
   ARPA community and to reach some conclusions to guide the further
   development of computer mail systems such that a coherent total mail
   service would continue to be provided.

このRFCはARPA共同体でコンピュータメールの状態について議論して、一貫性を持っている総メールサービスが、提供され続けるようにコンピュータメールシステムのさらなる開発を誘導するためにいくつかの結論に達するのにおいて3年より早く行われた会合を記録する非常におくればせの試みです。

807     Postel       Feb 82      Multimedia Mail Meeting Notes

807 注意を満たすポステル2月82日のマルチメディアメール

   This RFC consists of notes from a meeting held at USC Information
   Sciences Institute on the 12th of January to discuss common interests
   in multimedia computer mail issues and to agree on some specific
   initial experiments.

このRFCはマルチメディアコンピュータメール問題の共通の利益について議論して、いくつかの特定の初期の実験に同意する1月12日にUSC情報Sciences Instituteで行われる会合からの注意から成ります。

Postel & Westine                                               [page 16]

ポステルとWestine[16ページ]

RFC 899                                                         May 1984

RFC899 1984年5月

806     NBS          Sep 81      Specification for Message Format for
                                 Computer Based Message Systems

コンピュータのベースのメッセージシステムのためのメッセージ・フォーマットのための806NBS9月81日仕様

   This RFC deals with Computer Based Message systems which provides a
   basis for interaction between different CBMS by defining the format
   of messages passed between them.  This RFC is replaced by RFC 841.

このRFCはコンピュータBased Messageシステムに対処します(それらの間で通過されたメッセージの書式を定義することによって、異なったCBMSの間に相互作用の基礎を供給します)。 このRFCをRFC841に取り替えます。

805     Postel       Feb 82      Computer Mail Meeting Notes

805 注意を満たすポステル2月82日のコンピュータメール

   This RFC consists of notes from a meeting that was held at USC
   Information Sciences Institute on 11 January 1982, to discuss
   addressing issues in computer mail. The major conclusion reached at
   the meeting is to extend the "username@hostname" mailbox format to
   "username@host.domain", where the domain itself can be further
   strutured.

このRFCは1982年1月11日にコンピュータメールで問題提示について議論するためにUSC情報Sciences Instituteで行われた会合からの注意から成ります。 ミーティングで達した主要な結論は" username@hostname "メールボックス形式を" username@host.domain "に広げることです。そこでは、さらにドメイン自体をstruturedされることができます。

804     CCITT        Jan 82      CCITT Draft Recommendation T.4

804 CCITT1月82日のCCITT草稿推薦T.4

   This is the CCITT standard for group 3 facsimile encoding.  This is
   useful for data compression of bit map data.

これはグループ3ファクシミリコード化のCCITT規格です。 これはビットマップデータのデータ圧縮の役に立ちます。

803     Agarwal      Nov 81      Dacom 450/500 Facsimile Data
                                 Transcoding

803 Agarwal11月81日のDacom450/500ファクシミリデータコード変換

   The first part of this RFC describes in detail the Dacom 450 data
   compression algorithms and is an update and correction to an earlier
   memorandum.  The second part of this RFC describes briefly the Dacom
   500 data compression algorithm as used by the INTELPOST
   electronic-mail network under development by the US Postal Service
   and several foreign administrators.

このRFCの最初の部分は、以前のメモへの詳細にDacom450データ圧縮アルゴリズムを説明して、アップデートと修正です。 このRFCの第二部は米国のPostal Serviceと数人の外国人の管理者による開発中のインテルポスト電子メール・ネットワークによって使用されるように簡潔にDacom500データ圧縮アルゴリズムを説明します。

802     Malis        Nov 81      The ARPANET 1822L Host Access Protocol

802 アルパネット1822Lが接待するMalis11月81日はプロトコルにアクセスします。

   This document proposed two major changes to the current ARPANET host
   access protocol.  The first change will allow hosts to use logical
   addressing (i.e., host addresses that are independent of their
   physical location on the ARPANET) to communicate with each other, and
   the second will allow a host to shorten the amount of time that it
   may be blocked by its IMP after it presents a message to the network
   (currently, the IMP can block further input from a host for up to 15
   seconds).  See RFCs 852 and 851.

このドキュメントは現在のアルパネットホストアクセス・プロトコルへの2回の大きな変化を提案しました。 ホストは互いにコミュニケートするのに、最初の変化で、論理的なアドレシング(すなわち、アルパネットでそれらの物理的な位置から独立しているホスト・アドレス)を使用できるでしょう、そして、2番目はホストがネットワークにメッセージを提示した(現在、IMPは15秒までホストからさらなる入力を妨げることができます)後にそれがIMPによって妨げられるかもしれない時間に短くするのを許容するでしょう。 RFCs852と851を見てください。

801     Postel       Nov 81      NCP/TCP Transition Plan

801 ポステル11月81日のNCP/TCP変遷プラン

   This RFC discusses the conversion of hosts from NCP to TCP.  And
   making available the principle services:  Telnet, File Transfer, and
   Mail.  These protocols allow all hosts in the ARPA community to share
   a common interprocess communication environment.

このRFCはホストのNCPからTCPまでの変換について議論します。 原則サービスを利用可能にします: telnet、ファイル転送、およびメール。 これらのプロトコルで、ARPA共同体のすべてのホストが一般的なプロセス間通信環境を共有できます。

Postel & Westine                                               [page 17]

ポステルとWestine[17ページ]

RFC 899                                                         May 1984

RFC899 1984年5月

800     Postel       Nov 82      Requests for Comments Summary

800 コメント概要に関するポステル11月82日のRequests

   This RFC is a slightly annotated list of the 100 RFCs from RFC 700
   through RFC 799.  This is a status report on these RFCs.

このRFCはRFC700からRFC799の100RFCsのわずかに注釈されたリストです。 これはこれらのRFCsに関する現状報告です。

Postel & Westine                                               [page 18]

ポステルとWestine[18ページ]