Revised FTP reply codes
RFC 640
Document | Type |
RFC - Unknown
(June 1974; Errata)
Updates RFC 542
|
|
---|---|---|---|
Authors | |||
Last updated | 2020-07-29 | ||
Stream | Legacy | ||
Formats | plain text html pdf htmlized with errata bibtex | ||
Stream | Legacy state | (None) | |
Consensus Boilerplate | Unknown | ||
RFC Editor Note | (None) | ||
IESG | IESG state | RFC 640 (Unknown) | |
Telechat date | |||
Responsible AD | (None) | ||
Send notices to | (None) |
NWG/RFC# 640 JBP NJN 5-JUN-74 16:07 30843 Revised FTP Reply Codes Jon Postel 19 JUN 75 Revised FTP Reply Codes 1 This document describes a revised set of reply codes for the File Transfer Protocol. 2 The aim of this revision is to satisfy the goal of using reply codes to enable the command issuing process to easily determine the outcome of each command. The user protocol interpreter should be able to determine the success or failure of a command by examining the first digit of the reply code. 3 An important change in the sequencing of commands and replies which may not be obvious in the following documents concerns the establishment of the data connection. 4 In the previous FTP specifications when an actual transfer command (STOR, RETR, APPE, LIST, NLIST, MLFL) was issued the preliminary reply was sent after the data connection was established. This presented a problem for some user protocol interpreters which had difficulty monitoring two connections asynchronously. 4a The current specification is that the preliminary reply to the actual transfer commands indicates that the file can be transferred and either the connection was previously established or an attempt is about to be made to establish the data connection. 4b This reply code revision is a modification of the protocol in described in RFC 542, that is to say that the protocol implementation associated with socket number 21 (decimal) is the protocol specified by the combination of RFC 542 and this RFC. 5 A note of thanks to those who contributed to this work: Ken Pogran, Mark Krilanovich, Wayne Hathway, and especially Nancy Neigus. 6 NWG/RFC# 640 JBP NJN 5-JUN-74 16:07 30843 Nancy Neigus Ken Pogran Jon Postel 19 JUN 75 A New Schema for FTP Reply Codes 7 Replies to File Transfer Protocol commands were devised to ensure the synchronization of requests and actions in the process of file transfer, and to guarantee that the user process always knows the state of the Server. Every command must generate at least one reply, although there may be more than one; in the latter case, the multiple replies must be easily distinguished. In addition, some commands occur in sequential groups, such as USER, PASS and ACCT, or RNFR and RNTO. The replies show the existence of an intermediate state if all preceding commands have been successful. A failure at any point in the sequence necessitates the repetition of the entire sequence from the beginning. 8 Details of the command-reply sequence will be made explicit in a state diagram. 8a An FTP reply consists of a three digit number (transmitted as three alphanumeric characters) followed by some text. The number is intended for use by automata to determine what state to enter next; the text is intended for the human user. It is intended that the three digits contain enough encoded information that the user-process (the User-PI described in RFC 542) will not need to examine the text and may either discard it or pass it on to the user, as appropriate. In particular, the text may be server-dependent, so there are likely to be varying texts for each reply code. 9 Formally, a reply is defined to contain the 3-digit code, followed by Space <SP>, followed by one line of text (where some maximum line length has been specified), and terminated by the TELNET end-of-line code. There will be cases, however, where the text is longer than a single line. In these cases the complete text must be bracketed so the User-process knows when it may stop reading the reply (i.e. stop processing input on the TELNET connection) and go do other things. This requires a special format on the first line to indicate that more than one line is coming, and another on the last line to designate it as the last.Show full document text