Resumo

  • Um arquivo pode ficar armazenado num host remoto; um programa pode fazê-lo agir. O RFC 114 colocou um pedido limitado de execução ao lado das operações de arquivo e levantou a questão de quem definiria essa ação.
  • Os RFCs 171 e 172 depois separaram a transferência comum dos comandos de arquivo do FTP. O RFC 172 deixou a execução remota possível, mas sem procedimento padrão.

A diferença vai além da técnica. Receber um arquivo pede que o host remoto entregue informação; pedir que execute um programa faz esse host realizar trabalho. Surge então uma questão de controle: quem define a ação e o que dois hosts precisam combinar para entendê-la? Os RFCs não registram falha nem implantação ampla. Eles mostram uma escolha inicial sobre onde colocar o comportamento da aplicação. Uma comparação com serviços atuais é uma analogia, não uma afirmação de origem direta.

No RFC 114, “arquivo” significava mais do que um documento a ser copiado: a definição inclui instruções e/ou dados. O cabeçalho data a proposta de 16 de abril de 1971 — o catálogo do RFC Editor informa 1º de abril — e descreve transações entre processos cooperantes para usar o sistema de arquivos de outro host. A lista inclui identificar, buscar, gravar, acrescentar, renomear, excluir, abrir, fechar e pesquisar. Inclui também execute.

Isso não era um shell remoto de uso geral. O RFC 114 descreve o envio de dados de entrada, a execução de um programa ou sub-rotina no host servidor e o retorno da saída. Também limita a proposta: o processo solicitante precisava conhecer as convenções para argumentos e respostas. O protocolo esboçava uma troca controlada em torno de um arquivo de programa, não uma linha de comando universal nem um modelo de segurança.

O ambiente previsto era concreto, mas restrito. O RFC 114 diz que o protocolo foi desenvolvido para implementação imediata em dois hosts do MIT, GE 645/Multics e PDP-10/DM/CG-ITS, talvez também em um PDP-10 de Harvard. Uma versão provisória, com recursos limitados, estava em depuração. Isso comprova um esforço específico de implementação; não demonstra que todas as transações listadas funcionavam nem que o protocolo se espalhou pela rede.

Os documentos seguintes tornam a fronteira mais clara. O RFC 171, de junho de 1971, propôs um protocolo comum de transferência de dados para aplicações distintas: transferência de arquivos, entrada remota de tarefas, correio, gráficos e execução remota de programas. O argumento era arquitetural: separar transferência e funções de aplicação aumentaria a flexibilidade de implementação, reduziria a complexidade e evitaria a proliferação de protocolos.

O RFC 172, o protocolo de transferência de arquivos associado, usava esse DTP comum para transportar dados e definia as operações com arquivos como aplicação. Cada host podia implementar apenas um subconjunto dos comandos. O documento também dizia que o FTP poderia ser ampliado para permitir execução remota, mas não sugeria um procedimento padrão. A possibilidade permaneceu em vista, sem virar uma ação padrão do FTP.

A diferença importa porque um documento pode incluir uma operação no escopo sem torná-la um serviço confiável entre implementações. Comentários contemporâneos no RFC 141 discutem acesso a arquivos locais, subconjuntos de comandos e a possibilidade de um trabalho executado levar muito tempo. Isso revela perguntas dos projetistas, não um levantamento de uso. Revisões posteriores do FTP mostram uma linhagem de especificações, mas não provam que a transação execute do RFC 114 tenha se tornado comum.

A mudança mais duradoura foi conceitual. O mecanismo para mover dados podia ser compartilhado; o que uma aplicação remota faria com esses dados era uma decisão distinta. A proposta inicial aproximava as duas questões para explorá-las juntas. Em junho, os documentos deixaram mais explícita a separação entre uma camada de transferência reutilizável e comandos específicos de cada aplicação. A execução remota continuou possível como extensão, mas não como procedimento padrão do FTP.

O episódio deve ser lido como mudança no escopo da especificação, não como uma função perigosa amplamente implantada e depois removida. O RFC 114 registra uma primeira proposta ambiciosa e uma implementação provisória limitada. Os RFCs 171 e 172 registram uma divisão mais clara de responsabilidades. Os textos mostram o que seus autores decidiram especificar; sozinhos, não comprovam prevalência, segurança operacional ou o comportamento de cada host.

Fontes