摘要

  • RFC 1041 提议用单一 3270-REGIME 选项完成模式选择和切换；RFC 1576 说它只有极少开发者与厂商实现，实际通行的是 Terminal-Type、Binary 和 EOR 的组合。
  • 三项协商解决了呈现方式、八位数据与消息边界，却没有提供指定设备/LU、查看 SNA BIND、关联处理结果或统一解释 ATTN、SYSREQ 的机制。
  • 后来的 TN3270E 把设备名、BIND 与正负响应分别做成可协商功能。功能存在不等于必然启用，也不等于身份认证或最终业务结果。

一只完整开关没有成为运行事实

3270 显示终端与普通 Telnet 的 NVT 不属于同一语法世界。它使用 EBCDIC，以整块命令和数据交互；主机能否正确驱动画面，还取决于终端型号、屏幕尺寸与扩展能力。要把这种会话放进 TCP，双方至少要回答三个问题：八位组如何解释，一块在哪里结束，客户端模拟哪类终端。

1988 年的 RFC 1041 希望用 Telnet 选项 29 3270-REGIME 一次回答。客户端按偏好列出可用模式，服务器选择双方都支持的一个。选择 3270 模式会同时意味着 Binary 与 IAC EOR；发送空列表则回到 NVT ASCII。

它最谨慎的部分不是名称，而是切换时刻。协商开始后，客户端应停止接收用户输入；服务器应尽量不再发送数据，并在发出新模式前排空旧数据。客户端在收到选择后换解析器，服务器在发送选择后换解析器；必要时两边都要清空未决数据。文档承认：同一串合法字节若跨过错误的模式边界，就会被另一套语法消费。

这套设计清楚，却没有自动获得安装量。RFC 1576 在 1994 年明确说，只有极少开发者和厂商实现了 RFC 1041。它的 RFC Editor 条目 把文档标为 Informational。这里的“极少”不能被写成“没有”，文献也不是全行业普查；它只足以说明，新的共同说明必须面对已经运行的另一种做法。

现实用三项旧能力拼出模式

传统 TN3270 沿用 Telnet 基础协议，分别协商 Terminal-Type、Binary Transmission 与 End of Record。Terminal-Type 选出一个 3270 模拟型号；Binary 允许八位数据；EOR 用 IAC EOR 标出整块命令的结束。

没有任何单项等于“TN3270 已建立”。是三项状态的组合构成事实标准。RFC 1576 不要求固定协商顺序；在合适的终端类型与双向所需的 Binary、EOR 都成立后，客户端和服务器才交换 3270 数据。服务器若撤回 Binary 或 EOR，连接就不再满足 TN3270，客户端必须把后续服务器数据按 NVT ASCII 处理。

这是一种窄而有用的协议。Binary 证明的是八位组传输方式，EOR 证明的是块边界，Terminal-Type 声明的是呈现模型。它们没有说明 Telnet 服务器如何连接主机，也没有把 SNA 的内部状态自动带到客户端。

画面出现了，逻辑单元仍然匿名

Terminal-Type 本身就是非对称协商。服务器发问，客户端依次提供可用类型。客户端报出新类型时可能要切换模拟模式；服务器收到名称却不必立即改变处理。一个 3278 型号字符串描述屏幕行为，不是硬件身份证，更不是服务器已经分配的 Logical Unit。

在 SNA 环境里，一台 3270 终端通常同时拥有面向应用的会话和面向 System Services Control Point 的会话。TN3270 客户端看到的只有一条 Telnet 连接，既看不出服务器经由 SNA 还是非 SNA 接入，也不能要求连接绑定到某个 3270 device-name。

RFC 1576 说，客户端 IP 地址是 TN3270 环境中最接近 LU name 的东西。这个措辞恰好说明两者不同：IP 地址定位网络端点，LU name 标识主机环境中的逻辑资源；主机应用甚至可能因终端网络名不同而改变行为。

型号后的 -E 也只是受限提示。它通常代表支持 structured fields，有些服务器还据此推断扩展属性；文档承认实现解释并不统一。显示能力的标签不能代替逐项能力回执。

