摘要

  • IANA 注册行证明某个 tel URI 参数名已被协调，并指向公开规范；它不验证具体值，也不授予号码、路由或身份权力。
  • 应把名称空间、规范语义、URI 语法、接收方能力、政策、信令、身份和业务结果分别留证。

名字的权威被误当成数据的权威

一个风控系统看到 tel URI 中的参数名出现在 IANA 表里，于是把参数值标成“可信”。后续系统据此接受路由号码或验证状态。真正被注册的只是词汇及其规范出处，不是这次消息中的事实。

RFC 5341 要求新参数提交名称、是否只接受预定义值，以及永久公开的规范。新增参数值也要给出规范引用。这套机制避免名称碰撞，并让实现者知道应去哪里读取语义。

它没有验证发送者、值的新鲜度或号码控制权。一个合法字段名可以承载格式错误、陈旧、越权或伪造的数据。政策必须继续检查来源、上下文和实际执行。

No Value 不是“没有含义”

RFC 5341 说明，No Value 可以表示旗标，也可以表示没有预定义值集合。当前表中的 enumdi 与 npdi 属于这类。没有等号和值，不代表可随意丢弃。

旗标的“存在”本身就是语法载荷。引用的 RFC 决定它表达什么、何时允许出现、接收方如何处理。注册表并不替旗标声明真实性。若发送边界不可信，存在只能证明有人写了它。

Constrained 同样只是索引。约束细节在规范中。名称注册过的参数仍可能取非法值；合法值也可能不适用于本次号码环境。验证器必须读取引用，而不能把表格的一列当作完整语法。

tel URI 是标识符，不是拨号动作

RFC 3966 把 tel URI 定义为由电话号码标识的资源名称。它不描述如何到达该号码，不暗示具体拨号规则，也不等同于某一台物理设备。终端或网关还要根据本地网络生成拨号序列和信令。

URI 也不决定语音、传真或数据，连接参数需要另行协商。因此，即使每个参数都已注册、每个值都合法，也只能证明一个标识结构通过了语法和语义检查，不能证明呼叫已路由或媒体已建立。

本地号码必须携带 phone-context。这个字段声明号码在哪个范围内唯一，却不证明通信双方配置一致、号码由声明者控制或该范围存在可达路径。

未知必选参数必须显式失败

RFC 3966 规定，接收方遇到自己不理解的必选参数时不得使用该 URI。这使“实现能力”成为独立凭据。IANA 能注册一个新扩展，但不能让所有旧网关自动学会它。

观测系统需要记录解析器版本、参数是否识别、是否必选、值验证结果以及最终处置。只保存“名称存在于 IANA”会把正确拒绝和错误放行混成一个绿灯。

RFC 5341 还要求在缺少这些参数时，基础服务仍应能够调用并正常运行。若厂商把可选扩展改成产品必需条件，那是厂商政策，需要自己承担版本和兼容责任。

活注册表需要时间坐标

2008 年的初始表不是今天表的全部。当前 IANA 表还包含后来加入的 premium-rate、verstat 等项目。只硬编码最初 RFC 的软件会把新注册名称误判为私有扩展。

反过来，用 2026 年表解释旧抓包也会制造历史。今天已注册，不等于当年的发送者、接收者或规范拥有相同语义。审计凭据应冻结查询日期、表内容和引用文档指纹。

“已注册”必须带时态。IANA 的权威体现在协调当前状态及其历史，而不是给一个名称颁发跨时代不变的运行证明。

携号转网与中继组字段仍需来源

RFC 4694 定义 npdi、rn、rn-context、cic 和 cic-context；RFC 4904 定义 tgrp 与 trunk-context。注册保证名字与规范一致，不证明路由号码仍有效、运营商代码获授权、中继组存在或下一跳接受。

RFC 4759 的 enumdi 表达一种处理历史，存在本身不证明 ENUM 查询真的发生。isub-encoding 有统一定义，也不保证对端支持。每个字段仍需发送者、信任边界、时间、验证者和实际决策链。

来源与证据边界

这些来源证明标准、文档历史和 IANA 注册表快照，不证明当前呼叫、号码持有人、来电身份、产品能力、部署、路由、价格或结果。