Кратко

  • RFC 1049 предложил поле Content-Type для структурированных тел писем, в том числе PostScript, TeX и TROFF. Тело оставалось в пределах ASCII-ограничений тогдашней почты, а программа чтения могла выбрать подходящий механизм отображения.
  • Поле допускало указание версии и необходимых ресурсов. Пока автоматического обмена сведениями о возможностях адресата не было, отправитель держал собственный список подготовленных получателей. Позднее RFC 2045 расширил эту идею в MIME.

Письмо может доехать без единой потерянной буквы и оказаться совершенно неудобным для чтения. В почтовом ящике 1988 года документ PostScript легко превращался на экране в набор инструкций для принтера. Автор отправлял формулы и аккуратную страницу; корреспонденту доставалась инструкция по ее сборке. Мартовский RFC 1049 Martin Sirbu предлагал дать письму возможность сообщить, какой именно способ чтения ему нужен.

В формате RFC 822 уже были определены заголовки и тело из символов ASCII. Пользователи помещали в это тело TROFF, TeX, Scribe, SGML, DVI и PostScript. Такие данные проходили по почтовому каналу как допустимые символы, но для задуманного вида им требовалась отдельная программа. Поле Content-Type позволяло читающему приложению опознать технику и передать тело нужному обработчику. Почтовый транспорт продолжал переносить символы; выбор представления происходил на стороне читателя.

Метка у Sirbu была довольно подробной. Первым шел тип, например POSTSCRIPT или TROFF; для частных соглашений предусматривался тип X-. Затем можно было указать версию, ссылку на ресурсы и комментарий. Среди примеров — версии LaserPrep для PostScript и средства eqn, tbl, me для TROFF. Название блюда помогает выбрать повара, но продукты и посуда ему тоже нужны. Ссылка на ресурс делала эту зависимость частью объявления о документе.

Главная трудность ждала у адресата. Если нужного интерпретатора у него не было, письмо в ASCII все равно приходило, а экран показывал сырые команды. Как отправитель узнает, кому можно посылать PostScript? RFC рассмотрел три решения: местные базы данных о возможностях удаленных машин, согласование и преобразование в ходе доставки SMTP, публикацию возможностей через службу каталогов. Базу нужно постоянно обновлять; согласование меняло существующие почтовые программы и не охватывало все межсетевые пути; каталог затрагивал отправку и инфраструктуру имен.

Для первых опытов Sirbu выбрал удивительно ручной вариант: каждый отправитель сам хранит список адресатов и доступных им форматов. Общий заголовок называл содержимое, а личная записная книжка отвечала за рассадку гостей. RFC также оставил за читающей программой выбор конкретного действия после получения корректного поля. Опознать формат, иметь его интерпретатор и показать приятную страницу — отдельные задачи.

Позднее RFC 2045 прямо назвал MIME-версию Content-Type развитием поля из RFC 1049. В MIME появились тип и подтип данных, параметры, а также другие поля, включая MIME-Version и Content-Transfer-Encoding. Текст 1996 года характеризовал старый синтаксис как более простой и в основном совместимый. Но в 1988 году был сделан свой важный шаг: письмо научилось объявлять свой формат раньше, чем почта научилась узнавать возможности каждого читателя.

Маленькая метка избавила человека от угадывания формата по экрану команд. Зато обнажила вопросы подороже: у кого есть интерпретатор, нужная версия и вспомогательные ресурсы? Некоторое время самая полезная база возможностей сидела перед клавиатурой и нажимала «Отправить».