Кратко

  • 28 сентября 2026 года опубликована редакция 09 проекта IETF о сериализации CBOR. Её заголовок обещает обновить RFC 8949 в случае утверждения; пока это Internet-Draft на этапе последнего обсуждения в рабочей группе.
  • Раздел 7 предлагает запретить будущему тегу изменять типы данных за пределами собственного определения. Старые теги 2 и 3 для больших целых чисел специально выведены из-под правила.
  • Запрет содержался и в редакции 08. Новая редакция яснее обозначает предполагаемую связь с RFC и просьбы к IANA, но не превращает их в принятые изменения.

Что даёт номер в реестре

Действующий RFC 8949 описывает модель данных CBOR и способы их кодирования. Реестр IANA указывает для каждого тега тип элемента и его значение. Номер позволяет декодеру понять помеченный элемент. Но из появления нового номера не следует, что все обычные целые числа или строки без этого тега теперь надо понимать иначе.

Редакция 09 пытается сделать такое ограничение нормативным. Согласно её разделу 7, новые определения тегов не должны включать, менять или затрагивать другие типы данных. Если несколько тегов должны взаимодействовать, текст допускает это при явном согласии всех сторон, ответственных за их определения. У одного автора расширения не возникает одностороннего мандата на изменение общего словаря.

Отдельный случай — теги 2 и 3 из RFC 8949. Они представляют положительные и отрицательные большие целые числа, тем самым расширяя диапазон уже имеющегося целочисленного типа. Проект сохраняет это историческое устройство и прямо оговаривает исключение. Однако старое исключение не должно становиться общей лицензией для следующих регистраций. При экспертизе новой спецификации важно установить, какой тип она определяет сама и требует ли она незаметно пересмотреть смысл данных без нового тега.

Граница между заявкой и решением

В заголовке редакции 09 теперь написано Updates: 8949 (if approved). Раздел 10 просит IANA добавить ссылку на раздел 7 в реестр тегов CBOR и зарегистрировать оператор CDDL .serial. Просьба не равна внесённой записи. В открытом реестре общие правила регистрации по-прежнему ссылаются на RFC 8949. Документ также ничего не говорит о том, что реализации уже приняли предлагаемое правило.

Хронология ограничивает новостной вывод. В редакции 08 правило о новых тегах и исключение для больших чисел уже присутствовали. Список недавних документов IETF подтверждает дату новой версии и статус Working Group Last Call. Этот статус не является ни выпуском RFC, ни одобрением IESG, ни свидетельством исправленного поведения на работающих системах.

В проекте есть и другая тема: сериализация «preferred-plus» и детерминированная сериализация. Она касается выбора байтового представления. Полномочие определять смысл типа — отдельная плоскость. Упорядоченные в кодировке ключи карты не делают порядок свойством декодированной карты. Поэтому вопрос этой публикации отличается от предыдущего исследования о том, почему разные допустимые последовательности байтов имеют разные полные хеши.

Источники