Host-dependent FTP parameters
A pathname convention for passing host-specific information to an FTP server.
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 ]
ISO Plain Language
On this page
§1Passing Extra FTP Parameters
James White's memo responds to a point about site-dependent FTP parameters in RFC 430. The NIC needed to pass a filename, a statement address, view specifications, and a conversion algorithm to SRI-ARC's FTP server when retrieving an NLS view in sequential form.
The SRI-ARC server needed more than a filename to retrieve a selected view of an NLS file. The memo proposes passing that information through the pathname.
§2The Pathname Field
The proposed field is appended to a standard TENEX filename and has the form ;x program [/ parameters]. The program name tells the server's FTP process what program to dispatch; the file pointer is passed as an argument, along with optional parameters.
The pathname can name a program for the server to run. Optional parameters can provide more details to that program.
§3Parameters for NLS
For NLS files, the memo says the program name will be NLS. The optional parameters can specify a conversion algorithm with T:, a statement address with S:, and view specifications with V:; any parameters used are separated by commas.
The memo describes a planned convention, not a change to the FTP protocol itself.
For NLS, optional fields identify a conversion method, statement address, or view settings. The memo presents this as a plan for SRI-ARC's server.