摘要

  • RFC 1861 没有用一个“成功”包办整条链路，而是分别记录命令受理、设备在线或离线、消息排队、设备送达、用户查看、回复与最终关闭。
  • ACKRead 把实际查看与回复分开；Message_Tag、Pass_Code、MSTAtus 和递增的序列号则让客户端在连接结束后继续追踪状态变化。
  • 这些精细状态并不构成无限权威：RFC 1861 属于 Informational，安全问题未被讨论，部分保存和超时政策由运营者决定，独立协议与复用电子邮件设施之间的争论也没有因发表而消失。

一条专门证明“看过”的回执

RFC 1861 最有分量的设计藏在 ACKRead 这个命令里。启用后，寻呼设备要在用户实际查看收到的消息时返回通知。规范紧接着强调：这项功能独立于真正的回复。

这句话把常被界面压成一格的三个事件重新拆开。无线网络把内容交给设备，是设备层面的事实。用户拿出设备并看见内容，是人的注意力进入了链路。用户随后选择一个答案、输入文字，或保持沉默，又是第三个事件。它们可能相隔几秒，也可能相隔很久；其中任何一步都不能替后一步作证。

在值班告警里，这种区别并非礼节。如果寻呼机被放在外套里，设备可以按时收到消息，而工程师仍不知道故障。若控制台只显示“已送达”，操作者会把继续等待当成合理选择；若它显示“设备已收，等待阅读确认”，同一个操作者就知道人的环节仍然悬空。

RFC 1861 的价值，正在于它不让绿色指示灯替整个现实说话。

两年内长出的返回路径

SNPP 的演进很快。1994 年 1 月发布的 RFC 1568 描述了早期的单向版本；同年 7 月，RFC 1645 以第二版取代它。到 1995 年 10 月，RFC 1861 又使 RFC 1645 过时，并为支持确认和回复的双向设备增加第三级功能。

最初的协议像一层薄适配器，把互联网客户端的简单命令转换给使用 TAP/IXO 的寻呼终端。客户端选定寻呼号码，提交消息，然后发送。内部电话线、旧式控制字符和终端差异可以留在网关之后。

双向寻呼改变的不是字数，而是时间。规范指出，从主机到用户的技术送达和接收确认通常较可预测，但没人能预知用户什么时候会真正掏出设备、读完消息并作答。若为此一直占用电话连接，费用可能失控。互联网的优势不是让人立刻回复，而是允许交易记录在连接结束后继续存在。

因此，第三级交易天然围绕单个设备。2WAY 开始一次双向交易，SEND 发出消息并结束这一发送阶段，客户端日后再用 MSTAtus 查看进展。持续的是可查询的状态，不是假装永远在线的会话。

网关知道的事情很有限

普通的 250 表示服务器成功处理了一条命令。它可以说明号码被接受、消息内容被接收，或某个选项设置成功，却不能说明无线传输已经完成。

在双向模式下，PAGEr 又把下一层拆成三种结果。850 表示设备在线、交易被接受；950 表示设备不在线，但消息会进入稍后投递的队列；750 表示设备离线，交易被拒绝。

这些回复出现在相同位置，却代表不同的行动空间。850 允许继续尝试实时送达；950 要求调用方接受不确定的等待；750 则清楚地告诉调用方这条路径此刻不工作。若把三者都写成“请求成功”，系统没有增加可靠性，只是把失败决定推迟到了用户看不见的地方。

这也是薄协调应有的边界。网关负责报告自己能观察的受理和队列状态。它不因掌握一个入口，就取得替设备、用户或组织宣布结果的权力。

四组代码把未完成保留下来

RFC 1861 按“终局程度”划分双向结果。86x 表示初始消息已经送达，但所请求的动作仍未发生；87x 表示中间处理有了进展，交易仍待关闭；88x 表示最终状态；96x 表示交易正在队列中。

SEND 的首个结果可能是 860：已送达，等待已读确认；也可能是 861：已送达，等待回复；880 表示消息已送达且没有回复待处理；960 则明确承认仍在等待投递。

稍后的 MSTAtus 可以补上新的证据。870 是已送达、已读、仍待回复；881 是已送达并已读；888 携带预设选择的回复；889 携带自由文本。780 记录另一种终局：消息在送达前已经过期。

规范规定，收到 88x 后，所请求的各部分已经处理完毕，状态不再变化。这使“最终”成为可检查的协议条件，而不是产品经理挑选的宣传词。只要状态还在 86x、87x 或 96x，客户端就必须让未完成部分继续可见。

回复通道不制造授权

RTYPe 允许发送者决定可接受的回复形式：不允许回复、是或否、运营商预设的简短答复、针对本条消息配置的多项选择，或完整文本。MCResponse 则提前放入多个候选答案。

