要約

  • RFC 1874 は、SGML ソフトがなくても人が一般的な内容を理解できるものを text/sgml、それ以外を application/sgml とした。これは縮退時の扱いであり、内容が受動的だという認定ではない。
  • charset、SGML-bctf、SGML-boot は、文字表示、ビット組合せの変換、別の MIME 部品にある起動写像をそれぞれ扱った。一つの認識は次の成功を保証しない。
  • RFC は SGML システムがシステムレベルの命令を許し得ると警告した。後の XML 用メディアタイプは、同じ構文系統でも実装能力やエンティティの役割は共有されないことを示した。

まず、解釈できない受信者を設計に入れた

text/sgml の中心にいたのは、高機能な SGML 処理系ではない。それを持たない受信者だった。RFC 1874 は、専用表示ソフトなしでも内容を容易に読み取れる場合にだけ text を選ぶよう求めた。SGML のレコード開始・終了で区切られた一レコードは、MIME 本文の一行に対応した。

この条件により、未知の構造を普通の文字列として見せる最低限の経路が残った。タグの階層、外部エンティティ、組版上の関係まで再現するとは言っていない。人は大意を得られても、送信者が設計した文書状態を得たとは限らない。

専用処理がなければ意味を失うものは application/sgml に置かれた。二つのタイプは内容の価値を上下に分けたのではなく、失敗したときに許容できる残り方を分けた。

RFC 2046 が説明した MIME の上位型も同じ思想を持つ。未知の text サブタイプなら生データを見せる判断があり得るが、未知の画像や音声では同じ扱いは適切でない。上位型は、詳細を知らないソフトの振る舞いを限定する。

したがって text は、解析成功の印ではなく、解析しない場合の約束だった。

オクテットから宣言までには別の橋があった

charset は、SGML を知らない MIME ソフトが文字を表示する助けになった。SGML 処理系が参照する SGML-bctf は別の層を扱う。SGML の定幅「ビット組合せ」を、伝送されるオクテット列へどう変換したかを示した。

既定値の identity のほか、固定幅や可変長の方式が列挙された。受信側がタイプ名を知っていても、指定方式を実装しているとは限らない。変換後に文字が出ても、SGML 宣言が前提にした番号体系と一致するかは別に確認しなければならない。

SGML-boot はさらに間接的だった。値は起動データそのものではなく、別の application/octet-stream 部品の Content-ID である。その部品にある正整数の三つ組が、宣言を読むための文字番号対応を与えた。対象は文書エンティティに限られた。

参照を書けたことは、参照先を受け取ったことではない。部品の欠落、重複 ID、multipart 構造の破壊、三つ組の誤読、宣言の不成立がその後に残る。RFC 1590 による登録は名前と仕様を公開したが、個々のパッケージの完全性までは審査しなかった。

表示の成功から実行権限は生まれない

RFC 1874 のセキュリティ節は、SGML が受信システムで解析・処理されることを前提にした。実装によっては明示的なシステム命令を許し、表示や組版の処理命令も PostScript に似た危険を持ち得るとした。

ここで text という語を安全分類として読めば、証拠が一段飛ぶ。普通のビューアが行を表示したことは、その行を SGML エンジンへ渡す許可ではない。SGML エンジンが構文木を作れたことも、命令実行や外部参照を許す理由ではない。

受信記録には、MIME ヘッダーの受理、BCTF 変換、boot 部品の解決、宣言の解析、処理命令の判定、アプリケーション出力を別々に残す必要がある。「開けた」という一語では、どこまで権限が使われたか分からない。

未知の MIME パラメータを無視する規則も二面性を持った。古いソフトは新拡張に遭遇しても配送を続けられる。しかし、SGML-boot を無視した文書が正確に再現されるとは限らない。外側の互換性は内側の忠実性ではない。

XML は「SGML の一部」を実装一覧とは読まなかった

XML が SGML のサブセットなら SGML のタイプで十分、という推論は自然に見える。RFC 2376 はそれを採らなかった。XML 処理系の多くは SGML 全体を扱えず、SGML 処理系も XML が使う後年の修正を必ずしも扱えなかった。しかも XML は SGML-bctf と SGML-boot を使わない。

言語仕様上の包含関係は、稼働ソフトの双方向互換性を証明しない。不要なパラメータを継承すれば、かえって解釈が曖昧になる。

RFC 3023 は、用途固有の XML 形式に +xml という接尾辞を用いる考えを広げた。完全なタイプ名はアプリケーションの意味を保ち、接尾辞だけが共通構文を知らせる。

RFC 6838 は構造化構文接尾辞の登録に、符号化、相互運用、フラグメント、セキュリティの説明を要求した。登録は検討可能な記録を作るが、クライアントの実装状況を作るわけではない。

RFC 7303 は、+xml を見たソフトが XML らしさを仮定し、XML 処理系で検証してから先へ進む順序を示した。汎用 XML 処理が不適切なら接尾辞を使わない選択も残した。共通構文は入口であり、無条件のディスパッチ命令ではない。

同 RFC は文書、外部 DTD サブセット、外部解析済みエンティティ、外部パラメータエンティティも区別した。同じ XML でも役割が違えば、使える処理は違う。

RFC の公開と受信結果を混ぜない

RFC 1874 が証明するのは、1995 年に二つのタイプと三つの解釈層が文書化され、能動処理の危険が明記されたことだ。普及率、特定製品の挙動、事故、攻撃、成功した相互運用は証明しない。

歴史的な教訓は十分に具体的である。登録名は質問を正しい仕様へ運ぶ。text は低機能な経路を守る。BCTF と boot は復元手順を示す。どれも、受信者の状態や権限判断を代行しない。

情報源と限界

RFC 1590、1874、2046 は登録、SGML 媒体タイプ、MIME の縮退動作を示す。RFC 2376、3023、6838、7303 は XML の分離と構造化接尾辞を示す。これらは現行導入、製品適合、実行成功、実在の攻撃や損害を立証しない。