Resumen

  • FTP trató USER, PASS y ACCT como datos distintos de control de acceso. Superar el paso de la contraseña no garantizaba haber terminado el ingreso ni estar autorizado para cada acción posterior.
  • 332 era un estado intermedio positivo. Si aparecía después de una orden de archivo, además decía que el servidor conservaba esa orden mientras esperaba la cuenta; 532 la daba por descartada y exigía repetirla.
  • El estándar no definió la cuenta como pago, segundo secreto o identidad global. Reservó un espacio para la política local y una gramática para saber qué información y qué intención seguían pendientes.

El tercer renglón de una conversación de acceso

La escena comienza con dos resultados correctos. El servidor reconoce el nombre de usuario y acepta la contraseña. Sin embargo, no responde 230 User logged in. De acuerdo con RFC 959, puede devolver 332 Need account for login.

El primer dígito importa. La clase 3 no rechaza la orden anterior: la acepta y mantiene la acción en suspenso hasta recibir información adicional. El cliente debe enviar ACCT. Volver a probar la contraseña confunde una credencial ya aceptada con un contexto todavía ausente.

La mayoría de las interfaces actuales convierten el acceso en dos casillas y un resultado binario. Ese modelo no puede nombrar fácilmente una situación en la que la identidad y su secreto sean suficientes para una etapa, pero el servidor remoto aún deba saber a qué proyecto, asignación o dominio local aplicar el trabajo.

ACCT nació de una incompatibilidad concreta

RFC 385 añadió la orden en agosto de 1972. Mencionó sistemas como TENEX, donde usuario y contraseña no agotaban los datos necesarios: también hacía falta una especificación de cuenta.

El documento la separó de PASS. ACCT no tenía por qué relacionarse de modo fijo con USER, podía llegar en cualquier momento y un mismo usuario podía transferir archivos bajo cuentas diferentes. La cuenta podía ser requisito de ingreso o aparecer solo ante una acción particular, como almacenar.

Nada de ello autoriza a traducir account como una cuenta bancaria. El argumento era una cadena Telnet cuyo significado pertenecía al sitio. Podía representar consumo, proyecto, asignación o autorización local. FTP no normalizó esos sistemas; normalizó la posibilidad de pedirles un selector.

Los números se ordenaron para que la máquina no leyera prosa

En 1973, RFC 542 incorporó ACCT, pero empleaba otro repertorio: 331 Enter account para la cuenta necesaria durante el ingreso y 433 cuando una transferencia no podía continuar sin cuenta y debía reenviarse.

RFC 640 reorganizó las respuestas en 1974. Quería que el programa decidiera el estado siguiente por los tres dígitos, sin depender del texto humano que cada servidor podía redactar de forma distinta. La clase 3 pasó a significar aceptación intermedia; la 5, final negativo de la solicitud exacta. El segundo dígito 3 reunió autenticación y contabilidad.

De ahí surgieron los significados duraderos: 331 pide contraseña después de aceptar el usuario; 332 pide cuenta para ingresar; 532 pide cuenta para almacenar. Una traza de 1973 debe leerse con su propio código, no con el diccionario posterior.

El mismo dato faltante podía dejar viva o muerta la orden

RFC 765 y RFC 959 explican la bifurcación operacional. Un usuario ya conectado envía STOR; el servidor descubre que esa acción requiere cuenta. Si guarda la orden mientras espera ACCT, responde 332. Tras proporcionar la cuenta, el cliente no necesita inventar de nuevo la intención que el servidor conserva.

Si el servidor descarta STOR, responde 532. Enviar ACCT puede satisfacer el contexto, pero no resucita la orden eliminada. El cliente debe transmitirla otra vez.

Así, 332 y 532 no son dos estilos de mensaje para el mismo error. Indican quién custodia la intención. La distinción permite automatizar sin adivinar: completar solamente la secuencia cuando la orden está retenida, o reconstruirla cuando ya no existe.

Una cuenta ausente no equivale a falta de disco

La frase “for storing files” puede inducir a mezclar 532 con capacidad. RFC 959 usa 452 para espacio insuficiente en el sistema y 552 para una asignación excedida en el directorio o conjunto de datos.

Los remedios son distintos. A 532 le falta un contexto de control; a 452, capacidad del sistema; a 552, margen dentro de una asignación. Un panel que agrupe los tres como “almacenamiento lleno” puede pedir más disco cuando la acción correcta era presentar una cuenta, o reintentar una orden que el servidor ya desechó.

La identidad podía cambiar sin cerrar el transporte

RFC 959 permite enviar un nuevo USER dentro de la conexión de control. El servidor borra la información de usuario, contraseña y cuenta y reinicia el ingreso. Los parámetros de transferencia permanecen, mientras una transferencia en curso termina bajo los controles anteriores.

La frontera no coincide con el socket. La identidad nueva no reetiqueta retroactivamente bytes que ya se transfieren; la cuenta anterior tampoco debe filtrarse a órdenes posteriores. REIN ofrece otra separación: limpia usuario y cuenta, restaura parámetros y deja abierta la conexión.

Por eso una auditoría necesita secuencia, no solo ID de conexión. Debe localizar el último USER, ACCT, REIN o establecimiento anterior a cada operación. Haber visto una cuenta aceptada alguna vez no prueba que siga gobernando el presente.

Soportar la orden no obligaba a necesitarla

RFC 1123 incluyó ACCT entre las órdenes que cliente y servidor debían soportar, con la excepción indicada para sistemas subyacentes que no permiten una función. La regla protegía la interoperabilidad con sitios que sí tenían un tercer contexto.

No exigía que todos lo pidieran. Cuando una orden reconocida era superflua en un sitio, la respuesta positiva 202 permitía continuar. Entender el estado y activarlo en cada sesión son compromisos diferentes.

El registro de comandos y extensiones FTP de IANA conserva ACCT como orden base de control de acceso con referencia a RFC 959. El registro demuestra nombre, clase y autoridad documental. No demuestra implantación, uso, significado local ni éxito de una transferencia.

Lo que perdura es la negativa a fingir una sola decisión

FTP dejó que cada servidor definiera su cuenta porque cada sistema poseía los recursos y la política que esa cadena seleccionaba. A cambio, obligó a expresar si faltaba información para ingresar, si una operación concreta necesitaba otro contexto y si la orden seguía retenida.

La enseñanza no es que todo producto deba revivir ACCT. Es que demostrar al sujeto, seleccionar el contexto de recursos y aceptar la acción son hechos distintos. Cuando una API moderna los comprime en “login: true/false”, los casos que no caben reaparecen como credenciales compartidas, parámetros ocultos y fallos sin diagnóstico.

Fuentes y límites

El conjunto cerrado es RFC 385, RFC 542, RFC 640, RFC 765, RFC 959, RFC 1123 y el registro IANA. Estas fuentes fijan semántica e historia; no prueban frecuencia actual, una implementación concreta, confidencialidad, cobro ni culminación del archivo.