Resumo

  • Boa parte dos detalhes da RFC 1432 veio de um catálogo da Library of Congress acessado por Gopher e Telnet; a rede entregava a ficha, não necessariamente o livro, o estoque ou a versão esperada.
  • A lista combinava livros impressos, uma primeira edição apenas on-line, capítulos liberados aos poucos e títulos ainda não publicados, além de alertar que preços e contatos mudavam.
  • Uma operação responsável separa registro encontrado, rota testada, resposta do servidor, objeto recebido, edição identificada, oferta confirmada e entrega concluída.

Um mapa com destinos administrados por outros

John S. Quarterman publicou primeiro em Matrix News, em dezembro de 1992, o texto que se tornaria a RFC 1432 em março de 1993. O motivo era visível: nove ou dez livros sobre Internet haviam surgido em cerca de um ano. Alguns eram tão recentes que ainda não tinham sido publicados; outros vinham de 1984.

A tabela resumiu autor, número de páginas, preço, público, tipo de obra e presença de outras redes. Era uma ferramenta de orientação, não uma promessa de completude. Pontos de interrogação permaneciam onde faltava informação. As classificações eram aproximadas, pois um mesmo livro podia ser guia, catálogo, material didático ou análise social.

O formato criava uma visão comum sobre destinos muito diferentes. Cada linha podia levar a uma editora, a um arquivo, a um contato ou a uma publicação futura. O mapa aproximava esses pontos; não os colocava sob o mesmo operador.

O catálogo participava da viagem, não da entrega

A RFC informa que muitos detalhes bibliográficos vieram do servidor de catálogo da Library of Congress, consultado pela Internet via Gopher e Telnet. Essa frase registra uma mudança importante: a própria rede servia para levantar a literatura que explicava como usá-la.

Mas ela também distribui responsabilidades. A biblioteca controlava sua descrição catalográfica. O servidor respondia à consulta. Gopher e Telnet transportavam a interação. A editora determinava edição e preço. O livreiro conhecia o estoque. Um administrador de FTP decidia qual arquivo existia em determinado caminho. O compilador selecionava e descrevia.

Uma ficha devolvida pelo catálogo não demonstrava que havia exemplar disponível para empréstimo, muito menos que a biblioteca vendia o livro. Um endereço de editora não era estoque. Um caminho FTP não era prova de conteúdo completo. A rede descobria uma referência e oferecia meios para a próxima tentativa; o desfecho continuava em outra instituição.

O uso histórico da palavra “Matrix” amplia esse cuidado. Quarterman a empregava para redes que trocavam correio eletrônico em todo o mundo, incluindo FidoNet, UUCP, BITNET, USENET e Internet. Alguns livros cobriam esse universo maior. Estarem na mesma coluna não significava uma infraestrutura única nem uma autoridade central.

A sintaxe descrevia a tentativa

Quando uma citação terminava em domain.name:path/name, o leitor devia conectar-se por FTP, entrar como anonymous, usar seu e-mail como senha e tratar o restante como diretório ou arquivo. Quando aparecia local@domain, havia um endereço para pedir mais informações.

Era uma convenção compacta para transformar referência em ação. Ainda assim, cada ação podia parar em um ponto diferente. O domínio podia responder e o caminho ter sumido. O arquivo podia ser propaganda ou sumário. O conteúdo podia pertencer a outra edição. A mensagem podia chegar e não receber resposta. O pedido podia ser registrado e não ser enviado.

A RFC 1175 já havia organizado, em 1990, materiais on-line, impressos, referências e recursos multimídia como ponto de partida para usuários. Ela anexava instruções de obtenção e lembrava que os comandos FTP variavam entre sistemas. Descrever o material e ensinar a tentar obtê-lo eram funções próximas, não idênticas.

O livro mudava de meio sem mudar de nome

Os exemplos da RFC 1432 tornam impossível tratar “disponível” como uma chave de sim ou não. The Internet Companion estava sendo publicado por FTP anônimo a uma cadência de dois capítulos por mês. A primeira edição de Zen and the Art of the Internet existia apenas on-line em vários servidores FTP; a segunda era ampliada, atualizada e impressa. Em outras entradas, a rota apontava para anúncio ou sumário.

