"TYPE L m" is sometimes specified to the FTP programs
on two m-bit word machines to ensure the correct
transfer of a native-mode binary file from one machine
to the other. However, this command should have the
same effect on these machines as "TYPE I".
RFC1123 FILE TRANSFER -- FTP October 1989
4.1.2.2 Telnet Format Control: RFC-959 Section 3.1.1.5.2
A host that makes no distinction between TYPE N and TYPE T
SHOULD implement TYPE T to be identical to TYPE N.
DISCUSSION:
This provision should ease interoperation with hosts
that do make this distinction.
Many hosts represent text files internally as strings
of ASCII characters, using the embedded ASCII format
effector characters (LF, BS, FF, ...) to control the
format when a file is printed. For such hosts, there
is no distinction between "print" files and other
files. However, systems that use record structured
files typically need a special format for printable
files (e.g., ASA carriage control). For the latter
hosts, FTP allows a choice of TYPE N or TYPE T.
4.1.2.3 Page Structure: RFC-959 Section 3.1.2.3 and Appendix I
Implementation of page structure is NOT RECOMMENDED in
general. However, if a host system does need to implement
FTP for "random access" or "holey" files, it MUST use the
defined page structure format rather than define a new
private FTP format.
4.1.2.4 Data Structure Transformations: RFC-959 Section 3.1.2
An FTP transformation between record-structure and file-
structure SHOULD be invertible, to the extent possible while
making the result useful on the target host.
DISCUSSION:
RFC-959 required strict invertibility between record-
structure and file-structure, but in practice,
efficiency and convenience often preclude it.
Therefore, the requirement is being relaxed. There are
two different objectives for transferring a file:
processing it on the target host, or just storage. For
storage, strict invertibility is important. For
processing, the file created on the target host needs
to be in the format expected by application programs on
that host.
As an example of the conflict, imagine a record-
oriented operating system that requires some data files
to have exactly 80 bytes in each record. While STORing
RFC1123 FILE TRANSFER -- FTP October 1989
a file on such a host, an FTP Server must be able to
pad each line or record to 80 bytes; a later retrieval
of such a file cannot be strictly invertible.
4.1.2.5 Data Connection Management: RFC-959 Section 3.3
A User-FTP that uses STREAM mode SHOULD send a PORT command
to assign a non-default data port before each transfer
command is issued.
DISCUSSION:
This is required because of the long delay after a TCP
connection is closed until its socket pair can be
reused, to allow multiple transfers during a single FTP
session. Sending a port command can avoided if a
transfer mode other than stream is used, by leaving the
data transfer connection open between transfers.
4.1.2.6 PASV Command: RFC-959 Section 4.1.2
A server-FTP MUST implement the PASV command.
If multiple third-party transfers are to be executed during
the same session, a new PASV command MUST be issued before
=18= |