|
RFC 959 File Transfer Protocol
3.1.1.2. EBCDIC TYPE
This type is intended for
efficient transfer between hosts which use EBCDIC for their internal
character representation.
For transmission, the
data are represented as 8-bit EBCDIC characters. The character code is
the only difference
between the functional specifications of EBCDIC and
ASCII types.
End-of-line (as opposed to end-of-record--see the discussion
of structure) will probably be rarely used with EBCDIC type for purposes
of denoting structure, but where it is necessary the <NL> character should
be used.
3.1.1.3. IMAGE TYPE
The data are sent as
contiguous bits which, for transfer, are packed into the 8-bit transfer
bytes. The receiving site must store the data as contiguous bits. The
structure of the storage system might
necessitate the padding of the file (or of each record, for a
record-structured file) to some convenient boundary (byte, word or
block). This padding, which must be all zeros, may occur only at the end
of the file (or at the end of each record) and there must be a way of
identifying the padding bits so that they may be stripped off if the file
is retrieved. The padding transformation should be well publicized to
enable a user to process a file at the storage site.
Image type is intended for the efficient storage and retrieval
of files and for the transfer of binary data. It is
recommended that this type be accepted by all FTP implementations.
3.1.1.4. LOCAL TYPE
The data is transferred
in logical bytes of the size specified by the obligatory second parameter,
Byte size.
The value of Byte size must be a decimal integer; there is no
default value. The logical byte size is not necessarily
the same as the transfer byte size. If there is a difference
in byte sizes, then the logical bytes should be packed contiguously,
disregarding transfer byte boundaries and with any necessary padding at
the end.
RFC 959 File Transfer Protocol
When the data reaches the receiving host, it will be transformed in a
manner dependent on the logical byte size
and the
particular host. This transformation must be invertible (i.e., an
identical file can be retrieved if thesame parameters are used) and should
be well publicized bythe FTP implementors.
For example, a user sending 36-bit floating-point numbers to a host with a
32-bit word could send that data as Local byte with a logical byte size of
36. The receiving host would then be expected to store the logical bytes
so that they could be easily manipulated; in this example putting the
36-bit logical bytes into 64-bit double words should suffice.
In another example, a pair of hosts with a 36-bit word size may send data
to one another in words by using TYPE L 36.
The data
would be sent in the 8-bit transmission bytes packed so that 9
transmission bytes carried two host words.
3.1.1.5. FORMAT CONTROL
The types ASCII and EBCDIC also take a second (optional) parameter; this
is to indicate what kind of vertical format
control, if
any, is associated with a file. The following data representation types
are defined in FTP:
A character file may be transferred to a host for one of three purposes:
for printing, for storage and later retrieval, or for
processing. If a file is sent for printing, the receiving host must know
how the vertical format control is represented. In the second case, it
must be possible to store a file at a host and then retrieve it later in
exactly the same form. Finally, it should be possible to move a file from
one host to another and process the file at the second host without undue
trouble. A single ASCII or EBCDIC format does not satisfy all these
conditions. Therefore, these types have a second parameter specifying one
of the following three formats:
3.1.1.5.1. NON PRINT
This is the default format to be used if the second (format) parameter is
omitted. Non-print format must be accepted by all FTP implementations.
RFC 959 File Transfer Protocol
The file need contain no vertical format
information. If it is passed to a printer process, this process
may assume standard values for spacing and margins.
Normally,
this format will be used with files destined for processing or just
storage.
3.1.1.5.2. TELNET FORMAT CONTROLS
The file contains ASCII/EBCDIC vertical format controls (i.e., <CR>,
<LF>, <NL>, <VT>, <FF>) which the printer process will interpret
appropriately. <CRLF>, in exactly this sequence, also denotes
end-of-line.
3.1.1.5.2. CARRIAGE CONTROL (ASA)
The file contains ASA (FORTRAN) vertical format control characters. (See
RFC 740 Appendix C; and Communications of the ACM, Vol. 7, No. 10, p. 606,
October 1964.) In a line or a record formatted according to the ASA
Standard, the first character is not to be printed. Instead, it should be
used to determine the vertical movement of the paper which
should take place before the rest of the record
is printed.
The ASA Standard specifies the following control characters:
Character Vertical Spacing
blank Move paper up one line
0 Move paper up two lines
1 Move paper to top of next page
+ No movement, i.e., overprint
Clearly
there must be some way for a printer process to distinguish the end of the
structural entity. If a file
has record
structure (see below) this is no problem; records will be explicitly
marked during transfer and
storage.
If the file has no record structure, the <CRLF> end-of-line sequence is
used to separate printing lines,
but these
format effectors are overridden by the ASA controls.
RFC 959 File Transfer Protocol
3.1.2. DATA STRUCTURES
In addition to
different representation types, FTP allows the structure of a file to be
specified. Three file structures are
defined in
FTP: file-structure, where there is no internal structure and the
file is considered to be a continuous sequence of data bytes,
record-structure, where the file is made up of sequential records, and
page-structure, where the file is made up of independent indexed pages.
File-structure is the default to be assumed if the STRUcture command has
not been used but both file and record structures must be accepted for
"text" files (i.e., files with TYPE ASCII or EBCDIC) by all FTP
implementations. The structure of a file will affect both the transfer
mode of a file (see the Section on Transmission Modes) and the
interpretation and storage of the file.
The "natural" structure of a file will depend on which host stores the
file. A source-code file will usually be stored on
an IBM Mainframe
in fixed length records but on a DEC TOPS-20 as a stream of characters
partitioned into lines, for example by <CRLF>. If the transfer of files
between such disparate sites is to be useful, there must be some way for
one site to recognize the other's assumptions
about the file.
With some sites being naturally file-oriented and others naturally
record-oriented there may be problems if a file with
one structure is
sent to a host oriented to the other. If a text file is sent with
record-structure to a host which is file
oriented, then
that host should apply an internal transformation to the file based on the
record structure.
Obviously, this
transformation should be useful, but it must also be invertible so that an
identical file may be retrieved
using record
structure.
In the case of a file being sent with file-structure to a record-oriented
host, there exists the question of what
criteria the
host should use to divide the file into records which can be processed
locally. If this division is necessary,
the FTP
implementation should use the end-of-line sequence.
|
