Resumen

  • El pool propuesto por RFC 505 separaba depositar, avisar y recoger; STOU resolvió después una cuestión más estrecha al dejar al servidor la asignación de un nombre sin colisión.
  • Ni el nombre devuelto ni la respuesta final garantizan custodia futura, permiten afirmar que dos rutas llegan al mismo archivo, autorizan al destinatario o aseguran el canal.

Depositar fuera del directorio del destinatario

El RFC 505, publicado en junio de 1973, parte de una pregunta incómoda: ¿cómo puede un usuario enviar un archivo a otra persona en un host remoto sin conocer su contraseña? Colocarlo directamente en el directorio que el remitente atribuye al destinatario le daría demasiado poder. Podría consumir su espacio o destruir el contenido de una ruta ya existente.

Una de las soluciones propone un pool común. El archivo entra allí, el destinatario recibe una notificación y luego puede copiarlo a su propio directorio. El pool se purga periódicamente. La transferencia queda así insertada entre una admisión temporal y una recogida posterior. El servidor guarda algo en nombre de otra relación, pero no decide por sí solo que el destinatario ya lo haya aceptado.

La sintaxis propuesta, POOL id name, distinguía al receptor alegado y el nombre deseado. El servidor debía adaptar ese nombre con un prefijo o un sufijo cuando fuera necesario para mantenerlo único dentro del pool. El camino real podía no coincidir con la cadena enviada. Incluso antes de STOU, el depósito remoto enseñaba que el remitente no poseía la última palabra sobre el espacio de nombres de la zona de espera.

RFC 505 separaba además lugar de depósito, protección, aviso y movimiento posterior. Reconocía que distintos sistemas operativos obligaban al protocolo de alto nivel a conocer demasiadas particularidades. Su propuesta no constituye evidencia de un servicio desplegado de forma general ni de una línea directa de estandarización. Es un antecedente parcialmente sustituido que deja al descubierto el problema de custodia.

Recoger no es la operación inversa de depositar

El receptor no estaba simplemente al otro extremo de una copia instantánea. Primero debía enterarse; después, actuar desde sus propias credenciales y dentro de su propia asignación. El pool protegía su directorio precisamente porque no daba por válidas todas las decisiones del remitente. La recogida añadía una decisión que el depósito no podía anticipar.

La purga periódica introducía otra frontera. Un archivo podía existir en el pool y desaparecer si nadie lo reclamaba a tiempo. La presencia temporal no era conservación indefinida. Tampoco era una afirmación de que el contenido fuese auténtico o deseado. El ciclo permitía recibir sin convertir cada llegada en posesión permanente.

Este modelo se apoya en una premisa aún más antigua. El RFC 172, de 1971, definía el archivo mediante un camino único dentro de un sistema y dejaba las convenciones de nombres al host remoto. FTP no reemplazaba el control selectivo del sistema de archivos residente. Intercambiaba identificadores y contraseñas, pero la protección seguía siendo local.

Con STOR, el cliente proporcionaba una ruta: si no existía, podía crearse; si ya existía, el contenido podía ser reemplazado. En un flujo de custodia para terceros, esa facultad mezclaba demasiado. El remitente debía conocer una sintaxis extranjera y podía escoger una entrada cuya colisión afectaría a alguien más.

Nombrar el depósito se convirtió en una función del servidor

El RFC 949, de julio de 1985, recuperó expresamente escenarios de pools para impresoras, faxes y perforadoras de tarjetas. Propuso STOU, una orden que se comportaría como STOR excepto en la decisión del nombre. El archivo se crearía en el directorio actual con una ruta única respecto de ese directorio.

La propuesta estudió modificar STOR, añadirle un argumento de control o interpretar la falta de argumento. Prefirió una nueva orden para no reabrir el código de STOR; ampliar el despacho por nombres parecía más fácil. Ese razonamiento trataba la asignación como una capacidad separada, no como una corrección general de la custodia.

El remitente debía conocer el nombre elegido y la respuesta no podía ser opcional. Aun así, el RFC advertía que STOU no era un atajo para la autenticación, la contabilidad ni los controles de acceso del host. La facultad de crear un nombre libre solo opera después de que otras reglas permitan el depósito.

El RFC 959 estandarizó la forma STOU <CRLF> en octubre de 1985 como comando opcional. No hay ruta tras el verbo. El contexto de la sesión puede haber elegido un directorio corriente, y el servidor asigna dentro de él una cadena que no colisiona. La unicidad no sale de ese directorio, no dura necesariamente para siempre y no identifica el contenido.

El aviso de ruta pertenece al ingreso, no a la recogida

