Resumo

  • O rascunho que pretende substituir a RFC 7451 orienta os especialistas designados a serem permissivos quando uma extensão EPP tiver sido implementada e implantada por pelo menos um par registro/registrador ou servidor/cliente. Ele também permite várias extensões com funções iguais ou semelhantes.
  • O registro estabelece uma referência permanente, uma identidade técnica e um caminho de revisão responsável. Não escolhe o melhor projeto, não concede status Standards Track, não demonstra adoção ampla e não garante que duas extensões sejam intercambiáveis em uma implantação específica.
  • A própria tabela da IANA mostra a coexistência: suas notas dizem que as extensões de IDN e de privacidade da CORE são sintática e funcionalmente idênticas às equivalentes da TANGO, embora usem namespaces XML diferentes. A decisão operacional exige um mapa de coexistência que mantenha as duas partes da afirmação.

Imagine uma equipe de compras recebendo a exigência de “suportar a extensão EPP registrada”. A frase soa precisa, mas ainda não informa qual namespace, qual versão, quais TLDs ou qual contraparte. A existência de uma linha oficial mascara todas as escolhas que o documento deixou em aberto.

Esse efeito decorre de uma leitura errada da função do registro. O protocolo EPP foi feito para receber extensões além de seus comandos e objetos básicos. Registros, registradores e fornecedores podem desenvolver mecanismos em contextos operacionais distintos. A tabela pública torna esses mecanismos localizáveis, reduz colisões de identificadores e conserva um vínculo com suas especificações. Ela não converte diversidade implementada em uma única solução recomendada.

A revisão 10 do draft-ietf-regext-ext-registry-epp, publicada em 17 de agosto de 2026, torna o limite explícito. Várias extensões podem ter funcionalidade igual ou semelhante, e essa semelhança não deve ser motivo suficiente para rejeitar um pedido que satisfaça os demais critérios. Quando ao menos um par registro/registrador — ou servidor/cliente — já implementou e implantou o mecanismo, os especialistas devem adotar uma postura permissiva.

O teste evita reservar nomes para abstrações sem uso. Não mede liderança.

A prova é bilateral e limitada

EPP depende de diálogo. Uma função presente apenas no servidor ou apenas no cliente não conclui a operação pretendida. Por isso, um par em funcionamento é uma boa unidade mínima: mostra que a especificação atravessou a fronteira entre implementações e produziu uma troca real.

Ainda assim, o alcance dessa prova termina no par observado. Ela não informa quantos registradores conseguem usar o recurso, quantos domínios passam por ele, que versões de software o sustentam nem como os campos opcionais se comportam em outras combinações. Um segundo registro pode interpretar a mesma especificação de modo diferente; um cliente pode manter versões distintas para contrapartes distintas.

O estado “Active” também tem escopo estreito. O rascunho o define como implementado e em uso. “Inactive” cobre a ausência de implementação ou uso, ou a indisponibilidade da especificação. Não há percentual de adoção, volume de transações, taxa de falha ou cobertura por fornecedor. Ler Active como “padrão da indústria” é inventar uma métrica que a tabela nunca coletou.

Nem mesmo a coluna de TLDs substitui uma matriz de compatibilidade. Ela não informa se o suporte é obrigatório, qual versão está ativa, que clientes foram testados ou se uma ponte converte namespaces. Registro oferece coordenadas; operação oferece evidência de alcance.

A revisão garante legibilidade, não preferência

“Specification Required”, política descrita na RFC 8126, exige uma especificação permanente e publicamente disponível, submetida a especialistas designados. O novo rascunho aceita RFCs e especificações proprietárias que continuem facilmente acessíveis, com uma versão em inglês. Um Internet-Draft comum não vale como referência permanente para novos registros, e a alocação antecipada da RFC 7120 não se aplica.

Esses requisitos protegem a memória do namespace. Um desenvolvedor que encontre uma URI XML anos depois precisa descobrir o significado pretendido. A tabela registra nome, status do documento, referência, requerente, TLDs, informações de propriedade intelectual, situação ativa ou inativa e notas.

O exame técnico observa solidez arquitetural, documentação de privacidade, sintaxe e semântica de URI e o uso correto de namespaces IETF ou não IETF. Um especialista principal normalmente conduz a análise. Se estiver indisponível, o grupo de suplentes decide por consenso de maioria simples. Quem perceber conflito de interesse deve se afastar, e a lista REGEXT oferece um espaço público para questões difíceis.