这些功能适合有限屏幕和有限输入。值班人员可以迅速回答“正在处理”，而不必在寻呼机上输入整段文字。但速度不改变回复的制度含义。888 能证明某个预置代码沿返回路径到达系统，却不能证明持机者有权代表公司作出承诺。889 能保存文字，也不能自动证明身份、自由意志或法律效力。

协议记录通信事件，组织规则决定事件之后的意义。把这两层分开，既保护发送者免受模糊状态，也保护接收者不被一条技术回执强行塑造成授权主体。

NOQUEUE 让延迟重新成为选择

离线队列常被当作可靠性的同义词，其实它只保证系统愿意继续等待。对会议提醒，延迟几分钟或许无妨；对正在扩散的路由故障，稍后送达可能只留下迟到的证据。

RFC 1861 允许客户端在 PAGEr 之前发送 NOQUEUE。这样，服务器不得为这次双向交易排队；设备不在线时应明确拒绝。发送者由此保留判断消息是否还有时间价值的权力。网关无需理解事故严重性，只需尊重“不接受等待”的选择。

EXPTag 可以改变排队消息的过期时间。超时后，消息被删除，状态也要反映未能送达。默认期限和标签过期细节依赖厂商，这说明共同协议没有替所有运营者决定保存政策。

当最终状态已经读出，或客户端不再需要后续回复，KTAG 可以主动清除标签。证据保存太短，会妨碍排障；保存太久，又会积累阅读时间、回复和位置等敏感信息。协议提供清理动作，但治理期限仍要由负责任的运营主体说明。

标签、口令和变化顺序

双向 SEND 成功后，服务器返回 Message_Tag 与 Pass_Code。规范把前者称为记录定位符，把后者称为用于授权状态查询的随机 PIN。客户端用两者调用 MSTAtus。

记录还包含一个随着状态变化而递增的 Sequence，以及当前日期和时间。它让调用方辨认这是一次新的阅读或回复，而不是重复查看同一条旧状态。序列号证明记录发生了变化，却没有被描述为不可篡改账本，也不证明所有环节拥有完全一致的时间。

更不能把 Pass_Code 想象成完整安全体系。RFC 的安全考虑部分只有一句：本文不讨论安全问题。没有关于口令猜测、加密、强认证、授权范围、日志保护或恢复机制的分析。文章若替这份资料补出强安全承诺，就犯了它反对的同一种错误——让一个局部字段承担源材料没有证明的结论。

在线，不必交出位置

PING 可以查询双向设备的位置或状态。规范承认位置敏感，因此允许用户选择只返回通用结果：设备位于系统中，但不提供位置信息。文档把它称为 ACLU 模式，对应 821 回复。

这个设计把“服务知道位置”和“查询者有权获得位置”分成两件事。系统不必在完全暴露和完全否认之间二选一。有限披露也可以是一条正常、可理解的协议结果。

但 RFC 没有说明用户偏好如何认证、谁能例外访问、底层位置记录如何保存，或争议如何复核。821 限制了接口输出，不等于完成了隐私治理。共同协议只定义一个出口；运营者、合同和适用法律仍要约束数据的保管者。

RFC 编号没有终结架构争论

作者如实记录了审查中的反对意见。IETF 工作组和三位 IESG 成员认为，已有电子邮件基础设施覆盖广泛，再部署一套协议成本很高。有些审查者认为，通过谨慎配置客户端与服务器，电子邮件也能做到“立即送达，否则失败”；另一些人愿意接受寻呼专用协商，但更倾向把它做成 SMTP 扩展。

作者则认为，独立 SNPP 可以把 TAP/IXO 及其后继技术的细节隔离起来。邮件到寻呼的网关仍然可以存在，却不必让每个用户或邮件系统直接背负寻呼终端的复杂性。

RFC Editor 的 RFC 1861 信息页 将其列为 Informational。发表使提案获得稳定引用和公开检验，并没有证明所有人采用它，更没有把一场工程取舍变成强制命令。

可信记录靠收窄，而不是膨胀

这份规范里没有任何一个观察者拥有完整现实。网关知道命令是否处理；寻呼服务知道是否排队和发射；设备可以报告接收与查看；返回通道携带选择或文字；客户端把若干状态串成时间线。

可信度来自这些边界没有被抹平。消息可以同时“已经送到设备”和“仍未被人阅读”，两句话都正确。客户端可以知道用户看过，却仍然承认答复尚未出现。一个过期状态也可以比含糊的成功更有用，因为它让调用方及时结束等待。

RFC 1861 没有为所有系统提供治理制度，却给出了一种检验方法：这张回执由谁观察，发生在哪个表面，还有哪些状态开放，谁能修改记录，谁承担误报的损失？只要问题被保留，账本就是协调工具；一旦中间记录冒充人的行动、授权或结果，它就开始追求自己没有资格拥有的权力。

来源