RFC692 Comments on IMP/Host Protocol changes (RFCs 687 and 690)

0692 Comments on IMP/Host Protocol changes (RFCs 687 and 690). S.M.Wolfe. June 1975. (Format: TXT=2681 bytes) (Updates RFC0690) (Status: UNKNOWN)

日本語訳
RFC一覧

参照

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


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

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

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.

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.

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.

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

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

    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.

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

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.

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.




Wolfe                                                           [Page 1]

RFC 692          Comments on IMP/Host Protocol Changes         June 1975


       [ 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 ]
















































Wolfe                                                           [Page 2]

一覧

 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200 

スポンサーリンク

終了タグを省略したoption要素に続くoptgroup要素を無視する

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る