摘要

  • RFC 779 定义了 Telnet 的 SEND-LOCATION 选项，让客户端把用户位置写成可打印字符传给远端主机，弥补仅知登录来源站点的不足。
  • 这不是一按登录键就自动发生的动作：默认关闭，客户端提出、服务端同意，随后才发送文本；远端系统再决定怎样使用它。

1981 年要找一位同事，可以先问计算机。它也许能列出姓名、作业、终端所在房间。若对方从另一所机构远程登录，答案可能只剩“他在那边的实验室”。这个线索足够找一栋楼，不足以拨通桌边的电话。Earl Killian 在 RFC 779 里给 Telnet 添了一个小本领：让用户一侧的程序告诉远端主机，人现在坐在哪里。

当时的在线名录本就带着物理世界的味道。RFC 742 的 NAME/FINGER 描述了如何列出正在使用系统的人，连同能确定的终端物理位置；列表还可能显示空闲时间或作业名。知道同事在哪个终端，有助于走过去找人，或拨打附近的电话。远程登录让这个习惯出现了空白：服务器认识连接来自哪个站点，却看不到那片楼里的具体桌子。

Killian 给这个空白取名 SEND-LOCATION，Telnet 选项号为 23。协议默认两端都不启用。客户端若知道用户位置，可以先发 WILL SEND-LOCATION，表示愿意提供。服务端若能用这项信息，就回 DO SEND-LOCATION。得到同意后，客户端可在以 IAC SB 开始、以 IAC SE 结束的子协商中发送一串可打印 ASCII 字符。这是用户一侧给出的文字，可以是本地最有用的房间或联系线索。协议负责送话，不替人测出坐标。

那些英文动词也给拒绝留了位置。WON'T 是发送方拒绝使用；DON'T 是另一方要求停止。服务器可以提出请求，客户端也可以回绝。同意建立后，位置文本还可以稍后再发。提出选项、接受选项、真正交出内容，是三件独立的事。一张写着位置的卡片，不会因为有人开了终端就自己跨过网络。

这套用途已有前例。RFC 734 的 SUPDUP 允许用户端发送“控制台位置”文字，服务器通常保存下来，供 who 命令显示。RFC 779 把类似的用处安放到 Telnet 的选项协商中。共同点是明确的：近处的程序提供位置，远处的主机收下，再按自己的方式处理。

两种文档管的是链条上不同的一段。NAME/FINGER 说明在线用户列表里哪些信息有用；SEND-LOCATION 说明 Telnet 会话怎样把一个位置交给服务器。RFC 779 点名 ITS 作为能利用该信息的系统。至于最后的列表怎样排版、谁会看到，要由远端系统的程序处理。一个文本字段抵达服务器，和它出现在别人屏幕上，中间还隔着一道本地决定。

这个小功能有清晰的人情味，也有清晰的边界。把“来自某机构”改成“在某个房间、某部电话旁”，能让共用一台机器的人找到彼此。位置文字也可能进入其他用户查看的列表。RFC 779 用两页把选择分给两端：客户端提供描述，服务端决定是否接收和如何展示。Telnet 传的不只是终端上敲出的字符，还可能是敲字的人身边那张桌子的线索。