要約

  • RFC 2397 は、小さなデータを「即時」データとして収める data: を定義した。構成要素は任意のメディアタイプ、任意の ;base64、区切りのコンマ、そしてデータである。
  • 内容をURL内に置くと、外部取得の入口ではなく、利用側のURL解析器、メディアハンドラー、バッファ管理が実質的な制御点になる。

一般的なURLは、別の場所へ向かう約束を含む。クライアントは所在を読み、外部へ問い合わせ、表現を受け取る。RFC 2397 が示したのは、もっと短い回路だった。data:[<mediatype>][;base64],<data> では、所在を記すはずの文字列が内容まで運んでくる。

仕様はこれを “immediate addressing” と呼ぶ。コンマの先に小さなサーバーがいるわけではない。埋め込まれた項目については別の取得先がなく、利用側が宣言部分とペイロードを分け、オクテットを復元し、指定されたメディアタイプとして解釈する。ポインターと荷物が一つの直列化された入力になったのである。

省略規則にも意味がある。メディアタイプがなければ text/plain;charset=US-ASCII となり、text/plain を省いて charset だけを付ける短縮形も認められる。等号を伴わない ;base64 は通常のContent-Typeパラメーターではなく、base64表現を選ぶ標識である。それがなければ安全なURL文字は直接使い、その他のオクテットは %xx で表す。base64は暗号化でも真正性の証明でもない。

相対URL形は存在しない。相対参照は周囲の基底から所在を借りるが、data: は型とデータをその場で完結させる。だから、文書を移動可能にした相対参照の歴史とは別の仕組みである。一方は文脈から住所を補い、もう一方は内容を自分で持つ。

RFCは用途を「短い値」に限る姿勢を崩さない。HTML 2.0 のSGML宣言を例に、一つの属性値リテラルは1,024文字、タグ内の全属性値は合計2,100文字、タグ全体も2,100文字という上限を挙げた。例示された小さなGIFでさえ実用の限界に近いとされる。これは全実装共通の上限ではない。構文上書ける長さと、外側の形式やメモリーが受け止められる長さは別だという注意だった。

制御の移動はセキュリティ節で明確になる。ファイアウォールプロキシは外部から取得する特定メディアタイプを止められる。しかし、すでにURLの中へ入った内容を同じ取得経路で選別するのは難しい。そこでRFCは、設定上禁止されたメディアタイプをアプリケーションが解釈すべきではないと述べる。決定権は、バイト列を実際の振る舞いへ変える部品にある。

長大な値の影響は当時不明で、割り当て済みバッファを超える入力に対してソフトウェアが不合理な挙動を示す可能性も記された。問われるのは二重の境界である。その型を処理してよいか。そして、その大きさを安全に処理できるか。ネットワーク取得が発生しないことは、どちらの答えにもならない。

着想は1995年8月に遡り、VRML、HTMLへの埋め込み提案、商用製品、JavaやActiveXのオブジェクトパラメーターで使われていた。設計過程ではメディアタイプの省略、base64表示の圧縮、quoted-printableの削除が行われた。すでに %xx が役割を果たせたからである。

後年のerrataも同じ慎重さを要求する。Verifiedの二件は、不正な16進表記 %fg の修正と、RFC 2396から導入する生成規則を未定義の urlchar から uric へ直すものだ。引用符付きパラメーターと区切り文字の曖昧さはReportedまたはHeld for Document Updateに留まり、確定した置換文ではない。URLを一律URIへ改称する提案は、当時の用語として正しかったためRejectedとなった。

RFC 2397 の歴史的価値は、短い書き方そのものではない。経路を消せば統制も消える、という誤解を退けた点にある。統制は、解析し、復号し、意味を与え、実行を許すローカル部品へ移る。距離が短いほど、そこでの境界は明確でなければならない。

情報源