摘要

  • 1983 年 12 月的 RFC 884 给 Telnet 的 TERMINAL-TYPE 选项编了 24 号。DO、WILL 先取得交换许可；SEND 再问，IS 才把终端名称送过去。
  • 同一台设备可以先报精确型号，再报宽泛名称。重复最后一个名字表示名单到头。1985 年的 RFC 930 又补上一条规矩：收到询问后才能回答，免得两句话在路上撞车。

想象一位程序员，花半天把菜单画得整整齐齐；远方用户按下回车，屏幕却像被猫踩过键盘。网络传来的字符没有坏，坏在主机把它们交给了错误的屏幕习惯。不同终端移动光标、清除区域、显示颜色的指令各有脾气。电传打字机更直接：它根本没有可供光标炫技的屏幕。解决这场尴尬，先别急着重写菜单，问清楚对面坐着谁。

Telnet 基本规范 早给双方准备了一个共同起点：网络虚拟终端。无论实物是什么，连接一开始都能用这套想象中的设备交谈。这让人可以先敲字，再处理硬件差异。不过，程序若想使用光标定位等高级本领，就需要知道实物型号。Marvin Solomon 和 Edward Wimmers 在 RFC 884 中写下了这套“报名”礼仪。

终端类型选项的编号是 24，默认状态是 DON'T 和 WON'T，双方不交换型号。主机发 DO，另一端答 WILL，表示愿意进入下一步。这只是允许谈话，姓名尚未出现。随后主机发 IAC SB TERMINAL-TYPE SEND IAC SE；回答形如 IAC SB TERMINAL-TYPE IS IBM-3278-2 IAC SE。SEND 的子命令码是 1，IS 是 0。型号以 NVT ASCII 字符串表示，大小写算同一种写法。

规范列出的名字像一份旧机房设备清单：IBM 显示终端、TOPS20 环境常见机型、Unix 环境常见机型，里面有 DEC-VT100，也有 TELETYPE-33。互联网把这些秉性不同的机器拉进同一场对话。共同的网络入口解决了“先接上”的问题；型号名称帮助主机决定接下来该用哪套显示本领。

麻烦在于，机器的名字也是人取的。作者举例说，IBM3278-2 和 IBM-3278/2 这种写法差异足以让双方各说各话。Telnet 没有专门为“不认识这个型号”准备否定答复。它采用更像日常交谈的办法：如果设备同时有精确名称和通用名称，就在连续询问中从精确往通用报。最后一个名字再说一遍，表示名单已经翻到底；主机连续听到两次相同回答，就该收起好奇心。协议里竟然藏着一句“你还有别的叫法吗？”

拿到名称后，服务器可以把它交给本地终端驱动或程序，再决定怎样输出。RFC 884 提到光标定位、颜色，也提到配合 BINARY 选项。主机若认识这台设备，就有机会让远程使用更像直接连接。若名称无法让对方认出型号，还可以答 UNKNOWN。决定显示效果的仍是本地软件对名称的理解。

1983 年的礼仪还留了一处抢话风险。DO、WILL 谈妥后，原文允许持有终端名称的一方主动发送 IS。作者以为，主机若同时发送 SEND，最糟不过收到两份相同资料。1985 年的 RFC 930 看见更麻烦的情况：主动回答和询问在途中交错，下一份回答究竟是在答问题，还是名单里的第二个名字？修订版规定 IS 必须回应 SEND。设备依然可以有别名，双方从此按次序开口。

再到 1989 年，RFC 1091 把连续名称扩展成可切换的多个终端仿真模式。1983 年的核心故事却更朴素：一台远方计算机要善待你的屏幕，得先知道怎么称呼它。第一次叫错了，还可以礼貌地问一句：那你还有什么名字？