RFC611 日本語訳

Network Working Group                                          D. Walden
RFC # 611                                                        BBN-NET
NIC # 21354                                            February 14, 1974

1974年2月14日のネットワークワーキンググループD.ウォルデンRFC#611BBNネットのNIC#21354

                  TWO CHANGES T0 THE IMP/HOST PROTOCOL
                TO IMPROVE USER/NETWORK COMMUNICATIONS*

悪童/ホストのT0がユーザ/ネットワークコミュニケーション*を改良するために議定書の中で述べる2回の変化

1.  A Reminder

1. 思い出させるもの

    When a host receives an IMP-Going Down message from its IMP (see
page 3-15 of BBN Report 1822, Specifications for the Interconnection of
a Host and an IMP), the Host should forward the information included in
the IMP-Going-Down message to its users from the network and its local
users of the network.  Further, we suggest that the Host keep this
information around after the IMP has gone down, in order to tell local
users who are attempting to use the network.

ホストがIMPからIMP-現在のDownメッセージを受け取るとき(BBN Report1822、HostのInterconnectionのためのSpecifications、および3-15IMPページを参照してください)、Hostはネットワークとそのネットワークの地元のユーザから落ちるIMPメッセージでユーザに含められた情報を転送するはずです。 さらに、私たちは、IMPが落ちた後にHostがこの情報を置くことを提案します、だれが、ネットワークを使用するのを試みているかを地元のユーザに言うために。

    In the next two sections of the RFC, we describe modifications to
the IMP/Host protocol which will allow the IMPs to distribute the same
sort of information about Hosts which are down.

RFCの次の2つのセクションで、私たちはIMPsが同じ種類の下がっているHostsの情報を分配できるIMP/ホストプロトコルに変更を説明します。

2.  Expansion of the Host-Going-Down Message

2. ホスト低下メッセージの拡張

    The type 2, Host-Going-Down, message described on page 3-1l of BBN
Report 1822 has not previously allowed for any provision by the Host for
additional information such as why, when, and for how long the Host is
going down. The following describes a modification to the Host-Going-
Down message which permits the Host to supply this additiona1
information.

タイプ2、Hostが落ちて、なぜなどの追加情報、時で落ちて、Hostがどれくらい長い間であるか、BBN Report1822のページ3-1lで説明されたメッセージは以前に、Hostによる少しの支給も考慮していません。 以下はHostがこのadditiona1情報を提供することを許可するHostが落ちているメッセージに変更を説明します。

    In a type 2, Host-Going-Down message, bits 17-28 give the time of
the Host's coming back up, bit-coded as follows:

タイプ2、落ちるHostメッセージでは、ビット17-28はHostが上がって、ビットによってコード化されていた状態で戻る時間を以下の通りに与えます:

bits 17-19:  the day of the week the Host is coming back up. Monday is
             day 0 and Sunday is day 6.

ビット17-19: 週の曜日に、Hostは来て戻ります。 月曜日は、0日目であり、日曜日に6日目です。

bits 20-24:  the hour of the day, from hour 0 to hour 23, that the Host
             is coming back up.

ビット20-24: Hostが来て戻している時間0から時間23までの日の時間。

bits 25-28:  the five minute interval, from 0 to 11, in the hour that
             the Host is coning back up.

ビット25-28: Hostが円錐形にし返している時間の5分の0〜11までの間隔。

----------
*Please file this RFC with your copy of BBN Report 1822 until that
report is updated.

---------- *BBN Report1822のコピーでそのレポートをアップデートするまでこのRFCをファイルしてください。

Walden                                                          [Page 1]

RFC 611               Changes to IMP/Host Protocol         February 1974

ウォルデン[1ページ]RFC611は1974年2月に悪童/ホストプロトコルに変化します。

All three of the above or to be specified in Universal time (i.e.,
G.M.T.).  The Host may indicate that it will be coming back up more than
a week away by setting bits 17-28 all to ones.  Setting all bits 17-27
to one and bit 28 to zero means it is unknown when the host is coming
back up.

