Resumo

  • O RFC 3632 reutilizou -Approve:No: o patrocinador atual rejeitava uma transferência, enquanto o registrador que a solicitara cancelava o próprio pedido. A sessão autenticada e o estado pendente davam sentido ao texto.
  • 200 Command completed successfully comprova o processamento RRP bem-sucedido, não a vontade do titular, o consentimento humano, a publicação DNS nem o resultado do serviço.
  • Um recibo confiável une ator, papel, objeto, estado anterior, política, relógio, resposta, estado posterior e aviso fora de banda. Guardar apenas o comando preserva a forma e perde a responsabilidade.

O prazo expôs o que o painel havia escondido

O RFC 3632, publicado em dezembro de 2003 como Informativo, documentou o RRP 2.0.0. Ele não é um Internet Standard nem orientação para adotar RRP hoje. Seu valor atual está no modo como um pequeno detalhe revela a dependência entre linguagem e autoridade.

Com o registrador patrocinador conectado, -Approve:No rejeitava o pedido de outro registrador. Com o solicitante original conectado, o mesmo parâmetro cancelava o próprio pedido. Rejeitar e retirar não são sinônimos: atribuem a decisão a lados opostos da relação.

O registro do RFC Editor, o Datatracker, o histórico e a busca de errata confirmam a condição documental. Não comprovam implantação, conformidade ou o desfecho de uma transação real.

A identidade morava na sessão

No RFC 2832, a identidade do registrador solicitante vinha da sessão ativa autenticada. O registry já sabia quem patrocinava o domínio. A autorização resultava da junção entre principal, papel em relação ao objeto e estado da transferência.

Um campo no payload não poderia criar esse poder. Escrever uma identidade é fazer uma afirmação; autenticar a sessão e compará-la ao registro é avaliá-la. Tentativas de aprovação ou rejeição por um registrador sem a função correta deveriam falhar.

O mesmo texto exigia que o potencial perdedor recebesse aviso por um canal fora de banda, como e-mail ou relatório. A evidência institucional era distribuída: login, mensagem, objeto persistente e entrega do aviso respondiam a perguntas diferentes.

RRP não devolvia timestamps nem identificadores de transação. Relatórios diários e semanais acrescentavam horários no tempo local do registry. Sem uma chave de correlação e uma base de relógio preservadas, dois registros verdadeiros podiam continuar incapazes de provar sua ordem.

Cancelar era uma opção que expirava

O RFC 3375 já havia separado os poderes. O solicitante inicia e pode cancelar antes da decisão. O patrocinador vigente aprova ou rejeita. Terceiros não podem ocupar nenhum dos lados. Ambos precisam acompanhar o estado pendente e o concluído.

O RFC 3632 deu forma RRP ao cancelamento, reutilizando a negativa de aprovação. A retirada precisava chegar antes de uma decisão explícita do patrocinador e antes de uma decisão implícita aplicada pelo registry ao fim do prazo.

O relógio era, portanto, parte da autorização. A mensagem enviada um segundo antes do fechamento podia ser válida; a mesma mensagem depois dele não operava sobre o mesmo estado. O recibo precisa registrar hora de aceitação no servidor, referência temporal, versão da política do timer e evento que fechou a janela.

Essa borda é irreversível do ponto de vista probatório. Um processo posterior pode corrigir o domínio, mas não recria a oportunidade anterior de cancelar. Se o before-state desaparece, a equipe não consegue distinguir cancelamento tardio, corrida com o timer ou recusa do patrocinador.

O código 200 não representa o titular

A resposta do exemplo — 200 Command completed successfully — é um pronunciamento válido do servidor sobre seu processamento. O erro seria transformá-la em procuração para outros sistemas.

Ela não informa se o titular pediu a retirada, se o fluxo interno do registrador obteve autorização, se o patrocínio final mudou, se uma delegação DNS foi publicada ou se usuários observaram efeito. “Sucesso” precisa manter seu objeto: sucesso de qual operação, declarado por qual autoridade?

Em On Authority and Belief, Lu Heng insiste na origem e no alcance de cada afirmação. O registry fala com autoridade sobre o estado que mantém. Não fala em nome da intenção privada do cliente nem da realidade posterior da rede.

Um relatório de liderança deve manter colunas separadas para autorização do cliente, ação do registrador, mudança no registry, publicação DNS e observação de serviço. As colunas podem convergir; nenhuma herda automaticamente a certeza da outra.

EPP deixou a operação mais explícita

No RFC 5731, as operações são request, cancel, approve, reject e query. A informação pendente pode apresentar cliente solicitante, data do pedido, cliente da ação, data da ação e estado. O RFC 5730 oferece identificadores de transação do cliente e do servidor.

Isso produz um recibo potencialmente melhor: a exportação não depende apenas de interpretar um “No” com dados externos. Mas potencial não é retenção. Um pipeline pode descartar IDs; relógios podem divergir; o cliente solicitante continua distinto do titular; resposta EPP continua distinta de DNS.

