要約

  • RFC 9694 では、新しいトップレベル・メディアタイプは Standards Action であり、明確な所属境界、subtype 横断の安全性分析、少なくとも一つの実在 subtype を必要とする。
  • スラッシュ左側の名前は type/* の汎用 dispatch、既定アイコン、アプリ選択に影響するため、IANA の表に一行を追加するだけの作業ではない。
  • 定義、登録、subtype、生成側の送出、中継での保持、厳密な解析、fallback、内容検証、ローカル認可、観測結果には別々の証拠が要る。

正しいアイコンが示すのは表示規則だけ

あるファイル管理ソフトが haptics/hjif を知らず、haptics/* だけを知っているとする。触覚メディアらしいアイコンを表示し、広い形式を扱う候補アプリを起動できるかもしれない。しかし正確な subtype はまだ理解されず、payload は検証されず、機器に物理的効果を出す許可も与えられていない。それでもトップレベル名は既に dispatch と利用者の期待を変えている。

このため RFC 9694 は、新しい左側の名前を例外的な判断と位置づける。2025年3月に BCP 13 として発行され、媒体タイプ登録の一般手続きである RFC 6838 を更新した。多くの新形式は既存の型の下に置ける。より適切な分類がない離散データには application が残る。新しいトップレベル分類は分類学上の飾りではなく、producer、gateway、OS、library、user agent に新しい家族境界を認識させる要求である。

RFC 9694 が要求するのは、もっともらしい名称だけではない。Standards Track RFC による定義、IANA Considerations での登録要求、何がその型に属し何が属さないかの明確な基準、将来の全 subtype または相当数に共通する security considerations、そして少なくとも一つの subtype が必要になる。空の分類には運用上の役割がない。

IANA Top-Level Media Types registry は、その希少性を可視化する。手続きは Standards Action であり、RFC 2046 の初期 MIME 群に加え、model、example、font、haptics が並ぶ。この一覧は名称と定義RFCの存在を証明する。特定producerが正しい値を送ることや、特定consumerが安全に扱うことは証明しない。

境界は実際の形式で試される

トップレベル分類は、複数の subtype にわたって持続的な意味を予測できて初めて有用になる。明確な基準は、専門家が新しい形式の所属と登録内容を判断する助けになる。境界を説明できないなら、その曖昧さ自体がトップレベル化に不向きである強い兆候だと RFC 9694 は見る。

同文書は安易な近道も退ける。他の登録空間を複製するポインタ、拡張子や URI scheme の逆引き、programming language や ontology の型体系をそのまま移す用途には使えない。既存形式の alias を量産すべきでもなく、X- 接頭辞で私的実験を正式分類に変えることもできない。共有名前空間を、単一製品だけに通じる便利なラベルから守るためである。

非公式利用の広がりは需要の手掛かりにはなるが、標準手続きを省略する理由にはならない。逆に、実在する subtype の圧力がないまま抽象分類だけを作っても必要性は示せない。そこで RFC 9694 は、定義文書に初期 subtype 登録を含め、具体的形式で境界を検査できるよう勧める。

並行して進んだ haptics は実例である。RFC 9695 が家族を定義し、現在の IANA Media Types registry には haptics/ivs、haptics/hjif、haptics/hmpg がある。これは標準と登録の証拠だが、mail client、browser、共同作業サービス、content gateway、物理デバイスの対応を意味しない。RFC 9993 が haptics/hmpg を RTP で扱っても、全環境への導入が証明されたわけではない。

汎用 dispatch は失敗も広げる

RFC 9694 によれば、media type の主機能はデータ形式を application code に振り分けることだ。通常は完全な type/subtype と必要な parameter を使う。トップレベル名は、広い形式群を扱うアプリへの暫定 fallback として使われることがある。画像、音声、動画では既に見られ、HTML要素や既定アイコンの選択にも影響する。

ここに証拠の罠がある。正しいアイコンは表示規則が動いたことしか示さない。アプリ起動は候補が選ばれたことしか示さない。subtype の対応、parameter の尊重、宣言とbytesの一致、active content の隔離、利用者の意図は別問題である。しかもRFC 9694は、media type宣言が攻撃者に制御され得ると明記する。

安全な順序は、完全な型とparameterを保持し、subtypeの登録定義を確認し、protocol固有の制約とcontent validationを適用し、この場面で汎用fallbackを許すか判断し、rendering・execution・物理出力をlocal policyの後ろに置き、最後に実際の結果を記録することだ。content sniffing が不一致を見つけても、宣言を黙って別の推定へ置換すれば新しい権限の曖昧さを生む。

導入には十枚の受領証が要る

導入判断では、Standards Track 定義、IANAトップレベル登録、subtype登録、producer送出、中継保持、parserの厳密認識、汎用fallback、内容検証、renderingまたはexecutionのlocal認可、観測された結果を分離すべきだ。一段が真でも、次段は偽になり得る。

費用も段ごとに分散する。提案者は分類の一貫性を得るが、producerは移行とtestを負担する。intermediaryは値を変更または破棄し得る。consumer vendorは汎用handlerを維持するか決める。security teamには新しい分類境界が増え、support teamには「アイコンは正しいのに開けない」という問題が来る。名称を定義する組織が全実装を運用するわけではないため、標準の成功と導入の失敗は両立する。

RFC 8126 は高審査の登録変更に使う Standards Action を説明する。IETF Datatracker と RFC Editorの情報記録 は文書状態と履歴の証拠だが、利用調査ではない。導入にはproducer設定、protocol trace、中継test、handler inventory、validation結果、実際の振る舞いが要る。

Lu Heng の最小初期仕様は、相互運用に本当に必要な共通部分だけを中央化し、その後の判断をoperatorと実装の近くに残すという、明示された編集上の視点としてのみ用いる。IETF要件でも導入証拠でもない。RFC 9694が正当化する共有分類と、その後のlocal decisionを混同しないための補助線である。

情報源