または、すべての3つの上記、Universal時間(すなわち、G.M.T.)指定されるために。 Hostは、それが1週間後で十二分にすべてものにビット17-28を設定することによって上って来て戻るのを示すかもしれません。 1とビット28対ゼロにすべてのビット17-27を設定するのは、ホストがいつ来て戻る予定であるかが、未知であることを意味します。

    Bits 29-32 of the Host-Going-Down message should be used by the Host
to specify the reason it is going down.  These bits are coded as
follows:

落ちるHostメッセージのビット29-32は、落ちる予定である理由を指定するのにHostによって使用されるはずです。 これらのビットは以下の通りコード化されます:

Value     Meaning
-----     -------

値の意味----- -------

0-4       Reserved for IMP use (see Section 3 below)
5         Scheduled P.M.
6         Scheduled Hardware Work
7         Scheduled Software Work
8         Emergency Restart
9         Power Outage
10        Software Breakpoint
11        Hardware Failure
l2-15     Currently Unused

0-4 IMPのために予約されて、午後の5Scheduledを使用してください、(以下のセクション3を見ます)6Scheduled Hardware Work7Scheduled Software Work8Emergency Restart9Power Outage10Software Breakpoint11Hardware Failure l2-15 Currently Unused

    It is assumed that as the time for the Host to go down approaches,
the Host itself will send warning messages to its network users.  Just
before going down, the Host should send the Host-Going-Down message to
its IMP.  The IMP will store this message and return it to the source
Host along with Destination (Host) Dead messages.  The IMP will try to
preserve this message over IMP reloads where appropriate.  The NCC will
be able to update manually the stored copy of this message in response
to a phone call from the Host site in the event the Host is going to be
down longer than it said or if it didn't have time to say before going
down.

Hostがダウンしに行く時間に近づくときHost自身が警告メッセージをネットワーク利用者に送ると思われます。 落ちるすぐ前に、Hostは落ちるHostメッセージをIMPに送るはずです。 IMPはDestination(接待する)の死んでいるメッセージに伴うソースHostにこのメッセージを保存して、それを返すでしょう。 IMPは適切であるところにIMP再ロードの上にこのメッセージを保存しようとするでしょう。 言ったより長いかそれに落ちる前に言う時間がなかったなら、NCCは手動でHostがいるイベントにおけるHostサイトからの電話に対応して保存されたコピーに関するこのメッセージをアップデートできるでしょう。

3.  Addition of the Dead Host Status Message

3. 死んでいるホストステータスメッセージの追加

    The type 7, destination dead, message described on page 3-16 of BBN
Report 1822, does not allow for providing the reason for the Destination
Host's being "dead".  An additional IMP to Host message is therefore
being added which provides status information on the dead Host.  This
message is type 6, Dead Host Status, and will provide the additional
information as follows:

タイプ7(目的地死者、3-16BBN Reportページで1822説明されたメッセージ)は、Destination Hostの「死んでいる」理由を提供すると考慮しません。 したがって、Hostメッセージへの死んでいるHostの状態情報を提供する追加IMPは加えられています。 このメッセージは、タイプ6、Dead Host Statusであり、以下の追加情報を提供するでしょう:

    Bits 17-28 have the same meanings as bits 17-28 in the Host-Going-
    Down message described in Section 2 above.

ビット17-28は上のセクション2で説明されたHostが落ちているメッセージにビット17-28と同じ意味を持っています。

Walden                                                          [Page 2]

RFC 611               Changes to IMP/Host Protocol         February 1974

ウォルデン[2ページ]RFC611は1974年2月に悪童/ホストプロトコルに変化します。

    Bits 29-32 have the following meanings:

ビット29-32には、以下の意味があります:

        Value  Meaning
        -----  -------

値の意味----- -------

        0      The destination Host is not communicating with the
               network -- the destination IMP has no information about
               the cause.  Note that this is the message most likely to
               occur if the destination IMP has gone down since the
               destination Host went down.

0 目的地Hostはネットワークとコミュニケートしていません--目的地IMPには、原因の情報が全くありません。 目的地Hostが落ちて以来目的地IMPが落ちているならこれが最も起こりそうなメッセージであることに注意してください。

        1      The destination Host is not communicating with the
               network -- it took its ready-line down without saying
               why.

