摘要

  • 1994 年 10 月发表的 RFC 1703 规定了互联网邮件向无线寻呼服务器交付消息的办法。RCPT 和 DATA 都得到肯定答复时，答复所证明的事情仍取决于前面使用的 MAIL、SEND、SOML 或 SAML。
  • 当客户端与寻呼服务器直接建立单跳 SMTP 连接，并使用 SEND 或 SAML，RFC 所说的肯定答复才可确认消息已在无线寻呼网上发出。这个确认止于无线网络的发送动作。

“已收到”是从哪一道门传出来的

寻呼服务卖的是时机。医生值班、维修人员接警、记者等回电，差几分钟就可能换了整个场景。电子邮件的长处却是耐心：一个服务器先收下，放进队列，随后交给另一个服务器。两套节奏接在一起，最需要解释的反倒是平平无奇的成功代码。接收消息的机器，究竟完成了哪一步？

RFC 1703 给无线寻呼服务器划了清楚的最低要求：必须支持 MAIL，可以选择支持 SEND、SOML、SAML。Rose 把肯定答复的含义系在 RCPT 与 DATA 两个命令均成功之上。用 MAIL 时，最低承诺是消息已经排队，等待送入无线寻呼网。队列里有一条记录，也有尚未走完的路。操作者若把这张排队收据当作无线发射记录，就会过早合上事故单。

换用 SEND，同样的一对成功答复表示无线寻呼网已经接收消息，准备交付给收件人。SOML 和 SAML 的措辞则更小心：肯定答复可能意味着网络已接收。四个命令印在同一份 SMTP 家谱上，发给人的承诺却各不相同。成功码本身不会朗读上下文；客户端发出的动词替它补上了宾语。

寻址也有一套机关。电话号码变成 tpc.int 下的 DNS 标签，MX 记录把邮件带向愿意尝试该寻呼服务的服务器。通配 MX 能覆盖一段号码，却不保证其中每个号码都有可达的寻呼机。这一思路沿用 RFC 1530 所述的 TPC.INT 原则。地址解决“去哪里敲门”，RFC 1703 的主角是开门以后那句 OK 到底值多少钱。

设备能力还给消息内容设了边界。pager-numeric 要求正文全是数字；pager. 与 pager-alpha. 面向字母数字寻呼服务。邮件地址长得像邮箱，终端却不会因此平白多出一块键盘。网关必须把邮件请求翻译成无线网络能处理的任务，然后才谈得上确认任务走到了哪一步。

更棘手的是路程。普通邮件可以经过若干中继和网关，每一站都可能存储后再转发。Rose 写到，这种绕行可能多耗几分钟、几小时，甚至几天。对催人赶来的寻呼消息，这简直是让快递员先参加三次接力赛。RFC 建议客户端直接通过 IP/SMTP 连上无线寻呼服务器，只留一个 SMTP 跳点；中间邮件中继的等待由此从提交流程里消失。

第 3.4 节把直连和命令合在一起。SEND 或 SAML 明确要求实时无线发送，服务器需要回答这次发送成功还是失败。若客户端直连服务器并使用其中一个命令，服务器的肯定答复就能保证消息已在无线寻呼网上发出。这个句子停在无线网络。它没有替寻呼机屏幕、持机人的耳朵或人的行动编造一张回执。

RFC 1703 的妙处，是让一个看似单调的 OK 带上工序名称。排队、入网、发射，各有各的时钟，也各有各的责任人。客户端选命令、选路线；服务器按实际完成的工作回答。互联网终于可以替寻呼机传话，而不把邮件系统的礼貌误当成无线电已经开口。