-BetaFTPD does not fully meet the RFC959 minimum requirements for an FTP
-server. However, for all practical uses, it should be considered a legal
-implementation of the FTP protocol, and very close to being fully compliant
-with RFC959.
+BetaFTPD is now becoming more and more mature, with almost full RFC compliance.
+The few small things that it lacks (see below) are simply not a problem, so for
+all practical uses, BetaFTPD should be considered RFC959- and RFC1123-
+compliant.
-BetaFTPD is not RFC1123 compliant, but now that renaming is in place, the
-only thing that is left (I think) before it is, would be refusing Telnet
-commands. I'm not sure if I will ever do this -- I simply don't see that
-this could be a problem in today's FTP world.
+---
These commands are believed to be fully compliant with RFC959 and RFC1123:
PORT, PASV, USER, PASS, CWD, CDUP, QUIT, DELE, PWD, SYST, NOOP, STOR, APPE,
speak Telnet, although RFC959 seems to require it. Note that you can still
use Telnet to connect to the FTP port (to do a manual debugging session,
e.a.) and speak raw FTP, but BetaFTPD does not follow _all_ the rules about,
-say, Telnet IP and Synch signals.
+say, Telnet IP and Synch signals, and it doesn't refuse Telnet commands,
+like RFC1123 requires. The reason for this is that I don't see how this
+could be a problem in today's FTP world, and an implementation of this would
+thus be considered as plure bloat.
TYPE:
The TYPE command is included, but it ignores its argument and always uses
laughing, I will consider implementing it). RFC959 violation, but RFC1123
excuses the missing record structure.
-RETR:
-The RETR command is believed to be compliant with RFC959. (There is no default
-data port, though -- I'm unsure about this.)
-
LIST/NLST:
The LIST and NLST commands ignore some flags (like `-1') given to them. (This
is much better than it was before, though, even recursive listings should work