RFC 430

Comments on File Transfer Protocol

📅 published February 1973, from ietf

RFC 430: COMMENTS ON FILE TRANSFER PROTOCOL 💖

okay bestie, so this is RFC 430 🎀 and it's basically a group chat about FTP. It's from the Network Working Group, written by R. Braden of CCN/UCLA (NIC 13299) and dated 7 February 1973. The header doesn't list a category, and it doesn't say what it obsoletes or updates, so I'm not guessing 🙈

On January 23, 1973, Jon Postel (NMC), Eric Harslem (RAND), Stephen Wolfe (CCN), and Robert Braden (CCN) held an informal meeting at UCLA on FTP 🌸 This RFC mostly writes down what everyone agreed on, covering server-server transfers (ref. RFC 438 by Thomas and Clements), site-dependent information, and misc questions and disagreements with RFC 354, 385, and 414. They also talked about the print file muddle, but that gets its own RFC, No. 448 💅

Miscellaneous Comments on FTP 🦋

  1. RFC 385, P. 1 (3)

okay so the question of print files is going to get a whole RFC of its own 📄 But we did feel that the word "still" on the second line from the bottom of Page 1 is gratuitous 💀

  1. RFC 385, P. 2 (5.) RFC 385, P. 3 (8.) RFC 414, P. 4 (11.i)

To the extent that we understand these items, they seem to be unnecessary and probably undesirable concessions to particular bad implementations ("hacks") 😤 About the second item, No. 8 in RFC 385, you should note that in an asynchronous multi-process system like the ARPA Network, the phrase "immediately after" has little meaning. An implementation that depends on "immediately after" is erroneous and should be fixed 🔥 If the protocol as defined has an intrinsic race condition, of course, the protocol should be fixed, but we don't believe such a problem exists ✨ It would help if definitions of command-response sequences in the FTP document were tightened up considerably 🫶 As for the last item, we don't understand why Wayne Hathaway is so strongly opposed to "implied eor" 🙃

  1. RFC 354, P. 13, Format Definitions for Block Mode

(a) The definition of the header length presumably is meant to be the "smallest integral number of bytes whose length is greater or equal to 24 bits".

(b) The same definitional problem occurs for restart markers.

(c) Why does the restart marker have to be greater than 8 bits? 🤔

(d) Note that changing the Descriptor coding to bit flags would abolish the implied eor as well as the problem of RFC 385, P. 2, #6 🧚

  1. RFC 414, P. 5 (11.iii)

Note that text mode is not possible for any EBCDIC coded file. Since EBCDIC is an 8-bit code, Telnet control characters (128-255) cannot be used to distinguish either eor or eof. Stream and block modes will work, however 🌈 We have found the diagram on the last page to be useful for keeping track of the three-dimensional space of FTP parameters 🍓

  1. RFC 354, P. 17, PASS Command

There is no mechanism within FTP for changing a password. A user shouldn't have to use a different protocol (e.g., log into a time sharing system) to merely change his password 😭

  1. RFC 385, P. 3 (9.), TYPE Before BYTE

This admonition (to send TYPE before BYTE) should be clearly labeled as a recommended procedure for user FTP, not a restriction on a server FTP 👑

  1. RFC 385, P. 2-3 (7) Order of 255 Reply

Some of the participants felt (strongly) that the timing problem dealt with in this item is the result of bad NCP implementations and ought not be dignified in the protocol 💅 The issue here is the old, familiar, and touchy one of queueing RFC's or not. (My own view is that the protocol asymmetry forced by NCP's which can't queue RFC's is at least unaesthetic, and makes some elegant solutions impossible. For examples, see RFC 414 and the comments below on server-server interaction, and RFC 438 on Reconnection Protocol.) 🦋

  1. RFC 354, P. 15, Restart

Following a RESTart command, APPend and STORe presumably have identical meanings 🌸

B. FTP Parameter Encoding 💜

RFC 448, which discusses print files, points out that the print file attribute is logically independent of the character code attribute (ASCII vs. EBCDIC) in the type dimension. The set of allowable types in FTP is the outer product of the individual attributes. So FTP has (at least) four character types, summarized by this two x two matrix:

                  |  ASCII  |   EBCDIC
   ---------------+---------+------------
   Not Print File |         |
   ---------------+---------+------------
   Print File     |         |
   ---------------+---------+------------

I propose that the encoding in the TYPE command model this interdependence of the types ✨ Instead of using a distinct single ASCII character for each type, we should use multiple ASCII characters, qualifiers if you wish. For example:

         A represents ASCII code
         E represents EBCDIC code
         P represents print file
         I represents image
         L represents local byte

Then the legal types according to RFC 385 would be:

         A
         AP
         E
         EP
         I
         L

Note that the attributes under consideration here are type-like. They are not (logically) concerned with the structure or the transmission mode, only the internal encoding of the file 🎀

At present, this would be a trivial change. However, I foresee the file transfer protocol expanding significantly over the next several years as new types are added 🚀 Some servers will want to add server-specific type variations, and the NWG will want to add some. How about an APL character set? Or the multiple-overlay 256 character ASCII which has been proposed? Multiple qualifiers (and later perhaps more structure) in the type seems to be the cleanest escape mechanism for future growth 🌈

D. Site-Dependent FTP Parameters ✨

Okay bestie, so some hosts have a problem with FTP 💅 because their file system needs extra host-specific parameters in certain cases. The IBM operating systems are a perfect example. They hand the programmer a whole buffet of options for how a file gets mapped onto the disk 🍓.

