diff options
Diffstat (limited to 'doc/rfc/rfc385.txt')
| -rw-r--r-- | doc/rfc/rfc385.txt | 339 |
1 files changed, 339 insertions, 0 deletions
diff --git a/doc/rfc/rfc385.txt b/doc/rfc/rfc385.txt new file mode 100644 index 0000000..ab2059b --- /dev/null +++ b/doc/rfc/rfc385.txt @@ -0,0 +1,339 @@ + + + + + + +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. + + + + + + + [Page 1] + +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. + 2) It is usable with all data types. + + The disadvantages are: + 1) The EOF by closing the connection is not reliable. + + 2) The EOR by ASCII _CRLF_ is unreliable as the _CRLF_ + really may be valid data rather than an EOR. It is + an EOR only if the sender and receiver have a _prior_ + agreement to that effect. + + + + + [Page 2] + +NWG/RFC 385 Page 2 + + + 5. In the Block mode the protocol states that left-most bits not + containing information should be zero. It appears that some + sites have difficulty sending null bytes in the beginning of + a block. Since it is really not necessary for these bytes to + be zero, these bits are now defined to be "don't care" bits. + + 6. In the use of block mode it is possible for two or more + conditions requiring different descriptor codes (suspected + errors and either end of record or end of file) to exist + simultaneously. Such a possibility may be handled by sending + a separate EOR or EOF block with a zero byte count (this is + allowed by the protocol). Also it should be noted that an + EOF is an implicit EOR. + + 7. It needs to be emphasized again that the user-FTP must + "listen" on the data socket prior to sending a command + requiring a file transfer. Specifically the user-FTP should + not wait for a 255 reply (server data socket) before doing + the "listen". (The security check may be come later, as the + data connection can be closed if connection is to a socket + other than that specified by the 255 reply). Although the + protocol suggests that the 255 reply would be sent before + making the connection, it does not guarantee that the 255 + reply would arrive before the initiating RFC at the user + site. The above argument also applies to receiving a a close + (NCP-CLS) on the data connection before receiving a reply + indicating the reason for the close (note assertion on page + 24, paragraph 3, RFC 354). + + 8. Although the protocol does not restrict closing or leaving + open the data connection in Block and Text modes, it should + be emphasized that the closing of the data connection, if it + is to be done at all, should be done immediately after the + file transfer rather than just after a new transfer command + is received. This is because the server and user may have to + test whether the data connection is open or not before doing + a "listen" or an "init" respectively. + + 9. It should be emphasized again that 'Type' supersedes 'Byte', + and that the TYPE command should be sent before the BYTE + command. + + 10. It should be noted that both upper and lower case alphabetic + characters are to be treated identically in the command + syntax. This applies also to the symbols for type, mode, + and structure. For example, 'A' and 'a' both indicate ASCII + type. + + + + + [Page 3] + +NWG/RFC 385 Page 2 + + + 11. It should be noted that in the 'LIST' command, the data + transfer is over the data connection in type ASCII. + + 12. The following reply code is to be added: + + 454 FTP: Cannot connect to your data socket. + + This is a fail response any of the commands requiring data + transfer (including RETR, STOR, APPE, and LIST) + + 13. Rather than use the append command for sending mail files, a + new command 'MLFL' (for mail file) is defined. The syntax + of the mail file command is: + + MLFL <user>CRLF + where + <user> ::= <empty>| <NIC ident>| <sys ident> + + If the user field is empty or blank (one or more spaces), + then the mail is destined for a printer or other designated + place for site mail. <NIC ident> refers to the standard + identification described in the NIC Directory of Network + Participant. A serving host may keep a table mapping <NIC + ident> into <sys ident>. This would provide for uniform + convenient usage. <sys ident> is the user's normal + identification at the serving HOST. The use of <sys ident> + would allow a network user to send mail to other users who + do not have NIC identification but whose <sys ident> is + known. + + The intent of this command is to enable a user at the user + site to mail data (in form of a file) to another user at the + server site. It should be noted that the files to be mailed + are transmitted via the data connection in ASCII type. + These files should be appended to the destination user's + mail by the server in accordance with serving Host mail + conventions. The mail my be marked as sent from the + particular using HOST and the user specified by the 'USER' + command. The reply codes for the "MLFL" command are + identical to that in the "APPE" command, as shown below: + + COMMAND SUCCESS FAIL + ------- ------- ---- + MLFL 250 451,454,500-506 + Sec. reply 252 452,453 + + 14. The 'MLFL' command for network mail, though a useful and + essential addition to the FTP command repertoire, does not + + + + [Page 4] + +NWG/RFC 385 Page 2 + + + allow TIP users to send mail conveniently without using + third hosts. It would be more convenient for TIP users to + send mail over the TELNET connection instead of the data + connection as provided by the 'MLFL' command. The following + 'MAIL' command is therefore defined to send mail via the + TELNET connection: + + MAIL <user>CRLF + + the syntax of <user> is identical to that in the MLFL + command described above. After the 'MAIL' command is + received, the server is to treat the following lines as text + of the mail sent by the user. The mail text is to be + terminated by a line containing only a single period, that + is the character sequence ".CRLF" in a new line. The + following new reply codes are defined to handle the mail + command: + + 350 Enter mail, terminate by a line with only a '.' + 256 Mail completed. + + The reply codes are: + + COMMAND SUCCESS FAIL + ------- ------- ---- + MAIL 350 450,451,500-506 + Sec Reply 256 + + 15. An additional access control command called account (ACCT) + is now defined to facilitate accounting in systems such as + TENEX which require in addition to user and password, a + separate account specification. The 'ACCT' command is + different from the 'PASS' command in that it is not + necessarily related to the 'USER' command and may arrive at + any time. For example, a user may transfer different files + using different accounts. The 'ACCT' command has the same + reply codes as the 'PASS' command (230 for success and 430- + 432,500-506 for fail). Some servers may require that an + account command must be sent before the user is "logged in". + For suchcases the success reply to the 'PASS' command could + be '330 Enter account'. + + 16. Since password information is quite sensitive, it is + desirable in general to "mask" it or suppress type out. It + appears that the server has really no fool-proof effective + way to achieve this. It is therefore the user-FTP process + responsibility to hide the sensitive password information. + + + + + [Page 5] + +NWG/RFC 385 Page 2 + + + 17. The FTP is an open-ended protocol designed for easy + expandability. Experimental commands may be defined by + sites wishing to implement such commands. These + experimental commands should begin with the alphabetic + character 'X'. Standard reply codes may be used with these + commands. If new reply codes need to assigned, these + should be chosen between 900 and 999. If the experimental + command is useful and of general interest, it shall be + included in the FTP command repertoire. + + + + [ This RFC was put into machine readable form for entry ] + [ into the online RFC archives by BBN Corp. under the ] + [ direction of Alex McKenzie. 1/97 ] + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + [Page 6] + |