Кратко

  • В RFC 3632 текущий спонсор применял -Approve:No, чтобы отклонить перенос, а первоначальный заявитель — чтобы отменить собственную заявку. Значение задавали аутентифицированный субъект, роль, предыдущее состояние и момент времени.
  • 200 Command completed successfully доказывает успешную обработку команды RRP. Это не доказательство воли владельца, человеческого согласия, публикации DNS или результата услуги.
  • Полноценная квитанция связывает сессию, роль, объект, состояние до операции, правило, срок, ответ, состояние после и внешнее уведомление. Точный payload без этих связей теряет ответственность.

Временная шкала без действующего лица

RFC 3632 опубликован в декабре 2003 года как информационное описание RRP 2.0.0. Это не Internet Standard и не рекомендация внедрять RRP сегодня. Документ важен здесь как редкий чистый пример: текст команды не содержал всей семантики действия.

Текущий спонсор отправлял -Approve:No, чтобы отклонить запрос другого регистратора. Инициатор переноса отправлял те же символы, чтобы отозвать свой запрос. Отказ распоряжается чужой заявкой; отмена прекращает собственную. Поэтому для спора недостаточно знать, что в сообщении было «No».

Карточка RFC Editor, IETF Datatracker, история документа и поиск errata подтверждают публикационный статус. Они не подтверждают внедрение или исход конкретной операции.

Роль выводилась из сессии и объекта

RFC 2832 определял идентичность запрашивающего регистратора по активной аутентифицированной сессии. Реестр одновременно знал текущего спонсора домена. Допустимое действие возникало из соединения principal, его отношения к объекту и состояния переноса.

Самоописание внутри payload не создало бы таких полномочий. Поле делает утверждение; сессия удостоверяет отправителя; запись реестра определяет его роль. Попытка одобрить или отклонить перенос от постороннего регистратора должна была завершиться ошибкой.

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

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

Право на отмену исчезало по таймеру

RFC 3375 разделял роли: заявитель инициирует перенос и может отменить его до решения; текущий спонсор одобряет или отклоняет; неуполномоченные попытки отвергаются; обе стороны наблюдают pending и завершённые состояния.

RFC 3632 добавил отмену в RRP, переиспользовав отрицательное значение approve. Команда должна была поступить до явного решения спонсора и до неявного решения реестра после истечения установленного срока.

Время было входом авторизации. Нужны серверный момент приёма, база часов, версия timer policy, событие закрытия pending и состояния по обе стороны операции. Клиентская метка не показывает порядок на сервере, если связь часов не доказана.

После закрытия pending прежнее право уже не существует. Новый процесс может исправить положение, но не возвращает старую возможность отмены. Если хранится только финал, нельзя отличить поздний cancel от гонки с таймером или законного reject.

Ответ 200 говорит от имени одного слоя

В примере RFC 3632 сервер возвращает 200 Command completed successfully. Это сильная квитанция о выполнении RRP-команды. Её граница не делает её слабой; она делает её точной.

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

В On Authority and Belief Lu Heng предлагает проверять издателя, объект и предел утверждения. Реестр авторитетно говорит о своей обработке. Он не может через status code засвидетельствовать намерение клиента или состояние всей сети.

Поэтому отчёт должен отдельно показывать авторизацию клиента, действие регистратора, sponsorship в реестре, публикацию DNS и наблюдение сервиса. Связь между ними нужна; подмена одного другим — нет.

EPP сделал действие явным

RFC 5731 различает request, cancel, approve, reject и query. Pending transfer может раскрывать запрашивающего клиента и дату запроса, действующего клиента и дату действия. RFC 5730 добавляет client и server transaction identifiers.

Такой интерфейс потенциально оставляет более понятную квитанцию. Аналитику не приходится восстанавливать два глагола из одного «No». Но поля не гарантируют сохранность: сборщик может отбросить ID, часы могут расходиться, клиент-заявитель не равен владельцу, ответ EPP не является наблюдением DNS.

