Summary

  • RFC 769はRapicom 450のファクスデータをファイルとして保存する形式を記し、互換機器を持つARPA Internetの組織がファイル転送などでページを交換できるようにした。
  • ファイルには準備、データ、終端の区切りがある。一方、585ビットのブロックは装置独自の符号化のままで、画像を得るにはその復号手順が必要だった。

紙のファクスがコンピューターのファイルになる。いまなら当たり前に聞こえるが、1980年9月のRFC 769では、それ自体が具体的な協力の手順だった。ARPA Internetのいくつかの組織はRapicom 450をコンピューターにつないでいた。装置からページの表現を取り込み、保存されたデータから再びページを出せる。Jon Postelは、対応する装置を持つ別の組織もその交換に加われるよう、保存ファイルの形を書き残した。

ネットワークが運べたのは、まずバイト列である。Rapicom 450は内蔵の方式でページを585ビットのブロックに符号化した。これをファイルに詰めれば転送できる。しかしブロックを見ただけで一般のプログラムが画素の並びを読めるわけではない。RFCは、装置の符号化・復号手順を知らなければビットマップとして使えないと明記する。荷物は届いた。開け方の説明書は機械の中にあった。

ではPostelの文書は何を共通化したのか。ファイルを読む際の外枠だ。各レコードには長さを示す1バイト、命令の1バイト、その後にデータが続く。長さには前の2バイトも含める。命令56はSET-UP、57はDATA、58はEND。末尾のENDはデータを持たず、2バイトだけでもよい。受け取ったコンピューターは、装置固有の絵の意味を知らなくても、準備と本文と終わりの位置を見分けられた。

SET-UPには保存ならではの編集がある。Rapicomの装置は同じ準備ブロックを何度も送受信するが、ファイルには一つだけ残す。装置の動作を逐語的に記録するのではなく、交換に使う表現へ整える。実行中の反復と、保存物に必要な内容は同じではない。この一行に、機器とファイルの役割分担が見える。

ビット数も素直ではない。73バイトは584ビットで、装置の一ブロックより1ビット足りない。そこでデータ領域には74バイトを使う。長さと命令を加えた普通のレコードは76バイトになった。RFCが当時交換済みとしたファイルでは、一レコードに一ブロックを置き、先頭をSET-UP、途中をDATA、最後をENDとした。帳簿のような数字だが、ここを一つ間違えれば次のブロックはずれた場所から始まる。

文書はブロック先頭の24ビットの同期印、DATAで四つの値を巡る2ビットの通し番号も記録した。これらは装置が生んだ構造を扱う手掛かりになる。それでもページの内容を読めることとは別だ。ファイル転送はバイトを動かし、レコード解析は境界を示し、Rapicomの復号は絵を戻す。ひとつの作業に見えて、異なる担当が三人並んでいた。

1980年の目標は、互換装置を持つ仲間を増やすことだった。1992年のRFC 1314は、より一般的なファクス風画像の交換に向け、自己完結したTIFF-B形式を記述した。後年の試みと比べると、RFC 769の輪郭がはっきりする。あちらは装置に依存したページを運ぶ規則、こちらは画像の持ち方自体を広く揃える試みだ。

紙が装置に入り、符号化ブロックになり、ファイルに包まれ、ネットワークを渡り、対応装置から再び出てくる。RFC 769が残したのは、この鎖の真ん中にある小さくて重要な接ぎ目だった。「送れた」と「読めた」は別の出来事。1980年のファクスには、回線の向こうにも顔なじみの機械が必要だった。