組織：中國互動出版網（http://www.china-pub.com/）
RFC文檔中文翻譯計劃（http://www.china-pub.com/compters/emook/aboutemook.htm）
E-mail：ouyang@china-pub.com
譯者：李敬（watercloud    watercloud@263.net）
譯文發布時間：2001-7-16
版權：本中文翻譯文檔版權歸中國互動出版網所有。可以用于非商業用途自由轉載，但必須
保留本文檔的翻譯及版權信息。




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


對于IMP/HOST 協議的改動的注釋 (RFCS 687 AND 690)
(COMMENTS ON IMP/HOST PROTOCOL CHANGES, (RFCS 687 AND 690))

本篇RFC主要的是對于RFC 687進行似乎有道理的改動的意見集合，同時也可以作為對
RFC 690的注釋。

現在的主要的問題，就好象Postel所指出的那樣，在于改動后的IMP和HOST傳輸的前
導字符的總長度剛好為120位，這個數字并不是8或者36的整數倍。

一個可以想到的解決方案是將HOST到HOST協議的前導字符的長度增加24位，使得它的
總長度達到144位。但是這里依舊存在一個問題，就是在進行這樣的改動之后，IMP方必須
能夠插入或者刪除這多出來的24個位，來進行144位前導字符和120位前導字符之間的轉化。
上述解決方案中存在的這個問題，是相當明顯的。

更好的解決方案是改變IMP方前導字符的長度，我提議用104位長度代替原來的80位長
度。不過104位長度并不是一個IMP的字的長度的整數倍，這確實是一個問題。但是如果我
們使用以下的法則的話，解決這個問題并不是很難的事情。

    1.  決不用最后的8位傳遞信息。

    2.  網絡沒有被要求將它們從數據源傳遞到目的地，或者將它們返回到數據源

    3.  當發送不同于零的類型的消息（即不規則消息）的時候，IMP被允許發送96位，104
位，112位的數據，具體的選擇看當時IMP的便利而定。

    4.  同樣的，如果需要的話，96位和112位也可以作為不規則消息的前導字符的長度。

這樣，比較起強制所有的HOST進行修改以適應新的標準協議，修改IMP程序，使他們能
夠處理104位的前導字符就是一種更快，同時也是更便宜的選擇了。
  
另外一個建議是定義一種新的IMP到HOST的消息的類型。這個消息應當擁有一個包括了
HOST的名字（人類型的字符串（people type character string））和HOST的網絡地址的表。
這個消息應當在每一次接口重置的時候進行發送，或者當HOST對IMP發送了一個新的請求，
以要求得到上述信息的時候，這個消息可以作為響應被發送



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

RFC692—COMMENTS ON IMP/HOST PROTOCOL CHANGES, (RFCS 687 AND 690)
	對于IMP/HOST 協議的改動的注釋 (RFCS 687 AND 690)


1
RFC文檔中文翻譯計劃