RFC692 对于IMP/HOST 协议的改动的注释 (RFCS 687 AND

作者：zhaozj
发表时间：2020-12-23 10:56
来源：未知

组织：中国互动出版网（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文档中文翻译计划