RFC 385

1. Corrections 💖

Let's start with the errata, bestie. Here's what to fix in RFC 354 🎀

• (i) Page 2, line 15: replace user-FTP by server-FTP.
• (ii) Page 3, line 12: replace III.A by III.C.
• (iii) Page 15, last para, line 1: replace user s by user is.
• (iv) Page 28, line 21: replace _CRCRLF_ by _CRLF_.
• (v) Page 27, line 10: replace 451,451 by 451.
• (vi) Note that on Page 26, line 15 mode code is S|B|T|H.

2. Minimum Requirements ✨

RFC 354 says it's recommended for hosts to implement the default parameters, but the word "recommended" should be read as "required" 🫶 So the minimum for FTP servers is:

Type - ASCII (8-bit bytes)
Mode - Stream
Structure - File
Commands - RETR, STOR, USER (and PASS), SOCK and BYE

3. Print File Types 🎀

Okay this one is a whole saga 😭 The "Print File-ASCII" and "EBCIDIC Print File" types are specified wrong (pages 10 and 11 of RFC 354). The real problem with print files is ASA (Fortran) vertical format control. So instead of the two print file types, there should really be three:

• BCDIC: the sender transfers data using the EBCDIC character code and an 8-bit transfer byte size. The _CRLF_ convention is used for vertical format control. This one is for efficient transfer of EBCDIC files between systems that use EBCDIC internally 💜
• ASCII with ASA vertical format Control: this is the "Print file-ASCII" from RFC 354. The server transforms the data according to ASA (Fortran) vertical format control for printers that still use that standard. The data is transferred as 8-bit bytes.
• EBCDIC with ASA vertical format control: this is the "EBCDIC Print File" from RFC 354. The server transforms the data according to ASA (Fortran) vertical format control standards, but using the EBCDIC character code. The data is transferred in 8-bit bytes.

The new types are denoted by the symbols E for EBCDIC, P for Print file-ASCII, and F for Formatted (ASA standard) EBCDIC print file. You can read about ASA vertical format control in NWG/RFC 189, Appendix C, and in Communications of the ACM, Vol 7, No. 10, p. 606, October 1964 📚 Under the ASA rules, the first character of a formatted record isn't printed. It just decides the vertical spacing:

Character    Vertical Spacing before printing
---------    --------------------------------
 Blank          One line
   0            Two lines
   1            To first line of next page
   +            No advance

Besides those four, there are more characters (defined in Appendix C of RFC 189) that represent an IBM extension to the ASA standard 👑

4. Stream vs Text Mode 🦋

Okay, a comparison of stream and text modes is totally in order. The advantages of stream mode are:

• 1) The receiver doesn't need to scan the incoming bytes.
• 2) It works with all data types.

The disadvantages are:

• 1) Using EOF by closing the connection isn't reliable.
• 2) Using EOR by ASCII _CRLF_ is unreliable, because a _CRLF_ might actually be valid data rather than an EOR. It's an EOR only if the sender and receiver have a prior agreement to that effect 🙈

5. Block Mode Null Bytes 🌸

In Block mode, the protocol says the left-most bits that don't contain information should be zero. It turns out some sites have trouble sending null bytes at the start of a block. Since those bits don't really need to be zero, they're now defined as "don't care" bits 🫶

6. Overlapping Conditions in Block Mode 🧚

In Block mode, two or more conditions that need different descriptor codes (suspected errors plus either end of record or end of file) can exist at the same time. You can handle that by sending a separate EOR or EOF block with a zero byte count (this is allowed by the protocol) ✨ Also, note that an EOF is an implicit EOR.

7. Listen First, Always 🔥

I need to say this again, bestie: the user-FTP must "listen" on the data socket before sending a command that requires a file transfer. Specifically, the user-FTP should not wait for a 255 reply (server data socket) before doing the "listen". The security check can come later, because the data connection can be closed if the connection goes to a socket other than the one specified by the 255 reply 🚨

Even though the protocol suggests the 255 reply would be sent before making the connection, it doesn't guarantee the 255 reply arrives before the initiating RFC at the user site. The same logic applies to receiving a close (NCP-CLS) on the data connection before receiving a reply that says why the close happened (note the assertion on page 24, paragraph 3, of RFC 354) 💀

8. Closing the Data Connection 🍓

The protocol doesn't restrict closing or leaving open the data connection in Block and Text modes. Still, it's worth emphasizing that if the data connection is going to be closed at all, it should be closed right after the file transfer. It shouldn't wait until a new transfer command is received 💅 That's because the server and user may need to test whether the data connection is open before doing a "listen" or an "init", respectively.

The FTP is an open-ended protocol built to be easy to expand, bestie 🧚✨ Sites that want extra commands can define experimental commands of their own 💅. These experimental commands should begin with the alphabetic character 'X' 🦋. Standard reply codes may be used with these commands 💖. If new reply codes are needed, they should be chosen between 900 and 999 🌈. And if an experimental command turns out to be useful and of general interest, it shall be included in the FTP command repertoire 👑. Iconic glow-up arc 😭🫶

---

       [ This RFC was put into machine readable form for entry ]
       [ into the online RFC archives by BBN Corp. under the   ]
       [ direction of Alex McKenzie.                      1/97 ]