Resumo

  • A RFC 1 dividia a responsabilidade: a BBN especificava o software dos Interface Message Processors (IMPs), e os grupos dos hosts precisavam acordar o software que permitiria a seus computadores usar a rede.
  • Steve Crocker chamou o material de provisório e esperava reações. Depois, a RFC 3 explicou que leitores podiam confundir um texto publicado com uma decisão de autoridade — justamente o que a série queria evitar ao abrir espaço para ideias ainda discutíveis.
  • As mudanças na RFC 6, a implementação GORDO da UCLA descrita na RFC 11 e as revisões registradas na RFC 33 mostram um processo em andamento. Não provam que todos os hosts tenham adotado a RFC 1 sem mudanças.

O acordo que faltava ficava acima da rede de pacotes

O projeto inicial da ARPA Network tinha uma divisão técnica clara. A Bolt, Beranek and Newman especificava os IMPs, máquinas que encaminhavam mensagens entre os sites. Os computadores conectados a eles ainda precisavam de convenções de software para abrir conexões, identificar links e decidir como um host remoto trataria os dados recebidos.

Datada de 7 de abril de 1969, a RFC 1 de Steve Crocker levou esse problema entre hosts a um documento comum. Resumia o formato de mensagens dos IMPs e esboçava o software necessário nos hosts para pedidos de conexão, sessões parecidas com teletipo, transferências maiores de arquivos, verificação de erros e interação remota. Também considerava uma interface local que pudesse responder de imediato a certas ações do terminal sem enviar cada tecla pela rede.

Esse desenho não era uma única decisão tomada em uma única camada. O encaminhamento dos IMPs e o comportamento dos sistemas operacionais dos hosts envolviam responsabilidades e falhas diferentes. Uma mensagem podia chegar ao IMP de destino sem que os dois sistemas soubessem como abrir uma sessão ou interpretar a troca seguinte.

Crocker deixou o estágio da proposta explícito: o grupo havia alcançado alguns acordos tentativos, encontrara questões em aberto e quase nada do texto estava fechado. A nota é importante também por preservar essa incerteza. Tratá-la como especificação final apagaria justamente a etapa de trabalho que ela documenta.

O que a primeira nota colocou em discussão

A RFC 1 organizava a comunicação por links lógicos entre pares de hosts. Propunha reservar um link para o controle entre sistemas operacionais e usar os demais em sessões de usuários. Uma conexão poderia funcionar como um teletipo discado; outra, paralela e voltada a arquivos, serviria a volumes maiores sem depender do armazenamento em buffer e das interrupções próprias de um terminal.

O texto também procurava tornar a interação remota utilizável apesar do atraso da rede. Uma ideia era enviar um pequeno programa de interface local, escrito em uma linguagem então chamada DEL, para tratar perto do usuário as respostas rotineiras do terminal. A especificação ainda estava em discussão: a nota não dizia que a função já estivesse instalada em todos os hosts.

Os primeiros experimentos descritos também tinham limites. Crocker relatou o trabalho da SRI em um sistema de recuperação de informações e numa interface DEL, além de planos de uso envolvendo UCLA e Utah. Isso mostra o que os participantes tentavam construir. Não é um inventário de instalações por site, nem demonstra que os quatro hosts iniciais tivessem implementado todas as ideias.

A primeira RFC, portanto, não era uma ordem de uma autoridade de padronização. Era um espaço compartilhado para expor escolhas de projeto, receber correções e dar a um grupo distribuído algo concreto para discutir.

A série tornou o desacordo mais fácil de registrar

Dois dias depois da RFC 1, Bill Duvall escreveu a RFC 2, também intitulada “Host Software”. A RFC 3 estabeleceu algumas convenções: qualquer pessoa em qualquer site poderia produzir uma nota; a oportunidade importava mais que o acabamento; o título não precisava ser exclusivo. Bill Duvall, na SRI, distribuía os números de série.

