Movatterモバイル変換

NETWORK WORKING GROUP                                  R.T. BradenREQUEST FOR COMMENT NO. 448                            UCLA/CCNNIC #13299                                             February 27, 1973UPDATES:RFC 354, 385, 454                           PRINT FILES IN FTPINTRODUCTION------------    Many of those who contributed to the definition of the FTP and RJEprotocols have expressed varying degrees of uncertainty or unhappinesswith the "print file" type in FTP.  This RFC is intended to review theproblem of print files in preparation for the forthcoming FTP meeting.Originally drafted on the basis ofRFC 385, this RFC has been updated toreflect the terminology of the latest FTP document 454.  (Changing theterminology doesn't solve the problem!)    It turns out that the Network RJE protocol as presently defined (seeNIC 12112) seems to force a particular interpretation of print files inFTP and in fact, this interpretation is probably different from the oneassumed by most FTP implementors.VERTICAL FORMAT CONTROL-----------------------    What is a print file?  Presumably it is a file which is intended tobe sent (eventually) to a printer process to create a hard copy.  Manyoperating systems (particularly those which are batch-processingoriented) allow the programmer to include control codes within a file tobe printed, to control the vertical format of the printed page--forexample, single/double line spacing, overprinting, and page ejection.  A"print file" is one which includes such vertical format control ("VFC")information.  There are three common ways for printer processes todetermine VFC:CASE N:  Non-Print File         --------------         The file contains no VFC information.  The printer process         applies a standard format (e.g., single space, standard         vertical margins) if the file is printed.CASE T:  Print File with ASCII Format Effectors         --------------------------------------         The file is "Telnet-like", containing the ASCII controls CR,         LF, and FF to provide VFC.Braden                                                          [Page 1]

RFC 448                    PRINT FILES IN FTP              February 1973CASE A:  Print File with ASA (Fortran) VFC         ---------------------------------         The first character of each record is a VFC code; seeRFC 454         for the codes.    Assuming there are to be print files in FTP, these _three_ casesneed to be considered.  These three cases are explicitly included withinthe RJE protocol as "transmission" modes; we have borrowed the RJElabels N,T, and A from NIC #12112.  The current FTP (RFC 454) seems toprovide only _two_ cases: _unformatted_ and _print_file_.  It is unclearfromRFC 454 how these two FTP formats are related to the three VFCcases.  For example, it is unclear whether the FTP format is meant to bea property of the file as transferred over the Network or of the file asstored by the server.    As I understand it, the Tenex system supports only case T.  Thedistinction between Case N and Case T is not always clear, however.  Ifa Tenex file which contains only the CR LF combination of formateffectors is printed, it may be considered Case N where CR LF delimits alogical record, and where the standard format is to begin printing eachrecord on a new line.  The RJE protocol uses this ambiguity toadvantage; see below.    The IBM operating systems, on the other hand, support Cases N and A.The "output writer" process which drives the printer must know whetheror not a file to be printed contains ASA VFC, so the systemdistinguishes internally between "print files" (Case A) and non-printfiles (Case N).  The "print file" attribute is normally attached to aprint file when it is created.  For example, the language processorstypically create print files for their "printer" output streams.    Hence, when CCN's server FTP executes a STOR command, it must decidewhether or not the new file is to be marked with the internal print fileattribute.  As noted earlier, FTP does not explicitly distinguish thethree possible cases.  We must either add some additional assumptions orserver-dependent information outside FTP, or we must add a new format toFTP.IMPLICATIONS OF RJE-------------------To send an output ("printer") file to a user host, the RJE server willcause his FTP user process to send the file with the followingattributes*:*Note:  Making the obvious conversion fromRFC 385 toRFC 454terminology.Braden                                                          [Page 2]

RFC 448                    PRINT FILES IN FTP              February 1973 VFC Case      |     FORMat            |     STRUcture-------------------------------------------------------------------  N            |     Unformatted       |     Record structure               |     -                 |     -  T            |     Unformatted       |     File structure               |     -                 |     -  A            |     Print File        |     Record structure               |     -                 |     -Thus, the authors of RJE intended to use the _structure_ attribute toresolve Cases N and T.  This is perhaps a reasonable choice, but weshould understand the consequences and make them explicit within the FTPdocument.Assume for the moment that we want to maintain perfect consistencybetween FTP and RJE.  An FTP server which uses ASA VFC internally shouldconvert _every_ (Unformatted, Unstructured) file it receives to aninternal print file!  That is, the file must be mapped into a set ofphysical lines (which are really logical records internally), and an ASAVFC character must be appended to the beginning of each line before itis stored.  Note that this implies that the default file structure inFTP should be changed to _record_structure_.  (This reinforces the pointmade by Wayne Hathaway inRFC 414 that if a Tenex user transmits asource file to an IBM host and expects to manipulate it in some usefulway, he'd better send it with _record_ structure.)ANOTHER CHOICE--------------    If the loss of (unformatted, unstructured) as a simple default caseis too offensive, we can simply change FTP to include three formatscorresponding to Cases N, A, and T.  RJE would be changedcorrespondingly.ACKNOWLEDGMENTS---------------    Discussions with Steve Wolfe, Jon Postel, and Eric Harslem were veryhelpful in clarifying the print file problem in FTP.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 ]Braden                                                          [Page 3]