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
