要約

  • RFC 3073はapplication/font-tdpfrと識別用メタデータを公開した一方、Portable Font Resourceの完全な技術情報についてはBitstreamの原仕様を参照させた。
  • 登録名は受信ソフトが処理先を選ぶ手掛かりになる。しかし仕様の保全、互換コード、正常な解析、忠実な描画を証明するものではない。

2001年3月、BitstreamのJohn CollinsはPortable Font Resource（PFR）用のMIMEサブタイプをRFC 3073として登録した。登録票は曖昧ではない。名称はapplication/font-tdpfr、必須・任意のパラメーターはいずれもなし、転送にはbinaryまたはbase64が必要で、先頭を識別するマジックナンバーは16進数の50 46 52 30、拡張子はPFR、想定用途はcommonとされた。送信側と受信側は、本文が何であると名乗っているかを同じ公開記号で扱えるようになった。

しかし、その記号の中にフォーマット全体が収まっていたわけではない。RFCは、PFRを文字コードに対応するグリフ形状の小型でプラットフォーム非依存な集合として説明する。アウトラインは出力解像度に依存せず任意の大きさに拡大でき、ビットマップのグリフも含められる。ところが機能と技術の完全な説明が必要になると、読者は原PFR仕様へ送られる。その仕様はBitstreamが定義し、同社への依頼で入手でき、当時の同社サイトにも置かれていると記された。連絡先と著者／変更管理者にもCollinsとBitstreamが並ぶ。

これは記述漏れというより、登録が採用した役割分担だった。公開調整層には名前、登録票、識別に足る概要が置かれ、完全な記述契約は別の組織が保持した。文書は旧名も残している。このタイプは以前application/vnd.truedocとして登録されており、DAVIC、DVB、DTGで採用されたことを受けて新しい名前に再登録したという。ベンダーツリーの名を改め、当時の広いインターネット利用を示す無接頭辞の木へ置いたとしても、原仕様の全規則がRFCへ移されたわけでも、受信機すべてにレンダラーが配られたわけでもない。

MIMEタイプはまず振り分けの手掛かりである。アプリケーションはContent-Typeを読み、関連付けを引き、候補ハンドラーへバイト列を渡せる。だが、そこで得られる証拠は段階ごとに違う。文字列を認識したことは名前の一致、ハンドラーを起動したことは設定上の対応、解析成功はその実装が入力を受理したこと、画面が出たことは何らかの出力が生じたことを示すだけだ。製作者と同じPFR改訂版を実装したか、文字対応やメトリクスが保存されたか、読者が意図した形を見たかまでは、いずれの一段階からも分からない。

セキュリティに関するRFC 3073の記述も、文書が定めた範囲で読む必要がある。当時定義済みのフィールドは記述的で、受信側に特定の動作を起こさせないとされる。同時に、拡張可能な構造へ将来、動作を誘発するフィールドが入れば新たな危険が生じ得るとも述べ、そのような処理命令は参照仕様で支持されず、形式の目標にも反するとした。これは設計上の境界である。すべてのパーサーのメモリー安全性、ファイルの真正性、表示された形の信頼性、表示後の行為の正当性を保証する監査報告ではない。

登録票の「Interoperability considerations: none」も、相互運用試験済みという意味にはできない。RFCには適合試験一式、独立実装報告、検証用コーパス、レンダリング比較が付かない。Netscape Communicator、Bitstream WebFont Maker、Hexmac Typographが利用例として挙げられているものの、製品名の列挙は、任意の二実装がすべての妥当なPFRを同じように描けた証拠ではない。史料から安全に言えるのは、複数のアプリケーションや標準化団体による利用が報告された時点で、共通名と公開メタデータが用意されたということだ。

その後の制度整備も、この区別を消してはいない。RFC 6838は、メディアタイプを公開された命名制度として整理し、ツリー、公開要件、審査、変更管理の責任を定式化した。RFC 8081はさらにfontをトップレベルタイプとして新設し、font/ttf、font/otf、font/sfnt、font/woff、font/woff2を登録した。現在のIANA表では、古いapplication/font-sfntとapplication/font-woffに廃止の注記と移行先がある一方、application/font-tdpfrはRFC 3073を参照したまま同じ注記を持たない。この台帳状態から分かるのは現在の登録内容だけで、PFRの移行、消滅、現役利用、実装間互換性は導けない。

RFC 2045に戻ると、当初の取引がよく見える。MIMEは、受信側が理解できるかどうかにかかわらず、本文の種類と転送方法を共通文法で示すために必要だった。ラベルは自己申告の曖昧さを減らすが、世界中にデコード機能を発生させはしない。RFC 2048の登録手続きは、新しい名前を審査可能で記録可能なものにした。この意味でRFC 3073は確かな調整改善だった。ただし、登録の公共性と基礎実装チェーンの公共管理は同義ではない。

後年のRunning-Code Primacyという見方を借りれば、検証対象は一本の実行可能な鎖になる。登録名、取得可能で版が特定された仕様、保守されるデコーダー、ハンドラーとの関連付け、具体的入力、解析結果、描画結果である。Reality Layersは、公開名の象徴的な権威と、主張が現実になる地点の実行根拠を区別する問いを加える。これらは後世の分析枠組みであり、Collins、Bitstream、IANA、IETFの主張として扱ってはならない。

外部組織が管理する形式を公共レジストリで調整してはいけない、という話ではない。そうする必要はしばしばある。また、PFR仕様が秘密だったとも言えない。RFCは依頼による提供とウェブ上の所在を明記した。重要なのは、名前を公開検索できること、登録票を読めること、完全な形式を保有すること、互換コードを動かせること、正しい描画を観察できることが別々の条件だという点だ。一つが残ったからといって、残りも保存されたとは限らない。

RFC 3073は、送受信者が同じ内容種別を指せるだけの耐久性を名前に与えた。それは実在するインフラである。同時に、レジストリが示せるのはカプセルの呼び名と、文書の所在として当時申告された場所までだった。ある受信側がそのバイト列で実際に何をできるかは、仕様、実装、観測された出力を突き合わせて初めて分かる。

出典