要約

  • 個人Internet-DraftはIANA天体レジストリを提案したが、著者は公開議論で、命名はIAUとMinor Planet Centerを参照すべきだとの指摘を受け入れた。
  • 天文学上の同定、ネットワーク識別子、アドレス割当、経路状態、実際の配送は、それぞれ別の権限と証跡を要する。
  • TIPTOPが必要とするのは天体目録の複製ではなく、由来と版を保つ最小の対応表である。

第01版は、CBID、IAU公式名、天体種別、親天体をIANAに登録し、深宇宙アドレスの階層集約に使う構想を示す。しかしDatatracker上は個人提出のInformational向け草案である。TIPTOP憲章も、この文書の採用やレジストリ設置を決めていない。

9月6日、Erik KlineはRFC 9179がすでにIAUへ命名を委ねていると指摘した。草案著者はIANAに重複した負担を持たせるべきではないと応じた。

Marshall EubanksはMinor Planet Centerも参照先に加えるべきだと述べ、発見タグ、仮符号、確定番号、承認名という異なる段階を説明した。9月7日、著者は第02版にその枠組みを反映する意向を示した。まだ第02版が公開されたわけではない。

同じ物体に変わる名前、変えてはいけない結合

IAUの解説とMPCの仮符号規則は、命名が一回の書き込みではないことを示す。観測が統合されることも、番号だけが先に確定することも、名称に空白や記号が含まれることもある。

最新名称だけをネットワークの主キーにすれば、改名が別宛先に見える。複数の仮符号が統合された後も二つのネットワークIDが残り得る。一方、安定した不透明IDを設けても、ネットワーク側が天体の存在や分類を決める権限を得るわけではない。

必要なのは版付きの結合である。天文機関、永続参照、符号の段階、別名、有効期間、後継関係を保存する。ネットワークIDは独自の安定性規則を持つ。アドレス割当はさらに別の台帳で、割当者、保有者、プレフィックス、世代を記録する。

登録審査は外部事実を作らない

第01版はExpert Reviewを提案する。RFC 8126のExpert Reviewは、専門家が明示された基準で登録を審査する仕組みである。専門家はIAU/MPC参照を確認できるが、軌道を確定したり観測を統合したりはできない。

RFC 9179のastronomical-bodyも、座標を解釈する参照枠を指定する文字列でしかない。IPプレフィックスを割り当てず、宇宙機を認証せず、到達可能性を証明しない。

運用証拠はその先に続く。誰がいつまでプレフィックスを割り当てたか。どの起点が経路を広告し、どの検証を通り、どの経路が選ばれたか。末端はどのミッション資格情報を示したか。パケットは届き、アプリケーションは処理を確定したか。

Heng LuのReality Layersに従えば、名称、登録投影、割当、経路、実装、結果は連結できても代用できない。Minimum Initial Specificationは必要最小限の共通結合を求める。Running-Code Primacyは、正しい行が正しい配送を意味しないことを最後まで残す。

今回の議論は、採用や配備の証拠ではない。それでも設計上の前進である。権限の重複を実装前に外し、どの結合に証拠が必要かを可視化した。深宇宙では訂正の往復にも時間がかかる。だからこそ、読みやすい天体名を無言の運用権限にしてはならない。

情報源

  1. Datatracker：天体レジストリ草案
  2. TIPTOP憲章
  3. Heng Lu：Minimum Initial Specification
  4. Heng Lu：Reality Layers
  5. Heng Lu：Running-Code Primacy
  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：天体参照枠