要約

  • RFC 1927は、複数文書の結び付きの強さを電子ステープルと電子クリップで示そうとし、外観、階層、ワークフロー、課金、再利用、位置指定まで同じ物体に重ねた。
  • 後続のMIME仕様では、Content-Dispositionは表示上の提案、multipart/relatedは複合オブジェクトとルート、cid:とmid:は文脈付き参照という役割に分かれた。
  • アイコンは関係を人に説明できる。しかし保存、実行、削除、完全性を決めるのは、受信側が検証できる明示的な意味でなければならない。

紙では自然でも、転送時には仕様が要る

RFC 1927は、紙の経験をそのままデスクトップへ持ち込む。ステープル留めされた文書は離れず、クリップ留めなら広げやすい。手で紙を扱ったことがあれば、「結合の度合い」はすぐ分かる。

ところが提案は急速に膨らむ。大小のクリップは文書サイズや階層を表し、証明書は製造課金と特許違反の検出に使われる。フォルダーを削除すればリサイクラーが留め具を回収する。color=とshape=は外観を変え、src=は画像URLを指定し、銀と金は別の業務フローを起動する。ページや段落への目印にもなり、曲げた回数を数えて、やがて疲労破壊まで起こす。

ここには包含、順序、表示、識別、認可、会計、ライフサイクル、アンカー、可変状態が混在している。紙では人が状況を補うが、ソフトウェアはコピー、転送、保存、削除のたびに、どの関係を維持すべきか決めなければならない。

本文は高速コピー用プログラムが壊れるかもしれないと警告しつつ、セキュリティは論じないとする。しかし色が処理を起動する時点で境界は発生している。送信者が選んだ金色は装飾なのか、命令なのか。

Informationalという表示が権限を限定した

原文は情報提供のための文書であり、いかなるインターネット標準も定めないと明記する。RFC Editorの現行記録はIndependent Streamとして扱い、正誤表が一件あることを示す。1996年4月1日という日付、子どもやフロッピーへの危険、VR上の彫刻を見れば、真面目な製品仕様ではない。

それでも設計史として価値がある。「添付」という一語が、同時表示、同時保存、分離禁止、順序保持、同一性確認、受信後の動作のどれを指すのかを、冗談が露出させたからだ。

確認済み正誤表は“data flines”を“data files”に直し、子どもの表現も修正する。編集者は意図された文章を復元できるが、電子ステープルの動作契約までは作れない。文面の修復と運用意味の定義は別である。

パラメーターは内容の本質を奪わない

同年11月のRFC 2046は、Content-TypeをMIME本文の性質を示すものと位置付ける。パラメーターはサブタイプを修飾するが、内容の本質を変えるものではなく、未知のパラメーターは無視される。複合形式はmultipartまたはapplicationとして表現すべきだとした。

この原則に照らすと、架空のcolor=、shape=、src=へ中核機能を詰め込めない。表示属性なら無視されても本体は壊れない。不可欠な依存関係や実行命令なら、無視できる欄を唯一の根拠にはできない。

また、multipart/mixedは独立した部分を一定の順番で運ぶ。ひとつの封筒に入った事実は、輸送上のまとまりを示すだけで、不可分な一個のオブジェクトだとは証明しない。

表示は提案にとどめられた

RFC 2183はContent-Dispositionを表示情報の伝達手段として定義した。inlineは直ちに表示する提案、attachmentは利用者による追加操作を促す提案である。ファイル名も保存先で使える候補にすぎない。

安全上の注意はさらに明確だ。受信側は提示されたパスを盲信せず、既存ファイルを上書きせず、利用者の意思なしに実行される場所へファイルを置いてはならない。名前を出す権利と、受信環境を操作する権利は分離されている。

金色のクリップを社内キューの目印にするのは構わない。だが他組織でも処理を起動させるなら、認証された命令、権限確認、版管理、失敗規則が必要だ。色の親しみやすさは認可を運ばない。

