RFC 480

Host-dependent FTP parameters

πŸ“… published March 1973, from ietf

Host-Dependent FTP Parameters πŸ’–

okay bestie, this is RFC 480 πŸŽ€ by James E. White of SRI-ARC, filed as NIC #14949 on 8 March 73, and it's part of the Network Working Group 🧚. The title block doesn't list a category, and it doesn't say what it obsoletes or updates, so that's everything up top ✨.

This memo backs up one of the points Bob Braden (RTB) of UCLA-CCN raised in RFC #430, "COMMENTS ON FILE TRANSFER PROTOCOL" (see -- 13299,). It's the one in Section D., "Site-Dependent FTP Parameters" πŸ¦‹.

The NIC ran into similar problems and tentatively landed on similar solutions while designing ways for a user to use FTP to pull a VIEW of some portion of an NLS tree-structured file from the NIC, in sequential form πŸ’….

To do this without changing FTP, the user has to pass a filename, a statement address, viewspecs, and the name of a conversion algorithm to SRI-ARC's server FTP process. It has to happen in a way that's transparent to the user's user FTP process 🫢.

The plan is to have the user embed all of that in the pathname of FTP's STOR and RETR commands, by tacking a field like this onto a standard TENEX filename:

;x <program> [ / <parameters> ]

Here, <program> is an arbitrary program that SRI-ARC's server FTP process dispatches, with a pointer to the file being stored or retrieved as an argument. <parameters> is optional, and if it's there, it gets passed to the program too 🌈.

To store and retrieve NLS files in sequential form, we'll require that <program> be 'NLS' and <parameters> be of the form.

    [ T: <conversion-algorithm> ] [ S: <statement address> ] [ V:
    <viewspecs> ]

Each of those three items is optional, and any that show up 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 ]
πŸ“¦ where this page comes from