Кратко

  • В индивидуальном Internet-Draft о Canonical Action Identifier редакции -04 от 28 сентября 2026 года прямо сказано: для объектов, допустимых и по -03, и по -04, набор алгоритмов, хеш и каноническая форма не меняются.
  • При этом новая редакция отвергает некоторые объекты, имевшие действительный CAID по предыдущим правилам. При воспроизведении старого решения нужны его правила и снимок определения, а не только строка идентификатора.

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

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

Именно такой контур проявился в четвёртой редакции предложения Iman Schrock. CAID пытается сопоставлять материально одинаковые действия, даже когда разрешительные, исполнительные и аудиторские документы кодируют их по-разному. Для этого проект описывает типизированный объект действия, канонизацию и хеширование, компактную строку идентификатора, а также определения типов с обязательными значимыми полями. Datatracker IETF показывает статус индивидуального Internet-Draft без формального положения в процессе стандартизации. Это не RFC, не подтверждение принятия рабочей группой и не отчёт о внедрении или сбое в какой-либо сети.

Раздел 14 особенно аккуратно разводит непрерывность и изменение. В нём говорится, что редакция -04 существенно уточнила модель обработки. Одновременно наборы алгоритмов, хеш и каноническая форма остаются прежними для любого объекта, который принимают обе редакции. Последнее условие нельзя опускать. Часть старых входных данных больше не относится к общему множеству. Раздел 14.1 прямо сообщает о ранее действительных CAID у некоторых вновь отвергаемых объектов. Среди примеров — вложенность глубже 64 уровней, каноническая кодировка больше 16 777 216 октетов, строки с кодовыми точками Unicode категории noncharacter и отдельные формы временных меток со строчными t или z либо секундой 60. Не следует выдавать эти предельные случаи за обнаруженный инцидент. Но нельзя и обещать совместимость всех старых записей только потому, что хеш общих случаев не изменился.

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

Редакция -04 добавляет definition_sha256 — хеш проекции определения типа, влияющей на проверку. Можно указать ожидаемое определение и получить definition_mismatch при несовпадении. Даже одинаковое название типа поэтому ещё не доказывает, что два участника считают материальными одни и те же поля. Справочный реестр автора перешёл к версии 5, а файл версии 4 оставлен в истории без изменения байтов. Сохранение старого файла полезно для повторяемости; это не означает, что семь запрошенных проектом реестров IANA уже учреждены или используются всеми участниками.

Новая редакция точнее определяет чтение JSON, порядок причин отказа и обработку неподходящих определений. В частности, повторяющиеся имена членов JSON теперь отвергаются, даже когда совпадение обнаруживается после разбора escape-последовательностей. Но сводить смысл изменений к одному случаю дублирования было бы ошибкой. Предмет управления здесь — не только синтаксис. Нужно доказать, на каком основании независимые системы решили, что их действия вообще можно сравнивать, прежде чем считать совпадение устойчивым мостом между разрешением и исполнением.

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

Daniel Kade предлагает для будущих внедрений сохранять версионную квитанцию проверки. В ней должны быть исходный объект или проверяемая ссылка на него, CAID и набор алгоритмов, версии парсера и реализации, хеш определения либо снимок реестра, результат и причина отказа, а также отдельное решение о миграции. Это редакционная рекомендация по учёту, не обязательное поле Internet-Draft. Она позволяет отличить изменение объекта от изменения определения, парсера или местной политики, не объявляя короткий идентификатор доказательством полномочий.

Источники