RFC50 日本語訳

                                                  E. Harslen
                                                  J. Heafner
Network Working Group                             RANL
Request for Comments:    50                       4/30/70

E.Harslen J.HeafnerネットワークワーキンググループRANLはコメントのために以下を要求します。 50 4/30/70

                     Comments on the Meyer Proposal
                     ------------------------------

マイヤー提案のコメント------------------------------

We find the Meyer proposal (Note #46) to be the most acceptable
to dare, for exactly the reasons that he enumerates; viz., simple,
suffices for most planned uses of the Network, easy to implement,
can be extended.  It does not encompass everything that has been
suggested recently, however, we do agree with the items that are
proposed and we feel that the missing features are probably not
worth doing battle over and thus delaying the specification.

私たちは敢行するために、最も許容できるというマイヤー提案(注意#46)を見つけます、まさに彼が列挙する理由で。 つまり、簡単であることで、実行しやすいNetworkのほとんどの計画された用途に十分であり、広げることができます。 それは最近示されたすべてを取り囲みません、そして、しかしながら、提案される項目に同意します、そして、私たちはなくなった特徴は戦いをやり直して、その結果、仕様を遅らせるたぶん価値がないと感じます。

We make the following comments on the seven issues rasied in
Note #47.

私たちはNote#47でrasiedされた7冊の以下のコメントをします。

   1)  We agree with Steve that dynamic reconnection will later
       be required for more sophisticated uses of the Network.
       We also agree with the Project MAC people that it
       unnecessary initially.  A better job can be done of dynamic
       reconnection given some Network experience and the specific
       needs of its use.

1) 私たちは、ダイナミックな再接続が後でNetworkの、より高度な用途に必要であるとスティーブに同意します。 また、私たちが、それを住ませるようにProject MACに同意する、それ、不要である、初めは。 何らかのNetwork経験と使用の特定の必要性を考えて、ダイナミックな再接続について、より良い仕事ができます。

   2)  INT is easy to implement and serves a useful purpose.

2) INTは実行するのが簡単であり、目的に有効に適います。

   3)  We favor including a sub-field for instance tag identifier.
       We see the need for both cases; a) where multiple processes
       should appear indistinguishable, and b) where a given
       user owning multiple processes must distinguish among
       them.  Those program parts that should not distinguish
       among processes should simply ignore the instance tag.
       Tom's suggestion to use part of the user number sub-field
       merely reduces the combined length of sub-fields from 32
       bits to 24 bits; the problem remains.

3) 私たちは、例えば、サブ分野タグ識別子を含んでいるのを支持します。 私たちは両方のケースの必要性を認めます。 複数の過程が区別がつかなく見えるべきであるa)、および倍数を所有している与えられたユーザが処理するb)はそれらの中で区別されなければなりません。 過程の中で区別するべきでないそれらのプログラム一部が単に例のタグを無視するべきです。 ユーザ数のサブ分野の一部を使用するトムの提案は結合した長さのサブ分野を単に32ビットから24ビットまで減少させます。 問題は残っています。

   4)  We disagree with both Steve and MAC in that no special
       structure should be imposed on the data transmitted.  We
       prefer the "message data type" mentioned by E. I. Ancona,
       Note #42, page 1.  An example of its use was cited in
       Note #39, page 2, transmit vs broadcast.

4) 私たちはどんな特別な構造も送られたデータに課すべきでないという点でスティーブとMACの両方と意見を異にします。 私たちはNote#42、1歳のE.I.アンコナページによって言及された「メッセージデータ型」を好みます。 使用に関する例は39(2ページ)が放送に対して伝えるNote#で引用されました。

                                                                [Page 1]

       With regard to a standard character set, we strongly
       support adopting one in the beginning, and in particular
       ASCII.  We have observed that most sites have previously
       suggested ASCII.  Is there anyone who objects?

標準文字セットに関する[1ページ]、私たちは初めに1、および特にASCIIを採用するのを強く支持します。 私たちは、ほとんどのサイトが以前にASCIIを示したのを観測しました。 反対するだれかいますか?

   5)  Word boundary alignment is more attractive than double
       padding.

5) 語境界整列は二重詰め物より魅力的です。

   6)  Steve's suggestion of short-term queueing of RFCs is
       acceptable as an option.

6) スティーブのRFCsの短期的な待ち行列の提案はオプションとして許容できます。

   7)  We support the UCC in Note #46 for three principle reasons:

7) 3つの原則理由で、私たちはNote#46でUCCを支持します:

       a)  In general the user should not know the remote socket
           code of the process to whom he wishes to communicate.

a) 一般に、ユーザは彼が交信したがっている過程のリモートソケットコードを知るべきではありません。

       b)  The additional duplex connection can provide some
           superfisory control over process behavior, possibly
           in conjunction with the interrupt procedure.

b) 追加重複の接続はプロセス挙動の上とことによると中断手順に関連して何らかのsuperfisoryコントロールを提供できます。

       c)  Most of the other proposed methods demand queueing.

c) 他の提案された方法の大部分は待ち行列を要求します。

      We think there must be a standard UCC, yet we encourage
      parallel experimental UCCs.

私たちは、標準のUCCがあるに違いないと考えます、しかし、平行な実験的なUCCsを奨励します。

We make two additional comments on Note #46 that were not reiterated
in Note #47.

私たちはNoteの2つの追加コメントをNote#47で繰り返されなかった#46、にします。

BLK and RSM are more straightforward than previous suggestions and
they do not deny multiplexing over a given link.  With regard to
the use of links, we refer to an example given by Bob Kahn where
an intermediate IMP goes down and eats some's RFNM.  This
should not necessitate reconnection.

BLKとRSMは前の提案より簡単です、そして、それらは与えられたリンクの上に多重送信することを否定しません。 リンクの使用に関して、私たちは中間的IMPがどこで落ちて、いくつかを食べるかが、ボブ・カーンによる、RFNMであるという例の当然のことについて言及します。 これは再接続を必要とするべきではありません。

In Note #46, page 6, the statement that the UCC has the ability
to close connections to a dead process is installation dependent.
In our particular case the NCP is notified directly of process
failure due to the particular software interface through which all
processea, including NCP, must communicate.

Note#46、6ページでは、UCCには死んでいる過程に接続を終える能力があるという声明はインストールに依存しています。 特に我々の場合にはNCPはNCPを含むすべてのprocesseaが交信しなければならない特定のソフトウェア・インタフェースのため過程の失敗について直接通知されます。

JFH:hs

JFH: hs

       [ This RFC was put into machine readable form for entry ]
          [ into the online RFC archives by Gary Okada 7/97 ]

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

                                                                [Page 2]

[2ページ]