1 目的地Hostはネットワークとコミュニケートしていません--理由を言わないで、それは準備ができる系列を降ろしました。

        2      The destination Host is not communicating with the
               network -- the Host was tardy in taking traffic from the
               network and the network had to declare the Host down.

2 目的地Hostはネットワークとコミュニケートしていません--Hostはネットワークからトラフィックを取るのが遅く、ネットワークは、Hostがダウンすると宣言しなければなりませんでした。

        3      The destination Host does not exist to the knowledge of
               the NCC.

3 目的地HostはNCCに関する知識に存在していません。

        4      Currently unused.

4 現在、未使用です。

        5      The destination Host is down for scheduled P.M.

予定されていて、目的地Hostが下がっている5、午後

        6      The destination Host is down for scheduled hardware work.

6 目的地Hostは予定されているハードウェア仕事のためのものです。

        7      The destination Host is down for scheduled software work.

7 目的地Hostは予定されているソフトウェア仕事のためのものです。

        8      The destination Host is down for emergency restart.

8 目的地Hostは非常時の再開のためのものです。

        9      The destination Host is down because of power outage.

9 目的地Hostが電力供給停止のためにあります。

        10     The destination host is stopped at a software breakpoint.

10 あて先ホストはソフトウェア区切り点で止められます。

        11     The destination Host is down because of a hardware
               failure.

11 目的地Hostがハードウェアの故障のためにあります。

        12-15  Currently unused.

12-15 現在、未使用です。

    When the value of this 4-bit field is 0,1,2, or 3, bits 17-28 will
have the "unknown" indication.

この4ビットの分野の値が0、1、2、または3であるときに、ビット17-28には、「未知」の指示があるでしょう。

    Bit 1 in this message will always be set to zero and Hosts receiving
this message should discard without reporting an error type 6 messages
with bit 1 set to 1.  This will allow later addition of similar status
information on dead destination IMPs.

このメッセージのビット1はいつもゼロに設定されるでしょう、そして、ビット1がある6つのメッセージが1に設定する誤りタイプを報告しないで、このメッセージを受け取るHostsは捨てるはずです。 これは死んでいる目的地IMPsの同様の状態情報の後の追加を許容するでしょう。

Walden                                                          [Page 3]

RFC 611               Changes to IMP/Host Protocol         February 1974

ウォルデン[3ページ]RFC611は1974年2月に悪童/ホストプロトコルに変化します。

    The Dead Host Status message will be returned to the source Host
shortly (immediately, if possible) after each Destination Host Dead
message. The Destination Host Dead message applies to a specific
message-id (link) although the information contained in the Destination
Host Dead message should probably be reported to all users connected to
the dead Host.  The Dead Host Status message does not apply to a
specific message-id (link) and all users connected to the dead Host
should be notified of the information contained in the Dead Host Status
message.

まもなさに(すぐに可能であるなら)、次々とそれぞれのDead Host Status Destination Host DeadメッセージをソースHostに返すでしょう。 Destination Host Deadメッセージに含まれた情報はたぶん死んでいるHostに接続されたすべてのユーザに報告されるべきですが、Destination Host Deadメッセージは特定のメッセージイド(リンクする)に適用されます。 Dead Host Statusメッセージは特定のメッセージイドに適用されません、そして、(リンクしてください)死んでいるHostに接続されたすべてのユーザがDead Host Statusメッセージに含まれた情報について通知されるべきです。

    The modifications mentioned in Section 2 and 3 above will be put
into the network very soon, and we urge the Hosts to implement the code
necessary to take advantage of these modifications as soon as possible.
This modification is backward compatible with the exception (!) that
Hosts which have not done the implementation can receive a type 6
message which they do not know how To handle and will presumably log as
an error.

すぐ上のセクション2と3で言及された変更をネットワークに入れるでしょう、そして、私たちはできるだけ早くこれらの変更を利用するのに必要なコードを実装するようHostsに促します。 この変更は後方に例外(!)と互換性があった状態であります。実装をしていないHostsが彼らがするタイプ6メッセージを受け取ることができるのがおそらく、Toが誤りとしてどのようにログを扱って、望んでいるかを知りません。

       [ 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.           1/2000 ]

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

Walden                                                          [Page 4]

ウォルデン[4ページ]