引言

Bill Crowther 的 RFC 第 67 号提出的问题, 远比标记问题更为根本。对目前已确立的协议的任何修改, 都将牵涉到硬件/软件开发工作的改动, 而这些工作在某些情况下已经进行了 6 个多月。在 Multics 的情况下, 这项工作已经产出了完整的程序或处于高级调试阶段的程序。毫无疑问, 许多其他站点也是如此。

这里所阐述的论点并不是说现行协议是理想的, 而是说所有人都已同意它是可行的, 并且已经开始实施它。因此, 我们希望提议: 在接下来的 6 个月内, 或者在这套系统运行起来并能观察其特性所需的这段时间内, 暂停对本协议的大多数修改。

具体而言, 这意味着不做仅影响效率或实现便利性的修改。如果发现重大设计问题, 仍应将其提出以供考虑, 代表对现有系统扩展的问题也同样可以提出。但是, 不应修改现行系统的细节。

支持这一论点的理由有几点。第一点, 或许也是最重要的一点, 是让系统尽快运行起来。网络的重大益处将体现在它的各种用途之中, 而在网络投入运行之前, 沿着这些方向的开发实际上无法起步。我们认为, 尽管日后重新编写部分 NCP 所需的工作无疑会更大, 但届时它会被同时进行的、涉及网络使用和更高层网络开发的并行工作所掩盖。

随之立即出现的另一个问题是, 什么才算是协议的正式修改。现行协议的开发历程表明, 一个想法一旦提出, 在它被所有人普遍接受之前会被修改多次。因此, 每一个新的修改建议都可能使程序开发推迟数月之久。

最后还要考虑到, 一旦网络开始实际运行, 某个想法可能会被证明不可行。当全面测试开始进行时, 目前已经达成一致的任何问题都可能被重新提出。

我们认为这些考虑足够重要, 应当冻结网络协议, 除非出现某些会使某项功能无法实现的问题。那时, 仅仅为了带来更高效率的修改将被搁置, 直到网络的实际运行经过测试为止。

这并不是说新的想法或论点不应被提出, 而是说提出它们时应明确: 这些想法不是供立即实施的, 而是供讨论、以期日后有可能实施的。这一构想或许可以通过给此类文件冠以“提议在暂停期后对……的修改”这样的标题来体现。

注: 本 RFC 由 Bob Hinden 于 1997 年 6 月转换为机器可读形式, 以便录入在线 RFC 档案。