Resumo

  • A RFC 3367 definiu um núcleo interoperável para consultar serviços de nomes comuns, descobrir capacidades, receber resultados e referências e preservar a origem do serviço e do conjunto de dados.
  • Descoberta e escolha do provedor, registro, propriedade e unicidade ficaram deliberadamente fora do escopo. Uma pergunta podia ter formato comum sem que o protocolo determinasse quem tinha autoridade para respondê-la.

No fim dos anos 1990, a barra de endereço já recebia muito mais do que URLs. Usuários digitavam nomes de empresas, pessoas, livros e lugares. Navegadores e portais transformavam essas palavras em navegação ou busca, mas integrar diretórios especializados exigia interfaces próprias.

O Common Name Resolution Protocol propôs uma interface compartilhada. Publicada em 2002 como Proposed Standard, a RFC 3367 definiu mensagens XML para consultar associações já criadas entre expressões humanas e recursos da Internet. Ela não criou outro DNS nem prometeu um diretório mundial.

O nome comum não tinha sintaxe obrigatória. Diferentemente de um URI, não carregava estrutura formal de identificação. Diferentemente de um URN, sua associação não precisava ser única nem persistente. A mesma expressão podia aparecer em vários serviços e apontar para registros diferentes.

O CNRP começava depois da escolha do serviço. O cliente pedia uma descrição, aprendia propriedades e conjuntos disponíveis e enviava a consulta. A resposta podia trazer descritores de recursos, estados e referências. Um agregador conseguia consultar vários provedores e manter a procedência de cada resultado.

O núcleo exigido era pequeno: nome, identificador local, URI do recurso e descrição. Idioma, geografia e categoria podiam refinar a consulta, mas funcionavam como dicas de melhor esforço. O grau de apoio era um diferenciador do serviço, não uma promessa de ranking idêntico.

Por isso, uma consulta não equivalia a uma cláusula SQL. O provedor devolvia o que julgava mais próximo dos critérios e podia informar sucesso parcial quando ignorasse propriedades, usasse apenas um conjunto ou encontrasse uma referência indisponível. A norma coordenava formato e estados, não cobertura nem todas as taxonomias.

A RFC 2972 declarou o limite institucional: descoberta e seleção de provedores, administração, registro, propriedade e métodos para assegurar nomes únicos ficavam fora do desenho inicial. O protocolo falava com um destino já escolhido; não fazia a escolha.

Era nessa etapa que a autoridade entrava. Um navegador configurado para um diretório comercial e outro para um serviço regional podiam enviar a mesma frase e receber associações diferentes e conformes. O CNRP preservava a origem, mas não escolhia uma vencedora global.

Espaços públicos tornavam a pluralidade inevitável. Nomes de pessoas, lugares e obras não tinham uma autoridade única de atribuição. Serviços podiam organizar recursos semelhantes sob classificações incompatíveis. A própria RFC 2972 reconheceu que palavras-chave livres talvez não garantissem interoperabilidade completa entre taxonomias.

A RFC 3368 expressou essa fronteira no esquema go:. Uma forma indicava servidor; outra continha só a consulta, entregue aos serviços configurados no cliente. A mesma sequência copiada em duas máquinas podia chegar a instituições diferentes. A pergunta viajava, mas a escolha do respondente nem sempre.

O início do transporte era mais determinado. Clientes e servidores genéricos tinham de oferecer HTTP na porta 1096 para o primeiro contato. Depois, o serviço podia anunciar outras opções. Isso ensinava como alcançar um destino conhecido, não como descobri-lo ou confiar nele.

Referências ampliavam o grafo. Um serviço podia devolver resultados e sugerir outro destino. O cliente precisava registrar pares de serviço e conjunto de dados para detectar ciclos. Se um destino faltasse, a resposta podia ser parcialmente bem-sucedida, sem fingir completude.

A segurança voltava ao mesmo limite. A RFC 3367 identificou ataques de intermediário, falsificação do objeto Service e negação de serviço gerada por uma nova indireção. Uma assinatura ajudava, mas sua verificação exigia uma chave pública autorizada. Obter essa chave ficou fora do escopo porque dependia da descoberta do serviço.

A criptografia protegia uma declaração depois da escolha da raiz de confiança; não escolhia a raiz. Validade criptográfica e autoridade institucional continuavam sendo recibos diferentes.

Hoje, o registro da IANA lista go como esquema Permanent e cita a RFC 3368; a RFC 3367 permanece Proposed Standard. Esses fatos provam custódia normativa, não quantidade de navegadores, servidores, tráfego ou usuários. A expectativa de integração comercial da RFC 2972 também não é medição de adoção.

As RFCs 2396 e 3986 dão o contexto geral de URI. As RFCs 2276 e 2483 tratam de resolução no universo de URN, e a RFC 3401 descreve outra família de descoberta delegada. Elas situam a experiência, mas não provam substituição operacional entre mecanismos.

Dois ensaios de Lu Heng fornecem a lente declarada. “Minimum Initial Specification” ajuda a ler o núcleo determinístico pequeno e as decisões locais posteriores. O CNRP padronizou troca, não autoridade. “On Reality Layers” separa conformidade, identidade, procedência, associação, acesso ao recurso e intenção humana.

O desenho reconhecia respostas plurais, preservava origem, informava resultados parciais e exigia controle de ciclos. Essa transparência não eliminava o poder de distribuição. Quem controlava a lista inicial de serviços moldava quais conjuntos poderiam responder antes do intercâmbio padronizado.

A fronteira histórica da RFC 3367 é simples: a Internet podia concordar em como fazer a pergunta. Concordar sobre quem teria direito de responder exigia outra decisão, que o protocolo não tomou.

Fontes