摘要

  • RFC 873 质疑美国国防部等待一套基于 ISO 参考模型、由厂商提供的网络协议；1982 年的采购需求已经出现，而那套规范仍有部分未定。
  • 真正的试金石是两家厂商的产品能否互通：层间行为和可选功能即便各自解释得通，也可能把修补费用留给采购方。

采购文件上写“厂商支持”，看起来像有人已经接过了麻烦。报文到了另一台机器门口，仍要自己证明双方说的是同一种话。Michael A. Padlipsky 在 1982 年的 RFC 873 中，把这道缝摆到美国国防部的采购桌上。有人希望等待以 ISO 参考模型为基础、由厂商供应的协议，而不是采用已经在 ARPANET 路线中运行的协议族；理由之一是替政府省钱。Padlipsky 的回应很直接：先说清楚要买什么、何时到货，以及两套设备不合拍时谁出维修费。

他先拆开“整套协议”这四个字。X.25 涉及通信链条的一部分，却不足以提供计算机间资源共享所需的全部服务。再补上若干接入或地址规范，也还不是 National Bureau of Standards 与 ISO 当时分别讨论的完整套件；两家的设计并非一模一样。若采购条件只写一个听起来圆满的名称，合同能先盖章，接口细节却仍在不同人的文件夹里。箱子可以订，里面每一层怎样工作还没谈拢。

时间是第二本账。Padlipsky 指出国防采购本来就有长周期，而 1982 年的 ISO 路线协议套件尚未完成，一些层次的方案还只在纸上，缺少实际使用检验。标准化需要时间；国防部的网络合同却正在发出。另一边，基于 ARPANET 参考模型的协议已经在该部门使用的若干操作系统上有实现。维护现有代码需要人手，等待尚未成形的全套规范也要占用采购日程。Padlipsky 不肯让“再等等”躲在预算表的空白格里。

接下来是“支持”到底覆盖哪些行为。RFC 列出一连串现实问题：层与层的接口语义是什么，发送时是否必须依次经过每一层，一层里面到底允许多少种协议，紧急数据怎样抵达应用。参考模型能帮人描述系统，但采购需要的是两台机器对这些问题给出相容答案。两家厂商都可能认真照着各自理解实现，最后仍要有人花钱协调、修改与测试。符合一个抽象模型的字样，无法替报文把路走通。

可选功能把账单写得最清楚。厂商甲提供一个选项，客户的应用依赖它；厂商乙按规范允许的选择没有提供。双方都未必犯错，采购方的两套设备照样无法合作。是改应用，还是换配置，还是另签一份开发合同？Padlipsky 认为费用很可能落在用户身上。“可选”没有取消兼容决策，只把决定推迟到两份订单碰面的那天。

还有机器付出的账。CPU 时间和内存是当时很紧张的资源，协议软件每多绕一层、多维护一份状态，都可能挤占系统原本要共享的能力。Padlipsky 用一次历史上的定期探测经历说明，小小的控制消息重复得足够频繁，运行成本会变得显眼。这是要求测量的线索，不是一张适用于所有产品的性能排行榜。买家既要问是否有人维护软件，也要问软件运行时吃掉多少资源。

这篇 RFC 的语气辛辣，逻辑却不靠猜测厂商动机。设计环境可能自然地奖励功能承诺，却没有同样强烈的动力把实现做得精简。文章最后借“没有免费的午餐”把成本拆开：软件维护、跨产品互通、处理器时间和内存各有价格。Padlipsky 同时注意到越来越多厂商已经供应或准备供应 TCP/IP。现实市场正在把“厂商支持”与“ARPANET 协议”这组看似对立的选项搅在一起。

RFC 873 保存的是 1982 年采购争论的切面。它让人看清四个必须同时核对的事实：完整协议何时可交付，哪种实现已经运行，可选功能能否对上，以及分歧出现时由谁买单。采购单可以指定厂商；它没法代替两端系统约定并验证同一套行为。