Resumo

  • A revisão 04 do Internet-Draft sobre EPP via HTTPS determina que a camada HTTP devolva 200 quando houver uma resposta EPP, mesmo que essa resposta indique falha do comando.
  • Se nenhuma resposta EPP válida chega e o comando pode ter alcançado o processamento, o desfecho é indeterminado. Repeti-lo só cabe ao cliente EoH que conheça a idempotência do comando completo, inclusive extensões.
  • Um recibo de disposição deve ligar tentativas HTTP, identificadores EPP, barreira de ordenação, fundamento do retry e prova posterior de reconciliação.

O painel mostra verde. O monitor registrou HTTP 200, a latência voltou ao normal e a fila seguiu em frente. Em muitas aplicações, esse conjunto permite encerrar o incidente. Num serviço de registro que transporta EPP dentro de HTTPS, ele prova muito menos: prova que uma resposta HTTP de sucesso chegou. Ainda falta abrir a resposta EPP e descobrir o que o registro decidiu.

Essa separação é a parte mais importante da revisão 04 de draft-ietf-regext-epp-https, publicada em 3 de setembro de 2026. Quando uma requisição alcança a camada de processamento EPP e o servidor produz uma resposta EPP, o invólucro HTTP deve ser 200. Isso vale tanto para sucesso quanto para falha do comando. A camada externa informa que conseguiu carregar uma resposta da camada interna; não reescreve o seu significado.

Há um segundo limite, menos confortável. Uma falha de gateway, um limite de taxa ou uma conexão interrompida pode deixar o cliente sem resposta EPP válida. Se o comando talvez tenha chegado ao processamento, o operador não pode concluir que nada aconteceu. O rascunho chama esse estado de indeterminado. É justamente aí que a automação mais prestativa pode se tornar a autoridade menos qualificada: ela interpreta ausência de resposta como licença para repetir uma possível mutação.

A aparência de API não elimina a sessão EPP

RFC 5730 descreve EPP como protocolo XML com estado. O cliente inicia comandos, o servidor os processa em ordem e devolve respostas coordenadas. Há comandos de sessão, consultas e transformações de objetos. As operações são atômicas e foram desenhadas para que possam ser tornadas idempotentes; o transporte precisa preservar ordem, estado e enquadramento.

O mapeamento HTTPS começa com um POST vazio. A conexão EoH só existe quando o servidor devolve HTTP 200 com a saudação EPP e estabelece uma sessão HTTP por cookie. Depois, um login EPP bem-sucedido abre a sessão autenticada. Cada POST seguinte contém uma mensagem EPP, e cada resposta depois do processamento contém uma resposta EPP.

O uso da porta 443 e de balanceadores conhecidos ajuda ambientes de nuvem. Também mascara a diferença entre um pedido web comum e uma sequência de provisionamento. O próprio texto define a solução como tunelamento: aproveita a infraestrutura sem adotar, de forma irrestrita, cache, multiplexação, autenticação, logging ou retries automáticos típicos da camada HTTP.

Um caso de erro deixa a fronteira cristalina. Se o comando chega ao EPP com identificador de sessão vazio ou inválido, o servidor deve enviar o erro EPP 2002 dentro de HTTP 200. Quem lê apenas o indicador exterior registra sucesso onde a aplicação registrou uso inválido do comando.

O terceiro estado protege a verdade operacional

Sistemas administrativos gostam de dois estados porque dois estados cabem em metas e relatórios. “Indeterminado” parece uma falha de desenho. Na realidade, é uma conclusão positiva sobre o limite da prova: não há uma resposta EPP autoritativa disponível, mas os vestígios não excluem que o processamento tenha ocorrido.

Manter esse estado impede três excessos. O registrador não anuncia uma mudança sem confirmação. Também não atribui uma rejeição que o registro nunca comunicou. E bloqueia comandos posteriores que tornariam a sequência ainda mais difícil de explicar. O estado pode durar segundos ou exigir uma conciliação bilateral; sua duração não muda o significado.

Uma consulta posterior ao objeto ajuda, mas nem sempre fecha a causalidade. O estado observado pode ter existido antes, ter sido alterado por outro ator, resultar de processamento pendente ou refletir apenas parte da intenção. Provar o estado atual não é necessariamente provar qual tentativa produziu esse estado. Por isso um timeout não deveria desaparecer dentro de uma simples métrica de falha.

Idempotência não vem do método POST nem do nome do comando

RFC 9110 não define POST como idempotente. Um cliente só deveria repeti-lo automaticamente se souber que a semântica real é idempotente ou se puder detectar que a primeira requisição não foi aplicada. Um proxy não deve repetir automaticamente pedidos não idempotentes.

A revisão 04 aplica uma condição ainda mais específica. O cliente EoH pode tentar de novo quando a falha pode ser transitória, o significado do status HTTP permite o retry e o cliente sabe que o comando EPP completo, incluindo todas as extensões, tem semântica de aplicação idempotente. O retry precisa transportar o mesmo comando e o mesmo clTRID, se houver. Nenhum comando posterior pode sair até uma resposta válida ou o abandono da sessão.

O requisito sobre extensões impede que uma classificação superficial vire permissão. Uma operação básica pode parecer repetível, mas um módulo adicional pode anexar condições ou efeitos. A análise deve nomear o perfil de serviço, a versão da extensão e a razão concreta pela qual duas execuções produzem o mesmo efeito pretendido. Sem isso, “EPP foi projetado para idempotência” não é evidência suficiente.