EOR 只把块关上

3270 命令没有由传统 TN3270 另行携带的外层长度，因此 EOR 的价值非常具体：接收方终于知道一块在哪里结束，可以开始解释完整命令。但“完整收到”与“处理完成”仍然隔着一层。

RFC 1576 把 SNA 正负响应列入传统 TN3270 的缺口。正响应原本可以说明上一条数据已经处理完毕；负响应可以指出无效命令或客户端机械故障。传统 TN3270 不传这份结果，数据被假定为已经处理或被忽略。

因此，TCP 收到、Binary 保留、EOR 闭合、模拟器接受、屏幕更新、打印机动作、主机应用继续以及用户理解，必须分别记录。EOR 没有权力代表后面的事实。

NOP 与 Timing Mark 也只能缩小“仍在线”的范围。NOP 不要求应用响应；客户端异常退出后，服务器可能通过 TCP 发送错误发现它消失。进程可达不证明应用健康，更不证明人在屏幕前。

两个特殊键暴露了网关的决定权

ATTN 往往用于请求中断当前处理。许多 TN3270 客户端把它映射成 Telnet BREAK，再由服务器翻译为 SNA 侧动作；非 SNA 服务器可以忽略 BREAK。

SYSREQ 更不统一。有的服务器把 Telnet Interrupt Process 当作 SYSREQ，有的识别 3270 Test Request。在 SNA 中，它可以在应用会话与 SSCP 会话之间切换。SSCP 数据格式无法直接穿过传统 TN3270，服务器只能自行处理、转换成 3270 数据，或忽略这项功能。

于是一次按键至少跨过五条记录：用户输入、客户端发出的 Telnet 命令、服务器映射、SNA 控制事件、主机应用结果。最前面的记录不能越级证明最后一项。

TN3270E 没有放大旧标签，而是补独立账目

RFC 1646 与 RFC 1647 很快提出扩展。1998 年的 RFC 2355 及其 官方条目 把 TN3270E 带入 Standards Track。

TN3270E 先协商 device-type，并可附带资源名或 device-name 请求。服务器可以返回实际分配的名称，也可以用名称未知、设备占用、类型与名称冲突等理由拒绝。之后双方才协商 FUNCTIONS 列表。

功能被刻意拆开。BIND-IMAGE 让 SNA 服务器通知客户端主机应用会话的建立和结束，并传递已接受的 BIND image。RESPONSES 为数据加上响应策略与序号，让正负处理结果能对应到具体块。SYSREQ、打印机控制也各自协商。列表甚至可以为空，这就是 basic TN3270E。

沉默因此仍有多种语义。一块数据可能要求不响应、仅错误响应或始终响应。没有协商 RESPONSES 时，序号应被忽略；没有 BIND-IMAGE 时，协商了 TN3270E 也不会自动得到 BIND。任何一方拒绝 TN3270E，还可以退回传统 TN3270。

RFC 2355 同时说明，这些扩展没有带来超出普通 Telnet 的安全能力。服务器分配 device-name，只证明这次技术分配；用户是否有权使用它，仍需认证与本地策略。

运行代码是证据，不是全部主权

这段历史没有简单赢家。RFC 1041 的单一开关边界清楚，却未成为主流实现；三项旧选项降低了采用成本，却遗漏关键回执；TN3270E 补充记录，同时保留弱模式与回退。

Heng Lu 关于运行代码优先的论述要求研究者观察真正执行的系统，不让纸面规范替现实发言；最小共同规范与本地决策解释了为何复用小组件能形成可接受的共同层；现实分层则阻止我们把呈现、会话、身份和结果压成“终端已工作”。这是后来的编辑视角，不是对 RFC 作者动机的追认。

RFC 1576 留下的纪律很薄：每份记录只证明自己的范围。Terminal-Type 说明模拟方式，Binary 说明八位组，EOR 说明块结束。LU、BIND、处理、中断与人的后果，各自等待自己的证据。

来源