要約

  • ICANNの2026年8月24日付集約報告は、U+A9B4の特別規則について、許される先行文字をU+A9BAまたはU+A9BBとし、草案のU+A9BCを置き換える訂正を記録した。
  • 誤った組み合わせは説明文だけではなく、4月23日の提案書、HTML、RFC 7940形式のXMLに共通する。XMLの規則名もfollows-A9BA-A9BCである。
  • ICANNはジャワ文字コミュニティーと協議して最終版へ組み込むとしている。9月1日時点の公式ページは2024年10月25日版を現行とし、最終ジャワ文字LGRを掲載していない。
  • 参照LGRはレジストリのIDNテーブル設計とICANNの審査に使われるが、各レジストリのテーブルそのものではない。
  • 投稿、協議結果、正確な差分、最終成果物のハッシュを結ぶ版管理済み受領記録が必要であり、公開と下流採用は別の状態として扱うべきだ。

「誤植」より一段深い場所にある

公開コメントは5月12日に始まり、6月23日に締め切られた。対象はジャワ文字と統一カナダ先住民音節文字の新規参照LGR二件、既存LGRの更新六件だった。関連コメント33件のうち32件が支持し、残る一件がジャワ文字の訂正と規則関係の明確化を求めた。

提案の貢献者であるArif Budiartoは、U+A9B4（JAVANESE VOWEL SIGN TARUNG）が従えるのはU+A9BA（JAVANESE VOWEL SIGN TALING）またはU+A9BB（JAVANESE VOWEL SIGN DIRGA MURE）だと説明した。草案にあるU+A9BC（JAVANESE VOWEL SIGN PEPET）は誤りだという。変更は正書法上の意図を変えるのではなく、その意図を正しく記述するものと位置付けられている。

重要なのは、同じ誤りが三つの表現層にあることだ。40ページの提案書では38ページの規則4がA9BA/A9BCを挙げる。HTMLも同じ条件を表示する。XMLはU+A9B4にfollows-A9BA-A9BCを適用し、クラスへA9BAとA9BCを格納している。したがって訂正対象は解説文だけでなく、機械処理される規則である。

規則3との関係も整理された。規則3は従属母音一般について、子音、中間子音、独立母音の後に置くという条件を定める。規則4はU+A9B4に固有の追加制限を置く。作業部会は最終版で本文、規則参照、補足説明を更新するとした。

A9BCそのものがジャワ文字で無効になるわけではない。草案のレパートリーに残る文字であり、今回の論点はU+A9B4の先行文字になれるかという限定された関係だけだ。

集約報告と最終LGRの間

ICANNの回答は明快である。訂正はジャワ文字コミュニティーと協議し、その後に最終版へ反映する。コメントを検討し必要な修正を行った後、最終参照LGRをSecond-Level Reference LGRページへ掲載する。

この記述は訂正方針の証拠だが、訂正済みXMLの代わりではない。9月1日の確認では、公開ページが示す現行版は2024年10月25日で、スクリプト別一覧にジャワ文字はなかった。公開コメント用の4月版が、引き続きダウンロード可能なジャワ文字パッケージだった。

8日間で最終化されていないことを異常とみなす必要はない。コミュニティー確認、三成果物の同期、XML検証には時間がかかる。避けるべきなのは状態の混同だ。「訂正は受理されたが最終ファイルは未公開」と言えば、ICANNの応答も成果物の現状も損なわない。

ICANNの策定指針もXMLを中心に置く。規則はRFC 7940に従うXMLで表現し、そのXMLが意図されたコードポイントと規則を正確に表すかを審査する。報告書は方針を確定できる。最終バイト列は実装を証明する。

参照したことと採用したことは同じではない

最終参照LGRは、レジストリが国際化ドメイン名のテーブルを設計する際の参考となり、gTLDレジストリから提出されたテーブルをICANNが審査する際にも使われる。影響力のある共通資料だが、レジストリの設定を自動更新する仕組みではない。

共通参照、提出テーブル、ICANNの審査結果、運用中テーブルは別々の記録である。現時点の資料から、4月草案を採用したレジストリ、失敗した登録、壊れたドメイン、セキュリティー事故は確認できない。逆に、最終XMLの公開だけで全レジストリの修正完了を証明することもできない。

訂正を閉じる受領記録

最初の欄には観測対象を置く。4月23日パッケージのXML、HTML、提案書のURLとハッシュ、U+A9B4、規則識別子、A9BA/A9BCという草案条件、投稿者とA9BA/A9BBへの訂正要求である。規則3と規則4の役割も境界情報として残す。

次に権限と手続きを記録する。投稿時刻、コミュニティー協議の状態、ICANNの処置、最終検証を担う機能を明示する。最終XMLで規則名や構造が変わる場合は、単純な文字列比較ではなく意味上の同等性を示す。

公開欄は三成果物を一組にする。版、日時、安定URL、ハッシュに加え、U+A9B4の条件からA9BCを外しA9BBを加えたことを機械可読な差分で示す。許容・不許容例も付ける。旧草案は消さず、後継版を明確に表示する。

レジストリ側は別リンクにする。提出テーブルが参照版を示し、ICANNが審査結果を記録し、運用者が採用状態を持つ。リンクがなければ「公開証拠なし」であり、採用も不採用も推測しない。

Heng Luの最小仕様という考え方なら、共通層は主体、成果物、規則、状態、版、日付、改訂だけを運ぶ。地域・事業者ごとの判断を中央記録が奪う必要はない。

証拠が示さないもの

今回の資料は稼働中DNSの障害報告ではない。公開コメントは最終化前の誤りを見つけるための工程でもある。ICANNが意見を退けたという証拠もなく、集約報告は反映を明言している。

このニュースの意味は、単一の誤りを大事件に見せることではない。発見と処置が追跡可能になった以上、最終成果物まで同じ精度で追跡することにある。

情報源

  1. ICANN — 2026年8月24日付集約報告
  2. ICANN — Additional Reference Label Generation Rules公開コメント
  3. ICANN — Arif Budiartoの提出意見
  4. ICANN — 5月12日パッケージ索引
  5. ICANN — ジャワ文字LGR草案XML
  6. ICANN — ジャワ文字LGR草案HTML
  7. ジャワ文字Generation Panel — 補足提案書
  8. ICANN — Second-Level Reference LGR
  9. ICANN — 参照LGR策定指針
  10. RFC Editor — RFC 7940
  11. Heng Lu — Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption