Кратко

  • RFC 3023 ввёл соглашение +xml, чтобы разные типы media сохраняли собственные имена и одновременно сообщали об общей XML-структуре.
  • Суффикс не передавал прикладной смысл и не давал права действовать: точный тип, байты, разбор, профиль, доверие, авторизация и эффект оставались отдельными фактами.

К 2001 году XML стал основой для множества языков. Коммерческое сообщение, векторное изображение и конфигурационный документ могли иметь одну грамматику разметки, но требовать разных приложений. Название application/xml сохранило бы сведения о синтаксисе и скрыло прикладной контракт. Полностью непрозрачные имена сохранили бы контракт, но лишили универсальные редакторы, поисковые системы и парсеры знания об общей структуре.

RFC 3023 добавил к имени небольшой стык. Специальный subtype оставался на месте и завершался +xml. Левая часть называла формат, правая открывала базовое представление.

Один суффикс не превращал разные форматы в один

Приложение, понимающее application/foo+xml, могло применять правила foo. Инструмент, не знающий foo, но умеющий работать с XML, мог проверить последние четыре символа и решить, допустимы ли общий разбор, поиск, форматирование или преобразование.

Так каждому инструменту не требовался бесконечный список XML-словарей. RFC объяснил и отказ от параметра: параметры модифицировали subtype, а действующие MIME-dispatcher редко выбирали обработчик по ним. Новый top-level type изменил бы слишком большую часть архитектуры. Суффикс передавал минимальный общий факт.

При этом полный тип оставался главным. Процессор без знания XML видел +xml как непрозрачную строку. Поэтому приложение RFC 3023 запрещало приписывать одному присутствию суффикса дополнительную семантику. application/foo и application/foo+xml были независимыми типами. XML-вариант мог изменить и синтаксис, и смысл; поддержка одного не означала поддержку другого.

Успешный разбор не подтверждал допустимость команды

Полученный header был заявлением отправителя. XML-парсер мог проверить байты и построить дерево. Это всё ещё не доказывало, что namespace поддерживается, профиль соблюдён, подпись доверена, а подписант уполномочен запросить действие.

Элемент delete не получает право удаления только потому, что он well-formed. Приложение определяет смысл, политика проверяет субъект, исполнитель пытается выполнить операцию, а последующее наблюдение подтверждает эффект. Суффикс также не разрешает внешние entities, сетевые обращения, stylesheet или неограниченное потребление ресурсов. Это локальные решения безопасности.

+xml был полезен именно потому, что позволял повторно использовать грамматику и не заставлял принимать чужую семантику.

Соглашение стало частью регистрационной системы

RFC 6838 встроил structured syntax suffix в архитектуру типов media: символы после последнего плюса указывают зарегистрированный общий синтаксис. RFC 6839 формально зарегистрировал +xml и разделил уровни. Точный тип даёт специальную семантическую обработку; суффикс допускает общую обработку представления, когда специальный смысл не нужен и parser не требует дополнительных знаний.

RFC 7303 заменил RFC 3023, но сохранил принцип. Новые XML-форматы должны использовать +xml, если общий XML-процесс не противопоказан. Получатель может обнаружить суффикс, вызвать parser для проверки предположения и затем выбрать дальнейший путь. Отображение, редактирование, безопасность, runtime и fragment остаются правилами конкретного типа.

Современные реестры IANA показывают оба слоя: одна запись описывает +xml, а множество разных полных типов заканчиваются им. Общее окончание доказывает родство представления, но не взаимозаменяемость.

Источники

Lu Heng не писал и не одобрял RFC 3023. Его тексты используются здесь как явно раскрытые аналитические рамки.