Resumo

  • O RFC 873 contestou a espera por uma suíte de rede apoiada por fornecedores e baseada no modelo ISO quando o Departamento de Defesa já tinha contratos de interconexão em andamento.
  • Uma especificação incompleta, interfaces abertas a interpretações e opções escolhidas de modo diferente por dois fornecedores podiam transferir ao comprador a conta da interoperabilidade.

“Suporte do fornecedor” cabe lindamente na planilha de compras. O campo ao lado, “as duas máquinas vão conversar?”, costuma ser preenchido depois. Michael A. Padlipsky colocou essa diferença no centro de RFC 873, em setembro de 1982. Seu alvo era uma proposta no debate de compras do Departamento de Defesa norte-americano: esperar protocolos fornecidos pelo mercado e ligados ao modelo de referência ISO, em lugar de adquirir a família ARPANET já em funcionamento. A intenção declarada por alguns defensores era economizar dinheiro público. Padlipsky abriu a calculadora antes de aceitar o rótulo.

Primeiro, o que viria dentro da caixa? X.25 cobria parte do caminho técnico, argumentou, mas não constituía uma suíte completa para compartilhamento de recursos entre computadores. Outras especificações de acesso também não completavam o conjunto em desenvolvimento pelo National Bureau of Standards e pela ISO. E os dois esforços não eram cópias perfeitas um do outro. Uma exigência genérica em contrato podia esconder a pergunta principal: quais funções e interfaces o fornecedor teria condições de entregar como um conjunto que funciona?

O calendário tinha preço próprio. Processos de aquisição de defesa já levavam tempo, enquanto a suíte vinculada ao modelo ISO ainda estava incompleta em 1982. Algumas propostas existiam sobretudo no papel, sem teste de uso real. Os padrões levariam anos para amadurecer, na avaliação do autor, mas os contratos de rede saíam naquele momento. Implementações de protocolos inspirados na arquitetura ARPANET já rodavam em sistemas operacionais usados pelo departamento. Mantê-las também custava esforço. O que Padlipsky insistiu em colocar na conta foi o tempo perdido ao esperar que a futura suíte se tornasse comprável.

Depois veio o significado da palavra “suporte”. O ensaio levantou perguntas sobre a passagem de informações entre camadas, a obrigação de atravessar cada camada, quantos protocolos poderiam existir em uma mesma camada e como sinais urgentes chegariam ao aplicativo. Um modelo de referência ajudava a descrever o sistema; o comprador precisava de comportamento comum entre implementações. Duas equipes poderiam seguir honestamente suas leituras do texto e produzir software que precisasse de ajuste para conversar. O selo de conformidade seria uma descrição insuficiente da conversa que aconteceria no cabo.

As funções opcionais eram um teste fácil de entender. O produto de um fornecedor dependia de um recurso que o outro, autorizado pela especificação, decidira não implementar. Ambos tinham uma defesa técnica. O cliente tinha duas caixas e uma incompatibilidade. Poderia mudar configuração, encomendar software ou trocar uma peça. Padlipsky suspeitava que a conta da correção ficaria com o usuário, não com as empresas. A palavra “opcional” deslocava a decisão do projeto comum para a entrega concreta.

O próprio computador pagaria outra parcela. Ciclos de CPU e memória eram recursos valiosos para os hosts que a rede pretendia conectar. Regras que obrigassem todo envio a percorrer uma longa escada de camadas ou mantivessem estado extra consumiriam esses recursos. O RFC recordou um episódio de sondagens repetidas que elevaram a despesa de uma instalação histórica. O episódio indicava o tipo de medição a exigir, não uma estatística aplicável a todos os fabricantes. Uma proposta de compra precisava dizer o que o software faria enquanto rodasse, além de quem atenderia ao telefone quando ele falhasse.

O texto tem humor ácido, mas sua estrutura não depende de supor má-fé. Padlipsky observou que ambientes de projeto diferentes recompensam coisas diferentes; o incentivo para implantações pequenas e eficientes pode ser fraco mesmo entre profissionais honestos. No fim, evocou a velha regra de que não existe almoço grátis. Manutenção, integração entre produtos, processador e memória formavam linhas separadas de despesa. Ele ainda notou que mais fabricantes estavam oferecendo, ou se preparando para oferecer, TCP/IP. A oposição entre “software do fornecedor” e “protocolos ARPANET” já começava a perder nitidez.

O RFC 873 registra uma controvérsia com data, prazo e produtos ainda por completar. Ele orienta uma pergunta melhor do que “tem suporte?”: que suíte inteira existe hoje, quais opções são iguais nos dois extremos, quanto tempo falta para comprar e quem será chamado quando a ligação não acontecer? Um contrato escolhe o responsável comercial. A interconexão depende de comportamento acordado e verificado.