Summary

  • RFC 1011 separou a especificação de cada protocolo de seu status, comentários, dependências e contato, facilitando a coordenação de um sistema técnico amplo e mutável.
  • “Obrigatório” expressava o que os hosts deveriam implementar; não mostrava qual código estava instalado ou rodando em cada máquina.

Uma lista que precisava envelhecer

O memorando de Joyce Reynolds e Jon Postel, publicado em maio de 1987, tinha o título Official Internet Protocols. Ele se apresentava como um relatório de status: identificava os documentos que especificavam os protocolos usados na Internet e incluía comentários sobre revisões ou mudanças previstas. Era mais parecido com um mapa datado de um sistema em movimento do que com um manual que descrevesse o estado de cada máquina.

O próprio documento tornava essa limitação explícita. O leitor deveria usar uma versão publicada nos três meses anteriores. Cada entrada podia indicar a especificação, suas dependências, problemas de implementação e uma pessoa de contato. Assim, era possível saber não apenas qual texto descrevia um protocolo, mas também onde a descrição estava incompleta e quem poderia continuar a conversa.

Cada protocolo recebia um de cinco status. “Obrigatório” significava que todos os hosts deveriam implementá-lo. “Recomendado” incentivava a implementação. “Eletivo” deixava a escolha com o host. “Experimental” limitava a implementação a experimentos coordenados. “Nenhum” indicava que a entrada não era um protocolo. Eram expectativas diferentes, não cinco medições do que as máquinas faziam.

O status não instalava o software

As próprias linhas mostram a diferença. IP era obrigatório. TCP e UDP eram recomendados. A entrada “Graphics Protocol” era eletiva, mas seu comentário dizia que não havia implementações ativas conhecidas. O comentário não apagava a entrada, e a classificação não fazia surgir uma implementação. Os autores registraram tanto uma categoria quanto o limite do que sabiam.

Essa combinação importa. Um catálogo pode ser a referência para o status atribuído a uma especificação e, ainda assim, não certificar o comportamento de todos os hosts. “Obrigatório” é uma expectativa de compatibilidade. Para conhecer a realidade operacional, são necessárias implementações e observação. RFC 1011 não trazia um censo completo de hosts, um inventário de versões instaladas nem um recibo de testes que provasse que cada protocolo obrigatório rodava corretamente em cada máquina.

Especificação e implementação se encontravam ao longo do tempo

RFC 1011 fazia parte de uma sequência de publicações periódicas. Relatórios anteriores eram substituídos e os seguintes atualizavam a lista. Em abril de 1989, RFC 1100 descreveu o processo mais amplo de padronização: qualquer pessoa podia propor um protocolo, grupos técnicos formulavam recomendações e a política geral era esperar experiência de implementação antes de declará-lo padrão oficial. O texto também dizia que um número RFC nunca seria reutilizado, embora um protocolo pudesse melhorar e ser descrito em RFCs posteriores.

Isso não tornava os padrões irrelevantes. Uma especificação comum dava a implementadores independentes uma meta de comportamento. Mas entre a proposta e o serviço havia mais do que publicação: era preciso implementar uma versão, testá-la com outros sistemas, revisá-la conforme a experiência e adotá-la nos hosts. Os requisitos para hosts de 1989 tornaram mais concretas várias expectativas para hosts de Internet de uso geral. Ainda assim, a linguagem normativa dizia o que um host em conformidade deveria fazer; não provava que todas as máquinas em operação faziam isso.

A periodicidade da lista tinha um propósito. Um relatório trimestral ajudava operadores e implementadores a encontrar o documento atual, mas a data fazia parte de sua validade. Uma linha correta no dia da publicação podia ficar desatualizada quando especificações, comentários e práticas mudassem. O aviso para não usar uma versão antiga reconhecia que a coordenação precisava de manutenção.

Um registro útil, não uma rede em execução

RFC 1011 funciona melhor como ferramenta de coordenação. Tornava os status legíveis, ligava entradas a documentos e contatos, e expunha incertezas em vez de escondê-las. Essas funções podiam influenciar decisões; uma recomendação ou obrigação não era conversa vazia. Mas o relatório não entrava em cada host para fazer a decisão virar código em execução.

Essa fronteira ainda ajuda a ler a história da Internet. Número de documento não é implementação. Status de padrão não é captura de pacotes. Recomendação não é contagem de implantações. Regras comuns reduzem o conjunto de escolhas compatíveis, mas a rede existe nos sistemas que os operadores decidem executar e manter interoperáveis.

Fontes