摘要

  • draft-ietf-regext-balance-02 让已登录的 EPP 客户端能够查询可用余额、现金余额、信用额度，以及可选的执行下限和通知阈值。
  • 返回值足以驱动自动化，却不包含逐笔账目、余额时点、汇率来源与采样时间、政策版本或已预留义务，因此不能独立证明余额如何形成。
  • 一旦余额参与决定某笔收费命令能否执行，注册局与注册商就需要另存一份“资金状态凭证”，把当时的计算、规则、会话和命令结果锁在同一证据链中；这不是要求 EPP 承担完整会计功能。

设想一个常见场景：注册商在节日前启动批量续费，先通过 EPP 查询余额。服务器给出正数，第一批命令成功，随后一笔却因资金条件未被接受。运维手里有 clTRID 和 svTRID，财务手里有内部账簿，客服手里或许还有一张余额截图。三份记录放在一起，仍未必能回答关键问题：拒绝发生时，究竟是哪一组扣款、预留、汇率和阈值在起作用？

这不是简单的算术错误，而是操作协议与后台会计系统之间的一条制度边界。

REGEXT 工作组的余额映射试图把边界的一侧标准化。2026 年 8 月 14 日发布的第 02 版草案，允许当前已登录的客户端通过 EPP 获取自身资金状态。它是拟进入标准轨道的工作组 Internet-Draft，尚不是 RFC；文件的存在也不能证明任何特定注册局已经部署。

标准化查询很有价值。注册商不应为了判断预付资金或信用空间，只能登录各不相同的门户、解析邮件提醒或维护私有接口。可是，把数字搬进标准协议，并不会自动把数字背后的解释也标准化。

“可用”是一种操作能力，不是一张对账单

草案把 balanceAvailable 定义为 creditLine + cashBalance。现金余额是服务器运营方代客户持有的资金，信用额度是运营方允许客户使用的授信。收费记为负数，退款和入金记为正数，提款则再次记为负数。

这种定义比含混的“账户余额”严谨。它还明确区分了可用余额与未偿余额：后者回答客户欠款多少，是另一个会计概念，并未进入当前映射。

但 XML 结构不会列出组成现金余额的每笔注册、续费、退款、入金、提款或调整。它没有明确的“截至何时”，没有结算期标识，也不说明争议款项是否仍被计入、尚未入账的活动是否已经占用额度。客户端可以验证服务器此刻声称了什么，却不能只靠这次响应重算出同一个结果。

如果余额只是仪表盘上的提醒，这种局限容易接受。一旦它成为创建、转移或续费等收费活动的门槛，它就进入了注册商业务的控制面。控制面上的结果可以保持简洁，但不应失去可追溯性。

真正的边界由执行下限移动

可选字段 executionLimit 规定了服务器可以拒绝收费客户端交易的下限。默认值是 0.00，但草案特意允许正值和负值。

正数下限意味着零以上也要留出缓冲。草案给出的理由包括服务器主动触发的交易，例如自动续费。注册商即使看到可用余额为正，也可能不能把它全部花在新的客户端命令上，因为注册局要保护未来无需新请求就可能产生的义务。

负数下限则反过来扩大可操作空间：可用余额跌破零以后，客户端仍能继续提交一定范围的收费交易。于是，一笔命令的经济含义不能只从 balanceAvailable 读取，还要同时考虑执行下限和拟执行交易的价格。

响应公开当前下限，却不公开产生下限的政策。谁批准了缓冲？何时更改？自动续费敞口如何估算？不同产品是否适用不同规则？事故期间的临时例外什么时候失效？这些都不在映射中。

查询成功也不是后续命令的资金预留，更不是授权令牌。另一条会话可能先消耗资金，后台状态可能更新，产品规则或非财务政策也可能导致拒绝。余额响应只是决策输入，不是对未来结果的承诺。

低余额消息证明进入队列，不证明完成对账

可选的 notificationThreshold 会在相关金额跨越阈值时生成一条低余额消息。它的 basedOn 属性必须与执行下限采用同一计算基础，避免通知依据现金余额、实际阻断却依据可用余额的隐性错位。

通知沿用 EPP 的轮询队列。基础协议为消息提供入队日期与消息标识，命令和响应还带有客户端、服务器交易标识。客户端再通过常规 poll 流程确认收到。草案选择在越过阈值时产生一次消息，而不是在每次查询时反复报警。