Portanto, a disponibilidade precisava declarar seu objeto. A obra era conhecida? Uma edição estava concluída? Dois capítulos podiam ser baixados? Havia um arquivo integral? Um exemplar físico podia ser encomendado? O comprador o recebeu?

O ISBN ajuda a distinguir uma edição, mas não autentica sozinho os bytes de um servidor. Um hash pode fixar os bytes recebidos, sem determinar por si só a condição editorial ou jurídica. Uma cotação confirma uma oferta em certo momento, não o custo final com frete nem a entrega.

O próprio documento anotava “a publicar”, “ainda não visto”, primeira edição, segunda edição e liberação parcelada. Ele não deixou de construir um inventário perfeito. Nunca afirmou ser um inventário.

O aviso de mudança era um campo invisível

Quarterman avisou que preços, endereços de e-mail, telefones, números de fax e endereços postais podiam mudar. Um desconto reduziria o valor; frete e compra fora dos Estados Unidos poderiam aumentá-lo. Erros, mudanças e acréscimos deveriam ser comunicados por e-mail.

Esse aviso funcionava como um campo de validade para a tabela inteira. Nome de autor, título e ISBN de uma edição podem envelhecer devagar. Preço, contato, rota e estado de publicação envelhecem rápido. Colocá-los na mesma linha não sincroniza os relógios.

Uma RFC estável não deveria ser reescrita sempre que uma editora altera o telefone. Sua integridade histórica exige conservar o que era conhecido naquele momento. O problema começa quando o leitor remove a data e lê o valor como atual.

A RFC 1402 separava três trabalhos: saber que uma informação existe, avaliar sua importância e indexá-la para encontrá-la. Dizia também que a informação em rede se movia, crescia, mudava e morria. Muitas de suas entradas eram apenas ponteiros para a informação final.

Ponteiro é evidência de uma orientação, não custódia do destino. Um catálogo pode permanecer correto sobre uma rota histórica justamente quando essa rota já não funciona no presente.

Mais ferramentas não significavam um estoque único

Em março de 1994, a RFC 1580 precisou explicar Gopher, World-Wide Web, WAIS, Archie, WHOIS, X.500, Netfind e vários serviços de arquivos e correio. O crescimento de recursos era rápido demais para o usuário acompanhar com facilidade.

As ferramentas repartiam o problema. Gopher e Web ajudavam a navegar; WAIS pesquisava bases; Archie localizava arquivos e programas; WHOIS, X.500 e Netfind procuravam pessoas, computadores e endereços. Clientes locais, clientes remotos e acesso por e-mail não ofereciam a mesma capacidade.

Servidores interligados podiam produzir uma superfície contínua. Por baixo dela, descrição, armazenamento, venda e entrega continuavam separados. Essa distribuição permitia a expansão sem uma estante central; também impedia que uma busca bem-sucedida comprovasse a posse do objeto.

Da referência à entrega, degrau por degrau

Um registro encontrado prova que um catálogo representou algo na data da consulta. Uma rota escrita prova que o documento propôs um caminho. Uma resposta prova que um serviço atendeu naquele instante. Uma transferência prova que bytes chegaram. Folha de rosto, indicação de edição, ISBN e, quando aplicável, hash preservado ajudam a identificar o objeto. A confirmação do vendedor sustenta uma oferta. A entrega comprova o recebimento.

“Encontrado”, “no ar”, “disponível” e “adquirido” parecem atalhos úteis. Cada um pertence a um dono e a uma camada de evidência. Transportar a palavra de uma camada à seguinte cria uma promessa que ninguém fez.

A RFC 1432 não testou todas as rotas nem todas as vendas. Fez o que um registro histórico deveria fazer: preservou procedência, dúvida, meio, estágio de publicação e instrução de acesso. O mapa encontrou o livro. A estante, administrada por outros e movida por outro relógio, permaneceu fora de sincronia.

Fontes