Кратко

  • 17 августа 2026 года IESG одобрил draft-ietf-regext-ext-registry-epp-10 для публикации в статусе Best Current Practice. Документ усиливает требования к описанию, экспертизе и сопровождению расширений EPP, но не превращает каталог IANA во всемирную таблицу возможностей серверов.
  • Active подтверждает внедрение и использование как минимум одной парой «реестр — регистратор» или «сервер — клиент». Объявление URI целевым сервером, права конкретного клиента и успех операции требуют отдельных доказательств.

Верный факт ответил не на тот вопрос

Начальная ситуация условна и не описывает сбой конкретного реестра или TLD. Она показывает типовую ошибку автоматизации: достоверное институциональное сведение применяется как разрешение на эксплуатацию.

Реестр IANA отвечает на вопросы координации. Как называется расширение? Где находится стабильная спецификация? Кто отвечает за запись? Какова заявленная область TLD? Какие сведения об интеллектуальных правах раскрыты? Каковы статус и примечания? Такой каталог помогает находить существующую работу и предотвращать конфликты пространств имён.

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

Поэтому корректная регистрация совместима с отсутствием URI в приветствии. Объявленное расширение может быть недоступно одному клиенту. Даже согласованная сессия не отменяет отказа по местной политике.

Что именно улучшает решение IESG

Одобренный документ называется “Extension Registry for the Extensible Provisioning Protocol”. До выпуска RFC Editor версия 10 остаётся Internet-Draft. Она должна заменить RFC 7451 и повысить статус процедуры с Informational до BCP.

Публичное обсуждение переносится со старого списка eppext в REGEXT. Новые заявки не смогут ссылаться на Internet-Draft как на постоянную спецификацию; механизм раннего выделения RFC 7120 неприменим. Ссылка должна быть устойчивой и легко доступной, а в реестре необходима английская версия, даже если существуют другие языки.

Политикой остаётся Specification Required из RFC 8126. IANA передаёт заявки назначенным экспертам. Они оценивают архитектуру, описание безопасности и конфиденциальности. Конфликт интересов требует самоотвода, а неразрешённые возражения возвращаются в публичное обсуждение.

Уточнено управление URI. XML-схемы, URI схем и пространств имён должны быть синтаксически и семантически корректны и зарегистрированы по RFC 3688. Пространства IETF зарезервированы для документов потока IETF; собственная или независимая спецификация использует подходящее не-IETF пространство.

Запись становится надёжнее как технический ориентир: её проще однозначно определить и реализовать по устойчивому источнику. Но экспертиза не проверяет каждый работающий сервер.

У Active есть смысл и границы

Запись содержит название, статус документа, ссылку, регистранта, поле TLD, раскрытие IPR, рабочий статус и примечания. Для спецификации, не являющейся RFC, применяется Other, чтобы не приписывать ей точный смысл Informational RFC.

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

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

Поле TLD столь же ограничено. Конкретный TLD отражает заявленную область; Any сообщает, что расширение не связано с одним TLD; N/A — что оно не относится к обработке доменных имён. Any не значит «обязательно и повсеместно».

Безопасная система хранит не только «зарегистрировано» и «активно», но также источник, место и время наблюдения. Иначе точный каталог превращается в необоснованный глобальный переключатель.

Сходные функции не обязаны исключать друг друга

EPP сочетает небольшое общее ядро с точками расширения, поскольку реестры работают по разным техническим и коммерческим правилам. Похожие задачи закономерно получают разные расширения. RFC 7451 в том числе сделал такое пересечение заметным.

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

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

Операционная цепочка полномочий начинается с приветствия

RFC 5730 определяет приветствие EPP. Меню услуг перечисляет версии и языки, URI управляемых объектов и, при наличии, URI расширений. Сервер также вправе ограничивать управление объектами по клиенту.

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

Даже после этого будущие команды не гарантированы. Коды EPP различают запрет местной политики, зависимость объектов, семантически неверное по правилам сервера значение, нереализованную услугу, нарушение правил данных, временный или окончательный сбой. Единственный флаг «поддерживается» стирает причины, необходимые для управления.

Надёжная лестница доказательств выглядит так: зарегистрированная спецификация; текущий статус; свежее приветствие целевого сервера; успешное согласование для нужного клиента; принятая форма команды; успешная транзакция; проверенное состояние объекта. Каждая ступень подтверждает более узкое утверждение.

Текущий вид реестра не является историей

Процедура предусматривает добавление, изменение, деактивацию и удаление. Для удаления записи IETF consensus нужно IESG Approval. Другие записи удаляются или деактивируются с одобрения IESG либо по просьбе первоначального регистранта после консультации с экспертами. Исчезнувшего ответственного может заменить исправление контактных данных экспертом.

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

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

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

Источники