RFC209 日本語訳

Network Working Group                                          B. Cosell
Request for Comments: 209                        Bolt Beranek and Newman
NIC: 7187                                                 13 August 1971

コメントを求めるワーキンググループB.コーセルの要求をネットワークでつないでください: 209 BeranekとニューマンNICをボルトで締めてください: 7187 1971年8月13日

                     HOST/IMP Interface Documentation

ホスト/悪童インタフェースドキュメンテーション

   On 25 June 1971 we put a new version of the IMP system, Version 2500,
   up in the network.  Among other changes, the new system corrected the
   problem of Hosts receiving spurious "Destination Dead" [Type 7]
   messages.  The correction involved making the IMP refuse to accept
   any messages from its Host for about 30 seconds after the Host
   indicated its intention to come alive.  This delay has caused trouble
   to a number of NCPs because they had imposed an upper limit on the
   time an IMP may take to accept a message, and when that time was
   exceeded the IMP was declared inoperative and the NCP shut itself
   down, leaving the site personnel annoyed and perplexed.

1971年6月25日に、私たちはIMPシステムの新しいバージョン、バージョン2500をネットワークに置きます。 他の変化の中では、新しいシステムはHostsが偽りの「目的地死者」[7をタイプする]メッセージを受け取るという問題を修正しました。 修正は、IMPにHostが本物に見えるという意志を示した後におよそ30秒間、Hostからどんなメッセージも受け入れるのを拒否させることを伴いました。 わざわざIMPがメッセージを受け入れるかもしれない上限を課したので、この遅れは多くのNCPに問題を起こしました、そして、その時が超えられていたとき、IMPは効力がないと申告されました、そして、NCPはそれ自体を止めました、サイト人員をいらいらしていて、当惑するままにして。

   We're sorry to have caused so much trouble, but we thought that the
   new version modified no advertised property of the system.  To
   prevent misunderstandings of this type in the future, the IMP/Host
   interface should be well documented, well understood and invariant.
   The only way to set up and maintain such an interface is to presume
   that BBN Report No. 1822 is complete and correct.  We understand that
   it is neither, but operating on the basis of this assumption is the
   best way to force 1822 to improve.  In our view, the Hosts should
   proceed under the constraint that anything not specifically
   guaranteed by 1822 does not exist and should not be used.  If there
   are problems using this approach, please don't "code around" the
   problem or treat your IMP as a "black box" and extrapolate its
   characteristics from a series of experiments.  Instead, send your
   comments and problems to the NCC at BBN, and we will fix the IMP
   system, or 1822, whichever is necessary.

とても多くの問題を引き起こして、すみませんが、私たちは、新しいバージョンがシステムの広告を出している特性を全く変更しなかったと思いました。 将来このタイプの誤解を防ぐために、IMP/ホスト・インターフェースは、よく記録されていて、よく理解されていて不変であるべきです。 そのようなインタフェースをセットアップして、維持する唯一の方法はBBN Report No.1822が完全であって、正しいと推定することです。 私たちは、それがどちらもでない理解していますが、この仮定に基づいて作動するのは、1822を向上させる最も良い方法です。 私たちの意見では、Hostsは存在していなくて、1822年までに明確に何も保証されなかったものを使用するべきでないという規制で続くはずです。 このアプローチを使用することにおける問題があれば、しないでください、「「ブラックボックス」として」 問題か御馳走の周りでIMPをコード化してください、そして、一連の実験から特性を推定してください。 代わりに、コメントと問題をBBNのNCCに送ってください。そうすれば、私たちはIMPシステム、または1822を固定するつもりです、どれが必要であっても。

   We are, at the moment, working n an update to 1822.  It will reflect
   the deletion of the "cease" mechanism [as per RFC #107].

私たちは現在、1アップデートあたりのnを1822を扱っています。 それは「やんでください」というメカニズム[RFC#107に従って]の削除を反映するでしょう。

   We are also considering augmenting the IMP/Host protocol with a
   mechanism to allow a Host to detect a change in the "version" of the
   IMP system, and to provide the Hosts with status information as to
   who is alive in the net.

また、私たちは、HostがIMPシステムの「バージョン」における変化を検出して、だれがネットで生きているかに関して状態情報をHostsに提供するのを許容するためにメカニズムでIMP/ホストプロトコルを増大させると考えています。

         [ This RFC was put into machine readable form for entry ]
             [ into the online RFC archives by Ryan Kato 6/01]

[このRFCはエントリーのためのマシンに入れられた読み込み可能なフォームでした][ライアン・加藤6/01によるオンラインRFCアーカイブへの]

Cosell                                                          [Page 1]

コーセル[1ページ]