Resumo

  • THTTP codificava pedidos e respostas de serviços de resolução URN em HTTP 1.0 ou 1.1.
  • Uma resposta pode indicar uma URL ou entregar dados, mas não prova atribuição, mandato do resolvedor, integridade, permissão ou disponibilidade duradoura.

O valor da RFC 2169 foi tornar um experimento implantável. Um servidor HTTP já existente podia receber, por CGI ou mecanismo equivalente, o URN e o serviço desejado. Não era preciso instalar um protocolo completamente novo para testar a resolução. O texto tratava N2L, que pede uma URL, e N2R, que pede o recurso nomeado; códigos de estado, negociação e cache permaneciam mecanismos HTTP normais.

Essa praticidade não cria autoridade. A RFC 2141 separa a representação sintática e a equivalência lexical da equivalência funcional, que pertence às regras de cada namespace. A RFC 2169 exigia o mesmo resultado para URNs lexicalmente equivalentes, mas não escolhia um resolvedor universal nem transformava um cabeçalho Location em prova de titularidade.

Uma observação HTTP deve, portanto, ser lida em partes. Uma resposta 200 evidencia a resposta daquele endpoint naquele momento. Um redirecionamento sugere um local. Uma resposta N2R pode fornecer bytes. Nenhum desses fatos demonstra, sozinho, que o namespace concedeu o identificador, que o endpoint continua delegado, que o conteúdo não mudou, que o cliente tem permissão ou que outro resolvedor concordaria.

A RFC 3406 descreveu a atribuição de URNs como processo administrado e a resolução global como registro separado. O registro de namespaces URN da IANA, sob a RFC 8141, documenta namespaces reconhecidos; não certifica um resolvedor HTTP histórico específico.

A lição é de fronteira: HTTP pode transportar uma pergunta de resolução sem absorver as decisões de governança e custódia que continuam em outras camadas.

Fontes e limites de evidência

Baseado nas RFCs 2169, 2141, 1737, 3401, 3406 e 8141 e no registro IANA. As fontes não medem a adoção real de THTTP nem confirmam a autoridade atual de um endpoint.