O RFC 3730 ajuda a situar uma geração anterior de EPP. Nenhum desses documentos comprova quando um operador migrou ou como implementou. O padrão define uma interface; a prova de execução pertence ao sistema em funcionamento.

O 510 julgava uma codificação, não uma identidade

O RFC 3632 adicionou o código 510 para codificação inválida de nome em ADD ou MOD. O RFC 5890 forneceria depois conceitos mais precisos para nomes internacionalizados.

Aceitar a representação significa que ela passou pela gramática e pela política daquela interface. Não comprova direito de marca, identidade institucional, intenção, segurança visual ou delegação. Recusar também não condena o nome em todos os contextos; apenas descreve uma falha delimitada.

O adjetivo “válido” só é seguro com complemento. Válido para qual sintaxe, sob qual política, em qual versão e momento? Sem isso, o parser assume autoridade que não possui.

Guardar IPv6 não é demonstrar alcance

Outra alteração permitiu endereços IPv6 completos ou comprimidos em objetos de nameserver. O RFC 4291 trata da arquitetura; o RFC 5952, da representação textual recomendada posteriormente.

Há uma cadeia de provas: string aceita, objeto salvo, delegação publicada, rota disponível, servidor autoritativo respondendo e usuário alcançando o serviço. Cada elo tem observador próprio. Um cartão “IPv6 ativo” apaga essas diferenças se não declarar qual elo mediu.

Preservar objeto host, conjunto de delegação, zona pai ou raiz, visão de roteamento e sondas DNS distribuídas permite localizar a divergência. A capacidade do protocolo não deve ser apresentada como resultado da rede.

O 557 marcava uma fronteira de controle

O código 557 indicava que um nameserver ligado a um domínio de primeiro nível estava bloqueado. A alteração exigia coordenação fora da via comum com o suporte do registry. Não era impossibilidade; era ausência de autoridade unilateral naquele caminho.

A gestão atual da raiz pela IANA pertence a outro sistema. As páginas de gestão da zona raiz, operação de TLD, consentimento, requisitos técnicos e API RZMS separam credenciais, permissões, concordância de contatos ou gestor, testes, implantação e verificação. Mudanças de IP de um servidor compartilhado podem envolver outros TLDs.

Esses processos contemporâneos não explicam uma transação RRP histórica. Mostram por que objeto de registry, autorização de raiz, publicação e serviço não podem ser comprimidos num único status.

Um recibo mínimo precisa preservar a junção

A evidência de transferência deve relacionar versão, sessão autenticada, client ID, solicitante, patrocinador, domínio, origem e hora do pedido, estado anterior, bytes do comando, timer e política, decisão de autorização, resposta, estado posterior, avisos e decisão final. Se houver alegação sobre DNS, acrescentam-se publicação e observação.

O Minimum Initial Specification de Heng oferece a medida: uma interface mínima compartilhada sem centralizar toda autoridade futura. O registry torna seu ato correlacionável; não se transforma em árbitro do consentimento do cliente nem da disponibilidade.

As Reality Layers separam símbolo, decisão institucional, registro, publicação e experiência. Running Code Primary exige confirmar a transição executada. Juntas, as duas ideias mudam a pergunta: de “qual texto apareceu?” para “qual ator, em qual papel, alterou qual estado, por qual regra e antes de qual limite?”.

O “não” do RFC 3632 nunca foi autossuficiente. O servidor entendia porque ainda possuía a sessão e o estado. A ambiguidade surgiu quando o arquivo reteve a palavra e descartou a relação. É por isso que logs exatos ainda podem contar a história errada.

Fontes

  1. RFC 3632 — VeriSign Registry Registrar Protocol 2.0.0
  2. RFC 3632 em texto
  3. Informações do RFC Editor sobre o RFC 3632
  4. RFC 3632 no IETF Datatracker
  5. Histórico do RFC 3632
  6. Busca de errata do RFC 3632
  7. RFC 2832 — Registry Registrar Protocol 1.1
  8. RFC 3375 — Requisitos genéricos de protocolo registry–registrar
  9. RFC 3730 — Extensible Provisioning Protocol
  10. RFC 5730 — Extensible Provisioning Protocol
  11. RFC 5731 — Mapeamento de domínios EPP
  12. RFC 5732 — Mapeamento de hosts EPP
  13. RFC 4291 — Arquitetura de endereçamento IPv6
  14. RFC 5952 — Representação textual de endereços IPv6
  15. RFC 5890 — Definições de IDNA
  16. IANA — Gestão da zona raiz
  17. IANA — Gestão de um domínio de primeiro nível
  18. IANA — Consentimento para mudança na zona raiz
  19. IANA — Requisitos técnicos de nameserver
  20. IANA — API do sistema de gestão da zona raiz
  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