Кратко

  • RFC 2361 позволил интернет-приложениям указывать уже зарегистрированные кодеки WAVE и AVI как audio/vnd.wave;codec=... и video/vnd.avi;codec=...; IANA перепубликовывала эти значения, а не назначала их.
  • Найденная запись подтверждала существование имени в выбранной версии реестра, но не соответствие тела, наличие реализации, актуальность контакта, безопасность или результат воспроизведения.

Файл приходит с пометкой video/vnd.avi;codec=CVID. CVID находится в таблице, а на компьютере есть компонент с названием Cinepak. Интерфейс показывает готовность, но видео не начинается. Все три наблюдения могут быть верными: они просто относятся к разным этапам.

Параметр мог быть указан неверно. В контейнере могла находиться другая дорожка. Локальная библиотека могла поддерживать иную разновидность, отказаться от повреждённого заголовка или исчерпать память. Она могла даже выдать кадры, которые приложение не показало. Точное имя не служит протоколом фактического выполнения.

В июне 1998 года проблема была особенно заметна. Огромный массив мультимедиа появился в настольных экосистемах, а не внутри интернет-протоколов. WAVE и AVI уже имели идентификаторы в базах Microsoft. Сетевые приложения хотели находить, описывать и передавать эти материалы, не создавая вторую систему названий для каждого существующего формата.

Информационный RFC 2361 не переопределял потоки битов. Он создал ссылку из дерева поставщиков MIME во внешний реестр. audio/vnd.wave обозначал пространство WAVE, а обязательный параметр codec выбирал WAVE Format ID. video/vnd.avi тем же способом выбирал AVI Codec ID.

Полномочия оставались раздельными. Значения назначались в реестрах Microsoft, которые предотвращали коллизии и публиковали общую информацию. MIME давал переносимый синтаксис, RFC документировал отображение. На нынешней странице IANA процедура сформулирована прямо: IANA does not assign. Republication of values. Публикация на площадке IANA не превращала каждую строку в назначение, рекомендацию или аудит IANA.

Для WAVE важна система счисления. Format ID был шестнадцатеречным регистрационным номером. В параметр переносились его цифры без 0x. Поэтому MP3 с номером 0x0055 обозначался как audio/vnd.wave;codec=55. Это не десятичное число 55. Реализация, которая читает строку как десятичную и затем преобразует её, способна аккуратно вычислить неверную запись.

AVI использовал FourCC: четыре ASCII-символа, 32 бита, с учётом регистра. CVID, cvid и типографически нормализованная форма не равны только потому, что похожи. Регистр, длина и байты являются частью идентичности.

RFC также описал детерминированное отображение WAVE ID и FourCC в GUID. Номер или 32-битное значение символов помещались в первое поле постоянного шаблона. В примере H260 выглядел как 30363248; видимая перестановка объяснялась порядком байтов DWORD. Так две программные модели могли подтвердить ссылку на одну запись.

Отображение не добавляло доказательств. Производный GUID не становился новой спецификацией кодека, перечнем установленного ПО или аттестацией происхождения бинарного файла. Более поздний RFC 4122 стандартизировал формат и терминологию UUID, но не придал исходному идентификатору сведений о реализации, разрешении или безопасности.

У реестра была временная граница. RFC 2361 называл базы историческими. Компания, адрес, телефон или контакт обычно не менялись, если первоначальный регистрант не сообщал обновление. Приложения были авторитетным снимком значений, зарегистрированных к январю 1998 года, а не бессрочным подтверждением существования фирмы и поддержки продукта.

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

Параметр MIME не проверял тело. Это заявление отправителя. Получатель всё ещё должен разобрать контейнер, увидеть реальные дорожки и внутренние идентификаторы. Заголовок может отсутствовать, ошибаться или вводить в заблуждение; файл может быть обрезан, двусмыслен или подготовлен для атаки на парсер. Успешный поиск доказывает лишь наличие смысла у токена в выбранном снимке.

Позднее RFC 6381 определил множественный параметр codecs для других контейнерных типов и прямо указал: при конфликте решающим является тело. Он также признал, что не каждая объявленная дорожка обязательна для частично полезного результата. Этот документ не заменяет единственное число и vendor-tree RFC 2361. Он показывает устойчивость границы между декларацией и проверенным содержимым.

Локальная способность требовала отдельного учёта: точная версия декодера, источник, профили, глубина, архитектура, песочница, память и время. Установлено не значит выбрано; выбрано не значит запущено; запущено не значит успешно декодировано; декодировано не значит представлено нужному пользователю.

Транспортные протоколы не сокращали цепочку. RTSP мог управлять сеансом, HTTP доставлять объект, RTP переносить данные во времени. Название WAVE или AVI помогало говорить о материале, но не являлось форматом полезной нагрузки RTP, подтверждением сеанса, полной доставки, синхронизации или просмотра.

Раздел безопасности провёл жёсткую черту: документ лишь регистрировал форматы и не решал их проблемы безопасности; каждый формат следовало исследовать отдельно. Совпадение в реестре не давало разрешения автоматически устанавливать кодек, загружать привилегированный плагин или снимать ограничения ресурсов.

Проверяемая цепочка сохраняет исходный Content-Type, версию реестра, шестнадцатеричное или FourCC-толкование, порядок байтов, результат проверки контейнера, конфликт, фактический декодер и его происхождение, решение об изоляции, попытку, выходные дорожки и наблюдаемое представление. Каждый шаг может быть истинным, пока следующий остаётся неизвестным.

Историческим достижением RFC 2361 стала ограниченная федерация имён. Интернет получил точную ссылку на чужое пространство, не присваивая себе право назначения, код или результат.