Host-dependent FTP parameters
A technique to add server-specific parameters to FTP file requests without changing the protocol.
White, J.E., "Host-dependent FTP parameters", RFC 480, DOI 10.17487/RFC0480, March 1973, <https://www.rfc-editor.org/info/rfc480>.
@misc{rfc480,
series = {Request for Comments},
number = 480,
howpublished = {RFC 480},
publisher = {RFC Editor},
doi = {10.17487/RFC0480},
url = {https://www.rfc-editor.org/info/rfc480},
author = {J.E. White},
title = {{Host-dependent FTP parameters}},
pagetotal = 1,
year = 1973,
month = mar,
} RFC text
Network Working Group James E. White
RFC #480 SRI-ARC
NIC #14949 8 March 73
Host-Dependent FTP Parameters
This memo is in response to (and support of) one of the points raised by
Bob Braden (RTB) of UCLA-CCN in RFC #430, "COMMENTS ON FILE TRANSFER
PROTOCOL" (see -- 13299,), namely that raised in Section D., "Site-
Dependent FTP Parameters".
The NIC has been confronted with similar problems (and tentatively
decided upon similar solutions) in designing mechanisms which would
enable a user to use FTP to retrieve from the NIC, in sequential form, a
VIEW of some portion for an NLS tree-structured file.
To be done without modification to FTP, this task requires the user to
communicate information -- a filename, a statement address, viewspecs,
and the name of a conversion algorithm -- to SRI-ARC's server FTP
process in a manner that is transparent to the user's user FTP process.
We currently intend to require the user to embed this information in the
pathname of FTP's STOR and RETR commands by appending to a standard
TENEX filename, a field of the form:
;x <program> [ / <parameters> ]
where <program> identifies an arbitrary program to be dispatched by
SRI-ARC's server FTP process, with a pointer to the file being stored or
retrieved as an argument. <parameters> is optional and, if present, is
also passed to the program.
To store and retrieve NLS files in sequential form, we will require that
<program> be 'NLS' and <parameters> be of the form.
[ T: <conversion-algorithm> ] [ S: <statement address> ] [ V:
<viewspecs> ]
where each of the three items is optional, and any that appear are
separated by commas.
[ This RFC was put into machine readable form for entry ]
[ into the online RFC archives by Alex McKenzie with ]
[ support from GTE, formerly BBN Corp. 9/99 ]
AI ELI5
On this page
§1The FTP Parameter Problem
FTP works well for copying simple files between computers, but it does not handle site-specific needs. SRI-ARC's NIC needed to let users fetch parts of an NLS tree-structured file from the network, translating them to sequential form. The problem: this required passing information through FTP without modifying the protocol itself.
The NIC had a special kind of file that FTP could not handle directly, so they invented a trick to make it work.
§2Pathname Extension Syntax
The solution appends a field to standard TENEX filenames in the form `;x program [ / parameters ]`. This tells the server's FTP process to dispatch the named program with a pointer to the file being stored or retrieved, optionally passing additional parameters.
For NLS files, the program is named 'NLS' with parameters specifying the conversion algorithm (T:), statement address (S:), and view specifications (V:), each optional and separated by commas.
Instead of just sending a filename, you add extra instructions in a special format that the server understands and acts on.
§3Avoiding Protocol Changes
This design is elegant because it avoids modifying FTP itself. Old FTP clients continue to work, unaware of the extension field. The server's FTP process simply parses the pathname, recognizes the special format, and executes the appropriate program.
As the RFC notes, this approach generalizes beyond NLS files. Any server could define its own programs and parameter formats using the same syntax, allowing sites to add features without waiting for protocol updates.
Regular FTP clients ignore the extra instructions, so they keep working. Servers that understand the trick use the extra part to do special things.