要約

  • RFC 3023 は、異なる media type が固有の名前を保ったまま、共通の XML 表現を +xml で知らせる規約を導入した。
  • suffix が示すのは汎用処理の可能性までであり、語彙の意味、妥当性、安全性、権限、実行結果は別々に確認する必要があった。

2001年の XML は、一つの文書形式ではなく、多数の言語を作るための基盤になっていた。商取引 message、vector graphic、設定文書は同じ木構造を使えても、受け手に求める動作は違う。すべてを application/xml と呼べば構文は分かるが用途が消える。すべてに不透明な名前を与えれば用途は残るが、editor や検索 tool は共通構造を発見できない。

RFC 3023 は名前の末尾に小さな接合部を置いた。固有 subtype の後ろに +xml を付ける。左側は文書種別を、右側は底層表現を伝える。

固有処理と汎用処理を同じ名前に共存させる

application/foo+xml を理解する application は foo の規則を使う。foo は知らなくても XML を扱える tool は、最後の四文字を検出して、解析、整形、検索などの汎用処理が適切か判断できる。

これにより、新しい XML vocabulary が増えるたびに tool の一覧を更新する必要が減った。RFC は parameter 案も退けた。MIME parameter は subtype の修飾であり、既存 dispatcher は parameter で配送先を選ぶことが少なかった。新しい top-level type は変更範囲が大きすぎた。suffix は共有すべき最小事実だけを運んだ。

ただし、application/foo と application/foo+xml は別 media type である。XML を知らない processor にとって suffix は不透明で、存在だけから追加の意味を与えてはならない。XML 版では構文だけでなく意味も変わり得る。一方への対応は他方への対応証明にならない。

Parse 成功は語彙を承認しない

受信 header は送り手の主張である。XML parser を動かし、byte が実際に XML を構成して初めて、次の層へ進める。それでも namespace を理解したこと、schema や profile に適合したこと、署名が有効なこと、署名者が操作権限を持つことは証明されない。

delete という element が tree に現れても、削除権限は生まれない。application が意味を定義し、policy が主体を認可し、実行系が処理し、観測記録が結果を確認する必要がある。外部 entity の解決、network access、stylesheet 実行、無制限の資源消費も suffix から許可されない。すべて local control である。

共有構文を再利用できるのは、共有していない意味まで推測しないからである。

規約は登録制度へ成長した

RFC 6838 は structured syntax suffix を media type 登録制度に組み込んだ。最後の plus より後ろが登録済みの共通構文を示す。RFC 6839 は +xml を正式登録し、正確な type が固有 semantics を担い、固有知識が不要な場面だけ suffix が底層表現の汎用処理を可能にすると整理した。

RFC 7303 は RFC 3023 を置き換えたが、この分離を維持した。汎用 XML 処理が不適切でない限り、新しい XML-based type は +xml を使う。receiver は suffix を検出し、parser で主張を検証してから処理を選べる。表示、編集、安全性、runtime、fragment の規則は固有 type に残る。

現在の IANA registry では +xml 自体が一つの suffix として登録され、多数の異なる media type がそれを使う。共通の末尾は表現上の親族関係を示すだけで、交換可能性は示さない。

出典

Lu Heng は RFC 3023 の著者でも承認者でもない。ここでは分析 lens を明示して利用している。