Summary

  • RFC 769 описала формат файла для факсимильных данных Rapicom 450. Организации с совместимыми аппаратами могли обмениваться сохранёнными страницами через передачу файлов и другие протоколы.
  • Записи обозначали подготовку, данные и конец файла. Внутри оставались 585-битные блоки в кодировке аппарата; для восстановления изображения требовался его способ декодирования.

Бумажная страница входит в факс, а выходит из него компьютерным файлом. Для нескольких организаций сообщества ARPA Internet в сентябре 1980 года это уже было возможной рабочей процедурой: их аппараты Rapicom 450 были подключены к компьютерам. Jon Postel описал в RFC 769 формат сохранённых данных, чтобы другие участники с совместимым оборудованием могли присоединиться к обмену. Страница получила возможность путешествовать без курьера.

Однако файл и изображение жили в разных слоях. Rapicom 450 кодировал страницу собственным способом и выдавал блоки по 585 бит. Компьютер мог хранить эти блоки, сеть — перевозить. Превратить блоки в карту изображения можно было лишь зная и применяя процедуру кодирования и декодирования устройства. RFC прямо проводила эту границу. У получателя оказывался аккуратно доставленный конверт; алфавит письма знал аппарат.

Общим для участников делался внешний порядок файла. Каждая запись начиналась байтом длины и байтом команды, за которыми следовали данные. В число байтов длины входили и эти первые два. Команда 56 означала SET-UP, 57 — DATA, 58 — END. Последняя запись могла состоять только из двух начальных байтов. Компьютеру становилось понятно, где подготовка, где содержимое страницы и где конец, ещё до работы с внутренней кодировкой.

Блок подготовки хорошо показывает разницу между действием машины и сохранённым представлением. При работе Rapicom отправлял или принимал несколько одинаковых копий SET-UP. Файл сохранял одну. Его задача состояла не в подробной записи каждого повтора, а в сохранении того, что требовалось другому совместимому аппарату. Операционный ритм был одним фактом, архивный состав файла — другим.

Необычная длина блока требовала небольшого бухгалтерского расчёта. В 73 байтах 584 бита; блоку Rapicom нужен ещё один. Поэтому поле данных занимало 74 байта. Плюс два служебных байта — обычная запись получалась длиной 76 байтов. В уже обменянных к моменту написания RFC файлах один блок помещали в одну запись: сначала SET-UP, затем DATA, после них END. Ошибка на один бит сдвинула бы границы всей дальнейшей страницы. Старый Интернет строился и на таких мелких арифметических победах.

В документе были также зафиксированы 24-битная метка синхронизации в начале блока и двухбитный номер, проходивший четыре значения в записях DATA. Эти признаки помогали узнавать структуру устройства. Но они ещё не раскрывали содержание картинки. Транспорт доставлял файл, его парсер находил записи, а Rapicom выполнял декодирование страницы. Три вида компетенции встречались в одном обмене.

Предложение 1980 года было адресовано владельцам совместимых аппаратов. Позднее RFC 1314 1992 года описала самостоятельный формат TIFF-B для более широкого обмена изображениями, похожими на факс. Контраст между документами полезнее рассказа о якобы единой прямой эволюции: первый наводил порядок в файлах конкретного устройства, второй стремился описать сам образ страницы так, чтобы его можно было переносить шире.

Путь выглядел длиннее привычного «отправить документ»: бумага, факсимильный аппарат, закодированные блоки, записи файла, сеть, совместимый аппарат у адресата. На каждом этапе менялся хозяин операции. Возможность отправить страницу как данные была настоящей новинкой. Вернуть ей вид страницы на другом конце могло только оборудование, которое знало её язык.