Кратко

  • RFC 9682 снимает требование иметь правило внутри каждого исходного CDDL-файла, но сохраняет семантическое условие: после обработки директив модель должна иметь правило входа.
  • При модульной сборке одного сохранённого файла недостаточно для воспроизводимой приёмки. Нужно знать, какие зависимости были найдены, какой корень выбран и какая модель получена.

Самый удобный способ пройти устаревшую проверку — добавить то, что она хочет увидеть. Если проверка требует хотя бы одно правило в файле, можно дописать правило. Формальная проблема исчезнет, даже если новая строка ничего не говорит о реальной модели, которую собирались использовать.

Именно поэтому обновление технической грамматики иногда требует пересмотра управленческого документа. Не всякое ослабление ранней проверки означает снижение требований. Возможно, прежний объект проверки перестал быть целым и стал лишь исходным материалом для целого.

В CDDL такая перемена сформулирована достаточно точно, чтобы не оставлять места двум удобным крайностям. Нельзя требовать от каждой части самостоятельности, которая ей не нужна. Нельзя и объявлять завершённую модель пригодной, если необходимая точка входа так и не появилась.

Что изменилось на уровне синтаксиса

В ABNF нижняя граница повторения может быть указана явно. Если она равна единице, нужно хотя бы одно вхождение; если не указана, допускается ноль. Это определяет принимаемый синтаксис, а не завершённость практической задачи. RFC 5234, раздел 3.6

Опубликованный в ноябре 2024 года RFC 9682 допускает CDDL-файл без правил: все они могут поступить из модульных директив. Раздел 3.1 оставляет наличие правила входа семантическим условием после обработки всех директив. В информативном приложении B.2 также выбран отдельный последующий этап обработки содержимого квалифицированных байтовых строк. Перенос обработки не означает произвольности результата. RFC 9682

Речь здесь не о том, что данные правильной формы могут оказаться недостоверными. Вопрос возникает раньше: сформирована ли сама применимая модель? Пустой исходный CDDL-файл не равнозначен готовому валидатору, который принимает любые данные.

В базовом CDDL корнем становится первое определённое правило. Оно должно задавать тип, а не группу; буквальное имя start не обязательно. Разработчики приложения отдельно выбирают глубину проверки данных. Эта свобода не отменяет условия, предъявляемого к формированию модели. RFC 8610, разделы 2.2.4, 4.2 и 5

Поэтому ответ «правило уже есть» полезен, но недостаточен. Какое именно правило стало корнем? Для какого применения оно выбрано? Можно ли повторить выбор, не обращаясь к человеку, который однажды запускал сборку? Случайная добавленная строка не отвечает ни на один из этих вопросов.

У модели есть контекст, которого нет во вложении

На 7 сентября 2026 года рассмотренный проект модульной структуры — draft-ietf-cbor-cddl-modules-07 от 2 сентября. Это рабочий Internet-Draft, не опубликованный RFC. Документ 2024 года ссылался на более раннюю версию проекта.

Директивы оформлены так, что базовые инструменты могут читать их как комментарии. Это позволяет проектировать файлы для обоих вариантов использования, но не обещает одинаковую модель там, где один инструмент выполняет необходимую директиву, а другой игнорирует её. Проект различает включение правил и импорт с переходом по зависимостям. CDDL Module Structure, версия 07

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

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

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

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

Сохранять нужно не только начало сборки

Практическое предложение состоит в том, чтобы связать исходное содержимое, настройки поиска, версию процессора, выбранный корень и полученную модель в воспроизводимой записи сборки. Это редакционная рекомендация, а не дополнительная административная обязанность, установленная IETF.

Такая запись помогает и при успехе. Рабочий каталог впоследствии могут очистить, встроенную коллекцию обновить, а специалиста заменить. Тогда главный файл останется, но объяснение принятого решения будет зависеть от утраченных условий. Стоимость восстановления обычно проявляется позже стоимости сохранения.

Следует разделять три результата: синтаксис файла принят, зависимости обработаны, готовая модель имеет ожидаемый вход. Их может выдавать один инструмент и проверять одна команда. Нужны не три новые инстанции, а точное описание того, что действительно подтверждено.

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

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