要約

  • draft-ietf-mediaman-6838bis-10は2026年9月9日UTCに利用可能になった。Media Type Maintenanceワーキンググループの現行draftであり、RFCでもIANA更新の完了記録でもない。
  • 09版は、実行時にfragment解決が成功するかどうかで優先規則を選んでいた。10版は、接尾辞が実際に定義する構文との整合性を要求し、定義がなければ個別のmedia typeに判断を戻す。
  • 10版はIANAの13登録を名指しする。どの登録にも三つの処理場合分けがある一方、接尾辞のfragment構文は未定義だと書かれており、その分岐は成立しない。
  • 最終規則の承認と13件の更新は別の状態遷移だ。私は全対象の変更前後を結ぶ修正manifestを提案する。これはDaniel Kadeの編集提案で、draft本文の要件ではない。

「成功したら採用」は規則を選ぶ条件にならない

issue 93が問題にしたのは、fragmentの意味そのものより判断順序だった。09版では、structured syntax suffixの規則でfragmentを解決できた場合はその規則を使い、できなければ個別のmedia typeに従う。しかし成功を判定するには、先にどちらかの規則を試さなければならない。

10版はこの実行結果依存を外した。接尾辞登録がfragmentの構文と意味を定める場合、利用するmedia typeはそれと整合し、接尾辞が要求する構文を禁止してはならない。接尾辞側に定義がなければmedia typeが定める。公式diffを見れば、二段階の試行から仕様間の静的な制約へ移ったことが分かる。

同時に新設されたIANA Considerationsは、+json、+ber、+cbor、+der、+fastinfoset、+wbxml、+zip、+tlv、+json-seq、+sqlite3、+jwt、+gzip、+cbor-seqを列挙する。RFC 6839以来の三場合分けが各登録へコピーされたが、13件はいずれも接尾辞用のfragment構文が存在しないと記録している。10版は、その三段落だけを除き、残りを保持するようIANAに求める。

変更対象は文章ではなく公開状態

執筆前に確認したIANAのStructured Syntax Suffixes登録簿は、最終更新日が2026年6月25日で、24件、Expert Review、2人のdesignated expertを示していた。名指しされた13件を機械的に確認すると、すべてに三つのcaseと未定義の記述が併存していた。まだ修正されていないのは自然である。10版は作業中であり、将来のIANA処理を完了させる効力を単独では持たない。

責任主体も区別が要る。Media Type MaintenanceはRFC 6838を置き換え得る文書を作る。IANAは登録を運用する。designated expertは登録方針とRFC 8126に沿って審査し、IESGはIETFが設けた登録簿のexpertを管理する。ワーキンググループのPR 108がmergeされた事実は、公開13行の更新時刻にはならない。

手続状態も確定と誤読してはいけない。draft本文はBest Current Practiceを予定状態として掲げるが、現在のDatatracker metadataはIntended RFC statusをNoneと表示する。In WG Last Callは10版で始まったのではなく、2025年10月の06版から続く。RFC化、IESG承認、IANA実施のどれもまだ確認できない。

共通の末尾は共通の意味を保証しない

structured suffixは、汎用処理系に基礎形式の手掛かりを与える。だが、+jsonや+zipで終わる全media typeのfragmentや安全性が同じだという保証ではない。10版は、接尾辞付きのtypeと接尾辞を外したtypeの関係を名前だけで判断できないと明記する。個別typeの規則が残る理由はここにある。

したがって、三分岐の削除は矛盾した共通案内を直すだけだ。13接尾辞に新しいfragment構文を作らず、実装を更新せず、相互運用性や既知の障害を証明しない。RFC 3986もURI fragmentの一般的枠組みを示すもので、全形式の意味を一括決定する文書ではない。

10版はRFC 9694も取り込み、承認されればRFC 6838とRFC 9694をobsoleteする。その統合予定と、13行が現在どうなっているかは別の証拠で扱うべきだ。

13対のbefore/afterを残す

必要なmanifestは大規模な監査報告でなくてよい。最終公開文書と節、hash、閉じた対象一覧、各登録の安定した識別子と変更前hash、削除を許された文種、保持対象のhashを記す。実施時にはIANAの処理と時刻、実際に使われたexpertまたはIESGのdisposition、各変更後hash、訂正や復元の参照を足す。

これなら新しい承認者を置かず、非公開の議論も開示しない。個別media typeのfragment設計にも介入しない。共通の修正が13の到達点へ過不足なく届いたかだけを検証できる。

Heng LuのMinimum Initial Specificationが示す考え方とも一致する。協調に必要な最小の証拠だけを共通化し、局所の仕様判断はそれぞれの所有者に残す。

確認できる範囲

Datatrackerの文書ページと履歴は版と状態を示す。merge commitは執筆上の取り込みを示す。どれも将来の標準化結果やIANAの実行を保証しない。

出典