RFC 448

PRINT FILES IN FTP 🎀

Okay bestie, let's get into it 💖 This is RFC 448 by R.T. Braden of UCLA/CCN, dated February 27, 1973, filed as NIC #13299 for the Network Working Group. It updates RFC 354, 385, and 454. 🦋

INTRODUCTION 💖

Lots of people who helped define FTP and RJE have mixed feelings about the "print file" type in FTP, like anywhere from kinda uncertain to genuinely unhappy 😭 This RFC looks at the print file problem ahead of the upcoming FTP meeting. It started out based on RFC 385, then got updated to use the terminology from the latest FTP document, RFC 454. (Changing the terminology doesn't solve the problem! 💀)

Here's the tea 🫖 The Network RJE protocol as currently defined (see NIC 12112) seems to force one particular reading of print files in FTP, and ngl, that reading is probably not what most FTP implementors were assuming 🙈

VERTICAL FORMAT CONTROL 📜

So what even is a print file? 🤔 It's basically a file that's meant to be sent (eventually) to a printer process to make a hard copy. Lots of operating systems, especially the batch-processing ones, let programmers put control codes right inside the file to manage the vertical format of the printed page. Think single or double line spacing, overprinting, and page ejection. A "print file" is one that includes this vertical format control, or "VFC," info. 🌸

There are three common ways printer processes figure out VFC:

CASE N: Non-Print File 🍓 The file has no VFC info at all, so the printer process just applies a standard format (single spacing, standard vertical margins) when it prints.

CASE T: Print File with ASCII Format Effectors 🧚 This one is "Telnet-like," and it uses the ASCII controls CR, LF, and FF to handle VFC.

CASE A: Print File with ASA (Fortran) VFC 👑 Here the first character of each record is a VFC code. Check RFC 454 for the codes.

So assuming we're going to have print files in FTP, we have to think about all three of these cases 🫶 RJE explicitly lists them as "transmission" modes, and the author borrowed the RJE labels N, T, and A from NIC #12112. Meanwhile, the current FTP (RFC 454) seems to offer only two cases: unformatted and print_file. It's honestly unclear from RFC 454 how those two FTP formats connect to the three VFC cases. For example, it's not clear whether the FTP format is supposed to be a property of the file as it travels over the Network, or a property of the file as the server stores it. Confusing, I know 😭

As I understand it, the Tenex system only supports case T. The line between Case N and Case T isn't always crisp though ✨ If a Tenex file contains nothing but the CR LF combination of format effectors, it could be read as Case N, where CR LF marks a logical record and the standard format is to start printing each record on a new line. RJE actually uses this ambiguity to its advantage, and we'll see how below 👀

The IBM operating systems support Cases N and A. The "output writer" process that drives the printer has to know whether a file has ASA VFC, so the system internally tells apart "print files" (Case A) from non-print files (Case N). The "print file" attribute usually gets attached when the file is created. For instance, the language processors typically make print files for their "printer" output streams. 🖨️

So when CCN's server FTP runs a STOR command, it has to decide whether the new file gets the internal print file attribute. Like we said, FTP doesn't explicitly distinguish the three possible cases. That means we either need to add some extra assumptions or server-dependent info that lives outside FTP, or we need to add a brand-new format to FTP. Pick your fighter 🥊

IMPLICATIONS OF RJE 🔥

To send an output ("printer") file to a user host, the RJE server will make his FTP user process send the file with these attributes*:

 VFC Case      |     FORMat            |     STRUcture
-------------------------------------------------------------------
  N            |     Unformatted       |     Record structure
               |     -                 |     -
  T            |     Unformatted       |     File structure
               |     -                 |     -
  A            |     Print File        |     Record structure
               |     -                 |     -

*Note: Making the obvious conversion from RFC 385 to RFC 454 terminology.

So the RJE authors meant to use the structure attribute to tell Cases N and T apart. Honestly that's a pretty reasonable call 💅 But we should really understand the consequences and spell them out in the FTP document, no skipping 🙈

Now let's assume we want perfect consistency between FTP and RJE. An FTP server that uses ASA VFC internally should convert every (Unformatted, Unstructured) file it receives into an internal print file! 😱 The file has to be mapped into a set of physical lines (which are really logical records internally), and an ASA VFC character has to be stuck onto the front of each line before it's stored. This also means the default file structure in FTP should change to record structure. (This backs up the point Wayne Hathaway made in RFC 414: if a Tenex user sends a source file to an IBM host and wants to actually manipulate it, they'd better send it with record structure 💜)

ANOTHER CHOICE 🦋

If giving up (unformatted, unstructured) as a simple default case feels like too much of a loss, we can just change FTP to include three formats matching Cases N, A, and T. RJE would get changed to match ✨

ACKNOWLEDGMENTS 🫶

Discussions with Steve Wolfe, Jon Postel, and Eric Harslem were super helpful in making the print file problem in FTP clearer. Thank you, queens 👑

RTB/gjm

       [ 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 ]