Resumo

  • A RFC 1924 tratou os 128 bits do endereço IPv6 como um único inteiro e os codificou em vinte caracteres de base 85. O valor podia ser recuperado sem perda, mas ferramentas e pessoas ainda precisavam conhecer a nova superfície.
  • Nove caracteres imprimíveis foram reservados para a sintaxe ao redor: aspas, listas, frases, CIDR, URLs, colchetes e escape. A proposta reconhecia que um endereço precisa manter fronteiras fora do próprio campo.
  • Padrões posteriores preservaram o hexadecimal com dois-pontos, usaram colchetes em literais de URI e recomendaram uma saída canônica. A convergência melhora a pesquisa, mas não prova atribuição, autorização, rota, alcance, identidade ou entrega.

Uma economia exata, uma conta distribuída

Havia (2^{128}) valores a representar. Vinte dígitos em base 84 eram insuficientes; vinte em base 85 cobriam todo o espaço: (84^{20} < 2^{128} \leq 85^{20}). Bases 94 ou 95 também precisariam de vinte dígitos. Por isso, 85 era o ponto em que se obtinha a menor largura fixa e ainda se podiam retirar nove símbolos úteis para outras gramáticas.

A RFC 1924, publicada em 1º de abril de 1996 como Informational, não estabeleceu um padrão da Internet. Ela converteu o endereço inteiro em um número sem sinal e lhe atribuiu um alfabeto de 85 caracteres ASCII imprimíveis. O exemplo 1080:0:0:0:8:800:200C:417A virava 4)+k&C#VzJ4br>0wv%Yp. Zeros à esquerda continuavam presentes e todo resultado ocupava vinte posições.

O benefício local era concreto. Bancos de dados podiam dimensionar um campo fixo. Não havia escolhas concorrentes sobre quantos zeros omitir. Depois da decodificação, máquinas comparavam um mesmo inteiro. Mas cada parser, log, planilha, URL, terminal e pessoa que encontrasse o campo teria de conhecer o alfabeto. A conta da economia era distribuída pela cadeia.

Os nove símbolos guardavam as fronteiras

Foram excluídos aspas duplas e simples, vírgula, ponto, barra, dois-pontos, colchetes esquerdo e direito e barra inversa. A justificativa passava por citação, listas, fim de sentença, sufixos CIDR, URLs, delimitação de literais e escape. Não bastava escolher caracteres imprimíveis; era preciso evitar que o recipiente consumisse partes do conteúdo.

Esse cuidado torna a proposta mais interessante, não menos. Ela sabia que representação é uma interface. Ainda assim, evitar colisões não instalava o decodificador nos sistemas existentes nem dava ao operador uma forma reconhecível. Uma cadeia poderia ser perfeitamente válida e permanecer invisível a uma busca feita na grafia hexadecimal.

Reversibilidade responde: “consigo recuperar os bits?”. Interoperabilidade operacional acrescenta: “o receptor sabe que deve tentar?”, “o log preserva a forma?”, “a pesquisa une as variantes?” e “um humano percebe que olha para um IPv6?”. São testes independentes.

A forma conhecida também não era única

A arquitetura inicial do IPv6 usava oito grupos hexadecimais de 16 bits separados por dois-pontos. Permitia eliminar zeros iniciais, comprimir uma sequência de grupos zero com um único :: e terminar em decimal IPv4. Isso mantinha uma silhueta reconhecível, mas dava ao mesmo valor várias grafias legais.

O custo surgiu em comparações de texto. Uma planilha podia duplicar um endereço. Uma pesquisa podia achar uma variante e omitir outra. Diagramas, Whois e logs podiam parecer discordar. A base 85 eliminava a variação ao trocar toda a forma; o caminho normativo posterior preferiu preservar a forma e reduzir a variação.

O caso da URL mostra esse método incremental. Como os dois-pontos do IPv6 competiam com a sintaxe externa, a RFC 2732 colocou o literal entre colchetes e declarou a facilidade de copiar e colar com edição mínima. O texto também registrou implementações em versões IPv6 de Internet Explorer, Mozilla e Lynx. A RFC 3986 manteve os colchetes como o lugar específico do IP-literal.

Aceitar variedade, produzir convergência

A RFC 4291 conservou as formas hexadecimais flexíveis. A RFC 5952 depois reuniu os problemas práticos causados por múltiplas formas válidas em busca, arquivos de texto, planilhas, Whois, diagramas, logs, auditorias e verificação. Sua solução não foi rejeitar entradas antigas. Parsers continuariam aceitando todas as formas legítimas; formatadores passariam a emitir uma forma canônica.

Na saída, zeros iniciais seriam omitidos, letras hexadecimais seriam minúsculas, :: comprimiria a sequência zero mais longa, a primeira venceria um empate e um único grupo zero não seria comprimido. A meta não era obter sempre o mínimo absoluto de caracteres. Era fazer com que sistemas independentes deixassem uma evidência textual comparável.

Esse desenho separou compatibilidade de disciplina. A borda permaneceu tolerante para não invalidar dados existentes. O centro convergiu para reduzir ambiguidade futura. Os colchetes resolveram uma fronteira de URI sem entrar no valor do endereço.

O degrau que uma string não pode subir

Primeiro existem os bits. Depois vem o valor reconhecido pelo parser, a apresentação normalizada, a string realmente armazenada, o resultado da consulta e o evento de rede observado. Dois textos que decodificam para o mesmo inteiro provam equivalência de representação. Uma forma canônica comum prova acordo do formatador. Um registro prova que um componente gravou aquele texto.

Nada disso, isoladamente, demonstra a quem o endereço foi atribuído, se uma origem de rota estava autorizada, se havia rota ativa, se a interface era alcançável, se o serviço autenticava a entidade esperada ou se um pacote chegou. A normalização melhora a localização da evidência; ela não amplia o alcance lógico dessa evidência.

A sequência documental está em RFC 1884, RFC 1924, RFC 2732, RFC 3986, RFC 4291 e RFC 5952. Esses registros não são um censo de implantação e não autorizam afirmar que ninguém implementou a base 85 ou que os autores posteriores a rejeitaram formalmente.

Running-Code Primacy oferece uma leitura posterior: verificar o que parsers, logs e rotinas reais conseguem aceitar e preservar. Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption ajuda a explicar por que uma superfície comum pequena pode conviver com decisões locais. Nenhum dos dois textos documenta a intenção histórica dos autores das RFCs.

Os vinte caracteres da RFC 1924 carregavam o endereço inteiro. O que não cabia neles era o acordo operacional necessário para transformar valor em evidência compartilhada.