摘要

  • RFC 1079 将 TERMINAL-SPEED 的协商许可、后续请求和终端速度回应明确分开。
  • 回应可以帮助本地显示决策，却不能证明网络路径事实，也不能授权改变 TCP、路由或服务政策。

一个职责很小的数字

早期终端软件必须面对不同物理终端和调制解调器的节奏。操作系统通常记录直接连接的终端速度，用它控制与时间有关的显示过程，例如插入多少延迟填充字符；有些界面也会区分快慢终端。RFC 1079 正是在这个具体问题上工作。它没有让 Telnet 探测网络，而是让 Telnet 会话能够取得一项相近的终端信息。

因此，9600,100 不能因为看起来像技术测量就获得更多含义。在 RFC 1079 中，它是由一个对等端提供的 NVT ASCII 字符串，写着终端发送和接收速度的十进制表示。它不是探针，不是路由器的观察，不是可用容量报告，也不是 TCP 下一刻会交付多少字节的保证。一个数字适合帮助界面，并不表示它足以裁定整个连接。

若程序需要知道吞吐、丢包、实际显示结果或用户是否完成任务，仍须对那些事实分别取证。终端提示的价值恰恰在于它保持轻量：它可以为保守的呈现方式提供一个输入，却不篡夺其他层的判断权。

许可不是数值本身

RFC 854 为 Telnet 提供了通用结构。Network Virtual Terminal 是共同的基础表示；WILL、WON'T、DO 和 DON'T 用于同意或拒绝更丰富的约定。RFC 1079 将这一结构用于第 32 号选项 TERMINAL-SPEED。

默认状态是不交换信息：WON'T TERMINAL-SPEED 与 DON'T TERMINAL-SPEED。WILL 仅表示稍后愿意发送信息，DO 仅表示愿意接收信息。两者都不是速度报告，只是为未来对话开了一扇窄门。

双方交换 WILL 和 DO 后，发送 DO TERMINAL-SPEED 的一方才可用 IAC SB TERMINAL-SPEED SEND IAC SE 请求；发送 WILL TERMINAL-SPEED 的一方才可用 IAC SB TERMINAL-SPEED IS ... IAC SE 回答。信息不可自行冒出。这条规则把请求权与陈述权分给两个参与者，却没有把网络路径的裁决权授予任何一方。

回应格式也很严格：发送与接收速度为两个十进制数，中间一枚逗号，不得有前导零或多余字符。这让实现可以稳定解析，却不证明被描述的设备、调制解调器、路径或屏幕效果是真的。格式正确只证明消息符合格式，不会把消息变成更大现实的证明。

RFC 的建议仍留在本地

RFC 1079 考虑到某些系统只支持若干离散速度。若收到的值不在其中，可以选择安全方向上最接近的可用值；对于填充，向上取整往往比填充不足更安全。这是程序怎样在自己的能力范围内处理收到的元数据的建议，不是让它改造线路、预留带宽、配置路由器或控制拥塞的命令。

程序可以保存原始字符串，记录自己选择了哪个速度，并在以后再次请求。这种可追溯性把“对端提供的特征”和“本地软件做出的显示选择”分开。RFC 1079 所援引的 RFC 930 终端类型选项也有相似结构：SEND/IS 中传递的状态可供后续处理参考，但传递本身不等于处理已经改变。

这串字符不能裁定什么

收到 1200,1200 最多说明某个 Telnet 参与者在规定的交换中发出了这些字符。它不能证明终端确实以该速度物理连接，不能证明调制解调器同步、TCP 路径有同等容量、没有丢包、用户看到了预期屏幕，或应用操作成功。它不识别某个人，不授予某项权限，也不证明某个网络今天仍在使用 Telnet。

需要防止的推理膨胀很常见：本地属性变成数字，数字被当成测量，测量又被当成网络或服务政策的依据。RFC 1079 只给出第一步。每一步更大的结论，都需要独立的观察、责任和授权。

来源与证据边界

冻结来源包括 RFC 1079、RFC 854、RFC 930 与 RFC 1123。RFC 1079 支撑动机、命令、默认值、语法和本地建议；RFC 854 支撑 NVT 与协商框架；RFC 930 用于历史上的请求—回应比较；RFC 1123 仅把 RFC 1079 列入 Telnet 参考。它们都不支持当前部署、具名实现、链路容量、身份、授权或应用结果的断言。