Resumo

  • A revisão 15 de RDAP Extensions propõe uma data de obsolescência no registro da IANA. O contato registrado poderia pedir a mudança de sua extensão; o IESG poderia pedi-la para qualquer entrada. Isso altera o registro, não o software distribuído.
  • O rascunho de versionamento oferece start, end, versão padrão, predecessor e sucessor em /help, identifica a versão de cada resposta e recebe preferências do cliente. Ele coordena a transição sem conhecer todos os clientes.
  • Um recibo de retirada deve separar a autoridade registral, o estado anunciado e observado de cada servidor, a demanda amostrada e a incerteza residual. É uma proposta de Daniel Kade, não uma regra do IETF.

Em um inventário, aposentar uma interface parece simples: marcar, datar, substituir. Em RDAP, uma consulta pode atravessar serviços de bootstrap, redirecionamentos e referências até chegar a autoridades diferentes. O cliente não precisa ter relação contratual com o servidor. A simplicidade do inventário termina justamente onde começa a rede.

Publicado em 13 de agosto de 2026, draft-ietf-regext-rdap-extensions-15 trata as extensões como parte desse ecossistema. O documento é um Internet-Draft do grupo REGEXT com intenção de Standards Track. O Datatracker informa que uma revisão é necessária após questão levantada pelo grupo e não mostra Area Director responsável. A revisão 07 de Versioning in RDAP, de 31 de julho, também permanece rascunho. Nenhum dos dois é RFC ou mandato de implantação.

O poder de declarar um nome obsoleto

Identificadores de extensão ocupam o rdapConformance e servem como espaço de nomes para elementos do protocolo. São opacos. Um número no fim pode parecer versão, mas não prova relação de sucessão; é preciso consultar a especificação.

A revisão 15 criaria Deprecation Date. O contato inscrito pediria a obsolescência de sua extensão, e o IESG poderia pedi-la para qualquer entrada. A IANA registraria a data segundo o formato de dia completo da RFC 3339. Há, portanto, uma cadeia clara para mudar o status público do rótulo.

Essa cadeia não alcança a implantação. A IANA não remove uma estrutura JSON de servidores independentes nem atualiza uma biblioteca antiga. A data orienta a interpretação do nome; não comprova que o comportamento desapareceu.

O texto pede a data 21 de agosto de 2025 para icann_rdap_response_profile_0 e icann_rdap_technical_implementation_guide_0, já marcados OBSOLETED. O registro atual, atualizado em 1º de setembro de 2026, exibe os dois e seus sucessores de versão 1, mas ainda não uma coluna separada de data. Não há base para acusar a IANA: a instrução segue em um documento de trabalho.

A política Specification Required com Expert Review cuida de outra fronteira. A especificação precisa ser estável, acessível e detalhada o suficiente para implementações independentes. O rascunho propõe ao menos três especialistas e dupla checagem. É controle de entrada do vocabulário, não censo de instalações.

O servidor publica seu próprio calendário

No rascunho de versionamento, versioning_help informa em /help versões aceitas, padrão, documentação, relações de predecessor e sucessor e instantes start/end. versioning_data diz qual versão moldou uma resposta. versioning_list permite ao cliente indicar preferência.

Capacidade, execução e preferência não são equivalentes. Um servidor pode manter a versão antiga sem torná-la padrão. Uma resposta nova não prova que a antiga sumiu. Um cliente silencioso pode apenas aceitar o padrão, sem compreender o formato novo.

end é uma promessa do servidor sobre o fim do suporte. Passado o momento, o objeto de versão deve sair do anúncio. Sem end, não há expiração planejada. Nenhum dos estados comprova que todos os clientes externos estejam prontos.

Para mudanças incompatíveis, a revisão 07 recomenda uma fase intermediária: elementos antigos e novos coexistem, o substituto é anunciado e a remoção vem após tempo suficiente. Também se pode mudar primeiro o padrão e aceitar pedidos explícitos pela versão antiga até o fim. O mecanismo reduz rupturas; não descobre uma duração universal.

O rascunho de extensões admite a razão: sem relação entre servidor e cliente, não há como afirmar em termos absolutos que uma ruptura não afetará ninguém. A incerteza não pode virar veto eterno. Compatibilidade sem prazo também perpetua custo, ambiguidade e risco.

Medição com limite de privacidade

Telemetria pode contar pedidos pela versão antiga, comparar períodos e localizar erros em referências específicas. Clientes administrados podem confirmar a atualização. Mas tarefas sazonais e bibliotecas que nunca enviam preferência continuam invisíveis.

Guardar para sempre nomes consultados, endereços e assinaturas de software seria uma troca ruim. O relatório deve agregar, limitar a retenção e dizer quais servidores e períodos cobriu. “Nenhum pedido antigo observado nesta amostra” é uma conclusão válida. “Nenhum cliente depende” não é.

O recibo de retirada

Primeiro vêm o identificador exato, o solicitante competente, o registro da IANA e a data. Depois, predecessor, sucessor, incompatibilidades, elementos removidos e referência estável. A terceira parte guarda, por servidor, capturas de /help, mudança do padrão, início e fim, versão de respostas, tratamento de erro, reversão e remoção observada.

A quarta parte resume a demanda: janela, nós, método de agregação, taxa de versão antiga, clientes conhecidos pendentes e lacunas. Por fim, o operador registra sua decisão, o corte das evidências e as exceções. Planejado e observado nunca ocupam a mesma célula.

Esse desenho deixa cada autoridade no seu lugar. A IANA controla o estado do nome. O operador controla o serviço. O mantenedor controla o cliente. O recibo conecta as decisões sem declarar que uma delas representa as demais.

Fontes