Кратко

  • Редакция 28 Concise Diagnostic Notation систематизирует человекочитаемую запись CBOR и зарегистрированные расширения, но не превращает исходный текст в самодостаточный договор исполнения.
  • Для критичного процесса нужен протокол интерпретации: редакция, снимок реестра, спецификация, реализация и версия расширения, разрешения, проигнорированные индикаторы, предупреждения, итоговое значение и при необходимости хеш байтов.

Диагностическая запись ценна тем, что человек видит структуру без предварительного разбора бинарного CBOR. Ошибка начинается тогда, когда читаемость принимают за доказательство полного смысла.

Internet-Draft Concise Diagnostic Notation рабочей группы CBOR IETF объединяет текстовую запись модели данных CBOR. Строка с префиксом вызывает прикладное расширение. h и b64 могут создавать байтовые строки, dt обрабатывает время, ip — адреса и префиксы. Последовательность с префиксом передаёт параметры и выдаёт один элемент данных.

В исходнике, однако, указано только требуемое имя. Он не доказывает, какой снимок реестра разрешил это имя, какая спецификация применялась, какой пакет и версия исполнялись и разрешил ли оператор вызов. Параметры запуска, плагины, allowlist и хранение предупреждений остаются за пределами файла.

Редакция 28 прямо проводит эту границу. CDN предназначена для людей и не является детерминированным представлением. Путь от значения к тексту и обратно не обещает той же записи или тех же закодированных байтов. Если на аргументе расширения есть индикатор кодирования, которому расширение не задаёт специальной обработки, потребитель обязан принять его — обработать либо проигнорировать; в последнем случае рекомендуется предупреждение. Значит, успешный разбор не подтверждает, что каждый видимый знак повлиял на результат.

Раздел безопасности требует не допускать вызова злоумышленником расширений, которые оператор не собирался открывать. Явное включение и список разрешений являются допустимой границей; решение принимается вне документа. Два интерпретатора могут знать одну грамматику и поступить по-разному, потому что их владельцы выдали разные полномочия.

Имя координирует, но не исполняет

Проект создаёт реестр идентификаторов и требует реализации h, b64, t1, b1, dt и ip. Общий словарь уменьшает коллизии, но запись реестра, спецификация, код и политика развёртывания остаются разными фактами.

Политика реестра — Expert Review. Текст допускает, что полной спецификации ещё нет, а уже используемое имя регистрируют для предотвращения конфликта. Поэтому «зарегистрировано» подтверждает координацию имени, но не полноту семантики, единообразие библиотек, безопасное включение или право на последующее действие.

Представим, что среда разработки автоматически включает все установленные расширения, а производственная среда разрешает минимум. Один и тот же файл создаёт значение в первой и отклоняется во второй. Хеш и имя совпадают; различается локальное решение. Без снимка allowlist аудит не объяснит результат.

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

Редакция, которая сама просит осторожности

Datatracker показывает редакцию 28 как активный Internet-Draft группы CBOR на этапе Working Group Last Call со статусом IESG «I-D Exists». Это не RFC и не утверждённый стандарт.

Замороженные источники расходятся даже в предполагаемом статусе: заголовок текста говорит «Standards Track», API Datatracker — «Informational». Статья не выбирает один вариант и не выдаёт его за окончательное решение.

Примечание редакции сообщает, что версия 28 отражает удаления функций, обсуждавшиеся в рассылке, как дельту к версии 27. Оно называет текст частично несогласованным, предупреждает о потенциально вводящих в заблуждение объяснениях и фиксирует отсутствие мнения группы по названиям CDN и b1/t1. Сравнение действительно удаляет расширение CRI, реестр индикаторов кодирования и бинарные тегированные представления входа CDN.

Поэтому заявления «поддерживает редакцию 28» недостаточно. Нужно доказать, исчезли ли удалённые функции из кода, остались ли за флагом совместимости, какой снимок реестра использовался и какие действия соответствуют актуальному техническому содержанию.

Семь свидетельств вместо одного флага

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

Каждый слой меняется независимо. Источник остаётся прежним при обновлении пакета. Реестр не меняется, а локальная политика меняется. Значение сохраняется, байты различаются. Совпадение байтов ещё не даёт приложению полномочий изменить сеть или устройство.

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

Протокол заканчивается на выходе интерпретатора. Проверка схемой, подпись, авторизация, изменение сети и бизнес-результат требуют отдельных свидетельств. Единый флаг «валидно» скрывает место расхождения.

Источники не доказывают внедрение, измеренную совместимость, поведение продукта, уязвимость, инцидент, производительность или сбой. Аргумент не зависит от выдуманных случаев. Модель расширений, возможность игнорировать индикатор, правила реестра, внешнее включение и недетерминированность уже показывают распределённый контроль.

RFC 8949, RFC 8610, RFC 4648 и RFC 3339 описывают CBOR, CDDL, базовые кодировки и время. Они не доказывают одинаковые код и настройки двух установок. RFC 9741 касается детерминированной кодировки уже выбранного значения, а не выбора значения расширением.