Summary

  • A revisão 01 do RPP core, de 2 de novembro de 2026, mapeia a gestão de objetos compartilhados, como domínios, para HTTP. O rascunho de objetos de dados define o modelo em separado. O texto ainda é trabalho da IETF.
  • A transferência muda o cliente patrocinador do objeto, mas o RPP lhe dá um Processo próprio. A registradora interessada faz POST /domainNames/{name}/processes/transferProcesses; o exemplo retorna 201 Created e um Location para a URL do processo.
  • Quem iniciou pode cancelar um pedido pendente; a patrocinadora atual pode rejeitar ou aprovar. Uma fila durável de mensagens pode comunicar a conclusão assíncrona. Buscar a mensagem e confirmá-la são operações diferentes.

Uma transferência de domínio é vendida como movimento entre registradoras. No registro do RPP core, esse movimento tem etapas. Uma parte pede, outra pode decidir, e o resultado pode aparecer mais tarde numa mensagem. No exemplo do rascunho, o Created inicial diz respeito ao processo. Ele não confirma, sozinho, que o domínio já tem outra registradora patrocinadora. O painel que trata esse código como ponto final conta uma história antes de o registro terminá-la.

O RPP é concebido como protocolo independente. Pode haver uma ponte para EPP, mas essa correspondência é trabalho separado. O núcleo proposto determina caminhos, métodos, cabeçalhos e códigos HTTP; outro documento define os objetos, e a representação concreta das mensagens fica para especificações próprias. Ler um sucesso HTTP exige identificar qual objeto avançou: o domínio ou o processo sobre ele.

O que foi criado tem tarefas por cumprir

A seção 16.9.5 chama transferência de mudança do cliente patrocinador e a modela como Processo com ciclo de vida. A registradora que quer entrar envia POST à coleção transferProcesses daquele domínio. A resposta de exemplo traz 201 Created, código RPP e Location terminando em /transferProcesses/latest. A URL permite acompanhar o processo mais recente. Ela não é uma consulta ao patrocínio final do nome.

É possível consultar o estado do processo com GET. Enquanto estiver pendente, a iniciadora pode cancelá-lo com DELETE. A registradora atualmente patrocinadora dispõe de transferReject e transferApprove. Os verbos revelam a divisão de autoridade: pedir entrada não dá à interessada poder para aprovar a própria troca em nome da patrocinadora atual. O histórico confiável liga solicitação, estado, decisão e leitura posterior do domínio.

A permanência da URL também tem limites. Se o servidor expõe instâncias de processo, deve permitir acesso à mais recente por latest e pode atribuir um ID persistente. Se não expõe recurso de processo persistente, o rascunho manda responder 200 OK, não 201 Created. Assim, nem toda integração pode esperar um endereço duradouro para cada transferência. Ela pode, contudo, guardar IDs de transação, estados disponíveis e a leitura final do patrocinador.

Ler a mensagem não limpa a caixa postal

O rascunho define uma fila durável de avisos assíncronos para o cliente. Cita como exemplo a conclusão de transferência dependente da aprovação de outra parte. O cliente usa GET para obter mensagens e DELETE numa mensagem específica para confirmar o recebimento. Uma mensagem buscada mas não confirmada deve permanecer na fila. A regra distingue «vimos o resultado» de «tratamos o resultado» e deixa o aviso final separado da primeira resposta ao pedido.

Quando uma operação comum cria um processo como efeito adicional, a seção 15 usa o cabeçalho Link com rel="rpp-process". process marca o tipo; processId acompanha um identificador persistente atribuído pelo servidor; latest identifica a instância mais recente daquele tipo. O link é uma boa pista para o trabalho que resta. Não é o seu veredicto.

Os documentos oficiais não oferecem uma transferência de produção medida. Um ensaio com domínio controlado deveria guardar a resposta POST, os estados GET do processo, a decisão da patrocinadora atual, o aviso na fila, sua confirmação e a leitura final do domínio. Só essa sequência indica quando o painel pode passar de «solicitada» para «concluída». A tese do rascunho cabe numa frase: a transferência ganhou um endereço, mas o domínio pode continuar na mesma registradora.

RPP core revisão 01 · Datatracker · Objetos RPP · RFC 5730