Кратко

  • Мартовский RFC 1590 1994 года расширил почтовые «типы MIME» до «медиатипов», пригодных для разных приложений. Предложение публиковалось в рассылке ietf-types; через две недели его можно было представить IANA для регистрации и назначения OID.
  • Общий реестр мог содержать много имён. Для почты оставалась возможность отдельно рекомендовать небольшой набор широко поддерживаемых форматов в документе о применимости. Название объекта и способность конкретной программы его прочитать определялись в разных местах.

У нового объекта спросили имя

Изображение попадает в письмо и в архив. Если обе программы придумают собственные обозначения, у одних и тех же байтов появятся два паспорта. Другой вариант ещё хуже: разные данные случайно получают одно имя, и программа берётся за них неподходящим инструментом. Пока системы не обмениваются файлами, конфликт кажется мелким. После обмена исправлять его приходится в уже выпущенном коде.

В RFC 1521 механизмы MIME описывали тела почтовых сообщений. Асинхронная почта жила с практической неопределённостью: отправитель часто не знал возможностей программы получателя. Небольшой список распространённых типов улучшал шанс прочитать письмо. Но названия начали применять и за пределами почты. RFC 1590 Джона Постела предложил расширить общий словарь, оставив каждому применению право выбирать нужные ему инструменты.

Перемена отразилась даже в вывеске. «Типы MIME» стали «медиатипами». Пара тип/подтип давала общее обозначение объекта в разных программах. Реестр сообщал, на какой формат указывает запись. Приложение показывало собственным поведением, умеет ли этот формат обрабатывать. Новый тип видео можно внести в список, не превращая всякий старый почтовый клиент в видеопроигрыватель.

Первой остановкой была публичная рассылка ietf-types. Предлагаемый подтип до регистрации носил форму x-. Участники могли обсудить ясность имени, ссылки на версии и профили, выбор объектных идентификаторов и известные риски. Ограниченную область применения разрешалось указать сразу. Открытая дискуссия давала возможность поймать неудачное название прежде, чем оно станет частью чужого программного обеспечения.

После двух недель заявитель отправлял материалы в IANA. RFC описывал административную проверку, внесение типа, назначение OID в ветви IANA и публикацию записи. Форма запрашивала тип и подтип, обязательные и дополнительные параметры, кодирование, вопросы безопасности, спецификацию и контакт. Несколько граф в бланке создавали точку, где позднее можно было узнать, что именно означало имя.

Не у каждого распространённого формата имелась полноценная открытая спецификация. RFC 1590 допускал указание конкретного программного пакета и версии, создавших поток данных. Такое описание точнее расплывчатого «документ нового типа». Получателю всё ещё требовался работающий декодер для байтов соответствующей версии. Каталожный ярлык указывал на содержимое ящика; открыть его должен был читатель.

Совсем новый верхний тип требовал RFC или подходящего проекта и прохождения процесса стандартов. Подтип внутри существующей категории использовал более лёгкую административную дорогу. Почта могла отдельно рекомендовать ограниченный набор форматов в собственном заявлении о применимости. Благодаря этому реестр оставался общим и достаточно просторным, а программы сохраняли реалистичный список поддерживаемых объектов.

Очередь длиной в две недели давала обществу время посмотреть на имя, которое могло пережить множество версий софта. RFC 1590 не строил проигрыватели и декодеры из бумажных форм. Он делал так, чтобы программы с разными возможностями хотя бы начинали разговор об объекте с одного и того же обозначения.