Кратко

  • RFC 8334 разделяет регистрацию периода запуска и заявку периода запуска. В модели заявки корректный create может вернуть EPP 1001, applicationID и pendingCreate, хотя реестр ещё не выделил домен.
  • Успех подтверждает приём команды и создание объекта заявки. Он не подтверждает приоритет товарного знака, окончательное выделение, публикацию в реестре, делегирование DNS или работу сервиса.
  • Проверяемая история соединяет идентификаторы транзакций, фазу и версию политики, упорядоченные состояния и сообщения poll, затем окончательные domain:panData. После этого объект домена, публикация, DNS и сервис проверяются раздельно.

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

Пример RFC 8334 возвращает Command completed successfully; action pending. Код — 1001; ответ содержит фазу и applicationID. Команда закончилась. Действие, которое определит судьбу заявки, осталось незавершённым.

RFC 8334 опубликована в марте 2018 года на треке стандартов IETF. Её авторы — J. Gould, W. Tan и G. Brown. Реестр расширений EPP IANA ссылается на неё как на спецификацию фаз запуска. Gavin Brown рассматривается здесь как соавтор коллективной работы, а не единственный изобретатель, оператор реестра, валидатор или распорядитель домена.

Профиль IETF, сохранённый 31 августа 2026 года, указывает двадцать пять лет опыта в DNS и доменных именах, двадцать два года в Team Internet PLC, ранее CentralNic, четырнадцать из них на посту CTO, и нынешнюю работу в ICANN. Он перечисляет четыре RFC, включая RFC 8334, и публичные роли, среди которых председательство в RESTful Provisioning Protocol и рецензирование ARTART. Это датированный контекст, не полномочие над политикой реестра.

Какой объект создаёт create

Регистрация периода запуска — единственная регистрация в фазе, где сервер использует порядок поступления. Заявка периода запуска выражает намерение зарегистрировать имя. Сервер может держать несколько заявок на один домен и позднее выбрать одну для выделения.

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

При корректном create заявки сервер обязан создать объект заявки, присвоить идентификатор, установить pendingCreate из RFC 5731 и вернуть applicationID. Идентификатор позволяет обращаться к конкретной заявке, даже когда несколько заявок содержат одно имя.

Это настоящий успех: возникло долговечное состояние. Но объектом является заявка, не окончательная регистрация. applicationID не удостоверяет право на домен, а pendingCreate прямо сохраняет незавершённость действия.

Поле domain_create_success стирает дополнение к глаголу. Клиент читает «домен создан», биллинг начинает начисление, DNS-команда ищет отсутствующее делегирование. Корректная модель называет переходы: заявка принята, проверена, выделена или отклонена; объект домена создан; публикация, делегирование и сервис наблюдались.

Точный объём доказательства 1001

RFC 5730 определяет ядро EPP. Результат 1001 означает успешное завершение команды при ожидающем действии. Ответ может повторить клиентский идентификатор транзакции и должен содержать серверный, связывая журналы сторон.

Квитанция заявки сохраняет время, спонсирующего клиента, домен, endpoint, оба идентификатора, фазу, подфазу, форму create, применимую политику, результат, applicationID, состояние RFC 5731 и состояние запуска.

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

Полномочия распределены по глаголам. Клиент регистратора подаёт. Валидатор оценивает материал. Реестр применяет политику и выделяет. Система проекции публикует. Оператор зоны делегирует. Авторитетные серверы отвечают. Оператор сервиса настраивает приложение. Успех первого не наследует мандаты остальных.

Фаза не заменяет документ политики

RFC 8334 определяет sunrise, landrush, claims, open и custom. Клиент обязан указать фазу; сервер должен её проверить и может проверить подфазу. Фазы могут пересекаться, а атрибут имени уточняет их.

Это контекст, но не полная политика. Два реестра способны использовать sunrise с разными окнами, валидаторами, тарифами, документами и правилами выбора. Часть решения намеренно остаётся вне протокола.

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

RFC 7848 задаёт объекты товарного знака и подписанного знака. В зависимости от формы RFC 8334 переносит знак, подписанный объект, код или уведомление. Это происхождение доказательств, а не автоматическое выделение. Действительный знак может выполнить условие; решение всё равно принимает реестр по своей политике.

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

Ожидание — это последовательность

Состояния включают pendingValidation, validated, invalid, pendingAllocation, allocated, rejected и custom. Пока используемое состояние запуска не финально, сохраняется pendingCreate. Политика может пропустить промежуточные стадии.

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

Очередь poll RFC 5730 переносит асинхронные изменения. Сообщения имеют ID, извлекаются и подтверждаются. RFC 8334 рекомендует их для промежуточных состояний и требует domain:panData RFC 5731 для финальных allocated и rejected.

История сохраняет порядок, ID, постановку в очередь, получение, подтверждение, состояние, заявку и транзакции. Allocated доказывает выбор заявки и переход к объекту домена. Rejected доказывает, что она не стала регистрацией. Молчание или пустой публичный поиск не доказывают ни одно.

Само наличие заявки и её содержание могут быть конфиденциальны. Неавторизованная операция получает 2201, а представление может быть отфильтровано. Невидимость описывает права наблюдателя, не обязательно отсутствие объекта.

После выделения появляются новые часы

После allocated читается объект домена RFC 5731. Затем независимо проверяются публикация реестра или RDAP, делегирование в родительской зоне, авторитетный DNS и работа сервиса.

Выделение без объекта указывает на provision реестра. Объект без делегирования — на публикацию зоны или конфигурацию регистранта. Делегирование без авторитетного ответа — на DNS. Исправный DNS без сервиса — на приложение, сеть или хостинг.

Running-Code Primacy требует, чтобы каждый слой говорил только о наблюдаемом. EPP подтверждает состояние EPP, readback реестра — объект, RDAP — проекцию, DNS — ответ во времени и точке наблюдения, соединение — сервис. Первая квитанция не представляет всю цепь.

Необходимое соединение свидетельств

Значимый вывод должен восстанавливать:

  1. клиентский и серверный ID, время, клиента, домен, endpoint и результат;
  2. фазу, подфазу, форму, версию политики, срок и процедуру выбора;
  3. applicationID, начальный pendingCreate, состояние и права просмотра;
  4. валидатора, знак, подпись, код и уведомление только когда они применимы;
  5. упорядоченные состояния и poll с получением, подтверждением, пропусками и исключениями;
  6. финальные domain:panData allocated или rejected;
  7. итоговый объект RFC 5731 при выделении;
  8. реестр/RDAP, зону, авторитетный DNS и сервис как раздельные наблюдения;
  9. основание конфиденциальности, фильтр, хранение и владельца аудита.

Такая цепь доказывает приём без подмены его выделением. Заявитель, реестр и валидатор сохраняют собственные факты и границы, а эксплуатация находит задержку без раскрытия конфиденциального содержания.

RFC 8334 дала незавершённому идентичность, историю и финал. applicationID именует ожидание, состояния и poll сохраняют путь, panData закрывает его. Ошибка управления начинается там, где всё это превращают в один зелёный статус.

Источники