The Requested action is being initiated; expect another reply
before proceeding with a new command. (The user-process sending another
command before the completion reply would be in violation of protocol;
but server-FTP processes should queue any commands that arrive while a
preceding command is in progress.) This type of reply can be used to
indicate that the command was accepted and the user-process may now pay
attention to the data connections, for implementations where
simultaneous monitoring is difficult. The server-FTP process may send
at most, one 1xx reply per command.

The requested action has been successfully completed. A new
request may be initiated.

The command has been accepted, but the requested action is
being held in abeyance, pending receipt of further information. The
user should send another command specifying this information. This
reply is used in command sequence groups.

The command was not accepted and the requested action did not
take place, but the error condition is temporary and the action may be
requested again. The user should return to the beginning of the command
sequence, if any. It is difficult to assign a meaning to “transient”,
particularly when two distinct sites (Server- and User-processes) have
to agree on the interpretation. Each reply in the 4xx category might
have a slightly different time value, but the intent is that the
user-process is encouraged to try again. A rule of thumb in determining
if a reply fits into the 4xx or the 5xx (Permanent Negative) category
is that replies are 4xx if the commands can be repeated without any
change in command form or in properties of the User or Server (e.g.,
the command is spelled the same with the same arguments used; the user
does not change his file access or user name; the server does not put
up a new implementation.)

The command was not accepted and the requested action did not
take place. The User-process is discouraged from repeating the exact
request (in the same sequence). Even some “permanent” error conditions
can be corrected, so the human user may want to direct his User-process
to reinitiate the command sequence by direct action at some point in
the future (e.g., after the spelling has been changed, or the user has
altered his directory status.)

The RFC 2228
introduced the
concept of protected replies to increase security over the FTP
communications. The 6xx replies are Base64
encoded protected messages that serves as responses to secure commands.
When properly decoded, these replies fall into the above categories.

These replies refer to syntax errors, syntactically correct
commands that don’t fit any functional category, unimplemented or
superfluous commands.

These are replies to requests for information, such as status
or help.

Replies referring to the control and data connections.

Replies for the login process and accounting procedures.

These replies indicate the status of the Server file system
vis-a-vis the requested transfer or other file system action.