Resumen

  • Pedir a otro ordenador que envíe un archivo mueve información; pedirle que ejecute un programa hace que actúe. El RFC 114 exploró ambas peticiones en una sola propuesta.
  • Los RFC 171 y 172 separaron después la transferencia común de los comandos de archivos de FTP. El RFC 172 dejó la ejecución remota como posible ampliación, sin un procedimiento estándar.

La diferencia se entiende hoy en un servicio web: recibir un archivo es una petición; pedir que el servicio lo procese es otra, porque la segunda hace trabajar al sistema que lo recibe. La comparación ayuda a entender la decisión, pero no afirma que el RFC 114 condujera directamente a los servicios actuales. En 1971, un archivo podía contener instrucciones además de datos. ¿Debía un mismo protocolo transportarlo y pedir al host remoto que lo ejecutara?

En el RFC 114, «archivo» significaba algo más que un documento que se copia: la definición abarca instrucciones o datos. Su encabezado lo fecha el 16 de abril de 1971 —el catálogo del RFC Editor indica el 1 de abril— y describe transacciones entre procesos cooperantes para usar el sistema de archivos de otro host. La lista abarca identificar y recuperar, además de guardar, añadir, renombrar, borrar, abrir, cerrar y buscar. También incluye execute.

No era una consola remota de propósito general. El RFC 114 describe el envío de datos de entrada, la ejecución de un programa o subrutina en el host servidor y la devolución del resultado. También limita la idea: el proceso solicitante debía conocer las convenciones de argumentos y respuestas. El protocolo esbozaba un intercambio acotado alrededor de un archivo de programa, no una línea de comandos universal ni un modelo de seguridad.

La propuesta partía de un entorno concreto, aunque reducido. El RFC 114 dice que se había desarrollado para una implementación inmediata en dos hosts del MIT, GE 645/Multics y PDP-10/DM/CG-ITS, quizá también en Harvard. Una versión provisional de capacidades limitadas estaba en fase de depuración. Eso documenta un esfuerzo de implementación específico; no demuestra que funcionaran todas las transacciones enumeradas ni que el protocolo se extendiera por la red.

Los documentos posteriores hacen más nítida la frontera. El RFC 171, fechado en junio de 1971, propuso un protocolo común de transferencia de datos para aplicaciones diversas: transferencia de archivos, entrada remota de trabajos, correo, gráficos y ejecución remota de programas. Su argumento era arquitectónico: separar la transferencia de las funciones de aplicación daría flexibilidad de implementación, reduciría complejidad y frenaría la proliferación de protocolos.

El RFC 172, el protocolo de transferencia de archivos complementario, utilizaba ese DTP común para mover datos y definía las operaciones con archivos como su aplicación. Permitía que cada host implementara solo un subconjunto de comandos. También decía que FTP podía ampliarse para permitir la ejecución remota, pero no proponía un procedimiento estándar. La posibilidad seguía presente; no formaba parte de un procedimiento FTP normalizado.

La diferencia importa porque un documento puede incluir una operación en su alcance sin convertirla en un servicio fiable entre implementaciones. Los comentarios contemporáneos del RFC 141 examinan el acceso a archivos locales, los subconjuntos de comandos y la posibilidad de que ejecutar un trabajo implicara una espera prolongada. Muestran preguntas de diseño, no un recuento del uso. Las revisiones posteriores de FTP trazan una secuencia de especificaciones, pero no prueban que la transacción execute del RFC 114 se volviera habitual.

El cambio más duradero fue conceptual. Podía compartirse tanto el movimiento de archivos como el mecanismo para mover datos; lo que una aplicación remota hacía con esos datos quedaba como una decisión distinta. La propuesta inicial acercaba ambas cuestiones para explorarlas juntas. En junio, los documentos explicitaron mejor una capa de transferencia reutilizable y un conjunto de comandos propio de cada aplicación. La ejecución remota quedó como posible extensión, no como acción estándar de FTP.

Conviene leerlo como un cambio en el alcance de la especificación, no como la historia de una función peligrosa que se desplegó ampliamente y luego se retiró. El RFC 114 registra una primera versión ambiciosa y una implementación provisional limitada. Los RFC 171 y 172 documentan una división de responsabilidades más clara. Los textos indican qué decidieron especificar sus autores; por sí solos no establecen prevalencia, seguridad operativa ni el comportamiento de cada host.

Fuentes