这有利于控制噪声，却不是财务核对。确认消息只能说明 EPP 客户端处理了队列项，不能证明财务人员理解了告警、资金已经补足、注册商认可账目，或者同一个阈值在后来的拒绝时仍然有效。

“送达”“知悉”“同意”“纠正”是四件事。系统若把它们压成一个已通知状态，就会在争议出现时高估轮询记录的证明力。

多币种展示了公式，却隐藏了汇率的来历

草案允许把现金余额拆成多个币种组成项。每一项可包含币种、金额、换算率，以及折算到参考币种后的数值；这些折算值之和必须等于 cashBalance。它使用直接标价法：组成币种的一单位金额乘以汇率，得到参考币种金额。

因此，注册商能够检查响应内部的加总是否成立。ISO 4217 代码也让计价单位不至于混淆。但响应没有说明汇率提供者、行情采样时刻、舍入政策版本，或数据源中断时采用了什么备用值；整个余额也没有明确的“截至”时间。

当资金远高于执行下限时，这些缺口可能不影响操作。接近门槛时，微小的折算差异就可能决定一批续费能否通过。此时，汇率基础设施已成为域名操作的隐性依赖，却没有在协议响应中留下足以质疑和复算的来源链。

解决办法不是把 EPP 改造成外汇平台，而是在协议之外保留那次计算真正使用的汇率来源与时间。单位标准化解决的是互操作，来源记录解决的是问责，两者不能互相替代。

保密要求让证据分散在不同主体手中

草案把余额视为机密信息，并要求访问控制只允许当前登录客户端查询。这一限制十分必要：一家注册商的现金、授信和预警线不应被竞争者读取。

问题在于，事故复盘所需的证据往往因此分散。代运营服务商掌握 EPP 会话，却不拥有资金；注册商财务能看到账项，却不掌握命令顺序；注册局理解阈值规则，却不能随意披露完整后台账本。每一方都只有真相的一部分。

扩大公开范围不是答案。更合理的是设计一份窄而完整的凭证，只让有权的合同双方读取：它比账本泄露得少，却比余额截图证明得多。

给真正影响命令的资金状态留一张凭证

我建议：当余额规则实质性地警告、允许或拒绝一笔收费 EPP 命令时，应生成资金状态凭证。这是治理层面的编辑建议，不是 Internet-Draft 已规定的义务。

第一组字段绑定身份与响应：已认证客户端、会话或安全上下文、余额查询的 clTRID 与 svTRID、读取时间、参考币种、可用余额、现金余额、信用额度、执行下限与通知阈值。若有多个币种，还要保存每项金额、实际汇率、汇率来源、采样时间和舍入规则。

第二组字段指向协议没有携带的计算依据：不可变账本快照或对账单引用、具有实质影响的待处理借贷项、自动续费预留、政策版本和临时例外。它不必复制每笔商业明细；受控引用或哈希即可证明后台记录后来没有被悄然替换。

第三组字段绑定实际命令：对象类别、计价或费用引用、请求时间、决定时间、结果、EPP 结果码，以及命令的客户端和服务器交易标识。如果拒绝来自非财务规则，就明确写出。如果查询后余额发生变化，则同时保留前后状态，不能让新值覆盖旧值。

这样，“资金不足”就从无法质疑的系统结论变成可以检验的事件链。双方能够判断差异源于并发、折算、预留、入账延迟、政策变更，还是根本与余额无关。

让协议保持克制，让机构保留记忆

这项映射刻意只提供查询，没有为 EPP 的 check、create、delete、renew、transfer 或 update 定义余额专用行为。这种克制是优点：不同注册局的计费模式差异很大，完整发票与通用预留引擎不应被硬塞进供应协议。

真正的风险不是 XML 少了一个字段，而是标准字段被普遍使用后，客服、自动化和客户都把它当成唯一事实，同时后台丢弃了让它成立的条件。界面越统一，规则差异反而越不容易被看见。

第 02 版已经把中心概念从 balance 改名为 balance available，增加了 basedOn，并把命名空间更新到 0.3。名称变化很重要：“可用”承认这是受条件约束的操作能力。下一步治理不是继续美化数字，而是保留当时真正行使控制权的那些条件。

来源