Resumo

  • O membro redacted permite nomear um campo ocultado, indicar o método e apontar para a forma anterior ou posterior da resposta. Ele registra uma afirmação do servidor sobre a saída, não o conteúdo original nem sua exatidão.
  • Motivo e política são recibos separados, e até o sinal de existência pode ser omitido por privacidade. A auditoria precisa manter consulta, servidor, classe de acesso, horário, JSON bruto, avaliação de caminhos e versão da política no mesmo conjunto probatório.

O chamado que parecia simples

Uma equipe de suporte recebe a queixa de que o telefone do registrante “sumiu” do RDAP. O atendente compara a página pública com uma captura antiga e conclui que uma nova regra apagou o dado. Ele observou uma diferença, mas ainda não sabe se a origem deixou de fornecer o telefone, se a resposta mudou para outro perfil, se o cliente perdeu privilégio, se um objeto inteiro foi removido ou se o programa falhou ao ler um array.

A RFC 9537 foi publicada em março de 2024 no Standards Track do IETF para tornar uma parte dessa incerteza explícita. O texto define como respostas RDAP podem identificar campos removidos, esvaziados, parcialmente ocultados ou substituídos. James Gould assina o documento com David Smith, Jody Kolker e Roger Carney. O perfil do IETF capturado em 7 de setembro de 2026 lista treze RFCs ligados a Gould. A biografia do comitê Registration Operations Workshop o descreve como fellow da Verisign com responsabilidades sobre direção técnica de serviços de registro.

São evidências de atuação e autoria compartilhada, não uma reivindicação de invenção exclusiva nem de controle sobre cada implantação.

O ganho do padrão é pequeno no melhor sentido: o servidor pode deixar uma descrição verificável de como tratou um lugar da resposta. O protocolo não finge conhecer a verdade escondida atrás desse lugar.

O alcance do membro redacted

Quando a extensão é usada, rdapConformance inclui redacted. O objeto afetado normalmente carrega um array com uma descrição para cada campo ocultado. Toda descrição tem um name obrigatório, que pode empregar um tipo registrado ou texto livre.

Os caminhos registram a relação estrutural. prePath aponta para a posição no documento antes da ocultação e, por isso, pode não encontrar nada no JSON entregue. postPath aponta para o valor vazio, parcial ou substituto que continua presente. Os dois são mutuamente exclusivos. replacementPath pode indicar outro campo que assumiu a função. JSONPath, padronizado na RFC 9535, é a linguagem padrão.

Assim, um cliente pode provar que recebeu do servidor uma descrição com certo nome, método e caminho. Não pode recuperar o valor anterior, confirmar que o banco interno estava correto ou concluir que a pessoa presumida era realmente o titular. Tampouco o caminho verifica a decisão de autorização. Ele localiza uma asserção no formato; não certifica os fatos ocultos.

Os registros da IANA fornecem identificadores e vocabulários comuns para extensão, nomes, motivos e linguagens de expressão. Isso evita dialetos incompatíveis. O registro de um token não funciona como selo de conformidade para cada resposta que o utiliza.

Quatro métodos, resultados observáveis diferentes

No método removal, um campo ou objeto desaparece do JSON entregue. É o padrão quando method não aparece, salvo onde a posição em um array define o significado. Nesses arrays jCard, emptyValue preserva a posição e esvazia o conteúdo com uma string vazia ou null. PartialValue mantém apenas uma parte de um valor formatado. ReplacementValue entrega outro valor ou campo, como um e-mail anonimizado ou uma página de contato.

Uma interface pode aplicar a mesma faixa “oculto” a todos, mas um registro de evidências não deveria fazê-lo. Um objeto removido não é um slot vazio. Um endereço parcial ainda divulga alguma coisa. Um formulário de contato mantém uma função sem ser o e-mail do registrante. A especificação também proíbe usar enchimento feito de uma letra repetida; um texto arbitrário pode violar o formato do campo e parecer dado verdadeiro.

O operador deve guardar a forma recebida. Uma captura de tela que omite o método é justamente uma compressão das diferenças que a RFC quis tornar auditáveis.

O motivo não decide a política

Uma descrição pode trazer reason, como tipo registrado ou explicação para leitura humana. A descrição textual não pode ser dependência de processamento. Um fluxo automático que interpreta “política do servidor” como decisão final cria uma regra que o protocolo não definiu.

O servidor pode publicar uma política de ocultação, mas seu conteúdo fica fora da RFC 9537. O padrão não valida consentimento, não interpreta legislação e não decide qual solicitante tem direito de acesso. A RFC 7481 oferece autenticação e acesso em camadas segundo política local. Duas classes de cliente podem receber visões diferentes e ambas serem respostas previstas pelo serviço.

O perfil RDAP de 2024 da ICANN demonstra como uma comunidade adiciona requisitos concretos. No universo gTLD ao qual se aplica, ele relaciona elementos de registro a nomes e métodos da RFC 9537 e especifica, por exemplo, tratamento para e-mail. É uma camada operacional importante, mas não se transforma em política universal de todos os servidores RDAP.

Existe ainda uma exceção crucial: afirmar que um campo existe, embora oculto, pode vazar informação. A RFC permite ao servidor omitir a própria descrição quando o sinal de existência é sensível. Portanto, silêncio não equivale a completude. Pode significar ausência, falta de suporte à extensão ou decisão de não confirmar o campo.

Montando o recibo mínimo

O primeiro componente é a solicitação: URI exata, consulta direta ou busca, servidor autoritativo, redirecionamentos, horário, identidade do transporte, autenticação e classe de autorização. Uma busca pública e uma consulta privilegiada não são medições intercambiáveis.

Depois vêm os bytes da resposta ou seu hash, os valores de rdapConformance, a identidade do objeto e cada nome, linguagem, caminho, método e motivo. O relatório registra se postPath resolveu no documento entregue, como prePath foi interpretado e quais versões do cliente e do avaliador JSONPath foram usadas. Sem isso, uma atualização do parser pode parecer mudança do servidor.

Se houver um link de política, registre URL, versão e data observadas. Uma página alterada posteriormente não explica automaticamente uma resposta anterior. Na comparação de duas visões, cada resultado deve permanecer ligado à sua classe de acesso.

A RFC 9082 distingue lookup e search. Em buscas, a descrição de ocultação pertence a cada objeto; truncar o conjunto inteiro é outro evento. Notices e remarks da RFC 9083 podem fornecer contexto do serviço ou do objeto, porém não substituem o sinal estruturado por campo.

O conjunto sustenta uma conclusão proporcional: este servidor descreveu este campo como ocultado desta forma, nesta consulta, neste horário e para este acesso. O valor original, a correção da política e o direito de obtê-lo exigem outros recibos.

Fontes