複合オブジェクトは中心を明示した

RFC 2387のmultipart/relatedは、各部分を個別表示するだけでは正しく扱えない複合オブジェクトを対象とする。typeはルート部分のメディア型を示し、startがContent-IDでルートを指す。省略時は先頭部分がルートになる。内部リンクがほかの構成要素との関係を表す。

これにより、問いは「何が一緒に届いたか」から「何が全体を組織し、どの資源に依存するか」へ変わる。対応アプリケーションが関係を処理し、その場合はContent-Dispositionの表示提案より複合オブジェクトの規則が優先する。表示情報は重複し、時には誤解を招くからだ。

未対応のクライアントは全体をmultipart/mixedとして扱う。理解していない留め具を、勝手に構造的拘束へ読み替えない。この正直な縮退動作も相互運用性の一部である。

参照には名前だけでなく所属先が必要だった

RFC 2392は、MIME本文部分を指すcid:と、メッセージまたはその中の本文部分を指すmid:を定義する。Content-IDは大域的に一意であることを求められるが、保存システムによっては本文部分をメッセージから独立して索引しない。長いmid:形式は、その実装に必要な文脈を補う。

「第三段落」を指すページ旗は編集でずれ、外部URLは変化する。文脈付き識別子なら、少なくともどの対象をどこで解決するかが分かる。ただし識別子は信頼性の証明でも実行許可でもない。アドレス、完全性、権限は分けて検証される。

完全なページは関係を保ったまま運ぶ必要があった

RFC 2557は、HTML本文と画像などを一通のメッセージで送る具体的な問題にこの構造を使う。text/htmlのルートと従属資源をmultipart/relatedへまとめ、Content-IDまたはContent-Locationで参照する。

仕様は集合全体のURIとルートのURIを区別する。Content-Locationは部分にラベルを付けても、世界中から取得可能にするとは限らない。既存HTMLを書き換えると完全性検査が壊れ得るため、参照を不用意に変更しない。梱包、位置、同一バイトの保持は別の性質である。

電子ステープルより説明は長い。しかし根、構成要素、参照方法、処理責任が実装可能な形になった。保存すべきなのは見た目ではなく、この関係の構造である。

共通層に必要なのは装飾ではなく検証規則

Heng LuのRunning-Code Primacyは、文書の宣言ではなく、実装、検証、配備、採用によって変更が現実になると捉える。受信者が同じ意味を動かさなければ、公開されたステープルは何も留めない。

Minimum Initial Specificationが求めるのは曖昧な最小化ではない。ルート、識別子の範囲、関係規則、完全性境界、未知値の安全な処理など、共通でなければならない事項だけを厳密にすることだ。色やローカル業務は外に置ける。

現実層と象徴層を分けると、アイコンの限界も見える。留め具は人の認識を導く象徴である。ソフトウェアが分離を拒み、処理を開始し、資源を削除するとき、実行可能な力になる。両者を混同すれば、親切な画面が未審査の制御面になる。

RFC 1927が残した問いは、デジタル机に文房具が足りないということではない。絵が分かりやすいほど、関係定義を省けるように錯覚することだ。表示は説明できる。決定するのは明示され、検証された意味である。

出典

  1. RFC 1927 — Suggested Additional MIME Types for Associating Documents
  2. RFC Editor — RFC 1927現行記録
  3. RFC Editor — RFC 1927正誤表
  4. RFC 2046 — MIME Part Two: Media Types
  5. RFC 2183 — Content-Disposition
  6. RFC 2387 — MIME Multipart/Related
  7. RFC 2392 — Content-IDとMessage-IDのURL
  8. RFC 2557 — MIME Encapsulation of Aggregate Documents
  9. Heng Lu — Running-Code Primacy
  10. Heng Lu — Minimum Initial Specification
  11. Heng Lu — On Reality Layers