Resumo

  • O RFC 2352 propôs caminhos formados por nome legal, forma societária, localidade e país, deslocando a primeira decisão de elegibilidade do registro DNS para autoridades de empresas ou marcas.
  • O desenho registrou um conflito real entre rótulos memoráveis e múltiplos direitos legítimos, mas um registro legal não comprovava delegação, controle do serviço, reputação nem uma identidade universal.

Uma resposta hierárquica para uma disputa aparentemente plana

No fim dos anos 1990, o conflito parecia caber numa única posição de uma tabela: várias organizações queriam o mesmo nome curto, mas um ramo do DNS só podia delegá-lo uma vez. O RFC 2240 descreveu esse atrito entre escassez, nomes desejáveis e requerentes plausíveis. O RFC 2352, publicado em maio de 1998 como contribuição independente Informational, substituiu a versão anterior e propôs carregar mais contexto no próprio caminho.

O formato geral era <token-legal>.<localidade>.<país>. Uma sociedade limitada britânica poderia ficar sob LTD.UK; uma marca francesa, sob TM.FR; certas formas norte-americanas acrescentariam o estado. A etiqueta da organização viria de seu nome registrado completo, sem o sufixo jurídico já representado no ramo superior. Espaços virariam hífens, e pontuação seria descartada ou convertida.

O mecanismo tinha uma virtude: recusava a ficção de que “quem chegou primeiro” resolve toda legitimidade. Nomes iguais podem pertencer a organizações distintas quando forma jurídica, território ou classe de marca mudam. Também evitava pedir ao operador DNS que improvisasse direito empresarial.

Mas a pergunta respondida era limitada: qual nome consta deste cadastro, sob estas regras? A proposta tentava fazer essa resposta suportar outra, muito maior: qual nome público deve identificar a organização na Internet?

Cada comprovante tinha seu próprio alcance

O RFC afirmava que não surgiriam disputas porque o nome seria único no contexto jurídico aplicável. “No contexto” é a parte decisiva. Um cadastro pode garantir unicidade dentro de um município, estado, país, forma societária ou classe de marca. Outro cadastro pode aceitar as mesmas palavras sob outra competência. Nenhum deles se converte automaticamente num catálogo mundial de identidades.

A normalização introduzia uma segunda fronteira. Remover pontuação e trocar espaços por hífens produz uma etiqueta transportável pelo DNS, mas pode apagar diferenças mantidas pelo documento legal. Para auditar o resultado seriam necessários, no mínimo, o registro de origem, a versão da transformação, a decisão do operador do ramo pai e o estado da zona. A etiqueta final aponta para essa cadeia; não a substitui.

Também é importante conter a palavra “autoridade”. No RFC 1034, um servidor é autoritativo porque possui informação completa sobre uma zona. O RFC 1035 define a mecânica que permite transportar e consultar as etiquetas. Isso é autoridade técnica sobre uma parte delegada da árvore, não competência para decidir personalidade jurídica, prioridade de marca ou controle corporativo.

Até uma resposta DNS correta prova pouco além de sua camada. Ela não demonstra que a empresa ainda existe, que o registrante age legitimamente, que o site é seguro ou que o usuário chegou ao serviço pretendido. Registro legal, mapeamento, delegação, resolução e operação são realidades conectadas, não equivalentes.

A objeção veio no próprio registro de publicação

O registro editorial do RFC 2352 preserva uma nota incomum e substancial. O editor observou que organizações estabelecidas teriam de abandonar endereços conhecidos em favor de nomes mais longos, sem incentivo claro. A nota também apontou uma contradição institucional: o texto tratava a estrutura nacional como assunto de competência nacional e, ao mesmo tempo, prescrevia como países deveriam representar formas jurídicas e localidades. A implementação, concluiu, talvez não fosse politicamente viável.

Não era apenas uma crítica estética a nomes compridos. O RFC 920 já havia descrito domínios como entidades administrativas e registrado o custo de mudar um nome: referências antigas persistem em listas, mensagens, tabelas, impressos e memória humana. Um novo endereço juridicamente bem formado não herda automaticamente certificados, correio, links, configuração e reputação acumulados pelo anterior.

O RFC 1591 ajuda a localizar a outra competência. Gestores de domínios de país operavam delegações sob políticas locais, deveres técnicos e exigências de serviço robusto. Cooperação com um registro empresarial era possível, mas não fundia as duas instituições. O cadastro decidia um fato jurídico delimitado; a hierarquia DNS decidia a existência e a manutenção de um ramo.

Os mecanismos posteriores separaram problemas diferentes

Em 1999, a ICANN adotou a Política Uniforme de Resolução de Disputas por Nomes de Domínio. Seu teste exige semelhança capaz de causar confusão, ausência de direito ou interesse legítimo do titular e registro e uso de má-fé. Trata-se de uma via adjudicatória vinculada a contratos de registro. Ela não deriva todo domínio de uma razão social e não transforma todo certificado de empresa em delegação automática.

Outra limitação era a representação de nomes fora do ASCII. O RFC 3490 criou uma forma compatível com ASCII na fronteira das aplicações, mantendo a infraestrutura DNS existente. Ainda assim, preservou a consulta por correspondência exata e deixou muitas equivalências linguísticas, visuais e sonoras fora do protocolo. Codificar caracteres resolveu transporte; não resolveu titularidade.

Essa separação é o legado mais útil do RFC 2352. O texto identificou corretamente que uma disputa por rótulo curto ocultava vários contextos legítimos. A hierarquia preservava parte desse contexto melhor do que uma corrida por um único nome. Porém, o DNS comum só precisava garantir unicidade dentro de cada ramo, delegação correta e consulta interoperável. Não precisava incorporar todas as formas societárias do mundo para funcionar.

Os ensaios de Heng Lu sobre camadas de realidade e sobre uma especificação comum mínima com decisões locais oferecem uma leitura precisa: um registro descreve uma realidade delimitada, não cria todas as realidades que passam a depender dele. O RFC 2352 documentou uma proposta importante; não comprovou adoção, implantação ou sucesso. Seu valor histórico está justamente em mostrar que transferir uma decisão não elimina o poder — torna necessário identificar quem decidiu cada elo.

Fontes e limites

Esta análise usa o registro do RFC 2352, os textos dos RFCs 2240, 2352, 920, 1034, 1035, 1591 e 3490, a UDRP da ICANN e os dois ensaios de Heng Lu citados acima. As fontes não estabelecem titularidade atual de marcas ou domínios, nem oferecem aconselhamento jurídico sobre qualquer jurisdição.