Summary

  • RFC 1545 proposed LPRT and LPSV in November 1993 to let FTP name data-connection endpoints using an address-family field and explicit host and port lengths. The familiar PORT format had exactly six decimal octets: four for the host and two for the port.
  • The Experimental proposal added reply 228 for long passive mode and 521 for a server that understood the command but lacked the requested address family. RFC 1639 revised and obsoleted the proposal in June 1994, making room for non-IP network families and transport interfaces beyond TCP.

A very small address book

FTP has two conversations to manage. Its control connection carries commands and replies; a separate data connection carries the file or listing. The 1985 FTP specification, RFC 959, used PORT to tell the other end which data address to use. The address was compact and concrete: six unsigned decimal values separated by commas. Four values represented a 32-bit Internet host address. Two represented a 16-bit TCP port. In the IPv4 world that built the command, six slots were enough.

An application command can survive long enough to become a trap for its own successors. By 1993, engineers were weighing several candidates for a next Internet protocol and considering network and transport systems beyond the original pairing. A larger or variable-length address could exist perfectly well in its own protocol and still have no place to sit inside FTP's six-field PORT argument. The pinch point sat in the application conversation: an address embedded in a command exchanged before opening the data connection.

David Piscitello's RFC 1545, marked Experimental in November 1993, called the repair FTP Operation Over Big Address Records. FOOBAR sounds like someone dared a standards author to leave a placeholder in the title. The mechanism was more careful. A new LPRT command began with an address-family value, followed by the host-address length, the host address itself, the port-address length and the port address. Each piece travelled as unsigned decimal octets separated by commas. Instead of pretending that every destination was four host fields and two port fields, the command said what family it was speaking and how much space each part occupied.

The companion LPSV command handled the passive side. A server asked to listen for a data connection could return 228 Entering Long Passive Mode with the same family-and-length information. That mattered because FTP could establish its data channel in either direction. Expanding the client-supplied address while leaving the server's address reply stuck in the old format would have solved only half the conversation. FOOBAR gave both sides a longer vocabulary.

A third addition did a quieter job. The proposed 521 reply said which address families the server supported when it recognized the long-address command but could not handle the family requested. Existing 500 and 501 syntax-error replies remained available for malformed commands. The distinction is operationally useful: a peer that understood the new grammar but lacked one network family was a different case from a peer unable to parse the request. A 521 reply offered a route for choosing another family; the separate data connection would carry the file.

RFC 1545 listed contemporary possibilities including SIP, TP/IX, PIP and TUBA alongside Internet Protocol and ST Datagram Mode. That list is a 1993 snapshot of alternatives under discussion. It is especially revealing that the proposal included a length for the transport port, not only for the network host address. TP/IX contemplated longer transport selectors; FTP's old two-octet port assumption might become the next tight doorway. The memo also allowed the FTP command and data connections to use different address families.

Different network families could meet inside one FTP session, a more intricate migration than changing a single global switch.

The proposal did not freeze in that first form. RFC 1639 arrived in June 1994, explicitly obsoleting RFC 1545. It kept the larger address mechanism but sharpened the family allocation: values 0 through 15 were reserved for IP-family version numbers, while 16 through 255 were available for other network-layer protocols assigned by IANA. Novell IPX appeared at 16. The revision also spoke explicitly of FTP running over transport interfaces beyond TCP. FOOBAR's address book had grown from an IPv4 escape hatch into a more general application interface.

The design pressure is visible in the syntax. PORT h1,h2,h3,h4,p1,p2 was an ordinary-looking command whose commas carried a network assumption. Once the possible host address or transport selector grew beyond those fixed fields, the application had to explain the new shape to its peer. RFC 1545 and its revision show that the future Internet had to fit through application syntax as well as through routers. FTP's six slots were small. The engineering work needed to open them was not.