摘要

  • 1977 年的 NAME/FINGER 允许远端主机查询某系统的在线用户，或按姓名查询某个人。
  • 请求很短，响应却可能包含姓名、终端位置、空闲时间、最后登出时间和用户留言。

空行本身就是一次查询

NAME/FINGER 1977 年说明中最有意味的请求几乎什么也没有：一个回车换行。客户端连到远端服务，送出空命令，服务器便可返回此刻正在使用系统的人员名单。不同机器会列出全名、正在运行的任务、终端闲置多久，甚至终端所在的房间。按姓名查询还可能越过登录会话：若用户已经离线，系统仍可返回最后登出时间，以及那个人留给来访者的一段短讯。

网络统一了提问方式，没有统一人的呈现

这比网页个人主页早，却不是一张网页的雏形。它把网络上的提问接到各主机原本掌握的账户和终端信息上。Ken Harrenstien 在 RFC 742 中写明，协议主要规定一行命令，不强制响应格式。每个站点自行决定怎样把本机数据整理成人能读懂的回答。问题可以跨机器传递，人的呈现方式仍由本地系统决定。

到 1990 年，是否公开状态成为运维选择

RFC 742 记录的不是凭空设计，而是一条改造路径。Les Earnest 在 SAIL 编写的 FINGER 程序启发了 MIT ITS 上的 NAME。MIT 的 Earl Killian 与 SAIL 的 Brian Harvey 一起实现了所述协议；不久，SRI-KA 与 SRI-KL 也有了类似服务。文件列出三个参与站点，却没有提供全网部署数量，不能据此推算普及程度。

示例把“在线状态”背后的社会信息摊开了。一份输出列出控制台位置和正在运行的任务；另一份则说某人目前未登录，并展示其 plan：他预计会去哪里、何时容易找到、该如何联系。协议没有要求每个站点都公开这些字段。但示例说明，同一类查询可以把机器的运行数据与用户主动写下的文字并在一起。

最初的连接方式也属于当时的网络环境。RFC 742 规定用 ICP 连接八进制 117 号 socket（十进制端口 79），建立两条 8 位连接。1984 年的 RFC 924 将 Finger 列为 Elective，并指出它还需要适配 TCP；其简短定义仍是查询某用户当前或最近的活动。

1990 年 6 月的 IAB/IETF 会议纪要暂时保留 RFC 742 作为沿用的 Proposed Standard，同时要求另找一份更好的规范再审议。11 月发布的 RFC 1194 试图在不破坏既有实现的前提下说清客户端与服务端如何通信。它指出当时许多实现源自 Berkeley BSD Unix，也把用户信息称为敏感信息，并讨论拒绝查询、用户文件、可执行程序和审计记录等问题。

这个协议留下的边界很清楚：它让远端网络能够询问一个人，却没有让答案变成统一格式，更没有要求所有站点公开同样的内容。管理员选择服务返回什么；用户可以写 plan，却未必能控制系统自动生成的字段。1990 年的修订没有消除这种张力，只是让运营者有了更明确的管理问题可以处理。

一手记录