Intermediários ficam deliberadamente sem essa autoridade. Um balanceador vê o erro de conexão, não a intenção registral. Uma service mesh pode saber quantos bytes foram enviados, mas não se a extensão altera a semântica nem qual comando deve vir depois. Por isso o rascunho exige que o operador desabilite retries automáticos de POST EPP nos intermediários sob seu controle.

O mesmo clTRID cria vínculo, não necessariamente imunidade

Em RFC 5730, o cliente pode incluir um clTRID e deve manter a unicidade dentro do seu espaço. A resposta traz esse valor junto do svTRID, único e atribuído pelo servidor. O par sustenta a sincronização entre comando e resposta; as partes devem registrá-lo, retê-lo e protegê-lo.

O rascunho exige repetir o mesmo clTRID num retry permitido. Assim, as tentativas pertencem ao mesmo caso. Mas os textos não afirmam que o identificador, sozinho, obrigue todo servidor a suprimir uma segunda execução. Uma garantia de deduplicação pode existir numa implementação ou acordo operacional; ela precisa ser explícita, versionada e aplicável às extensões usadas.

Essa distinção evita uma falsa segurança comum: confundir capacidade de localizar duas mensagens com capacidade de impedir o efeito da segunda. Correlação facilita a investigação. Idempotência e deduplicação controlam comportamento. São propriedades relacionadas, não sinônimos.

Ordem é uma medida de contenção

HTTP/2 e HTTP/3 oferecem multiplexação. O mapeamento EoH proíbe mais de uma requisição pendente por sessão EPP. Se um intermediário criar concorrência, o servidor precisa escolher e documentar entre falhar e serializar.

Essa regra conserva o nexo causal. Uma atualização pode depender de uma criação; uma transferência pode mudar quem está autorizado a alterar o objeto. Se o primeiro comando permanece indeterminado e o seguinte é aceito, o estado final admite histórias concorrentes. O operador passa de reconciliação para especulação.

Abandonar a sessão interrompe a progressão, não resolve a operação passada. Ainda é necessário confrontar logs do servidor, respostas, consultas apropriadas ou um procedimento acordado. Criar uma nova sessão sem transportar o recibo pendente apenas restaura conectividade e perde contexto.

O recibo de disposição do comando

Um log HTTP normalmente contém rota, backend, status, duração e número de tentativas. Um log EPP contém comando, código de resultado e identificadores. A governança precisa de uma junção durável entre os dois. O recibo deve registrar:

  1. tipo de comando, objeto afetado e impressão canônica da mensagem completa com extensões;
  2. identidade da sessão, clTRID e identificador de cada tentativa HTTP;
  3. momento do envio e último ponto no qual a não entrega ainda pode ser demonstrada;
  4. status HTTP e componente que efetivamente o gerou;
  5. código EPP e svTRID, quando chegou resposta válida;
  6. disposição em três valores: sucesso confirmado, falha confirmada ou indeterminado;
  7. fundamento e versão da classificação de idempotência;
  8. evidência da barreira que impediu o próximo comando;
  9. pessoa ou política responsável pelo retry, abandono ou conciliação;
  10. prova que encerrou o caso, horário, confiança e diferenças remanescentes.

Não é necessário padronizar um produto único. A especificação inicial mínima defendida por Lu Heng sugere obrigar apenas os elementos compartilhados que preservam responsabilidade, permitindo implementações locais. O recibo pode viver como evento assinado, ticket bilateral ou relação protegida entre logs. Seu teste é simples: consegue manter “não sabemos ainda” sem transformá-lo em erro ou sucesso por conveniência?

The Policy Mirror mostra quem se beneficia da configuração. O retry pode elevar o indicador de disponibilidade do provedor enquanto transfere ao registrador, ao titular ou ao suporte o custo de desfazer uma ação repetida. Nesse momento, uma opção de resiliência distribui poder e prejuízo. Ela é política, mesmo que apareça num arquivo de infraestrutura.

A evidência do rascunho tem limites próprios

A revisão 04 é um Internet-Draft ativo do grupo REGEXT, com intenção de Standards Track. Não é RFC, não concluiu avaliação do IESG e expira em 7 de março de 2027. O marco de setembro de 2026 para submissão é uma meta do grupo, não prova de que a publicação foi aprovada.

O texto lista o SDK EPP da Verisign e uma implementação IIT-CNR/Registro.it. Sob o aviso de RFC 7942, essas informações foram fornecidas por participantes, não verificadas pelo IETF, não equivalem a endosso e não formam catálogo. Mostram experiência declarada, não conformidade universal de produção.

A entrada de extensão EPP descrita para a IANA também é proposta. Até o processo produzir o registro correspondente, a linguagem correta é “o rascunho propõe”. A mesma precisão que separa 200 de um resultado EPP deve separar intenção normativa de autoridade já adquirida.

Fontes

  1. IETF — EPP Transport over HTTPS, revisão 04
  2. Datatracker — situação do documento
  3. Datatracker — histórico
  4. Grupo de trabalho REGEXT
  5. RFC 5730 — Extensible Provisioning Protocol
  6. RFC 5731 — mapeamento de nomes de domínio em EPP
  7. RFC 5734 — transporte EPP sobre TCP
  8. RFC 9110 — semântica HTTP
  9. RFC 7942 — consciência de código em execução
  10. IANA — Extensions for EPP
  11. Lu Heng — Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
  12. Lu Heng — The Policy Mirror