要約

  • RFC 1314 は、ファクス型白黒画像の交換に TIFF-B を定めた。複数ページ、一ページ一 strip、可能なら MMR、そして限定された圧縮・解像度の選択を含む。
  • 画像ファイルの形式と、ファイルを通信する方法は明確に別である。FTP や SMTP は運搬手段になり得るが、ファイルの性質そのものではない。
  • スキャン、作成、保存、加工、通信、表示、印刷、ファクス出力はそれぞれ別の操作である。形式への適合は、どれかが完了した証拠にならない。

紙がライブ接続から離れたとき

従来のファクスでは、紙の入力、符号化、リアルタイムの交渉、復号、紙への出力が一つの場面に束ねられていた。「ファクスを送った」という言葉は、その連鎖全体を一つの成功に見せやすい。

RFC 1314 は別の順序を置く。画像は紙からファイルへスキャンされることも、ソフトウェアで作られることもある。ファイルは保存、加工、通信の対象になり、その後に表示または印刷される。スキャナ、ソフトウェア、ファクス機という出所と、共有、複製、表示、印刷、ファクスという行為は、同義語でも必須の直列工程でもない。

この見方では、ファクス機は紙とファイルの間の入出力装置になり、ネットワークそのものではない。文書は保存場所で待ち、別の手段で運ばれ、別種の装置で出力されうる。だから証拠も分けて読む必要がある。ファイルの存在は転送を示さない。転送は復号を示さない。表示は人の注意や既読を示さない。

TIFF-B が約束するもの

RFC は TIFF を枠組みとして使い、交換用の TIFF-B を規定する。複数ページを支え、一ページにつき一 strip を使う。可能な場合は MMR を推奨し、MH、MR、無圧縮も許す。MH または MR の場合、走査線はバイト境界に合わせる。相互運用性のため、600、400、300 dpi、または本文で挙げる Group 3 の解像度も勧める。

これは実装間の境界で差し出せるファイルの範囲を定める契約である。成功証明書ではない。TIFF-B はページの構造や符号化方式について語れるが、元のスキャナ、送信者、実際に使われた運搬手段、受信側の圧縮対応、正しい変換、紙への出力を証明しない。

保存についても RFC は慎重である。ホストは画像を指定形式で保持する義務を負わず、自身の局所形式と交換形式を変換できる。受信側が圧縮を扱えなければ変換が必要になることがある。誰が変換し、どのアルゴリズムを使うかは規定しない。表現の仕様は境界での形を定めても、内部作業の履歴を自動的には生まない。

運搬者はファイルの外にいる

RFC 1314 は、画像のファイル形式とファイルを通信する方法は別問題だと明記する。FTP と SMTP は可能な手段の例である。同じ TIFF-B が異なる仕組みを通っても、その形式は変わらない。一方で、記録、保証、失敗の種類は運搬者に属する。

当時の SMTP のバイナリやサイズに関する難しさへの言及は、当時の制約であって、後年のすべての添付ファイルの歴史ではない。さらに、可能な手段として名があるだけで、あるファイルが実際に FTP や SMTP を通ったとは言えない。それには転送ログ、必要なら完全性と受信側の独立した記録が要る。

局所保存も同様である。ホストにある画像、交換に出したファイル、ネットワークに渡ったバイト列は関連していても同一とは限らない。この三つを混同すると、相互運用できる能力を、保管や到達や完了の物語に変えてしまう。

「ファクス」をほどく

RFC は従来のファクスが束ねる四つの問題を分ける。データ表現と圧縮、データ伝送、紙からの画像入力、紙への画像出力である。ソフトウェア生成のページは通信前に保存できる。スキャンした画像は複数の場所へ複製できる。ファイルは印刷ではなく表示されることもある。正しい形式だからといって、どの経路も必ず実行されるわけではない。

ファクスボードやモデムは受信機と交渉するかもしれず、圧縮を受け手が扱えなければ変換もあり得る。交渉、変換、印刷は後続の出来事であり、それぞれ条件を持つ。安定したバイト列がその後すべてを目撃したかのように、ファイルに遡って入れてはならない。

出典と証拠の限界

本稿は RFC 1314 A File Format for the Exchange of Images in the Internet（1992年4月）に基づく。TIFF-B、圧縮と解像度の指針、形式・通信・保存の分離、そして作成またはスキャン、保存/加工/通信、表示/印刷のモデルを根拠とする。個別の転送、送信者、受信者、変換、表示、印刷、ファクス、既読、現在の運用、商業結果は証明しない。