Dismiss
There will be a system update on Friday, May 5th, 6 PM ET. You may experience a brief service interruption.
Browse Prior Art Database

Print files in FTP (RFC0448)

IP.com Disclosure Number: IPCOM000003601D
Original Publication Date: 1973-Feb-27
Included in the Prior Art Database: 2000-Sep-13
Document File: 3 page(s) / 6K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

R.T. Braden: AUTHOR

Abstract

------------

This text was extracted from a ASCII Text document.
This is the abbreviated version, containing approximately 46% of the total text.

NETWORK WORKING GROUP R.T. Braden

REQUEST FOR COMMENT NO. 448 UCLA/CCN

NIC #13299 February 27, 1973

UPDATES: RFC 354, 385, 454

PRINT FILES IN FTP

INTRODUCTION

------------

Many of those who contributed to the definition of the FTP and RJE

protocols have expressed varying degrees of uncertainty or unhappiness

with the "print file" type in FTP. This RFC is intended to review the

problem of print files in preparation for the forthcoming FTP meeting.

Originally drafted on the basis of RFC 385, this RFC has been updated to

reflect the terminology of the latest FTP document 454. (Changing the

terminology doesn't solve the problem!)

It turns out that the Network RJE protocol as presently defined (see

NIC 12112) seems to force a particular interpretation of print files in

FTP and in fact, this interpretation is probably different from the one

assumed by most FTP implementors.

VERTICAL FORMAT CONTROL

-----------------------

What is a print file? Presumably it is a file which is intended to

be sent (eventually) to a printer process to create a hard copy. Many

operating systems (particularly those which are batch-processing

oriented) allow the programmer to include control codes within a file to

be printed, to control the vertical format of the printed page--for

example, 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 to

determine 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.

CASE A: Print File with ASA (Fortran) VFC

---------------------------------

The first character of each record is a VFC code; see RFC 454

for the codes.

Assuming there are to be print files in FTP, these _three_ cases

need to be considered. These three cases are explicitly included within

the RJE protocol as "transmission" modes; we have borrowed the RJE

labels N,T, and A from NIC #12112. The current FTP (RFC 454) seems to

provide only _two_ cases: _unformatted_ and _print_file_. It is unclear

from RFC 454 how these two FTP formats are related to the three VFC

cases. For example, it is unclear whether the FTP format is meant to be

a property of the file as transferred over the Network or of the file as

stored by the server.

As I understand it, the Tenex system supports only case T. The

distinction between Case N and Case T is not always clear, however. If

a Tenex file which contains only the CR LF combination of forma...