Summary

  • Проект RPP core, редакция 01, от 2 ноября 2026 года сопоставляет операции с объектами общей базы, включая домены, с HTTP. Проект о моделях данных определяет сами объекты отдельно. Работа IETF продолжается.
  • Перевод меняет спонсирующего клиента, но в RPP это отдельный процесс со своим жизненным циклом. Желающий принять домен регистратор вызывает POST /domainNames/{name}/processes/transferProcesses; пример ответа — 201 Created и URL процесса в Location.
  • Заявитель может отменить ожидающий перевод; нынешний спонсор может отклонить или одобрить его. Постоянная очередь сообщений позволяет позже известить об асинхронном завершении. Получить сообщение и подтвердить его — разные действия.

В обычном описании домен «переходит» от одного регистратора к другому. Запись IETF о RPP core показывает несколько этапов внутри этого глагола. Запрос создаёт дело. Другая сторона может вынести решение. Позже приходит уведомление о результате. Первое Created в примере относится именно к процессу. Оно само по себе не подтверждает изменения спонсора в карточке домена.

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

Появился адрес дела, не итоговое право

Раздел 16.9.5 определяет перевод как смену спонсирующего клиента и моделирует его отдельным объектом процесса. Входящий регистратор отправляет POST в коллекцию transferProcesses данного домена. Пример возвращает 201 Created, код RPP и Location, оканчивающийся на /transferProcesses/latest. Это путь к последнему процессу перевода. Это не чтение записи о новом спонсоре.

Клиент может получать состояние процесса через GET. Пока перевод ожидает решения, заявитель вправе отменить его через DELETE. У нынешнего спонсора есть действия transferReject и transferApprove. Разные методы принадлежат разным участникам. Регистратор, который хочет войти, может подать заявку, но не может создать одобрение от лица регистратора, который пока отвечает за домен. История перевода состоит из запроса, состояния, решения и последующего чтения объекта домена.

Долговечность URL тоже условна. Если сервер открывает доступ к экземплярам процесса, он обязан поддерживать путь latest к последнему и может присвоить постоянный идентификатор. Если постоянный ресурс процесса вообще не раскрывается, проект требует 200 OK, а не 201 Created. Интеграция не должна ожидать бессрочную ссылку у каждого реестра. Можно сохранить идентификаторы транзакций, доступные состояния и окончательную запись о спонсоре.

Прочитанное письмо остаётся до подтверждения

Проект определяет постоянную очередь асинхронных сообщений для клиента. Среди примеров — завершение перевода, требовавшего согласия другой стороны. GET извлекает сообщения; DELETE на конкретное сообщение подтверждает его. Извлечённое, но не подтверждённое сообщение должно оставаться в очереди. Таким образом, «увидели» и «обработали» не сливаются в одну отметку. Начальный ответ на запрос и уведомление о завершении тоже имеют разный смысл.

Когда обычная операция побочно создаёт процесс, раздел 15 использует заголовок Link с rel="rpp-process". Атрибут process указывает тип, processId появляется при постоянном серверном идентификаторе, latest отмечает последний процесс данного типа. Ссылка помогает клиенту найти незавершённую работу. Она не сообщает её конечный результат.

Официальные материалы не содержат измеренной истории перевода в действующем реестре. Контрольный перевод собственного домена должен связать ответ POST, последовательные GET процесса, решение прежнего спонсора, сообщение в очереди, его подтверждение и итоговую запись домена. Лишь после этого клиентскому экрану есть основание заменить «заявка принята» на «перевод завершён». URL перевода может уже существовать, пока домен остаётся у прежнего регистратора.

Проект RPP core 01 · Datatracker · Объекты RPP · RFC 5730