Resumo

  • O changelog atual da AFRINIC lista JSContact como nova funcionalidade RDAP na entrada WHOIS 2.10.7, datada de 29 de novembro de 2022.
  • O guia RDAP atual explica as consultas, o cliente e o redirecionamento para fora da região, mas não identifica versão JSContact, representação de resposta, sinal de conformidade ou mecanismo de pedido.
  • Essa é uma fronteira da documentação pública, não uma constatação sobre a resposta atual do endpoint, uma falha de padrão ou um dano a clientes.

A diferença entre anunciar e orientar

O registro de mudanças da AFRINIC tem uma afirmação clara. WHOIS 2.10.7 aparece como a versão atual. A nota de 29 de novembro de 2022 inclui melhorias ligadas à conformidade com o perfil RDAP da NRO e diz que uma nova funcionalidade RDAP, JSContact, foi adicionada. Essa informação basta para reconhecer que a organização anunciou uma alteração em sua superfície de registro.

O guia RDAP tem outra função. Ele mostra o endpoint e as consultas por endereço IP, autnum, DNS reverso e entidade. Indica o NicInfo como cliente de linha de comando e explica que uma consulta por recurso de outra região recebe HTTP 301 com um Location para o recurso RDAP apropriado. É uma descrição útil de como alcançar dados de registro.

Ainda assim, a descrição não transforma o nome da funcionalidade em uma instrução de interoperabilidade. Na orientação RDAP atual não aparecem JSContact, jCard, rdapConformance nem version. Portanto, o leitor não consegue saber pelos dois documentos juntos se a palavra do changelog se refere a uma versão específica, qual formato de contato seria padrão, se um cliente poderia pedir uma representação diferente, ou que marca na resposta mostraria o resultado.

Essa lacuna precisa conservar o seu tamanho. Ela não prova que o endpoint da AFRINIC não produz JSContact. Não prova que um parâmetro de pedido é ignorado. Não demonstra falta de conformidade com um perfil NRO, quebra de cliente, exposição de informação ou incidente operacional. Esta comissão não observou uma resposta ao vivo. Ela compara o que o changelog afirma com aquilo que o guia torna legível ao leitor.

O mesmo nome não manteve o mesmo contexto

Há uma razão histórica para não preencher os espaços por suposição. Em abril de 2022, antes da nota da AFRINIC, já existia uma versão do Internet-Draft do IETF sobre JSContact em respostas RDAP. Era explicitamente trabalho em andamento, descrevia uma extensão de contatos de entidades e usava termos como jscard. A coincidência temporal não demonstra que a AFRINIC tenha adotado aquele texto ou qualquer um de seus detalhes.

O rascunho atual, de agosto de 2026, usa termos posteriores: jscontact_card, escolha de representação feita a pedido do cliente, sinalização por rdapConformance e fases de transição entre jCard e JSContact. Ele é útil como comparação porque mostra que formato, versão, pedido, marcador de resposta e compatibilidade são decisões diferentes. Não é, porém, uma obrigação retroativa para a entrada da AFRINIC de 2022.

O registro atual de JSContact da IANA também separa as versões maiores 1.0 e 2.0. Isso não aponta uma versão implantada pela AFRINIC. Mostra apenas que um nome amplo pode exigir informação adicional antes de orientar um cliente público.

A melhor defesa da AFRINIC é concreta. Um registro não deve precisar publicar arquitetura interna, dados de contato, configurações de segurança, logs de tráfego ou planos privados para que uma página de ajuda seja útil. Um changelog curto e um guia centrado em consultas comuns são escolhas editoriais e operacionais legítimas.

O complemento proporcional seria um registro de disponibilidade de extensão. Ele poderia ligar a alegação de funcionalidade à revisão de serviço e de documentação; declarar a representação e a versão quando aplicável; listar um método público de solicitação apenas se existir; nomear o sinal de conformidade da resposta; descrever a situação de compatibilidade; apontar o perfil de referência; registrar comportamento de fallback, responsável, correção e substituição. Um resumo não sensível de captura de teste bastaria para mostrar a verificação sem expor dados reais.

Uma ligação pública, não uma ordem técnica

Esse registro não escolheria o formato por AFRINIC. Também não prometeria uma data de migração. Ele manteria a autoridade operacional no registro e deixaria de fora o material que não deve ser público. Sua função seria impedir que fornecedores, clientes ou revisores convertessem uma frase breve em uma garantia que nunca foi escrita.

Para o leitor, a melhoria é simples: cada nome público volta a uma documentação pública que explica seu alcance. Para a AFRINIC, a melhoria é igualmente simples: uma eventual correção passa a ter um lugar, uma data e uma relação de substituição. Esse é o tipo de precisão que aumenta a verificabilidade sem transformar transparência em exposição.

Fontes

  1. AFRINIC Online Services Changelog
  2. Guia do serviço RDAP da AFRINIC
  3. IETF draft-ietf-regext-rdap-jscontact-11
  4. IETF draft-ietf-regext-rdap-jscontact
  5. Registro JSContact da IANA