RFC692 日本語訳

Network Working Group                                      Stephen Wolfe
RFC # 692                                                  UCLA CCN
NIC # 32734                                                June 20, 1975

1975年6月20日にワーキンググループスティーブンウルフRFC#692UCLA CCN NIC#32734をネットワークでつないでください。

       COMMENTS ON IMP/HOST PROTOCOL CHANGES, (RFCS 687 AND 690)

悪童/ホストのコメントは変化について議定書の中で述べます。(RFCS687と690)

Basically, the proposed set of changes in RFC 687 seems reasonable, as
are the comments in RFC 690.

基本的に、RFC687における、提案されたセットの変化はコメントのようにRFC690で妥当に思えます。

The major problem, as pointed out by Postel, is the change in the
combined length of the IMP and Host leaders to a total of 120 bits,
which is not a multiple of both 8 and 36 bits.

ポステルによって指摘されるように、大した問題は、8と36ビットIMPの結合した長さにおける変化と合計120ビットへのHostリーダーです。(ビットは両方の倍数ではありません)。

The suggested solution is to increase the length of the host to host
protocol leader by 24 bits, creating a total length of 144 bits.  The
problem, however, is that the only way of compatibly changing this
length would be to have the IMP either insert or delete the extra 24
bits when converting to/from the old format leader.  The problems with
this solution are obvious.

提案された解決法は24ビットに従ってホストプロトコルリーダーにホストの長さを増強することです、144ビットの全長を作成して。 しかしながら、問題はこの長さを矛盾なく変える唯一の方法が古い方式リーダーからの/に変えるとき、IMPが付加的な24ビットを挿入するか、または削除するのを持つだろうことであるということです。 このソリューションに関する問題は明白です。

The better solution is to change the length of the new proposed IMP
leader. I suggest 104 bits instead of 80 bits.  The complaint that 104
is not a multiple of an IMP word is valid, but it should not be that
difficult if the following rules are observed.

より良いソリューションは新しい提案されたIMPリーダーの長さを変えることです。 私は80ビットの代わりに104ビットを勧めます。 IMP単語の倍数ではなく、104がそうである苦情が有効ですが、以下の規則が守られるなら、そんなに難しいはずがありません。

    1.  The last 8 bits are never used to convey information.

1. ベスト8ビットは、情報を伝達するのに決して使用されません。

    2.  The network is not required to pass them from source to
        destination, or to return them to the source.

2. ネットワークは、ソースから目的地までそれらを渡すか、またはそれらをソースに返す必要はありません。

    3.  When sending messages of types other than zero, (irregular
        messages), the IMP is allowed to send either 96, 104 or 112 bits
        of data, the choice being at the IMP's convenience.

3. ゼロ以外のタイプに関するメッセージ、(不規則なメッセージ)を送るとき、IMPは96ビットか104ビットか112ビットのデータ(IMPの便利にはある選択)を送ることができます。

    4.  Also, if desired, either 96 or 112 could be used as the new
        leader length for irregular messages.

4. また、望まれているなら、96か112が不規則なメッセージに新しいリーダーの長さとして使用されるかもしれません。

It must be faster (and cheaper) to just change the IMP program to handle
a 104 bit leader, than to force additional changes in all hosts using
the standard protocol.

104ビットのリーダーを扱うためにただIMPプログラムを変えるのは、より速い、そして、(より安い)でなければなりません、すべてのホストで標準プロトコルを使用することで付加的な変化を強制するより。

Another suggested extension to the protocol would add a new type of IMP
to Host message.  This message has a table of Host names (people type
character strings) and Host network addresses.  Send this message(s) to
the Host after each interface reset, or alternatively, it could be a
response to a new Host to IMP request for this information.

別のものは、プロトコルへの拡大がIMPの新しいタイプをHostメッセージに追加すると示唆しました。 このメッセージには、Host名(人々は文字列をタイプする)とHostネットワーク・アドレスのテーブルがあります。 それぞれのインタフェースリセットの後にこのメッセージをHostに送ってください。さもないと、あるいはまた、それはこの情報に関するIMP要求への新しいHostへの応答であるかもしれません。

Wolfe                                                           [Page 1]

RFC 692          Comments on IMP/Host Protocol Changes         June 1975

ウルフ[1ページ]RFC692は1975年6月に悪童/ホストプロトコル変化を批評します。

       [ This RFC was put into machine readable form for entry ]
       [ into the online RFC archives by Alex McKenzie with    ]
       [ support from GTE, formerly BBN Corp.            10/99 ]

[このRFCはエントリーのためのマシンに入れられた読み込み可能なフォームでした]、[アレックス・マッケンジーによるオンラインRFCアーカイブ、][GTEからのサポート、以前BBN社10/99]

Wolfe                                                           [Page 2]

ウルフ[2ページ]