Кратко

  • W3C выделил w3.org/2026/08/xmldsig-more# для XML Security, однако страница ведёт на последнюю версию черновика, а не на пронумерованную редакцию с хешем.
  • Редакция -08 ещё использовала w3.org/tbd#; -09 от 21 августа впервые подставила новый URI и внесла другие изменения. Страница W3C была обновлена двумя днями раньше.
  • Собственное руководство W3C предлагает указывать, как имена могут определяться или удаляться и кто это решает. На новой странице такой политики нет; молчание не доказывает ни изменяемость, ни неизменяемость.
  • Конституция изменений должна связать выделение адреса с версией и хешем, описать допустимые правки до заморозки, совместимость и решающую сторону, назвать событие заморозки и разнести состояния W3C, IETF и IANA.
  • Нет оснований говорить о недействительном выделении, одобрении алгоритмов, принятии IETF, задержке IANA или провале сотрудничества. Проблема состоит в читаемости цепочки полномочий.

Два дня между указателем и его содержимым

Страница W3C сообщает, что URI выделен XML Security, связывает его со спецификацией через Datatracker RFC 9231bis и называет Simone Onofri и 19 августа 2026 года датой последней правки. Номер редакции, хеш, публичное решение о выделении и правила для локальных имён не приведены.

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

Но ссылка на latest решает только задачу поиска настоящего. Она не восстанавливает прошлое разрешение. Читатель не видит, какие байты рассматривались и какие более поздние правки допускались без нового решения.

Публичная координация сменила форму

Issue 484 в W3C Strategy появилось 17 ноября 2024 года как предложение провести семинар по постквантовой криптографии для XML Signature и XML Encryption. Это свидетельство открытой координации, но не Recommendation, устав или формальное решение.

21 ноября 2024 года автор индивидуального черновика предложил добавить алгоритмы в RFC 9231bis. 14 июня 2025 года в обсуждении перечислили HSS/LMS, ML-DSA, SLH-DSA и ML-KEM и предположили, что issue может заменить семинар. Предложение автора и рабочий список помогают процессу, но не создают консенсус W3C или принятие IETF.

17 августа 2026 года участники отметили, что -08 включает четыре отслеживаемых семейства, а для -09 готовится дополнительный материал. Страница пространства имён имеет дату 19 августа. Автор объявил -09 21 августа. 26 августа назначение issue описали уже не как подготовку семинара, а как отслеживание потребностей обновления XML Signature и XML Encryption.

Такая смена маршрута — нормальное свойство живой работы. Она не свидетельствует о провале. Но именно поэтому разрешение на пространство имён должно иметь собственный версионный след: место дискуссии и текст меняются, URI остаётся.

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

Заголовок черновика и Datatracker отвечают на разные вопросы

Datatracker показывал -09 как активный индивидуальный Internet-Draft в состоянии I-D Exists, без определённого RFC stream и ответственного Area Director. Публикация индивидуального черновика — нормальная открытая работа, но не принятие IETF.

В заголовке документа стоят Independent, Obsoletes: 9231 (if approved), предполагаемый Standards Track и срок до 22 февраля 2027 года. Это заявленная цель автора и условный будущий эффект. Datatracker фиксирует институционально атрибутируемое настоящее. Ошибкой одного другое не становится.

Архивная редакция -08 от 26 мая использовала w3.org/tbd#. Её SHA-256 — cd9d7a31d66dabcb692b2bba3804102b5bba9e3376b999b0cb1404a20ff7f10f.

Редакция -09 от 21 августа заменила маркеры на w3.org/2026/08/xmldsig-more#, добавила schema нового пространства и другие материалы. Её SHA-256 — 09d36d24b05cbc0c1be1579d65fab88e6f9b6cfc13f214d55d4eeed42ad3866b.

Публичная история редакций подтверждает даты 26 мая и 21 августа, не показывая принятия Working Group, назначения stream или Area Director.

Итак, установлена последовательность: временный адрес в -08, страница W3C 19 августа, настоящий URI в -09 21 августа. Дата самого решения, рассмотренные байты и охват прочих правок -09 не установлены.

