Кратко

  • RFC 3073 зарегистрировал application/font-tdpfr и опубликовал идентификационные метаданные, но за полным техническим описанием Portable Font Resource отсылал к исходной спецификации Bitstream.
  • Имя в реестре помогает программе выбрать обработчик. Оно не доказывает наличие нужной версии спецификации, совместимого кода, успешного разбора или верного отображения.

В марте 2001 года John Collins из Bitstream опубликовал RFC 3073 для регистрации MIME-подтипа файлов Portable Font Resource. Запись была вполне предметной. У application/font-tdpfr не было ни обязательных, ни необязательных параметров; для передачи требовались binary или base64; магическая последовательность указывалась как шестнадцатеричное 50 46 52 30; расширение файла — PFR, предполагаемое применение — common. Отправитель и получатель получили общий публичный знак для того, чем тело сообщения себя объявляло.

Сам формат внутри знака не помещался. RFC описывал PFR как компактный, независимый от платформы набор форм глифов, связанных с кодами символов. Контуры не зависели от разрешения вывода, масштабировались до произвольного размера и могли дополняться растровыми глифами. Но за полным набором возможностей и техническими подробностями читателя отправляли к первоначальной спецификации PFR. Документ говорил, что её определила Bitstream, что её можно запросить у компании и что копия размещалась по адресу Bitstream. Collins, также из Bitstream, был указан и как контакт, и как автор/контролёр изменений.

Такое разделение не пряталось в примечаниях: на нём строилась институциональная схема регистрации. Публичный координационный слой хранил имя, шаблон записи и краткое описание для идентификации; полный описательный договор оставался у другой организации. RFC сохранил и прежнюю идентичность типа: ранее он был зарегистрирован как application/vnd.truedoc. По тексту, повторная регистрация последовала после принятия формата DAVIC, DVB и DTG. Однако переход от имени в дереве поставщиков к имени без префикса, которое тогда связывали с широким применением в Интернете, не переносил все правила формата в RFC и не устанавливал визуализатор на каждую принимающую машину.

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

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

Поле «Interoperability considerations: none» тоже нельзя превращать в сертификат совместимости. В RFC нет набора тестов соответствия, отчёта о независимых реализациях, эталонного корпуса или измеренного сравнения изображений. Среди использующих тип приложений названы Netscape Communicator, Bitstream WebFont Maker и Hexmac Typograph, но перечень продуктов не подтверждает, что любая их пара одинаково обрабатывала каждый допустимый файл. Осторожный исторический вывод уже: регистрация дала общий термин и публичные метаданные в период, когда сообщалось об использовании формата несколькими программами и организациями стандартизации.

Позднейшая институциональная работа не отменила эту границу. RFC 6838 систематизировал регистрацию медиатипов как публичную систему имён с разными деревьями, правилами публикации, процедурами рассмотрения и ответственностью за изменения. RFC 8081 затем создал верхнеуровневый тип font и зарегистрировал font/ttf, font/otf, font/sfnt, font/woff и font/woff2. Сегодня реестр IANA помечает старые application/font-sfnt и application/font-woff устаревшими в пользу вариантов font/*, но по-прежнему связывает application/font-tdpfr с RFC 3073 без такой пометки. Это свидетельство текущего состояния реестра, но не миграции, прекращения, нынешнего развёртывания или практической совместимости PFR.

RFC 2045 помогает понять исходный эксплуатационный компромисс. MIME требовалась общая грамматика для обозначения и передачи тел, которые получатель мог понимать или не понимать. Метка уменьшала неоднозначность самопредставления содержимого, но не создавала универсальную способность декодирования. Процедура RFC 2048, в свою очередь, делала новые имена обозримыми и документируемыми. Поэтому RFC 3073 действительно улучшил координацию, не превращая публичную регистрацию в опеку над всей нижележащей цепочкой реализации.

Более поздний принцип Running-Code Primacy даёт полезную рамку для этой разницы. Проверяемая цепочка начинается с зарегистрированного имени, продолжается доступной версией спецификации, поддерживаемым декодером, сопоставлением обработчика, конкретным входом, успешным разбором и наблюдаемым результатом. Reality Layers добавляет вопрос: опирается ли символический авторитет публичного имени на исполняемое основание в той точке, где утверждение должно стать действием? Это последующие аналитические подходы; их нельзя приписывать Collins, Bitstream, IANA или IETF.

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

RFC 3073 сделал имя достаточно устойчивым, чтобы отправители и получатели могли ссылаться на один и тот же заявленный тип содержимого. Это была настоящая инфраструктура. Настоящим был и её предел: реестр мог сообщить, как называлась капсула и где, по утверждению регистратора, находилась документация. Что конкретный получатель умел делать с байтами, показывали только спецификация, реализация и фактически наблюдаемый вывод вместе.

Источники