要約

  • RFC 2159 の「ほぼバイトコピー」は、パラメータ写像、バイト内ビット順の反転、ページ末尾の補完、6 EOL 境界の挿入を含む変換だった。
  • 可逆な帰路には、ページ境界、末尾 EOL、名前のない DCS ビットが必要であり、本文ハッシュの一致だけでは同じファクスオブジェクトの復元を証明できない。
  • 構造上の往復に成功しても、受信側のモード対応、走査線の画素数、表示の縦横比、利用可能な画像までは証明しない。

nearly は例外ではなく設計だった

1998年1月の RFC 2159 は、すでに Group 3 ファクス形式になっている情報を MIME で運び、X.400 表現と相互変換する方法を定めた。image/g3fax を汎用のインターネット画像形式とは位置付けていない。目標は別形式への変換ではなく、既存のファクス表現を二つのメッセージ体系の間で再構成可能にすることだった。

本文は三種類の状態を持つ。符号化方式を示すフラグ、ビットをページに分ける構造、そして各ページの T.4 画像ビットである。フラグは MIME パラメータに移り、X.400 のページごとの BIT STRING は本文中の境界記号に変わり、画像ビットには別のバイト内順序が適用される。

先行する RFC 1494 は、本当の Byte Copy を「変換せずにバイトストリームをそのまま複製する場合」と説明した。G3Fax の項目はすでに nearly とされていた。圧縮画像を展開して再圧縮する必要はないが、画像を包む構造は作り直さなければならない。

省略値も未知ビットも意味を持った

MIME 側のパラメータは、ページ長、ページ幅、一次元・二次元・非圧縮の符号化、粗・細解像度、ページ数、Base64 の Device Control String である。何も指定しない場合にも、A4 長、A4 幅、一次元、粗解像度という既定値がある。欠落は「意味がない」のではなく、特定の意味を選ぶ。

同じ機能でも T.30 と X.400 ではビット番号が異なる。X.400 はオクテットの MSB 側から、T.30 は逆側から数えるためである。ゲートウェイは番号ではなく意味を写像する必要がある。これはページデータそのものについて各バイトのビット順を反転する処理とも区別される。

名前付き項目に収まらない Device Control String のビットが立っていれば、RFC は DCS パラメータを付けるよう求める。同時に、そのような NonBasicParameters の相互運用性は保証しない。未知のビットを運ぶことは証拠の保存であって、相手に機能を実装させることではない。

したがって、画像本文が一致しても十分ではない。既定値の解釈が違う、能力ビットが落ちる、受信側が指定モードを持たない、という失敗があり得る。画像と能力記述は結び付いているが、同じデータではない。

ページ列を一つの MIME 本文へ変換する

X.400 の g3-facsimile は、1ページを1個の ASN.1 BIT STRING とする列である。MIME は連続した本文なので、RFC 2159 は6個連続する EOL をページ境界にした。EOL は 11 個のゼロと1個の1から成り、6個の列はバイト境界から始まらなければならない。そのため画像末尾には必要な数のゼロが補われる。

境界のバイト列は 00 10 01 00 10 01 00 10 01 と示され、画像内部には出現しないと仕様は述べる。画像を描画せずに境界を検索できる一方、境界位置、アラインメント、補ったビット数も復元記録の一部になる。ページ分割を失った長いビット列は、元のページ列と同じとは言えない。

X.400 から MIME へ進むときは、各 BIT STRING の末尾 EOL を除き、最初のバイトの最上位ビットが G3Fax の先頭ビットになるよう順序を変え、バイト境界まで補い、6 EOL を付け、ページを連結する。画像の再符号化ではないが、文字通りのコピーでもない。

戻るときは6 EOL で分割し、末尾 EOL を削除せず、各バイト内のビット順を反転し、各ページを BIT STRING にして列を組み立てる。末尾 EOL を残す命令は RFC 1494 からの変更だと明記された。RFC 1494 は帰路で末尾 EOL とパディングを除くとしていた。nearly という分類が同じでも、往復の境界条件は更新されていた。

ハッシュは対象層を明示して初めて役立つ

MIME 本文が一つのメール区間で同じハッシュを持つなら、その区間で MIME オクテットが保たれた証拠になる。しかし X.400 から作る際のビット順が正しかったかは分からない。ASN.1 BIT STRING の格納バイトと MIME バイトを直接比較すれば、正しい変換でも異なる。仕様が意図的に各バイトを反転するからである。

比較は同じ意味層で行う。元のページごとの有効ビット長と ASN.1 の未使用ビット数を記録し、指定規則で順序を変え、パディング数と各6 EOL の開始位置を残す。帰路では境界数からページ数が戻ること、有効ビット、パラメータ、DCS が元と一致することを確かめる。

RFC 2157 の用語では、equivalence は二つの mapping を組み合わせた無損失変換である。一方向に妥当な本文を作っただけでは mapping の実行にすぎず、指定された帰路を同じ対象へ適用して初めて強い主張を検証できる。

可逆な格納形式と利用できる画像は別である

RFC 2159 の実装案内は、構造の可逆性を表示可能性と同一視していない。fineResolution がなければ画素は横の2倍の高さになる。DCS の機能空間は少数の MIME 名付きパラメータより広かった。細解像度や一部の用紙長に比べ、B4・A3 幅は難しいとも報告する。また、宣言された数だけ画素を持たない走査線、特に右端の白を省いたデータで問題を起こす機械があると警告した。

従って、ページとオプションを完全に戻しても、デコーダがモードを実装していないことがある。受理されても縦横比が違い、右端が欠け、もっともらしい画像だけが残ることもある。構文受理、復元、画素形状、視覚的一致、読者の利用は別々の観測である。

現在の IANA Media Types は image/g3fax を掲載し、歴史的な MIME/X.400 表 は g3-facsimile との対応を残す。公開識別子の存在は、製品実装や配備設定、全オプションの表示能力を証明しない。

必要なのは層をつないだ受領記録である

試験は X.400 のパラメータ、DCS バイト、ページ数、各 BIT STRING の有効ビット長と指紋から始める。ゲートウェイ版と写像表も固定する。MIME 側ではパラメータ、本文、パディング数、境界位置を保存し、帰路で列、ページ長、パラメータ、DCS が復元されたか比較する。

その後にデコーダ試験を行う。符号化、解像度、幅、長さの対応範囲、走査線の画素数、表示寸法を測り、合意した参照画像と比べる。配送と人間の読解はさらに後の事実である。

Lu Heng の Running-Code Primacy は、規則と実行結果を分ける視点を与える。Minimum Initial Specification は共通写像とローカル能力の境界を保ち、Reality Layers はラベル、可逆表現、描画、利用結果が互いの証拠を借りられない理由を示す。

RFC 2159 の nearly は曖昧語ではなく、コピーから外れる状態の一覧だった。画像ビットだけでなく、パラメータ、ページ境界、ビット順、パディング、受信能力のどれか一つを失えば、完全に保存されたように見えるバイト列から元のファクスを戻せない。

出典