摘要

  • 一份个人 Internet-Draft 提议由 IANA 建立天体注册表；作者随后在公开邮件中接受了天文命名应继续引用 IAU 与 Minor Planet Center 的意见。
  • 这次修正揭示的并非简单归属问题：天体身份、稳定网络标识、地址分配、路由状态和实际送达是五类不同证据。
  • TIPTOP 可以定义最小、可版本化的映射，但不能让名字、草案或注册表行自动取得下一层权威。

事情从一份五页草案开始。第 01 版提出建立 IANA Celestial Bodies Registry，记录 CBID、IAU 正式名称、天体类型和母体，用于深空地址的层级聚合。

它目前只是提案。Datatracker将其标为个人提交，预期状态为 Informational。TIPTOP 章程授权工作组研究深空环境中的 IP 架构、QUIC、安全与 DNS，但没有把这份草案变成工作组文件，更没有创建 IANA 注册表。

9 月 6 日，Erik Kline 指出，RFC 9179 已经把 astronomical-body 的命名来源交给 IAU，IANA 是否还有必要复制这项工作？草案作者 Alejandro Acosta 随即同意：IANA 不应承担已经由别的权威维护的天体分类负担，下一版会删去多余设计。

随后，Marshall Eubanks 补上 Minor Planet Center，并解释小天体可能先有发现标签，再有临时编号、永久编号和获批名称。不同临时编号还可能在轨道数据改善后被认定为同一个物体。9 月 7 日，作者 表示会把 IAU/MPC 框架写入计划中的第 02 版。这是一项公开编辑意向，不是已经存在的新版本。

网络需要的是谱系，不是最新显示名

IAU 的命名说明与 MPC 的临时编号规范共同表明，天体身份会经过多个阶段。编号与名称不必同时出现；分类可能变化；名称可能含有空格、撇号等对天文界合法、对软件解析器棘手的字符。

如果网络系统只复制当前名称，改名会像出现了新目的地；两个临时编号合并时，旧系统可能留下两个网络身份。反过来，一个稳定的网络标识也不能决定天体的名称、轨道或分类。

最小公共对象应是一张带版本的交叉映射：天文权威及其持久记录、命名阶段、别名、有效期与取代关系；网络标识及其稳定规则；在映射之外，再记录地址或前缀的分配机构、持有人与生效世代。

Expert Review 只能审记录，不能创造天文事实

草案第 01 版提出 Expert Review。RFC 8126对它的定义是：指定专家依据公开标准审核注册申请。专家可以检查申请是否引用正确的 IAU/MPC 记录，却不能替 MPC 合并观测、替 IAU 命名，或因为一个网络前缀很有用就确认某个天体存在。

RFC 9179的边界同样清楚：astronomical-body 是坐标参考系的一部分。它说明坐标围绕哪个天体解释，不分配 IP 地址，不认证航天器，也不证明到该天体存在路由。

因此，证据链必须继续向下。地址分配要有授权者、持有人、前缀、有效期和转移史；路由要有起源、验证状态和实际选择路径；终端还需独立的设备或任务凭据；最后才是包到达、应用提交和任务结果。

层级聚合可以缩短路由表，却不能回答“谁有权使用这个前缀”，更不能回答“指令是否到达了正确设备”。真实环境甚至可能出现正确名称、正确映射、正确分配与错误路由同时成立。

Heng Lu 的现实层分离要求名称、注册投影、分配、协议状态、运行代码与结果各自留证。最小初始规范支持只协调必要字段，不复制外部权威。运行代码优先则规定最终边界：注册表再准确，也不能代替实际路径和送达记录。

这次公开修正的价值正在于它发生得足够早。它没有证明深空地址体系已经成熟，却及时拆掉了一项重复权威，并把真正需要设计的连接暴露出来。通信距离越远，纠错窗口越少，越不能让一个好记的名字默默承担全部控制权。

来源

  1. Datatracker：天体注册表草案
  2. TIPTOP 章程
  3. Heng Lu：最小初始规范
  4. Heng Lu：现实层
  5. Heng Lu：运行代码优先
  6. IAU：天体命名
  7. Erik Kline：已有 IAU 引用
  8. Alejandro Acosta：移除多余 IANA 负担
  9. Marshall Eubanks：IAU/MPC 命名阶段
  10. Alejandro Acosta：第 02 版编辑计划
  11. 个人 Internet-Draft 第 01 版
  12. Minor Planet Center：临时编号
  13. RFC 8126：IANA 注册政策
  14. RFC 9179：天体参考系