摘要

  • RFC 1312 定义了经 TCP 和 UDP 发送短消息的实验性服务；消息中的收件人、收件终端、发送者、cookie 和签名字段并不天然等于某个在场的人。
  • TCP 的 + 表示消息成功投递给某个用户或终端，但 RFC 限定它可能仅代表服务器成功调用本地消息投递服务。
  • 文档没有规定确认必须等到窗口显示、用户看到或关闭弹窗之后才发出，因此正向确认不是“已读”的证据。

分析

一个目的字段并不等于一个被找到的人

RFC 1312 的消息由版本字节和一串以空字符结束的字段构成，其中有 RECIPIENT、RECIP-TERM、消息正文、发送者、发送终端、cookie 和签名。它们让服务知道怎样尝试投递，却没有把人和屏幕压缩成一条确定的地址。

收件人字段为空时，消息可以投递给目标系统上的任何用户；收件终端为空时，由系统自行选择“合适”的终端；终端字段为 * 时，意味着所有终端；两者都为空时，消息应写到控制台——即一个可能被操作员或管理员看见的地方。控制台在这里不是某个姓名，而是一种功能性地点。系统选择、终端存在和人是否在场依然是不同问题。

这正是消息服务和人际事实的边界。一个请求可以带着某个用户名或终端偏好抵达服务器，也可以被服务器的本地规则处理。它不因此证明服务器选中了哪块屏幕，更不证明一位具体的人在那块屏幕前。把“面向某人”的字段说成“某人已经获知”，会越过来源没有给出的证据层。

加号确认的对象是服务步骤

TCP 服务在连接建立、消息送入之后，以一个 + 或 回应，后面可附解释。正号意为消息成功投递给某个用户或终端；负号意为没有投递给任何终端。对服务器而言，这是一项可以报告的本地状态。

不过 RFC 接着划出一条不能忽略的线：正向确认可能只表示 Message Send 服务器成功调用了本地消息投递服务，未必能够据此推断真正的端到端语义。文档特意列出几种尚未选定的终点：调用本地服务、由窗口系统显示消息，或者用户通过关闭弹窗确认已阅读。规范没有要求确认对应其中哪一项。

因此，+ 的价值不在于它能证明一切，而在于它能诚实地证明有限的一步。它不能说明窗口是否显示，显示是否持续，收件人是否在终端前，内容是否被注意或理解，更不能说明有任何后续回应。每一个新结论都必须来自真正观测到该结论的组件或人，而不是从一个服务回复中借来。

UDP 的沉默也有自己的含义边界

UDP 版本可以发送回答数据报。若消息指向一个特定用户并且成功投递给该用户，服务应回复正向确认；若消息面向任何用户，或未能投递，则不发送回复。RFC 的理由是避免广播消息触发所有服务器的大量回包。

这意味着沉默不能被机械地翻译为失败：它可能来自服务为控制回包而规定的无回复策略。同样，cookie 与发送者 UDP 端口组合后应当唯一，服务器可以靠它识别重复消息，客户端也可以为提高收到概率而多次发送。这个机制处理的是有限范围内的重复识别；它既不能证明第一份消息被显示，也不能证明某位用户收到，更不能把重发变成端到端完成。

签名字段没有替身份下结论

SIGNATURE 字段也提醒读者不要把形状当成事实。字段为空时，发送者身份无法验证；字段非空时，RFC 只把它称为某种安全令牌的、大小写不敏感的文本编码，而没有定义其编码或解释。文档还要求过滤将被显示的消息文本，以免控制字符或未经允许写终端带来风险。

发送者名字、IP 来源、令牌、调用本地服务、显示文字和人的阅读都是不同的证据对象。RFC 1312 没有把它们捆成一项结论。今天重读它，也不应替它完成这种越权的合并。

小确认的准确性比大承诺更有用

RFC 1312 是实验性文档，不是对当代通知、聊天或告警产品的描述。它留下的历史价值是对“成功”范围的克制命名：本地服务被成功调用，可以成为一条有效记录；显示、注意、阅读和同意必须另有证据。

若所有绿色标记都被叫作“已读”，操作记录会显得完整，却会失去可核查性。让每个标记只代表它观测到的状态，反而能保留系统和人的责任边界。

来源

RFC 1312 是 1992 年的实验性规范；它不证明真实收件人、显示、阅读、同意、身份、部署或结果。