对于IMP/HOST 协议的改动的注释

本篇RFC主要的是对于RFC687进行似乎有道理的改动的意见集合，同时也可以作为对
RFC690的注释。
现在的主要的问题，就好象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的名字（人类型的字符串（peopletypecharacterstring））和HOST的网络地址的表。
这个消息应当在每一次接口重置的时候进行发送，或者当HOST对IMP发送了一个新的请求，
以要求得到上述信息的时候，这个消息可以作为响应被发送

[ThisRFCwASPutintomachinereadableformforentry]
[intotheonlineRFCarchivesbyAlexMcKenziewith]
[supportfromGTE,formerlyBBNCorp.10/99]