NWG/RFC 385                                       Abhay K. Bhushan
NIC 11357                                                  MIT-MAC
Updates: RFC 354                                  August 18, 1972
RFC 354

            COMMENTS ON THE FILE TRANSFER PROTOCOL (RFC 354)
            ------------------------------------------------

   The following comments pertain to the File Transfer Protocol, NWG/RFC
   354.  The comments include errata, further discussion, emphasis
   points, and additions to the protocol.  I shall incorporate these
   comments into the main protocol document after we have had sufficient
   experience.

   1. Please note the following corrections:
       (i)    Page 2, line 15:  replace user-FTP by server-FTP.
       (ii)   Page 3, line 12:  replace III.A by III.C.
       (iii)  Page 15, last para, line 1:  replace user s by user is.
       (iv)   Page 28, line 21:  replace _CRCRLF_ by _CRLF_.
       (v)    Page 27, line 10:  replace 451,451 by 451.
       (vi)   Note that on Page 26, line 15 mode code is S|B|T|H.

   2. The language of RFC 354 reads that it is recommended for
      hosts to implement the default parameters.  The sense of the
      word recommended should be taken as required.  Thus the
      required minimum implementations for FTP servers is:

           Type - ASCII (8-bit bytes)
           Mode - Stream
           Structure - File
           Commands - RETR, STOR, USER (and PASS), SOCK and BYE

   3. The "Print File-ASCII" and "EBCIDIC Print File" types are
      incorrectly specified (pages 10 and 11, RFC 354).  The real
      problem with print files is of ASA (Fortran) vertical format
      control.  Instead of the two print file types, there should
      really be three types as described below:

           BCDIC - The sender transfers data using the EBCDIC
                    character code and 8-bit transfer byte size.
                    The _CRLF_ convention is used for vertical format
                    control.  This type will be used for efficient
                    transfer of EBCDIC files between systems which
                    use EBCDIC for their internal character
                    representation.







 
NWG/RFC 385 Page 2


           ASCII with ASA vertical format Control - This is the
                    "Print file-ASCII" defined in RFC 354.  The
                    server is to transform the data in accordance
                    with ASA (Fortran) vertical format control
                    procedures for printing on printers that
                    still use this standard.  The data is to be
                    transferred as 8-bit bytes.

           EBCDIC with ASA vertical format control - This is the
                    EBCDIC Print File defined in RFC 354.  The
                    server is to transform the data in accordance
                    with ASA (Fortran) vertical format control
                    standards but using the EBCDIC character code.
                    The data is to be transferred in 8-bit bytes.

      The new types are to be denoted by symbols E for EBCDIC, P
      for Print file-ASCII and F for Formatted (ASA standard)
      EBCDIC print file.  A discussion of the ASA vertical format
      control appears in NWG/RFC 189, Appendix C, and in
      Communications of the ACM, Vol 7, No. 10, p. 606, October
      1964.  According to the ASA vertical format control
      standards, the first character of a formatted record is not
      printed but determines vertical spacing as follows:

           Character    Vertical Spacing before printing
           ---------    --------------------------------
            Blank          One line
              0            Two lines
              1            To first line of next page
              +            No advance

      In addition to the above four, there are more characters
      (defined in Appendix C, RFC 189) which represent an IBM
      extension to the ASA standard.

   4. A comparison of "stream" and "text" modes is in order.  The
      advantages of "stream" mode are:
           1) The receiver need not scan the incoming bytes.