Кратко

  • RFC 1874 относил к text/sgml сущности, понятные человеку без SGML-программы, а остальные — к application/sgml. Это определяло запасное отображение, а не отсутствие активных свойств.
  • charset, SGML-bctf и SGML-boot отвечали за разные переходы: чтение текста, превращение битовых комбинаций в октеты и ссылку на отдельную MIME-часть с загрузочным отображением.
  • RFC предупреждал, что SGML-системы способны разрешать команды системного уровня. Позднейшее выделение типов XML подтвердило: общий синтаксический предок не делает процессоры и роли сущностей взаимозаменяемыми.

Классификация описывала поведение при нехватке возможностей

RFC 1874 выбирал между text и application не по расширению файла и не по важности документа. Критерием было остаточное значение. Если без SGML-дисплея человек легко различал содержание, подходил text/sgml.

Каждая запись SGML, ограниченная знаками начала и конца записи, должна была соответствовать строке MIME-тела. Обычная программа могла показать эти строки. Она не обязана была восстанавливать иерархию, разрешать сущности и исполнять указания компоновки. Читатель получал общий смысл, но не обязательно предусмотренное представление.

Если без специального процессора смысл исчезал, применялся application/sgml. Типы фиксировали приемлемую деградацию, а не полноту обработки.

RFC 2046 обобщил это свойство MIME. Верхний тип помогает даже при неизвестном подтипе. Неизвестный текст иногда разумно показать как есть; с изображением и звуком такой подход не работает. Поэтому текстовый подтип не должен полностью скрывать общий смысл за специализированной программой.

Итак, слово text говорило, что делать без парсера. Оно не говорило, что разрешено парсеру.

До синтаксиса требовалось восстановить алфавит

Параметр charset помогал обычному MIME-пути показать text/sgml. Параметр SGML-bctf предназначался SGML-системе и описывал преобразование постоянных по ширине битовых комбинаций модели в переданный поток октетов.

Документ перечислял identity, фиксированные формы и переменные кодировки. Знание подтипа не доказывало поддержку объявленного BCTF. Правдоподобные символы на экране не доказывали совпадение номеров, на которых строилась SGML-декларация.

SGML-boot хранил не саму загрузочную информацию, а Content-ID другой MIME-части application/octet-stream. В ней находились тройки целых чисел, задававшие отображение значимых символов для декларации. Механизм относился только к сущности документа.

Ссылка могла быть правильной, а цель отсутствовать. Часть могла потеряться, идентификатор — повториться, multipart-структура — разрушиться. После нахождения цели оставались чтение троек и разбор декларации.

RFC 1590 обеспечил публичную регистрацию медиа-типов. Запись объясняла имя и указывала спецификацию. Она не проверяла отдельный пакет, версию программы или результат на машине получателя.

Передача парсеру создавала новое полномочие

Раздел безопасности RFC 1874 говорил о сущностях, которые принимающая SGML-система анализирует и обрабатывает. Некоторые системы могли допускать явные команды системного уровня. Указания для представления или верстки несли риск, похожий на PostScript.

Поэтому читаемый текст не был пассивным по определению. Простой просмотр использовал одну поверхность полномочий. SGML-обработка могла открыть ссылки, инструкции и команды. Первое действие не разрешало второе.

Успешное дерево разбора не подтверждало политику исполнения. Запрещённая инструкция не означала бесполезность текста. Ошибка BCTF происходила ещё раньше. Единый статус «файл открыт» не показывал, кто и какое решение принял.

MIME требовал игнорировать неизвестные параметры, чтобы новые расширения не ломали старые программы. Это сохраняло внешний обмен, но игнорирование SGML-boot могло лишить документ необходимого отображения. Совместимость оболочки не была верностью приложения.

XML получил отдельное имя из-за работающих различий

XML был подмножеством SGML, однако RFC 2376 зарегистрировал text/xml и application/xml. Многие XML-программы не поддерживали более широкий SGML. SGML-программы не всегда принимали исправления, использованные XML. Параметры BCTF и boot XML не применял и при их появлении получил бы неоднозначность.

Подмножество описывало языки, а не двоичную совместимость установленного кода.

RFC 3023 добавил соглашение +xml для прикладных форматов. Полный медиа-тип сохранял предметный смысл, а суффикс раскрывал общий синтаксис универсальным инструментам.

RFC 6838 оформил реестр структурных суффиксов с требованиями описать кодирование, совместимость, фрагменты и безопасность. Регистрация делала заявление проверяемым, но не устанавливала процессор.

RFC 7303 предлагал заметить +xml, проверить предположение XML-процессором и затем учитывать конкретный тип. Когда универсальная XML-обработка неуместна, формат мог отказаться от суффикса. Сигнал был приглашением к проверке, не распоряжением исполнить.

Документы, внешние DTD-подмножества, внешние анализируемые сущности и внешние параметрические сущности также оставались разными ролями. Общий XML не отменял различия.

Квитанция заканчивалась там, где было наблюдение

Зарегистрированный тип подтверждал публикацию. Заголовок — заявление отправителя. Захват — получение в одной точке. Экран — один путь отображения. Журнал парсера — локальное преобразование. Ни один из них отдельно не подтверждал комплектность, разрешение активных функций и полезный итог.

RFC 1874 не доказывает распространение, поведение названного продукта, эксплуатацию или ущерб. Его собственный текст даёт более точный исторический вывод: удобная деградация не сокращает цепочку полномочий при полноценной обработке.

Источники и границы

RFC 1590, 1874 и 2046 задают регистрацию, SGML-типы и MIME-поведение. RFC 2376, 3023, 6838 и 7303 задают XML-разделение и структурные суффиксы. Они не подтверждают современное внедрение, соответствие продукта, реальное исполнение, атаку, ущерб или коммерческий результат.