Ftp-WG: Re: comments on the MLST draft

Granted, a lot of that "implementor be aware" stuff is because the doc
started life as my notes to myself to remember to check things.

On SIZE and MDTM being optional: I don't think they add anything.  MLSx has
the info; newer implementations should use MLSx and forget SIZE and MDTM.
Older servers which don't have them shouldn't need to add them.  Making the
commands optional is a strong hint to client authors to switch to MLSx.

On the problem with MDTM: You're right, there's really no good workaround if
the server tries to change the time as in the example.

On whether SIZE should error if the current mode would require conversion:
To be honest, having supported the darned thing for years now, I'm just
plain tired of explaining to admins that the reason their server got shut
down was not an error in the server, but a consequence of them allowing such
large files to begin with.  I tried adding a sleep call occassionally, to
let other processes have a chance, and all that did was gather complaints
that it was taking WAY too long to get the size.  Can anyone come up with a
zero-growth cost means of determining the size?  The only solution I can
come up with is to marry something like MySQL and store such 'facts' there;
and I don't EVEN want to think about the problems keeping that synchronized
would cause.

I didn't look too closely at the facts for MLSx, but I assume the size fact
there is intended to be the actual, stored, size and not the on-the-fly
size.  If not, it'll suffer the same problems as SIZE.

To be BRUTALLY honest, I wish SIZE had never been added.  The "error on
conversion" solution is the only way I've come up with which maintains the
command as a cheap way to get the file's size without having to read through
LIST output, and stop the DoS complaints.

On why I recommend REST and not SIZE and MDTM: unlike SIZE and MDTM, REST
for streams actually adds something useful to the protocol.  I don't think
it's the panacea the users think it is, and personally dis-recommend its use
for most transfers.

On why I say REST can appear anywhere: What I was trying to describe was the
way existing clients misuse the command in an attempt to see if it _might_
work today.  Yes, 959 says it must be immediately followed with a transfer
command.  But clients send it at the top of the session, when they're doing
SYST and such, and it's typically a command or two away from the data
transfer.

On truncating the file to the STOR: You're right it does not matter that the
truncation occur before or after the STOR, but it must occur; and I don't
recall ever seeing it stated, though, that STOR following a REST truncates.

On letting REST exceed the size: Sure, on a lot of systems, all you get is a
huge file.  But on others you get memory-image garbage.  And on others you
get whatever was recorded on that area of the drive.

Allowing the creation of holes is much the same as allowing a short-length
STOR which does not truncate.  With REST we have given the users lseek().
They already have read() and write().  Suddenly we have a random-access file
system implemented over FTP.

As to whether implementor advice should be part of an RFC; security starts
with design.  On of the most common complaints about the FTP is it's total
lack of regard for security.  Much of that owes to the protocol's desire to
make it easy to share files.  But a lot of it comes from the fact that the
common refrain is "Security issues are not discused in this memo."  The
intention of adding that section to the RFCs was to encourage authors to
consider and discuss security issues.  To date, it's main purpose, though,
has been for the author to admit that, if he did the considering, he didn't
do the discussing.

On the stuff you're leaving for later: in the Security section, I suggest
saying something like some of the issues have been corrected in the memo and
others may be handled by implementation and configuration choices.  If you
don't remove the DoS caused by SIZE (and the size fact, if it's the same
there) you should read that as saying "none of the issues reported have been
corrected, although some may be handled by implementation or configuration
choices."