Resumo

  • O grupo de requisitos de hosts colocou a interoperabilidade à frente da pureza arquitetural ao aproximar regras e implementações reais.
  • As RFCs 1122 e 1123 estabeleceram uma base prática; a RFC 1127 registrou os compromissos e as questões em aberto.

Em 1989, o desafio já não era apenas saber se a Internet tinha protocolos. Era também garantir que softwares de hosts diferentes seguissem regras suficientemente consistentes para se comunicar. Um fabricante podia implementar um protocolo publicado e ainda encontrar lacunas, contradições ou escolhas abertas em uma pilha de documentos antigos. Para os usuários, essas diferenças apareciam quando uma máquina tentava alcançar outra.

O grupo de trabalho de requisitos de hosts da IETF passou cerca de vinte meses esclarecendo essa superfície de implementação. Em sua retrospectiva contemporânea, o editor Robert Braden relembrou sete reuniões formais, aproximadamente três megabytes de mensagens eletrônicas, cerca de vinte especialistas dedicados ao esforço e contribuições importantes de outros vinte. Os documentos passaram por aproximadamente vinte versões distintas. São estimativas arredondadas de Braden, não uma contagem auditada de participantes ou mensagens. RFC 1127

A ordem das prioridades explica melhor o esforço do que o volume de correspondência. O grupo listou interoperabilidade, extensibilidade, funcionalidade, eficiência e pureza arquitetural. Braden afirma que a interoperabilidade era claramente a prioridade principal e que a pureza arquitetural ficava em último lugar; o peso dos objetivos intermediários variava conforme o tema. A tarefa era fazer implementações diferentes funcionarem juntas, mesmo quando um modelo perfeitamente uniforme não cabia em todos os casos reais.

O resultado saiu em duas normas complementares, em outubro de 1989. A RFC 1122 cobre as camadas de enlace, IP e transporte. A RFC 1123 trata dos protocolos de aplicação e suporte. Ambas definem requisitos para o software dos hosts; a RFC 1122 diz que os dois documentos estabelecem as regras para a realização da arquitetura da Internet naquele momento. A RFC 1009, em separado, tratava dos gateways: hosts e equipamentos que encaminhavam pacotes tinham funções relacionadas, mas distintas.

Esses textos não criaram uma nova especificação de protocolo. Reuniram normas anteriores em uma referência de trabalho para implementadores, corrigiram e atualizaram especificações, preencheram lacunas, restringiram escolhas onde a consistência exigia, esclareceram a intenção dos protocolos e registraram dicas de implementação. Braden observa que algumas cláusulas apenas repetiam requisitos já explícitos ou implícitos. Ainda assim, foram mantidas porque ao menos uma implementação não as havia seguido. Publicar uma regra e torná-la utilizável entre fabricantes eram tarefas diferentes.

O grupo também definiu onde a base comum deveria parar. Uma decisão acordada exigia que os hosts implementassem DNS. Outras questões permaneceram controversas. O multihoming — o comportamento de um host com várias interfaces de rede — estava entre os temas em aberto. Quando os participantes não conseguiam decidir se um comportamento deveria ser exigido ou proibido, a RFC 1127 diz que as especificações às vezes registravam os pontos de vista concorrentes e deixavam a função como opcional. O consenso criou uma base comum em algumas áreas e preservou escolhas em outras.

Esse limite importa. Os requisitos de hosts não tornaram todas as máquinas iguais, não garantiram a conformidade de cada fabricante nem encerraram o debate sobre a arquitetura da Internet. Eles tornaram as expectativas para um host mais fáceis de localizar e aplicar, mantendo visíveis as divergências em vez de apresentá-las como doutrina resolvida. Sua contribuição histórica foi descrever de modo utilizável a interoperabilidade no ponto em que o software encontra a rede.