RFC 430 (rfc430) - Page 3 of 8

Comments on File Transfer Protocol

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