Os códigos correspondiam. O circuito ainda exigia permissão: RFC 1394

Resumo

• RFC 1394 reuniu nomes de países e áreas, códigos telefônicos, códigos de telex, answerbacks e domínios de Internet em uma tabela datada. A linha indicava uma relação conhecida, não um serviço em operação.
• A publicação preservou incerteza: distinguiu duas formas de dado ausente, avisou que alguns códigos poderiam estar errados e abriu correções por correio, email e telex.
• Um código correto não provava delegação DNS, rota disponível, permissão política, identidade do destino, entrega nem reconhecimento de um país.

A correspondência atravessava redes diferentes

Em janeiro de 1993, a RFC 1394 tentou resolver uma dificuldade cotidiana. Quem conhecia o código telefônico de uma área talvez não soubesse seu answerback de telex ou domínio de Internet. Quem recebia um endereço de uma rede pública de correio precisava descobrir por onde entrar a partir da Internet.

A tabela colocou lado a lado o nome, o indicativo telefônico, o código nacional de telex, o answerback e o domínio. Também incluiu provedores de correio, territórios, nomes antigos e subdivisões. Era uma superfície de descoberta que passava por tecnologias e instituições diferentes.

Nenhuma coluna executava a função da outra. O indicativo era interpretado pela telefonia. O answerback pertencia ao telex. O domínio ocupava uma posição no espaço de nomes. Uma etiqueta comercial podia identificar um serviço, não uma jurisdição. Estar na mesma linha era evidência de correspondência editorial, não uma conversão universal.

O desconhecido não foi apagado

O guia da tabela reservou quatro traços para um código telefônico desconhecido e três para outras informações faltantes ou desconhecidas. Assim, a ausência permanecia visível e não ganhava uma explicação inventada.

As relações eram irregulares. Um local podia ter vários códigos de telex. Nomes históricos e atuais podiam apontar ao mesmo domínio. Certas áreas tinham sufixo Internet sem answerback listado; outras apareciam apenas em uma das redes. Antigos Estados, regiões e sistemas privados coexistiam por utilidade de busca, não por igualdade política ou técnica.

O autor declarou ter reunido dados de fontes e países diversos. O cuidado editorial não permitia garantir exatidão, e alguns códigos poderiam estar errados. Correções eram aceitas por três meios. Isso criava custódia e uma trilha de revisão, mas não sincronização automática com cada rede de origem.

Uma linha, portanto, podia orientar a próxima consulta. Para sustentar uma ação de alto custo, ainda precisava de data, proveniência e confirmação pela autoridade competente naquele sistema.

O código de país não instalava o domínio

A RFC 920 havia proposto os códigos alpha-2 ingleses da ISO 3166 para nomes nacionais de primeiro nível. O mesmo documento separava o código disponível, o estabelecimento do domínio e a divulgação de administrador e agente. A forma do nome não concluía o ato de delegação.

A RFC 1034 colocou essa diferença dentro do DNS. O espaço de nomes é dividido em zonas. Um servidor é autoritativo apenas para uma parte delimitada da árvore e pode guardar dados não autoritativos em cache. Delegar exige registros na separação entre zona pai e filha e dados para alcançar os servidores da filha.

Imprimir duas letras na RFC 1394 não criava esses registros. A tabela não nomeava o gestor efetivo, não alterava a raiz e não provava resposta dos servidores. A delegação devia ser observada no pai autoritativo; a disponibilidade exigia um teste situado no tempo.

O inverso também falhava. Um ccTLD em operação não atualizava o código telefônico ou de telex ao lado. Cada coluna tinha seu próprio operador e relógio.

Nem todo sufixo era DNS

As notas sobre BITNET e UUCP tornaram a distinção explícita. Formas como System.BITNET e host.UUCP eram usadas nessas comunidades, mas não estavam registradas no DNS. Para enviar correio a partir da Internet, era necessário transformar o endereço e passá-lo por um gateway, usando a notação de porcentagem da época.

O texto parecia um domínio, mas o próximo passo não era resolver aquele sufixo. O gateway possuía a regra operacional. Sua aceitação comprovava apenas a transferência a um intermediário; o sistema remoto, a caixa e a leitura humana eram estados posteriores.

Já .ARPA foi descrito como uma parte histórica do DNS usada para consultas reversas. Pontos semelhantes podiam esconder delegação autoritativa, costume comunitário ou comando de gateway. A sintaxe não revelava sozinha quem mantinha a verdade.

O circuito podia não existir ou não ser permitido

Antes da lista, RFC 1394 avisou que alcançar um país dependia da existência de uma conexão e de a conexão ser permitida. Restrições políticas apareciam entre as causas de impossibilidade.

Havia, portanto, uma afirmação descritiva, uma observação operacional e uma decisão de permissão. O código podia corresponder ao lugar, mas nenhuma rota estar disponível da origem. A rota física podia existir, mas contrato, política ou autoridade pública impedir o uso. E um caminho autorizado ainda podia terminar num destinatário inexistente ou recusado.

Uma falha não escolhia a causa. Código desatualizado, gateway parado, rota ausente, bloqueio normativo e rejeição remota podiam produzir o mesmo silêncio. Esse silêncio não decidia a validade do território ou do domínio.

O sucesso também não autorizava tudo. Uma comunicação concluída provava um caminho em um momento. Não autenticava necessariamente a pessoa remota nem concedia direito permanente de repetir a chamada.

O catálogo não decidia quais países existiam

RFC 1394 negou expressamente qualquer posição sobre a validade do nome ou da existência de um país. Nomes antigos e alternativos eram desejados porque ajudavam leitores com vocabulários históricos a localizar entradas, não porque a inclusão fosse reconhecimento diplomático.

Em uma lista com Estados extintos, territórios, áreas, redes privadas e códigos nacionais, essa modéstia protegia a função de busca. Se cada alias virasse um juízo político, uma correção editorial assumiria poder constitucional.

A RFC 1591 descreveu depois a delegação de domínios de primeiro nível e as responsabilidades do gestor designado. O gestor de um ccTLD precisava operar o serviço e manter contatos administrativos e técnicos. O texto também afirmou que IANA não decidia o que era ou não um país; a ISO 3166 fornecia um procedimento separado.

As responsabilidades continuavam distribuídas. Uma entidade mantinha códigos, outra coordenava a raiz, o gestor operava a zona, redes transportavam comunicações e poderes públicos aplicavam suas normas. Cuidar de um elo não transferia autoridade sobre os demais.

Uma tabela fina podia ser muito útil

RFC 1394 não discutiu segurança. Não autenticou suas linhas, não comprovou consentimento e não garantiu entrega. O limite não anulava a ferramenta; impedia que ela fosse usada como credencial.

Seu trabalho era encaminhar perguntas: qual código confirmar, se o sufixo estava delegado, qual servidor era autoritativo, se o gateway funcionava, se havia rota, se o uso era permitido e se o destino aceitou. Cada resposta vinha de uma testemunha diferente.

Ao manter esses estados separados, o catálogo fazia coordenação sem reivindicar soberania. Ele aproximava referências, não comandava circuitos.