Кратко

  • Проект, который должен заменить RFC 7451, предлагает назначенным экспертам действовать разрешительно, если расширение EPP внедрила хотя бы одна пара «реестр/регистратор» или «сервер/клиент». Несколько расширений с одинаковой или похожей функцией могут быть зарегистрированы, и одно лишь сходство не служит причиной для отказа.
  • Запись подтверждает наличие постоянной спецификации, технического идентификатора и подотчётной процедуры рассмотрения. Она не выбирает лучший проект, не присваивает статус Standards Track, не доказывает массовое распространение и не гарантирует взаимозаменяемость в конкретной системе.
  • Действующий реестр IANA уже показывает сосуществование: расширения CORE для IDN и приватности названы синтаксически и функционально идентичными соответствующим расширениям TANGO, хотя используют другие пространства имён XML. Для решений нужна карта, которая удерживает сходство и различие одновременно.

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

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

Редакция 10 draft-ietf-regext-ext-registry-epp, опубликованная 17 августа 2026 года, проводит эту границу прямо. В реестре могут находиться несколько расширений с одинаковой или сходной функциональностью. Нельзя отклонять корректную заявку только из-за такого сходства. Если механизм внедрила хотя бы одна пара «реестр/регистратор» — в более общем виде «сервер/клиент», — экспертам следует быть разрешительными.

Этот порог отделяет реальное внедрение от заявки на будущее имя. Он не измеряет лидерство.

Одна рабочая пара — ровно одно доказательство

EPP существует в диалоге. Возможность на сервере бесполезна, если её не понимает клиент, и наоборот. Поэтому рабочая пара — разумная минимальная единица: спецификация прошла через границу двух реализаций и породила настоящую транзакцию.

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

Active также не означает повсеместную доступность. По проекту активное расширение реализовано и используется. Inactive означает отсутствие реализации или использования либо недоступность спецификации. Это состояние жизненного цикла, а не доля рынка. В таблице нет числа установок, интенсивности использования или показателя надёжности.

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

Политика защищает объяснимость пространства имён

Режим Specification Required из RFC 8126 требует постоянной общедоступной спецификации и проверки назначенными экспертами. Новый проект допускает RFC и устойчиво доступные собственнические спецификации, причём нужна английская версия. Обычный Internet-Draft не считается постоянной ссылкой для будущей регистрации; раннее выделение по RFC 7120 здесь не применяется.

Такой барьер нужен не для сертификации победителей, а для памяти. Обнаружив пространство имён XML в старом журнале, разработчик должен узнать, что оно означало. Поэтому реестр хранит название, статус документа, ссылку, заявителя, TLD, сведения об интеллектуальной собственности, Active/Inactive и примечания.

Экспертная проверка содержательна. Она охватывает архитектурную состоятельность, документирование приватности, синтаксис и семантику URI, правильный выбор пространства имён IETF или не-IETF. Обычно заявку ведёт основной эксперт. Если он недоступен, резервная группа принимает решение простым большинством при достижении консенсуса. Эксперт с предполагаемым конфликтом обязан отойти; сложный вопрос можно вынести на открытую рассылку REGEXT.

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

Сам документ о новой процедуре ещё не стал RFC. Десятая редакция — активный Internet-Draft с предполагаемым статусом Best Current Practice, переданный IESG и ожидающий назначения редактора в очереди RFC Editor. После одобрения и публикации он должен сделать RFC 7451 устаревшим. До этого момента правила могут измениться, и статус проекта нельзя повышать задним числом.

CORE и TANGO занимают соседние, но не общие координаты

Действующий EPP Extension Registry IANA обновлён 4 сентября 2026 года. В нём соседствуют документы Standards Track и категории Other, активные и неактивные записи. Примечания к CORE и TANGO позволяют увидеть смысл этой неоднородности.

Для IDN расширение CORE описано как синтаксически и функционально идентичное аналогу TANGO, но использующее другое пространство имён XML. Аналогичное примечание дано расширениям приватности обеих семей.

Различие пространства имён нельзя отбросить как косметику. Оно входит в идентичность сообщения. Клиент, формирующий элементы TANGO, не получает автоматической совместимости с сервером, который знает только CORE. Сервер может поддерживать один вариант, оба или ни одного. Могут расходиться тесты, циклы версий, органы управления изменениями и область фактической установки.

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

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

Карта сосуществования для практического выбора

Таблица IANA должна оставаться источником факта регистрации. Для поддержки и миграции нужна дополнительная аналитическая поверхность — карта сосуществования. Это предложение автора статьи, а не новое требование IETF или IANA.

Сначала карта группирует расширения по устойчивой функции: IDN, приватность, запуск, тарифы и другие классы. При этом она не сливает XML-пространства, а показывает версию спецификации и затронутые команды. Затем фиксирует происхождение регистрации: постоянный документ, его статус, заявителя, дату и путь экспертного решения.

Внедрение получает собственную карточку: конкретный сервер и клиент, программа, версия, TLD и дата. Если доказана одна пара, так и пишется — одна пара. Для сходства указывается источник: примечание IANA, заявление авторов, сравнение схем, тест на совместимость или наблюдение в работе. Отдельно обозначается, охватывает ли проверка ошибки и необязательные элементы.

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

Тогда четыре утверждения перестают подменять друг друга: зарегистрировано; где-то внедрено; поддерживается у нас; взаимозаменяемо с другим расширением в этом сценарии. Наличие строки напрямую подтверждает первое, но не остальные три.

Чистая таблица может сделать прошлое нечитаемым

Проект различает добавление, изменение, деактивацию и удаление. Для смены статуса нужно обоснование. Удаление записи, появившейся через консенсус IETF, требует одобрения IESG. Не-IETF-запись может удалить или деактивировать IESG либо первоначальный заявитель во взаимодействии с экспертами.

Одновременно проект признаёт: у реестра нет механизма истории, а удалённую запись потом нельзя отследить в нём. Поэтому обслуживание каталога непосредственно влияет на сохранность доказательств.

Inactive предупреждает против новой зависимости, оставляя координату для старого ПО и журналов. Удаление убирает координату из текущего вида. Если исчезнет и спецификация, позднее расследование не отличит допустимое старое расширение от ошибки версии или частной конструкции.

Текущий реестр координирует настоящее. Датированные снимки делают прошлое объяснимым. Без второго слоя сегодняшняя аккуратность становится завтрашней эксплуатационной амнезией.

Источники