RFC 430 (rfc430) - Page 3 of 8
Comments on File Transfer Protocol
Alternative Format: Original Text Document
RFC 430 COMMENTS ON FILE TRANSFER PROTOCOL FEBRUARY 1973
B. FTP Parameter Encoding
RFC 448, which discusses print files, points out that the print file
attribute is logically independent of the character code attribute
(ASCII vs. EBCDIC) in the type dimension; the set of allowable types
in FTP is the outer product of the individual attributes. Thus FTP
has (at least) four character types, summarized by the following two
x two matrix:
| ASCII | EBCDIC
---------------+---------+------------
Not Print File | |
---------------+---------+------------
Print File | |
---------------+---------+------------
I propose that the encoding in the TYPE command model this
interdependence of the types. Instead of using a distinct single
ASCII character for each type, we should use multiple ASCII
characters---qualifiers, if you wish. For example:
A represents ASCII code
E represents EBCDIC code
P represents print file
I represents image
L represents local byte
Then the legal types according to RFC 385 would be:
A
AP
E
EP
I
L
Note that the attributes under consideration here are type-like; they
are not (logically) concerned with the structure or the transmission
mode, only the internal encoding of the file.
At present, this would be a trivial change. However, I foresee the
file transfer protocol expanding significantly over the next several
years as new types are added. Some servers will want to add server-
specific type variations, and the NWG will want to add some. How
about an APL character set? Or the multiple-overlay 256 character
ASCII which has been proposed? Multiple qualifiers (and later
perhaps more structure) in the type seems to be the cleanest escape
mechanism for future growth.
Braden