RFC 3730 описывает более раннее поколение EPP. Сравнение показывает эволюцию выразительности, но не доказывает миграцию или соответствие конкретной организации.

Код 510 ограничен проверкой представления

RFC 3632 ввёл код 510 для недопустимой кодировки доменного имени в ADD или MOD. Более поздний RFC 5890 даёт развитую терминологию IDNA.

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

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

IPv6 в объекте не означает доступность

RFC 3632 разрешил полную и сокращённую запись IPv6 в объектах nameserver. RFC 4291 определяет архитектуру адресации; RFC 5952 позже рекомендует каноническую текстовую форму.

Принятие строки, сохранение объекта, публикация в parent или root zone, наличие маршрута, авторитетный DNS-ответ и доступ пользователя — разные факты. Первый может быть верным при ложном пятом. Метка «IPv6 включён» без слоя наблюдения вводит в заблуждение.

Нужно раздельно хранить host object, delegation set, публикацию зоны, routing view и распределённые DNS-пробы. Расхождение локализует границу между формальным состоянием и работающей сетью.

Код 557 отделял чужую поверхность управления

557 обозначал заблокированный nameserver object, связанный с top-level domain. Для изменения требовалась внешняя координация с поддержкой реестра. Это означало не невозможность, а отсутствие односторонней власти у обычного пути регистратора.

Современное управление корневой зоной IANA — другой контур. Материалы об управлении root zone, работе с TLD, согласии, технических требованиях к nameserver и RZMS API разделяют credentials, ограниченные права, подтверждение контактов или менеджера, тестирование, внедрение и проверку. Изменение общего nameserver может затронуть другие TLD.

Эти сегодняшние процессы ничего не доказывают о старой RRP-транзакции. Они демонстрируют устойчивую границу: объект реестра, разрешённая заявка в root, публикация и работающий сервис — не одно состояние.

Минимальная квитанция — это соединение

Для переноса нужно связать версию протокола и сборки, сессию, client ID, заявителя и спонсора, домен, время запроса, before-state, точные bytes, timer и policy, проверку авторизации, ответ, after-state, уведомления и финальное решение. Заявление о DNS требует отдельной публикации и наблюдения.

В Minimum Initial Specification Heng предлагает общий минимум без централизации всех последующих решений. Реестр обязан сделать своё действие коррелируемым, но не становиться судьёй клиентского согласия или сетевой доступности.

On Reality Layers удерживает отдельно символ, институциональное решение, запись, DNS и пользовательскую реальность. Running Code Primary требует смотреть на выполненный переход.

Сервер RFC 3632 понимал одинаковую команду, потому что у него оставались сессия и состояние. Неоднозначность создал поздний экспорт, сохранивший видимое и отбросивший неявные входы. Буквальная точность журнала не гарантирует точной атрибуции власти.

Источники

  1. RFC 3632 — VeriSign Registry Registrar Protocol 2.0.0
  2. RFC 3632 в текстовом виде
  3. Информация RFC Editor о RFC 3632
  4. RFC 3632 в IETF Datatracker
  5. История RFC 3632
  6. Поиск errata RFC 3632
  7. RFC 2832 — Registry Registrar Protocol 1.1
  8. RFC 3375 — Требования к протоколу registry–registrar
  9. RFC 3730 — Extensible Provisioning Protocol
  10. RFC 5730 — Extensible Provisioning Protocol
  11. RFC 5731 — EPP Domain Mapping
  12. RFC 5732 — EPP Host Mapping
  13. RFC 4291 — Архитектура адресации IPv6
  14. RFC 5952 — Текстовое представление IPv6
  15. RFC 5890 — Определения IDNA
  16. IANA — Управление корневой зоной
  17. IANA — Управление доменом верхнего уровня
  18. IANA — Согласие на изменение корневой зоны
  19. IANA — Технические требования к nameserver
  20. IANA — API системы управления корневой зоной
  21. Lu Heng — On Authority and Belief
  22. Lu Heng — On Reality Layers
  23. Lu Heng — Running Code Primary
  24. Lu Heng — Minimum Initial Specification