摘要

  • draft-ietf-regext-balance-03 提议用只读 EPP 查询返回一个或多个财务账户；它仍是工作组 Internet-Draft，不是 RFC，也不是部署证据。
  • 可用余额、现金余额、授信额度、执行限额和通知阈值是五项不同的状态，不能压缩成一个“够不够钱”的灯号。
  • <info> 响应没有资金预留语义。下一条付费指令是否获准，只能由那条指令自己的服务器响应证明。

注册商凌晨批量续费时，最危险的并非余额显示为零，而是系统把一个非零数读成了承诺。屏幕上的 USD 800 可能完全准确；同一时刻，服务器仍可以在 USD 500 的安全垫处停止新的付费指令。这里没有矛盾，只有两个被混为一谈的问题。

草案先把“余额”拆开。Balance Available 等于 Credit Line 加 Cash Balance。Credit Line 由服务器按本地政策汇总有效的信用工具，可以包含普通授信或应急授信；工具到期时，即使现金没有移动，可用余额也会下降。Cash Balance 则记录客户付款以及含费用、税款在内的计费借贷。一项是信用能力，一项是现金账面，它们相加仍不是被冻结的消费额度。

决定未来付费指令何时被禁用的是 Execution Limit。它可以以 Balance Available 为基准，也可以以 Cash Balance 为基准，默认基准是前者。正数限额会让系统在余额用尽前就停止客户发起的付费操作，为自动续费等服务器发起的成本留出空间；负数限额则允许选定指标跌破零后仍继续一定额度。只看正负号，会错过真正的门槛。

Notification Threshold 又是另一条线。选定指标到达或低于该值时，服务器为相应 Balance 放入一次低余额 poll 消息。通知阈值和执行限额必须使用相同基准，却无需数值相等。因此，预警可以早于禁止；收到预警也不证明某条指令已被拒绝，更不证明发票、结算或偿付能力。

修订版 03 新增了同一客户—服务器关系下的多个 Balance。账户可以按顶级域、合同或其他服务器政策命名，也可以使用相同或不同的主币种。此时名称、币种、五项数值和 basedOn 必须作为一个证据单元保存。把三个账户相加，再显示一个“全球总余额”，看似更简单，实际会消除各自的执行政策。

多币种字段也有清晰边界。cashBalanceByCurrency 可以列出原始币种、金额和用于换算成主币种的直接报价汇率；各项换算后的总和必须对应 Cash Balance。这足以解释服务器怎样得到查询时的汇总值，却不构成下一笔交易的锁价、结算汇率或汇率风险保证。

EPP 核心协议已经提供了判断线索。RFC 5730 把查询指令与改变对象状态的转换指令分开，<info> 属于只读查询。Balance 草案定义了 <info> 和低余额 <poll>，没有为 Balance 定义 create、update、renew、delete 或 transfer，也没有定义预留令牌、报价有效期或把一次查询与后续指令原子绑定的条件。

两条消息之间，可能发生并发扣款、退款、存款、提款、信用工具变更或服务器发起的自动收费。后续指令必须得到自己的 EPP 响应。那份响应才说明服务器如何处理了指令；早先的余额查询只能说明服务器在某一协议时刻向已登录客户呈现了什么。

这也是现实层次的区别。余额响应属于表述层，低余额消息属于提醒层，指令响应属于决定层，对象状态、发票与资金结算则属于后续运行和商业层。它们应当串联，却不能彼此替代。

标准状态同样不能越级。修订版 03 于 2026 年 9 月 24 日发布，是 REGEXT 工作组的 Standards Track 意向草案。balance-0.4 命名空间、XML Schema 和 IANA 请求描述了拟议的互操作接口，不证明 IETF 已批准，也不证明任何注册局或注册商已经部署或正确使用。

来源