Resumen

  • El RFC 1545, experimental en noviembre de 1993, añadió LPRT y LPSV como propuesta para direcciones de conexión de datos con familia identificada y longitudes expresas. El viejo PORT fijaba seis octetos decimales: cuatro de host y dos de puerto.
  • FOOBAR propuso la respuesta 228 para modo pasivo con dirección larga y 521 cuando el servidor comprendía la orden pero no admitía la familia solicitada. El RFC 1639 sustituyó la primera versión en junio de 1994 y amplió el esquema a otras redes y transportes.

El mostrador solo tenía seis ventanillas

FTP separa su trabajo en dos conexiones. Por una viajan las órdenes; por la otra, los datos de un fichero o de un listado. Según el RFC 959, el cliente podía enviar PORT para indicar dónde debía abrirse la conexión de datos. El argumento era corto y cómodo: h1,h2,h3,h4,p1,p2. Los primeros cuatro valores representaban una dirección de host de 32 bits; los dos últimos, un puerto TCP de 16 bits. Cada valor era un octeto escrito en decimal y separado por comas. Todo cabía en seis ventanillas.

Las ventanillas no crecían con la red. Mientras se debatían opciones para la siguiente generación de IP, una dirección de longitud mayor o variable necesitaba llegar a la aplicación que iba a usarla. También podía surgir un selector de transporte más largo que el puerto de TCP. Un paquete de otro protocolo podía existir sin problemas y, sin embargo, la orden FTP que preparaba la transferencia seguía pidiendo seis cifras de un molde anterior. La frontera no estaba en el fichero: estaba en la frase pronunciada antes de abrir su camino.

David Piscitello dedicó el RFC 1545 a esa grieta. Lo llamó FTP Operation Over Big Address Records, FOOBAR, como si el acrónimo se hubiera escapado de una pizarra y recibido un número oficial. Era una propuesta Experimental. La nueva orden LPRT comenzaba con una familia de direcciones; después indicaba cuántos octetos ocupaba el host, escribía esos octetos, indicaba la longitud del puerto y escribía el puerto. La transmisión seguía usando valores decimales separados por comas. La diferencia estaba en anunciar el tamaño de cada pieza antes de entregarla.

La mitad pasiva de FTP también necesitaba aire. LPSV pedía al servidor que escuchara en un puerto de datos y devolviera 228 Entering Long Passive Mode con familia, longitudes, host y puerto. Si solo se ensanchaba la dirección que daba el cliente, la respuesta del servidor continuaría encerrada en el formato viejo. FOOBAR trató las dos direcciones como parte de una misma conversación. La conexión de control podía planear un canal de datos que usaría otra familia.

Había una respuesta más, menos vistosa y muy útil: 521. Un servidor podía reconocer la gramática de LPRT o LPSV y carecer de soporte para la familia pedida. En vez de mezclar ese caso con los errores de sintaxis 500 y 501, 521 enumeraba las familias admitidas. Así quedaba a la vista si fallaba la forma de la orden o la capacidad del par. Elegir otra familia seguía siendo una decisión de los extremos; el código facilitaba saber cuáles estaban disponibles.

El inventario de RFC 1545 retrata un momento de alternativas abiertas: IP, ST Datagram Mode, SIP, TP/IX, PIP y TUBA. Sus números de familia aparecían como opciones contemporáneas, no como una lista de ganadores. El campo de longitud para el puerto iba más allá del problema inmediato de la dirección de host. TP/IX contemplaba selectores de transporte más largos; el límite de dos octetos podía volver a morder por el otro extremo. El documento incluso permitía que la conexión de órdenes y la de datos pertenecieran a familias distintas. Una transición real podía ser una mezcla, no una noche en que todo el mundo cambiara de protocolo a la vez.

La propuesta recibió una revisión rápida. En junio de 1994, el RFC 1639 declaró obsoleto al RFC 1545. Reservó los valores de familia 0 a 15 para versiones relacionadas con IP y dejó de 16 a 255 para otros protocolos de red asignados por IANA; Novell IPX figuraba con el 16. La revisión habló expresamente de operar FTP sobre interfaces de transporte distintas de TCP. El formulario había pasado de admitir una dirección más larga a reconocer que quizá hubiera varios mostradores.

Basta mirar la antigua línea PORT h1,h2,h3,h4,p1,p2 para entender por qué importaba. Dentro de una aplicación de transferencia se había fijado una idea concreta de host y puerto. Al ensancharse la discusión sobre la red, aquella idea seguía escondida entre comas. FOOBAR la sacó a la luz con familia y longitud declaradas. El futuro de Internet tenía que pasar por los routers, sí; también debía conseguir que FTP supiera escribir la dirección en su orden.