Resumo

  • Nas relações de resultado único rdap-up e rdap-top, o RFC 9910 permite ligar à busca ou a uma consulta direta que produzia a mesma resposta quando o documento foi gerado.
  • Uma mudança no banco antes da abertura do link pode alterar o resultado; a resposta original, o contexto da relação e cada acesso posterior precisam de registros separados.

Um pacote de investigação guardava a resposta de uma rede subordinada, o horário de coleta e um link rdap-up para um identificador superior. Horas depois, o analista acessou o endereço e arquivou o objeto devolvido. A ferramenta juntou as duas peças e exibiu uma hierarquia histórica coerente.

Coerente não significava contemporânea. O objeto superior não fora capturado quando a resposta subordinada chegou. A consulta posterior mostrava o estado posterior do serviço, mas não recuperava a representação inicial e não provava continuidade entre os dois pedidos.

O cenário é hipotético e não descreve o comportamento de um registro específico. Ele serve para tornar visível o limite temporal que o RFC 9910 impõe aos links de relação.

O documento acrescenta buscas básicas, relacionais e reversas para redes IP e números de sistemas autônomos. rdap-up encontra o objeto menos específico mais próximo que contém o recurso. rdap-top encontra a cobertura mais geral. São operações de um único resultado: retornam um objeto como na consulta direta ou HTTP 404.

rdap-down e rdap-bottom produzem conjuntos. A diferença só delimita este texto. Não se reabre a discussão sobre cobertura bottom nem se repete um exemplo observado da ARIN. A questão aqui é a evidência temporal de um único destino superior.

O servidor pode inserir a URL da busca relacional correspondente. Pode também usar outra URL que entregue a mesma resposta no momento do pedido. Em relações únicas, essa alternativa pode ser a URL comum de consulta do objeto encontrado.

A substituição é conveniente, mas sua equivalência tem data. Se o estado da base mudar antes de o link ser resolvido, alerta o RFC, a consulta direta poderá apresentar um resultado diferente da busca que justificou o link.

O href pode permanecer idêntico enquanto muda a representação selecionada. Um link preserva o caminho, não o conteúdo encontrado. Guardar apenas o endereço arquiva uma referência e descarta a observação da outra ponta.

O RFC 9083 exige value, rel e href no link RDAP: contexto, relação e alvo. No RFC 8288, um link web é uma conexão tipificada entre recursos. O tipo não fixa todas as representações futuras do alvo.

Descobrir a autoridade também não congela os dados. O RFC 9224 orienta o cliente até o serviço RDAP autoritativo para endereço, prefixo ou ASN. Ele responde onde perguntar, não transforma a resposta numa fotografia imutável.

O tempo precisa aparecer no modelo de prova. A resposta subordinada é uma observação. Uma resolução imediata do superior seria outra. O acesso do dia seguinte é uma terceira. Cada registro deve preservar bytes, hash, URL, horário de recebimento, estado HTTP, Date, validadores, conformidade e endpoint autenticado.

Segundo o RFC 9110, Date marca a origem da mensagem. ETag e Last-Modified, quando existem, ajudam a descrever ou validar uma representação selecionada. Não são identificadores de transação do registro nem revelam a causa da mudança.

O RFC 9111 separa a atualidade do cache da história registral. Uma resposta fresca pode refletir uma alteração recente da base. Uma resposta ainda reutilizável pode anteceder a decisão estudada. Frescor HTTP não demonstra identidade histórica.

O filtro status altera a hierarquia aparente. A relação é calculada como se objetos sem o estado solicitado fossem removidos. Uma busca active pode pular uma cobertura mais próxima e escolher outra camada. O link resultante expressa uma relação filtrada, não um parentesco incondicional.

Suporte é evidência, não pressuposto. Combinações não oferecidas podem receber HTTP 501. A presença de relações dentro das respostas é opcional. Ausência de link não prova que uma busca explícita ficaria sem resultado. Transformar uma escolha de apresentação em negativa de registro cria um fato inexistente.

A captura correta começa antes do clique. Primeiro se guarda a resposta atual sem alteração. Depois se extraem contexto, relação, alvo e filtro. Uma resolução imediata gera outro registro ligado por tempo e hash. Verificações futuras acrescentam linhas e nunca substituem a observação inicial.

Pedidos condicionais são úteis quando há validadores. Um 304 sustenta uma conclusão específica sobre aquela representação sob as regras HTTP. Não prova o resultado de uma busca que não foi feita, de outro filtro ou de um estado anterior que não foi capturado.

O mesmo limite evita extrapolação institucional. Uma relação RDAP pode demonstrar a hierarquia publicada por um serviço autoritativo em certo instante e sob certa consulta. Sozinha, não comprova origem de rota, autorização RPKI, controle de conta, uso operacional, propriedade jurídica ou motivo da alteração.

Em Running-Code Primacy, Heng Lu distingue o texto compartilhado do comportamento executado. A norma torna a pergunta interoperável; o estado real e a resposta preservada fornecem uma resposta verificável.

Minimum Initial Specification recomenda um núcleo comum estreito. As relações pertencem a esse núcleo; retenção, comparação e escalonamento são decisões locais responsabilizáveis.

Reality Layers impede que a precisão de um vínculo simbólico domine outras camadas da realidade. Data Sovereignty também separa controle formal do registro e controle prático da rede.

O RFC 9910 melhorou o percurso pela hierarquia, não a viagem no tempo. Preservar a resposta subordinada, a primeira resposta superior e cada acesso futuro permite que o link conecte observações sem inventar simultaneidade.

Fontes