RFC 959 cometió un error al situar el nombre. Indicó que debía aparecer en una respuesta «250 Transfer Started», aunque 250 designaba una acción completada. La propia tabla de STOU reservaba 125 o 150 para el comienzo y 226 o 250 para el final. El texto mezclaba el ingreso a la zona de espera con el cierre de la transferencia.

El RFC 1123 corrigió la fase en 1989. El camino real debe volver antes de los datos en una de dos formas exactas: 125 FILE: pppp o 150 FILE: pppp. FILE: convirtió el nombre obligatorio en un campo reconocible dentro de una respuesta cuyo texto solía depender del servidor.

La corrección no añadió una promesa de custodia. Informa el archivo que va a escribirse; una respuesta posterior indica si la transferencia terminó o falló. Después todavía quedan la notificación, la recogida, el eventual traslado y la retención. Incluso un final positivo no certifica copia de seguridad, visibilidad futura o inmutabilidad.

Los resultados negativos conservan información que el pool necesita. 425 y 426 distinguen problemas al abrir o mantener la conexión de datos; 451, 551 y 552 preservan otras clases de fallo local, de página o de espacio. Ninguno autoriza a fingir que la entrada nunca fue asignada. Según el comportamiento del sistema de archivos puede quedar una referencia o contenido parcial que la política local deba reconocer, pero el protocolo no permite afirmar cómo se materializó ni que una sola operación atómica resolviera el nombre y los datos.

Por el mismo motivo, un 226 o 250 final cierra una afirmación de FTP, no el reloj del pool. El aviso puede seguir pendiente y el destinatario puede no haber recogido nada. El servicio que convierte la conclusión del transporte en “entrega” elimina de sus registros precisamente las etapas que justificaron separar el directorio temporal del directorio personal.

El mismo RFC obliga al cliente a aceptar las rutas remotas como cadenas arbitrarias. Si una aplicación modifica el camino para adaptarlo a sus convenciones locales, puede romper la referencia que conecta el depósito con el aviso y la posterior recogida.

Un archivo parcial no adquiere continuidad porque reciba otro nombre

La custodia también limita la reanudación. El RFC 3659 extiende REST para reiniciar una transferencia en modo flujo y espera normalmente que lo siga RETR o STOR. Un servidor puede aceptar APPE o STOU, pero no se recomienda; STOU después de REST tiene semántica indefinida.

La razón es que reanudar exige reconocer un archivo de destino anterior y una posición en él. STOU solicita un nuevo camino. Guardar el resto bajo otra asignación no demuestra que ambas partes pertenezcan a la misma entrega. El documento no declara imposible que un producto acepte la combinación; niega una interpretación común fiable.

Unique=, definido también por RFC 3659 para listados, responde a una pregunta diferente. Su token opaco y sensible a mayúsculas permite afirmar que dos rutas conducen al mismo archivo almacenado. La relación tiene que mantenerse al menos durante la conexión de control. El token no es el nombre producido por STOU, y una ruta nueva no se convierte por ello en una referencia mundial permanente.

El RFC advierte además contra tokens basados en valores internos del sistema de archivos que puedan eludir protecciones. Poder comprobar que dos rutas llegan al mismo archivo no concede permiso para recogerlo. Esa comparación y el derecho de acceso permanecen separados.

Custodiar un nombre no protege el canal

El RFC 2577 documentó en 1999 que el FTP estándar transmite contraseñas, control y datos sin cifrado, y describió riesgos distintos de robo o sustitución de la conexión de datos. Un pool puede evitar que el remitente sobrescriba directamente el directorio del destinatario; STOU puede evitar una colisión al asignar la ruta. Ninguno autentica el contenido, valida al par de datos o garantiza confidencialidad e integridad.

El estado normativo tampoco demuestra uso. El RFC 5797 creó un registro para reducir conflictos entre nombres de comandos y extensiones. El registro FTP de IANA conserva STOU como comando base opcional con referencias a RFC 959 y RFC 1123. Esa fila no mide implantación ni soporte presente. Su pseudo-código FEAT base tampoco es una línea destinada a la respuesta FEAT de un servidor.

La limpieza periódica del pool tampoco obtiene un calendario de esa inscripción. El registro evita que dos especificaciones reclamen STOU para propósitos distintos; no decide cuánto puede ocupar una entrada, cuántas veces debe notificarse ni quién resuelve una reclamación tardía. Esas decisiones pertenecen a la custodia local y deben permanecer visibles como tales.

El recorrido vuelve así al pool. Un nombre asignado permite localizar una entrada temporal. Una conclusión FTP indica el resultado del transporte. Pero solo los procesos posteriores pueden avisar, aceptar, trasladar, conservar o eliminar. La mejora histórica no fue una promesa de entrega perpetua: fue hacer más estrecho el poder del depositante sin ocultar el trabajo que aún quedaba al custodio y al destinatario.