If the xferlog file doesn't exist, BetaFTPD will now try to create one. Thanks to...

[betaftpd] / doc / RFC-COMPLIANCE

diff --git a/doc/RFC-COMPLIANCE b/doc/RFC-COMPLIANCE
index 0884e597a82a496bcbf39ddc1d5ed8d5849d2802..35bac493332e0e7e17b16f825cd6e8fc18876bae 100644 (file)
--- a/doc/RFC-COMPLIANCE
+++ b/doc/RFC-COMPLIANCE
@@ -1,16 +1,13 @@
-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,
-ABOR, RNFR, RNTO, MKD, RMD, ALLO, REIN, ACCT, HELP and STAT.
+ABOR, RNFR, RNTO, MKD, RMD, ALLO, REIN, ACCT, HELP, STAT and MODE.
 
 These commands are not implemented at all: SMNT, STOU and SITE.
 
@@ -21,7 +18,10 @@ Telnet signals are ignored, to the best of my knowledge. BetaFTPD does not
 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
@@ -30,24 +30,16 @@ binary mode. RFC959 violation, but RFC1123 excuses the missing ASCII mode.
 RFC1123-compliant.)
 
 STRU:
-The STRU command is included, but it ignores its argument and always uses
-file structure (if you really need record structure, mail me; when I'm done
+The STRU command is included, but only file structure is supported (all other
+modes are refused; if you really need record structure, mail me; when I'm done
 laughing, I will consider implementing it). RFC959 violation, but RFC1123
 excuses the missing record structure.
 
-MODE:
-The MODE command is included, but it ignores its argument and always uses
-stream mode (the other two are never used anyway). RFC959 violation, it
-requires all other modes to be refused. 
-
-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 `-R') given to them. (This
-is much better than it was before, though.) The RFCs say nothing about
-directory listing formats anyway, but I guess this is a violation of GNU ls :-)
+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
+now.) The RFCs say nothing about directory listing formats anyway, but I guess
+this is a violation of GNU ls :-)
 
 REST:
 The REST command is implemented, but it doesn't check that its argument really