This is true for TSS/360 (see Wayne Hathaway's discussion of his STOR command implementation, Page 5 of RFC 418) and for OS/360 too. Honestly, the huge pile of options and parameters in the OS/360 file system is the (legit) reason most people complain about OS Job Control Language (JCL) 😭.

If the FTP user just wants to store data and isn't using it at one of these sites, they're totally fine ✨. Defaults can be picked to handle any reasonable FTP request. But the user who sends a file to an IBM/360 so it can actually be used there might need to specify local file system parameters that can't be worked out from any of the existing FTP commands 🙈.

In designing an FTP server implementation for CCN, we first tried to solve the mapping problem by picking a (possibly different) default mapping for each combination of FTP parameters: type, mode, and structure. We hoped that if a user picked "reasonable" or "suitable" FTP parameters for a particular case (e.g., "ASCII, stream, record" for source programs, and "image, block, record" for load modules), the right OS/360 file mapping would come out the other end. We had to abandon this approach, though, for these reasons:

  1. Some user FTPs probably may not implement all FTP type/mode/structure combinations (though they ought to!).
  2. Some user FTPs may not give the user full or convenient control over their type/mode/structure. Honestly, the mode should be chosen based on efficiency, not end use.
  3. There weren't enough logically distinct combinations of FTP parameters.
  4. The result would have been a set of hard-to-remember rules for sending files to CCN for use here.
  5. Some common cases require non-invertible transformations on the data. For example, most IBM language processors (i.e., compilers) accept only fixed length records of (surprise!) 80 bytes each, i.e., literal card images. These ugly (and logically unnecessary) implementation stupidities in OS/360 are a fact of life 💀. Now, if an FTP user innocently sent a data file to CCN with the type/mode combination that defaulted to card images, they'd find their records truncated to 80 bytes. That would be downright unfriendly 😤.

So the CCN server FTP would have to choose between being useful or being friendly 🥺. We decided on the following strategy:

  1. The defaults will be friendly. We'll accept any FTP type/mode/structure and store it invertibly (except print files) 🎀. However, the user who only uses these defaults will probably find they have to run a utility under TSO later to reformat the data.
  2. We'll provide some handy keywords for use with STOR commands to choose the proper disk mapping. For example, if someone wants to STORe a Fortran source file for compilation at CCN, they'll only need to specify "SOURCE" or "FORT" to get reasonable and workable OS/360 file system parameters ✨. We'll also provide pretty complete "DD" parameters for the sophisticated user 👑. The syntax and semantics of these keywords and parameters will be as close as possible to the corresponding TSO commands. Full details will be published as soon as the implementation is working 🧚.

All of this leads to a general protocol question: how should this host-dependent information appear within FTP? Hathaway used the ALLO command (see RFC 418, P. 6). CCN, on the other hand, feels that this information belongs in the only part of FTP syntax that's already host-dependent: the pathname 💜. So CCN plans to allow a "generalized" pathname in a STOR command, meaning a (full or partial) file name optionally followed by one or more keywords or keyword parameters separated by commas.

A third possible solution is for the user to precede their STORe command with a server-dependent data set creation command, using Hathaway's proposed SRVR command 🦋. The data set creation command could then carry all the parameters the server file system needs. CCN might switch to this approach if SRVR is adopted and people find the generalized pathname objectionable or unworkable 🙃.

For another interesting example of host-dependent problems, see Hathaway's discussion of his DELE command in RFC 418 (pp.6-7) 🌈.

+-------++-------+-------+-------++-------+-------+-------++
| \ MODE||       |       |       ||       |       |       ||
|   \   ||STREAM | TEXT  | BLOCK ||STREAM | TEXT  | BLOCK ||
|TYPE \ ||       |       |       ||       |       |       ||
+-------++-------+-------+-------++-------+-------+-------++
|       ||       |       |       ||       |       |       ||
| ASCII ||       |       |       ||       |       |       ||
|       ||       |       |       ||       |       |       ||
+-------++-------+-------+-------++-------+-------+-------++
|       ||       |///////|       ||///////|///////|       ||
| IMAGE ||       |///////|       ||///////|///////|       ||
|       ||       |///////|       ||///////|///////|       ||
+-------++-------+-------+-------++-------+-------+-------++
| LOCAL ||       |///////|       ||///////|///////|       ||
| BYTE  ||       |///////|       ||///////|///////|       ||
|       ||       |///////|       ||///////|///////|       ||
+-------++-------+-------+-------++-------+-------+-------++
|       ||       |///////|       ||       |///////|       ||
| EBCDI ||       |///////|       ||       |///////|       ||
|       ||       |///////|       ||       |///////|       ||
+-------++-------+-------+-------++-------+-------+-------++
| ASCII/||///////|///////|///////||       |       |       ||
| ASA   ||///////|///////|///////||       |       |       ||
| VRC   ||///////|///////|///////||       |       |       ||
+-------++-------+-------+-------++-------+-------+-------++
|EBCDIC/||///////|///////|///////||       |///////|       ||
| ASA   ||///////|///////|///////||       |///////|       ||
| VRC   ||///////|///////|///////||       |///////|       ||
|       ||///////|///////|///////||       |///////|       ||
+-------++-------+-------+-------++-------+-------+-------+
 KEY:
 +---+
 |///| Excluded
 +---+  case

[This RFC was put into machine readable form for entry] [into the online RFC archives by Helene Morin, Via Genie, 12/99]

📦 where this page comes from