A RFC 3 também apontou um problema que continua presente na governança técnica: leitores tendem a atribuir autoridade a uma afirmação só porque ela foi escrita e publicada. O formato flexível buscava promover a troca de ideias ainda não autoritativas. O número permitia localizar a nota; não respondia à questão levantada por ela.

Não era um processo de padronização completo em miniatura. As primeiras RFCs misturavam propostas, perguntas, detalhes de implementação e pedidos de resposta. Seu valor comum era tornar o raciocínio técnico visível entre sites que precisavam interoperar sem abrir mão de computadores e sistemas operacionais próprios.

Revisar e implementar são provas diferentes

A RFC 6, relato de Crocker sobre uma conversa com Bob Kahn em 10 de abril, registra uma mudança no campo de link Host–IMP: ele passou a ter cinco bits e um bit adicional para indicar conversão. O detalhe é pequeno, mas o momento importa. Dias depois da RFC 1, um dos seus elementos ainda estava sendo discutido e alterado.

Em agosto, a RFC 11 de Gerard Deloche descreveu os procedimentos entre hosts e sua implementação no GORDO, sistema de tempo compartilhado da UCLA para o SDS Sigma 7. O texto especificava tipos de conexão, mensagens de controle, somas de verificação, buffers e programas que faziam a ponte entre os usuários e a interface dos IMPs. Também em agosto, a RFC 13 citou a RFC 11 e propôs uma mensagem de comprimento zero para marcar o fim de uma transferência de arquivo por uma conexão auxiliar.

Esses registros mostram ideias ganhando forma numa implementação identificada e uma proposta posterior para resolver uma necessidade concreta. Não demonstram que todos os hosts usassem os procedimentos do GORDO ou que a rede tivesse parado de mudar. Uma implementação é evidência mais forte de operação em um site do que uma proposta isolada, mas não informa quantos outros a adotaram.

A RFC 33 torna essa diferença explícita. Em fevereiro de 1970, ela informou que o protocolo antigo descrito na RFC 11 havia passado por muitas mudanças, relacionadas a uma reunião de rede em dezembro. Também dizia que o documento anexado ainda não tinha informações suficientes para escrever um Network Control Program e pedia respostas. As conexões já funcionavam e a rede começava a ser usada, mas o protocolo entre hosts continuava em revisão e documentação.

Por que a RFC 1 importa sem ser a palavra final

A importância histórica da RFC 1 não está em todos os campos ou procedimentos terem permanecido. Está em ter tornado discutível um problema de projeto comum antes que todos os hosts dispusessem de uma implementação consolidada. A nota indicava responsabilidades, apresentava opções e deixava as incertezas visíveis.

Esse resultado é diferente de implantar um protocolo. Um texto pode definir o problema comum; uma revisão pode reduzir a discordância; o código pode mostrar que um sistema funciona; testes repetidos de interoperabilidade podem mostrar se sistemas independentes interpretam as mensagens de forma compatível. As etapas se relacionam, mas uma não certifica automaticamente a seguinte.

O registro inicial permite, então, uma história mais precisa da coordenação. A BBN especificava a camada dos IMPs. Os grupos dos hosts trabalhavam no software acima dela. As RFCs forneciam uma superfície de discussão numerada e fácil de compartilhar. Implementações e notas posteriores mostravam o que havia sido tentado e alterado. O primeiro número abriu esse processo; não o concluiu.

Fontes

A RFC 1 é a fonte primária da proposta provisória de Crocker. A RFC 2 registra a nota “Host Software”, de Bill Duvall; a RFC 3 explica as primeiras convenções documentais. A RFC 6 registra uma discussão posterior sobre a interface Host–IMP. A RFC 11, de Deloche, descreve procedimentos e a implementação GORDO; a RFC 13, de Cerf, propõe um marcador de fim para transferências auxiliares. A RFC 33, de Crocker e colegas, documenta mudanças posteriores e questões ainda abertas. O índice RFC 170, de 1971, lista as primeiras notas e suas datas.