Resumo

  • Em 17 de agosto de 2026, o IESG aprovou draft-ietf-regext-ext-registry-epp-10 para publicação como Best Current Practice. O texto fortalece especificação, análise e manutenção das extensões EPP, sem transformar o registro da IANA em uma lista universal de capacidades.
  • Active comprova implementação e uso em pelo menos um par registro–registrador ou servidor–cliente. O anúncio pelo servidor-alvo, a autorização do cliente e o sucesso da operação pertencem a etapas posteriores e independentes.

O catálogo não respondeu à pergunta operacional

A situação de abertura é hipotética, não um incidente atribuído a algum TLD. Ela começa com um dado verdadeiro e termina em uma decisão falsa porque o sistema ignora a finalidade do dado.

O registro da IANA responde questões de coordenação: nome da extensão, especificação estável, responsável, escopo TLD declarado, informações de propriedade intelectual, estado e observações. Isso permite descobrir implementações, localizar documentação e reduzir colisões de namespace.

A saudação EPP responde o que um servidor oferece naquele momento. O login seleciona versão, idioma, objetos e extensões para um cliente identificado. A resposta ao comando aplica privilégios e política local a uma operação e a um objeto específicos. O estado posterior confirma se o efeito esperado ocorreu.

Nenhuma camada substitui a seguinte. Uma extensão registrada pode não ser anunciada. Uma extensão anunciada pode estar vedada àquela conta. Uma sessão negociada pode receber uma rejeição legítima por política. O aparente conflito desaparece quando cada prova conserva seu alcance.

A decisão do IESG aumenta a qualidade do registro

O documento “Extension Registry for the Extensible Provisioning Protocol” foi aprovado em sua versão 10. Até a publicação pelo RFC Editor, continua sendo Internet-Draft. Seu objetivo é tornar RFC 7451 obsoleta e elevar o procedimento de Informational para BCP.

A revisão pública migra da antiga lista eppext para REGEXT. Novas solicitações não poderão usar Internet-Draft como especificação permanente, e a alocação antecipada de RFC 7120 não se aplica. A referência precisa ser estável e facilmente acessível; o registro deve apontar uma versão em inglês mesmo quando houver outros idiomas.

Permanece a política Specification Required, definida em RFC 8126. A IANA envia a solicitação a Designated Experts. Eles examinam arquitetura, segurança e privacidade; um conflito de interesse exige recusa, e questões não resolvidas voltam à discussão pública.

Há também uma regra explícita para XML. Esquemas, URIs de esquema e de namespace devem ser sintática e semanticamente adequados e registrados conforme RFC 3688. Namespaces reservados à IETF pertencem às especificações do fluxo IETF; trabalhos proprietários ou de outro fluxo precisam de namespace apropriado.

O ganho é concreto: uma entrada passa a oferecer identidade e documentação mais confiáveis. Mas esse processo não consulta todos os servidores instalados nem garante um produto comercial.

Active é uma constatação limitada

Cada entrada contém nome, situação do documento, referência, registrante, campo TLD, divulgação de IPR, estado e notas. Especificações que não são RFC usam Other, evitando a aparência indevida de uma RFC Informational.

Active significa que a extensão está implementada e em uso. Inactive cobre ausência de implementação ou uso e pode ser aplicado quando a especificação citada deixa de estar disponível. O estado, portanto, informa algo verificável.

O mínimo de implantação é propositalmente modesto. A existência de uso em um par registro–registrador ou servidor–cliente recomenda uma análise permissiva. Isso inclui no catálogo práticas reais antes de qualquer adoção ampla. Não permite concluir que todos os registros, clientes ou TLDs ofereçam a função.

O campo TLD segue a mesma lógica. Um nome específico informa o escopo declarado; Any significa que a extensão não foi vinculada a um único TLD; N/A indica ausência de relação com processamento de domínios. Nenhum dos dois é sinônimo de disponibilidade global.

Automação segura precisa armazenar quem sustentou a evidência, em que ambiente e quando. Reduzir a entrada a “registrada” e “ativa” cria um botão global que o registro jamais pretendeu oferecer.

Funções semelhantes podem coexistir

O EPP usa um núcleo pequeno e pontos de extensão porque registros têm regras técnicas e comerciais diferentes. Era previsível que duas extensões resolvessem necessidades parecidas. RFC 7451 procurou tornar essa sobreposição visível.

Pelo novo procedimento, especialistas podem pedir reconsideração de uma proposta ainda não implantada se já houver alternativa semelhante. Mas semelhança isolada não justifica recusa quando os demais critérios são atendidos. Uma implantação existente entre servidor e cliente deve ser reconhecida.

Essa tolerância preserva o mapa do que existe; não declara vencedor nem equivalência. Extensões para elegibilidade, preços ou nomes internacionalizados podem ter modelos de dados, políticas e resultados incompatíveis. O cliente deve casar o URI exato anunciado com a especificação exata, não inferir substituição por um rótulo funcional.

A autoridade ao vivo começa na saudação

RFC 5730 define a saudação do servidor. Seu menu de serviços relaciona versões e idiomas, URIs dos objetos administráveis e, opcionalmente, URIs das extensões suportadas. O servidor também pode limitar privilégios de gerenciamento por cliente.

No login, o cliente escolhe versão e idioma compatíveis e indica objetos e extensões desejados. Uma autenticação bem-sucedida cria sessão que preserva identidade e autorização.

Ainda assim, comandos futuros podem falhar. Os códigos EPP distinguem proibição de política local, dependência de objeto, valor semanticamente inválido para o servidor, serviço não implementado, violação de política de dados e falhas transitórias ou terminais. Um campo único chamado “suportado” apaga diferenças essenciais à operação.

A cadeia adequada é: especificação registrada; estado atual; saudação recente do servidor-alvo; negociação para o cliente exato; formato de comando aceito; transação concluída; estado final do objeto verificado. Cada etapa autoriza uma afirmação mais estreita.

A visão presente não guarda todo o passado

O procedimento define inserção, modificação, desativação e remoção. Registros de consenso IETF exigem IESG Approval para remoção. Os demais podem ser removidos ou desativados por aprovação do IESG ou solicitação do registrante após consulta aos especialistas. Se o responsável desaparecer, um especialista pode corrigir seus dados.

Uma entrada pode alternar entre Active e Inactive. Quando a referência fica indisponível de modo persistente, deve ser marcada inativa até que uma fonte confiável retorne. Isso mantém íntegra a visão atual.

Entretanto, o registro não possui mecanismo histórico, e uma entrada apagada não pode mais ser acompanhada ali. Quem depende dela precisa arquivar observações datadas, cópia ou hash da especificação, saudações, decisões de sessão e planos de migração. Caso contrário, a evidência que aprovou uma integração desaparece enquanto o código continua dependente.

A divisão institucional fica clara. IANA e especialistas mantêm coordenação pública. Operadores controlam capacidades anunciadas e política local. Registradores controlam o que seus clientes negociam. A legitimidade depende de não transferir a um desses atores uma afirmação que só outro pode observar.

Fontes