摘要

  • RFC 1096 定义 Telnet 选项 35，用来请求并返回 X 显示位置。WILL/DO 只允许双方以后讨论该选项，真正的定位符必须经过有方向约束的 SEND/IS 子协商传递。
  • 定位符采用 Unix DISPLAY 格式 <host>:<dispnum>[.<screennum>]。Telnet 客户端必须把 :0 这类仅在本机成立的写法改成远端可理解的形式，但这种改写不证明主机身份、显示归属或网络可达。
  • 远端应用仍需建立一条独立的 X 连接，并通过 X 服务器自己的访问列表与授权设置。收到 IS 不是获得屏幕使用权，X 连接获准也不等于窗口已经出现或用户已经看到结果。

两台机器之间缺的不是命令，而是坐标

设想 1989 年的一张工作台。用户在 X 环境里打开 Telnet 客户端，登录另一台主机，再在远端 shell 中启动一个 X 程序。程序已经运行，却不知道图形该送到哪里。用户面前的显示器属于本地主机的 X 服务器，进程则处在远端；命令通道和显示通道从一开始就不是同一条路。

RFC 1096 解决的是这个坐标缺口。它在 1989 年 3 月以 Proposed Standard 发布，把 35 分配给 X-DISPLAY-LOCATION。今天的 IANA Telnet Options 登记表 仍把 35 记为 X Display Location，并指向 RFC 1096。

这个设计没有试图让 X 图形流穿过 Telnet。它让现有 Telnet 连接带回一个字符串，远端程序再据此尝试另一条连接。看似“在远端运行、本地显示”的连续体验，在协议上实际由至少两个会话拼成。RFC 1096 只负责交接点上的那张地址纸条。

WILL 与 DO 只打开讨论窗口

选项的默认状态是 WON'T/DON'T。一次普通登录不会自动公布显示位置。双方首先使用 RFC 854 的 Telnet 命令体系协商：WILL 表示愿意在后续子协商中提供位置，DO 表示愿意接收；WON'T 与 DON'T 则拒绝相应角色。

RFC 1096 特意写明，WILL 和 DO 仅用于取得与授予“未来讨论”的许可。它们没有携带 DISPLAY 值，也没有表达 X 服务器的访问决定。这正是 RFC 855 所定义的两阶段模式：先同意讨论某个参数，再在 SB 与 SE 之间传送参数本身。任何一方还可用 WON'T 或 DON'T 结束后续子协商。

这条边界是全文最重要的句子。协议同意只能证明双方进入了某个状态。它不能证明某台显示器存在、属于当前用户、能从远端到达，或愿意接纳将要启动的 X 客户端。允许询问地址，不等于允许使用地址所指的资源。

SEND 与 IS 把主动权分得很清楚

即便 WILL/DO 已经成立，位置也不能自行出现。只有发送过 DO 的一方可以发 SEND；只有发送过 WILL 的一方可以用 IS 回答。愿意提供位置的一端不得在没有请求时主动推送。

RFC 1096 明说，它的文字与命令流程紧跟 RFC 1079 的 Telnet Terminal Speed Option。终端速率也使用先协商、后 SEND/IS 的请求式状态模式。复用现成状态机能减少实现分歧，但不意味着两个值拥有相同的安全含义。终端速度描述连接属性，显示位置则指向另一个有自身权限的服务。

规范给出的例子是 SRI-NIC.ARPA:0.0，整条选项子命令占 22 个八位组。远端收到这串 NVT ASCII 后，最多能证明 Telnet 对端按约定格式给出了这项陈述。此时还没有 X 连接，也没有 X 服务器的判断。

把 :0 改写出去，是作用域转换

位置字符串遵循 Unix DISPLAY 约定：<host>:<dispnum>[.<screennum>]，不得夹带空格或其他多余字符。主机部分给出网络目的地，显示号选择一项 X 服务，可选的屏幕号再选其中的屏幕。

难点藏在本机简写里。 :0 或 unix:0.0 对本机程序很自然：它们省略可从本地环境推断的主机信息。若原样送到远端，“本机”会变成远端主机，意义完全改变。因此 RFC 1096 要求 Telnet 客户端在发送前对它们作适当修改。

这里发生的是作用域翻译。客户端把仅在一台机器内部成立的定位符，转换成希望从另一台机器也有意义的定位符。规范没有说这一步会认证主机名、验证 DNS、探测路由、测试端口或证明用户拥有该显示。

一个格式正确的值可能过期、错误或不可达；一个完全准确的值也可能指向拒绝远端访问的 X 服务器。语法合格只是第一层证据。

Telnet 交出定位符后，X 才开始自己的连接

RFC 1013 描述 X Window System Protocol Version 11 时，把 X 客户端连接定义为独立的进程间通信路径。走 TCP 时，显示号 N 对应 6000+N 端口。RFC 1096 交出的 host 与 display number 能帮助远端进程选择目的地，却没有替它建立这条路径。

Telnet 的 TCP 流不会在某个字节之后变成 X 流。选项 35 不传 X 请求、不传窗口内容，也不是隧道、代理或转发机制。远端应用要作为 X 客户端另行连接；寻址、路由、过滤、监听状态都可能在这条新路径上独立失败。

这也决定了故障语言。收到 IS 说明字符串到达 Telnet 服务器；连接 6000+N 失败属于后续网络或服务状态；X setup 被拒又是更后一层。把三者都写成“Telnet 失败”，会抹掉最有诊断价值的边界。

接纳客户端的决定属于 X

RFC 1013 的连接建立信息包含字节序、协议版本、授权协议名称与授权数据。X 服务器可以拒绝并返回原因，也可以接受并返回厂商、屏幕、像素格式与资源标识信息。核心协议把“哪些授权机制有效”留在核心协议之外处理。

同一文档还单独描述主机访问控制列表。列表初始包含本地主机与经配置的主机，可由获准客户端修改；不满足条件的连接可以被服务器拒绝。换言之，Telnet 协商没有替 X 服务器作出准入决定。

今天的 IANA 表把 X Display Location 记作 35，把 Telnet Authentication 单独记作 37。这项当前分类能帮助我们避免把定位选项误称为认证，却不能倒推 1989 年的具体实现组合。RFC 1096 本身没有规定加密、认证、cookie 传输、访问策略或窗口绘制。

证据必须依次写清。WILL/DO 证明允许进行选项对话；SEND/IS 证明对端返回了一串定位符；TCP 连接证明一条路径到达监听端；X setup 获准证明服务器依据当时采用的控制接受连接。每一步都比前一步多，但没有一步能替代后一步。

被 X 接受，也还没有抵达人的结果

假设定位符准确、网络可达、X setup 也成功，远端应用仍要创建资源、发出请求，服务器还要处理并映射窗口。窗口必须保持可用，出现在相关屏幕上，用户还得实际看到或操作它。连接获准是强证据，却不是最后的用户观察。

自动化最容易把早到的成功信号升级成想要的结论：拿到地址就说资源可用，连接获准就说功能完成，进程退出为零就说用户体验正常。RFC 1096 的价值恰恰在于它只解决一件事，并把后续真相留给后续证据。

IANA 登记也同样克制。登记项证明编号与规范的对应关系，不是部署普查，不能说明某个产品、主机或用户曾经怎样使用它。官方资料支持的是机制史，不是臆造的使用故事。

因此，这份很短的 RFC 留下了一个长久原则：系统可以跨协议传递上下文，却不会因此跨协议继承权限。显示位置越过了 Telnet，访问权仍留在 X。

来源