У трёх организаций три разных действия

Одобренной опорой остаётся RFC 9231. Он документирует предыдущее поколение и уже отделяет идентификатор от официального статуса алгоритма в W3C или IETF.

Реестр IANA XML Security URIs по-прежнему правильно ссылается на RFC 9231, использует Specification Required и назначенных экспертов. Пока преемник не одобрен или нет другого действительного основания, это ожидаемое состояние, а не отставание.

W3C хранит URI в своём веб-пространстве. Документный процесс IETF может развивать, принимать, проверять и, возможно, одобрять спецификацию. IANA применяет политику реестра. Автор редактирует текст, но не получает власть над политикой W3C. W3C выделяет адрес, но не одобряет RFC. IANA регистрирует идентификатор, но не предписывает внедрение.

Нужна карта передачи между этими компетенциями, а не их слияние.

Общая политика W3C уже формулирует недостающий тест

Руководство W3C по пространствам имён признаёт датированные формы и говорит, что @w3c/transitions выделяет и разрешает их через pull requests в w3c/ns. Стабильность во время обсуждения полезна, а выделение не является одобрением.

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

Finding TAG уточняет: если пространство не неизменно, спецификация должна описать, как имена определяются или удаляются и кем. Без прямого заявления неизменность нельзя выводить.

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

Политика постоянства URI W3C охватывает датированные ресурсы, но допускает изменения с архивированием прежних состояний. Постоянство адреса не равно заморозке набора имён.

Этого недостаточно, чтобы объявить нарушение. Допустимое решение может существовать вне страницы. Требование уже: показать правило там, где пользователь ожидает его по руководству W3C.

У прошлых поколений есть названная точка заморозки

В -09 префикс 2000 года назван “Frozen by W3C”, а поколения 2001, 2007 и 2021 годов связаны с заморозкой через RFC 4051, RFC 6931 и RFC 9231. Заморозка — атрибутируемый переход.

Для поколения 2026 не сказано, можно ли до RFC добавить или удалить имя, резервируется ли уже используемое написание, замораживает ли одобрение RFC автоматически, требуется ли отдельный акт W3C и нужен ли новый датированный префикс для последующего расширения.

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

URI не оценивает криптографию

XML Signature 1.1 и XML Encryption 1.1 объясняют, зачем XML-структурам совместимые идентификаторы. Они не одобряют автоматически любой будущий алгоритм с URI.

RFC 8126 описывает Specification Required как постоянную публичную спецификацию плюс экспертную проверку. Это правило допуска записи, а не всеобщий сертификат безопасности или команда внедрения.

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

Короткая конституция изменений

В первой части должны быть URI, датированный класс, решение о выделении, субъект, дата и публичный pull request или transition record. Версия и хеш, рассмотренные при выделении, указываются отдельно от версии, на которую страница ссылается сейчас.

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

В третьей называются событие заморозки, решающий субъект и время. Правило после заморозки определяет: тот же префикс, IANA Expert Review, errata, RFC-преемник или новое датированное пространство.

Отдельные поля показывают хранителя W3C; класс, группу, stream, принятие и Area Director документа IETF, когда они появятся; состояние, политику и область экспертов IANA. Источник синтаксиса идентификатора отделяется от источника семантики алгоритма. Исправления, преемственность, истечение и следующая проверка замыкают историю.

Выделение пространства, публикация черновика, принятие IETF или stream, одобрение RFC, обновление IANA и внедрение — шесть разных действий. Одно не заменяет другое.

Частные обсуждения и чувствительные отчёты можно не раскрывать. Достаточно версии, полномочия, класса изменения и перехода.

Речь о читаемости, а не о нарушении

Публичное дело содержит открытое обсуждение, сохранённые редакции, постоянный URI W3C, корректное состояние IANA и явный отказ считать идентификатор одобрением. Нет доказательств злого умысла, захвата, неправомочной регистрации или разрушенного сотрудничества.

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