Trata-se de revisão substantiva, mas não de seleção comparativa. O especialista pode barrar uma proposta mal documentada ou exigir correções. Não precisa avaliar participação de mercado, premiar elegância nem decidir qual fornecedor deve se tornar dominante. A inscrição estabiliza a pergunta “o que esse identificador quer dizer?”. Não resolve “qual mecanismo todos devem comprar?”.

O documento que atualiza o processo ainda está em movimento. A revisão 10 é um Internet-Draft ativo, destinado a Best Current Practice, enviado ao IESG e aguardando designação de editor na fila do RFC Editor. Se aprovado e publicado, tornará a RFC 7451 obsoleta. O status provisório precisa permanecer visível; antecipar um RFC seria atribuir uma autoridade que o processo ainda não concluiu.

A tabela já contém respostas paralelas

O EPP Extension Registry da IANA, atualizado em 4 de setembro de 2026, reúne documentos Standards Track e “Other”, além de extensões ativas e inativas. As notas sobre CORE e TANGO mostram com clareza por que uma tabela de coexistência não é uma tabela de campeões.

Na função de IDN, a extensão da CORE é descrita como sintática e funcionalmente idêntica à equivalente da TANGO, mas com um namespace XML diferente. As extensões de privacidade das duas famílias recebem observação semelhante.

A palavra “idêntica” não apaga o namespace. Ele integra a identidade no fio: o cliente envia elementos de um espaço, e o servidor declara os espaços que entende. Suportar CORE não significa reconhecer automaticamente uma mensagem TANGO. Ferramentas de conformidade, ciclos de versão, responsáveis por mudanças e escopo de implantação podem divergir.

A nota também não afirma que todas as operações, opções, respostas de erro e revisões futuras continuarão substituíveis. Ela documenta uma relação forte num momento e contexto determinados. A origem da duplicidade pode estar em cronologia, comunidades, contratos, implantação anterior ou custos de coordenação.

Apagar uma linha produziria simplicidade visual sem eliminar o código antigo. Logs, contratos e sistemas continuariam carregando o namespace removido, agora com menos pistas. Preservar as duas entradas permite que uma migração reconheça de onde parte e para onde pretende ir.

Um mapa para enxergar as decisões restantes

O registro da IANA deve continuar sendo a referência da inscrição. Para decisões de suporte, proponho uma camada separada: o mapa de coexistência. É uma ferramenta editorial deste artigo, não um novo requisito do IETF ou da IANA.

O mapa agruparia extensões por função duradoura — IDN, privacidade, lançamento, tarifas e outras — sem fundir seus namespaces. Em seguida mostraria versão da especificação, comandos afetados e identidade XML. A procedência da inscrição teria campos próprios: documento permanente, status, requerente, data e percurso de revisão.

A evidência de implantação indicaria o par exato, software, versão, TLD e data. Se a comprovação cobrir apenas um servidor e um cliente, a ficha diria isso literalmente. Outro bloco trataria da sobreposição: quem declarou a equivalência, com que método e até onde ela foi testada. Nota da IANA, comparação de esquemas, teste de conformidade e observação em produção têm pesos e alcances diferentes.

O mapa incluiria ainda suporte atual de clientes e servidores e qualquer tradução entre namespaces. Uma ponte precisa ter dono, regras e perdas registradas. Por fim, manteria histórico de referências, notas e estados.

Essa visualização separa quatro afirmações: a extensão está registrada; foi implantada em algum lugar; é suportada aqui; pode substituir outra neste caso. Confundi-las transforma uma informação verdadeira em quatro conclusões, três delas não demonstradas.

Remover é diferente de desativar

O rascunho disciplina inclusão, modificação, desativação e remoção. Uma mudança de estado deve trazer justificativa. Remover uma entrada resultante de consenso IETF exige aprovação do IESG. Para entradas não IETF, o IESG ou o requerente original, junto aos especialistas, pode buscar remoção ou desativação.

Ao mesmo tempo, o texto reconhece que o registro não possui mecanismo histórico. Depois da remoção, a entrada apagada já não pode ser rastreada ali. Isso torna a escolha de ciclo de vida uma escolha sobre preservação de evidência.

Uma entrada inativa desencoraja nova dependência e mantém a coordenada de sistemas passados. A remoção tira essa coordenada da tabela presente. Se a especificação também ficar indisponível, um incidente futuro pode deixar de ser explicável: ninguém saberá se o XML era uma extensão legítima antiga, uma versão incompatível ou uma invenção local.

O catálogo atual coordena o presente. Cópias datadas permitem reconstruir o passado. Sem as duas camadas, a limpeza administrativa de hoje se torna a amnésia operacional de amanhã.

Fontes