组织：中国互动出版网（http://www.china-pub.com/）<br />
RFC文档中文翻译计划（http://www.china-pub.com/compters/emook/aboutemook.htm）<br />
E-mail：ouyang@china-pub.com<br />
译者：李敬（watercloud&nbsp;&nbsp;&nbsp;&nbsp;watercloud@263.net）<br />
译文发布时间：2001-7-16<br />
版权：本中文翻译文档版权归中国互动出版网所有。可以用于非商业用途自由转载，但必须<br />
保留本文档的翻译及版权信息。<br />
<br />
<br />
<br />
<br />
Network&nbsp;Working&nbsp;Group&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Stephen&nbsp;Wolfe<br />
RFC&nbsp;#&nbsp;692&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;UCLA&nbsp;CCN<br />
NIC&nbsp;#&nbsp;32734&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;June&nbsp;20,&nbsp;1975<br />
<br />
<br />
对于IMP/HOST&nbsp;协议的改动的注释&nbsp;(RFCS&nbsp;687&nbsp;AND&nbsp;690)<br />
(COMMENTS&nbsp;ON&nbsp;IMP/HOST&nbsp;PROTOCOL&nbsp;CHANGES,&nbsp;(RFCS&nbsp;687&nbsp;AND&nbsp;690))<br />
<br />
本篇RFC主要的是对于RFC&nbsp;687进行似乎有道理的改动的意见集合，同时也可以作为对<br />
RFC&nbsp;690的注释。<br />
<br />
现在的主要的问题，就好象Postel所指出的那样，在于改动后的IMP和HOST传输的前<br />
导字符的总长度刚好为120位，这个数字并不是8或者36的整数倍。<br />
<br />
一个可以想到的解决方案是将HOST到HOST协议的前导字符的长度增加24位，使得它的<br />
总长度达到144位。但是这里依旧存在一个问题，就是在进行这样的改动之后，IMP方必须<br />
能够插入或者删除这多出来的24个位，来进行144位前导字符和120位前导字符之间的转化。<br />
上述解决方案中存在的这个问题，是相当明显的。<br />
<br />
更好的解决方案是改变IMP方前导字符的长度，我提议用104位长度代替原来的80位长<br />
度。不过104位长度并不是一个IMP的字的长度的整数倍，这确实是一个问题。但是如果我<br />
们使用以下的法则的话，解决这个问题并不是很难的事情。<br />
<br />
&nbsp;&nbsp;&nbsp;&nbsp;1.&nbsp;&nbsp;决不用最后的8位传递信息。<br />
<br />
&nbsp;&nbsp;&nbsp;&nbsp;2.&nbsp;&nbsp;网络没有被要求将它们从数据源传递到目的地，或者将它们返回到数据源<br />
<br />
&nbsp;&nbsp;&nbsp;&nbsp;3.&nbsp;&nbsp;当发送不同于零的类型的消息（即不规则消息）的时候，IMP被允许发送96位，104<br />
位，112位的数据，具体的选择看当时IMP的便利而定。<br />
<br />
&nbsp;&nbsp;&nbsp;&nbsp;4.&nbsp;&nbsp;同样的，如果需要的话，96位和112位也可以作为不规则消息的前导字符的长度。<br />
<br />
这样，比较起强制所有的HOST进行修改以适应新的标准协议，修改IMP程序，使他们能<br />
够处理104位的前导字符就是一种更快，同时也是更便宜的选择了。<br />
&nbsp;&nbsp;<br />
另外一个建议是定义一种新的IMP到HOST的消息的类型。这个消息应当拥有一个包括了<br />
HOST的名字（人类型的字符串（people&nbsp;type&nbsp;character&nbsp;string））和HOST的网络地址的表。<br />
这个消息应当在每一次接口重置的时候进行发送，或者当HOST对IMP发送了一个新的请求，<br />
以要求得到上述信息的时候，这个消息可以作为响应被发送<br />
<br />
<br />
<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;[&nbsp;This&nbsp;RFC&nbsp;was&nbsp;put&nbsp;into&nbsp;machine&nbsp;readable&nbsp;form&nbsp;for&nbsp;entry&nbsp;]<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;[&nbsp;into&nbsp;the&nbsp;online&nbsp;RFC&nbsp;archives&nbsp;by&nbsp;Alex&nbsp;McKenzie&nbsp;with&nbsp;&nbsp;&nbsp;&nbsp;]<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;[&nbsp;support&nbsp;from&nbsp;GTE,&nbsp;formerly&nbsp;BBN&nbsp;Corp.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;10/99&nbsp;]<br />
<br />
RFC692—COMMENTS&nbsp;ON&nbsp;IMP/HOST&nbsp;PROTOCOL&nbsp;CHANGES,&nbsp;(RFCS&nbsp;687&nbsp;AND&nbsp;690)<br />
	对于IMP/HOST&nbsp;协议的改动的注释&nbsp;(RFCS&nbsp;687&nbsp;AND&nbsp;690)<br />
<br />
<br />
1<br />
RFC文档中文翻译计划<br />